[ajs]

The issue was with the C programming MZX is written in, and had nothing to do with MZX games themselves. In C, the "stack" is a place storage can be allocated for variables. If a program writes beyond the end of the storage allocated to it, it can overwrite other storage or, perhaps worse, a function's return address. This, known as a "buffer overflow", has security implications or may simply cause crashes.

Normally, such bogus writes remain undetected, and if they are slight (e.g. a single byte) may not adversely affect program execution. This was the case here. However, Ubuntu Linux has something known as SSP[1] enabled by default in its compiler. This functionality detected a buffer overflow in MegaZeux, but instead of ignoring it, forcibly terminated the application.

It was necessary for me to locate the source of the "stack smashing" and fix the code. This required me to release an updated version of 2.81h for Ubuntu Linux users.

[1] http://en.wikipedia....hing_protection

--ajs.

[Old-Sckool]

huh, I thought that player cloning glitch with swap worlds was going to be fixed...
I can't seem to rebuild it, so maybe this will help
http://www.yourfilehost.com/media.php?cat=other&file=BKZ.mzx

[ajs]

Not sure what causes it, but that world helps me reproduce the problem. I doubt I'll fix this bug before the DoZ (and it's not a priority or a regression anyway). Thanks for the report.

--ajs.

[Quantum P.]

From a PM:

Terryn said:

Hi. If you can find the time to do so, could you make an OSX binary of MZX 2.81h and post it on DMZX? Thanks.

Sorry -- I've been rather busy lately, and I've been putting off doing a lot of things I should probably get around to doing while I'm on break.

I can't remember exactly what happened the last time I tried to build MegaZeux. I think I was having trouble building some of the dependencies (libvorbis and I think SDL) using the Xcode tools on Leopard. I'll have another look at it soon. Worst case scenario, I can just copy the frameworks from the last OS X build.

[ajs]

For impatient OS X users, it is possible to build MZX from source without (much of) Xcode on that platform. You must first install gcc/make (from xcode, about 200MB installed). Then I recommend grabbing fink and switching to the "unstable" branch. Install the libsdl-dev, libogg-dev, libvorbis-dev packages (and libpng12-dev if you want PNG screenshots) and then follow the build instructions given in my original post.

The architecture is "darwin" and --prefix must be provided as "/sw" (fink's default install directory). This is how I test building MZX on OS X (I do not have the required disk space for Xcode). It will generate an unbranded UNIX application which is machine specific, so it is simply not as good as an Xcode build. I confirmed this works correctly on Leopard (10.5).

--ajs.

[Quantum P.]

Apologies for the delay! Let me know if this build works:

Megazeux 2.81h for OS X
Xcode project files


The problem with libvorbis was the result of me using a case-sensitive filesystem. When building libogg and libvorbis using the Xcode tools, you get Ogg.framework and Vorbis.framework, respectively. However, when libvorbis includes a header file from libogg, it does so like this:

#include "ogg/whatever.h"

This is actually asking for whatever.h in ogg.framework -- which, of course, does not exist. The quick fix:

sudo ln -s /Library/Frameworks/Ogg.framework /Library/Frameworks/ogg.framework

I did this for Vorbis.framework too. SDL.framework and libpng.framework were already correctly capitalized, and they worked just fine.

[ajs]

Doesn't work here, "image" is missing from the package:

Dyld Error Message:
  Library not loaded: /Users/chris/Library/Frameworks/libpng.framework/Versions/1.2.8/libpng
  Referenced from: /Applications/Megazeux.app/Contents/MacOS/Megazeux
  Reason: image not found

Also, if it's not too much hassle, could you correct the capitalisation? Megazeux -> MegaZeux.

--ajs.

[jjsonick]

Quantum P., on Dec 28 2007, 12:08 AM, said:

Apologies for the delay! Let me know if this build works:

Megazeux 2.81h for OS X
Xcode project files

Didn't work for me, either, unfortunately. No error message -- when clicked the app almost appears in the dock, but then immediately dies (this is on OS X 10.4.11 / Intel MacBook Pro).

[Quantum P.]

Irony of ironies! I corrected my own capitalization error, and I believe I fixed the problem that caused it to fail on Macs other than my own:

New MegaZeux 2.81h build
Updated Xcode project files

[ajs]

Both issues seem fixed. I tried to test PNG screenshots, but I noticed F12 is taken over by Dashboard and MZX never receives the key-press. F11 (for debugging counters/strings) also doesn't work.

I wonder if there's some way we can tell SDL to grab the keyboard from OS X?

Otherwise, this is a great build.

--ajs.

[jjsonick]

Yes, it's now working great for me, too, with the function key caveats ajs mentioned.

Thanks, Quantum!

[Quantum P.]

Screenshots work if you don't have any shortcuts defined for F12 (shortcuts can be managed from System Preferences, Keyboard & Mouse).

Keyboard input is an interesting problem. On one hand, we want application shortcuts to respond like they do with every other Mac app. A couple of people have complained that Command-H doesn't hide the application, and Command-Q doesn't quit (although clicking on the menu items will hide the application and produce the equivalent of hitting the escape key, respectively). On the other hand, we probably want to override the system-wide shortcuts for keys that we use, like the function keys.

Are there any keyboard input problems like this on other platforms?

[ajs]

There's also SDL_WM_GrabInput[1] which might fix it here, but I'm reluctant to jump on that band wagon because users would want a way to leave the grab mode. On a lot of software (like VMWare and QEMU) this is achieved with ctrl+alt.

MegaZeux however does not have a central input handler, and spreads handlers across the code base depending on whether you are playing a game, in the editor, in the robot editor. Though it would be possible to patch in this functionality into all call-sites, it's not very tidy. (Basically, SDL_WM_GrabInput should be set to SDL_GRAB_ON if you click in the window, and SDL_GRAB_OFF if you press ctrl+alt.)

Another bug I just noticed with the OS X SDL (possibly an OS X policy issue) is that fullscreen no longer works. I'm pretty sure it did used to work in Tiger (?) and would at least provide a workaround for the issue (we could just SDL_GRAB_ON when fullscreened and SDL_GRAB_OFF when windowed).

Thoughts?

[1] http://www.libsdl.or...fWM_5fGrabInput

--ajs.

[Quantum P.]

2.81g, Tiger: Fullscreen works
2.81g, Leopard: Fullscreen works
2.81h, Tiger: ??? (jjsonick, can you test this?)
2.81h, Leopard: Fullscreen is broken

I was going to say I liked your idea of having fullscreen mode capture all keyboard input, but from testing 2.81g, it looks like this is already the case on OS X. I turned on keyboard shortcuts that used F11 and F12, went into fullscreen mode, and was able to bring up the debug panel and take screenshots. How does fullscreen work on other platforms -- does anything happen when you hit the Windows key, alt-tab, etc?

I don't know how well ctrl+alt would work -- ctrl+alt feels too much like using an emulator (petty complaint, I know), and fullscreen is triggered by ctrl+alt+enter (conflict? you'd have to steal back focus when toggling fullscreen). It just seems like, if F11 and F12 cause problems on OS X, it would be easier to just change one's own settings if only a few people complain, or maybe offer alternate shortcuts if almost everyone uses F11/F12 to view desktop/Dashboard (perhaps F11/F12 plus a modifier key?). The reason emulators have a capture-all-input mode is because they have to assume that every key combination could mean something to the virtual machine -- whereas most other applications make no such assumptions and get along just fine.

[ajs]

On Windows, full screen traps everything except alt-tab, ctrl-escape, win+?? and ctrl-alt-delete, and it's possible to mask these too.

I agree that it would be better to fix fullscreen in OS X's 2.81h (must be the SDL Framework, we didn't change any of that code to my knowledge) and forget about fixing window mode. Consistent with other platforms too.

EDIT: Discovered the problem. We think SDL 1.2.12 might have broken changing resolution on some platforms. Terryn is having problems on Windows, and I've just verified that if I set fullscreen_resolution to 1280,800 on my Macbook first generation fullscreen works fine.

If you want a "quick fix" I recommend rebuilding with 1.2.11, otherwise I'll try to magic up some kind of workaround.. really irritating..

EDIT #2: Okay the Windows problems are something else (windib versus DirectX again) so no need to panic there. Just OS X is broken.

--ajs.

[Quantum P.]

I compiled MegaZeux with both versions of SDL.framework -- the latest one they distribute (pre-built), and one I stole from the build of 2.81g. No effect.

I then debugged both 2.81g and 2.81h, taking note of the parameters being passed to SDL_VideoModeOK (the function used to determine if a certain screen mode is possible). The difference was that 2.81g had height=480, while 2.81h had height=400. Since the two config.txt files were exactly the same, I checked the code that parses the file, and found the following in 2.81g:

  { "force_bpp", config_force_bpp },
  { "fullscreen_resolution", config_set_resolution },
  { "force_resolution", config_set_resolution }, /* backwards compatibility */
  { "fullscreen", config_set_fullscreen },
  { "gl_filter_method", config_set_gl_filter_method },

Everything is in alphabetical order except for fullscreen_resolution, and configure.c uses binary search. So 2.81g pretty much ignored anything config.txt had to say about fullscreen_resolution, leaving it at the default resolution of 640,480 -- which works in OS X.

In 2.81h, this bug was fixed. As a result, 2.81h actually uses the resolution specified in config.txt (640,400) -- which does not work!

So, how to fix: control-click on MegaZeux.app, click "Show Package Contents", and navigate to Contents/Resources/config.txt. Open it in Textedit and change "fullscreen_resolution = 640,400" to "fullscreen_resolution = 640,480". I'll update the files tomorrow -- right now, I need to get some sleep.

[Why-Fi]

mzxgiant, on Dec 14 2007, 06:23 PM, said:

As ajs pointed out in the post above yours, Why-Fi, you can run

apt-get remove --purge megazeux

to remove the older version. Don't forget to update the apt repository before trying to install again!

Ooops... forgot to update the apt repository... What will happen to me?

[ajs]

You'll turn purple and explode.

--ajs.

[Quantum P.]

I just updated the binary and project files. The Xcode project now uses a customized version of config.txt in which 640,480 is the default fullscreen_resolution. In addition, I fixed a very minor cosmetic bug -- when MegaZeux starts up, the world selection dialog flashes gibberish where the filename should be.

diff of game.c:

--- Downloads/mzx281h/src/game.c        2007-12-08 16:06:37.000000000 -0800
+++ Desktop/mzx281h/src/game.c  2007-12-29 21:43:57.000000000 -0800
@@ -154,6 +154,7 @@
 static void load_world_selection(World *mzx_world)
 {
   char world_name[512];
+  world_name[0] = '\0';
 
   m_show();
   if(!choose_file_ch(mzx_world, world_ext,

[ajs]

Nice, I fixed this in SVN already but I wondered if anybody else would notice. There's a couple other places where uninitialized memory is used, which I have valgrind to thank for catching.

I'll probably set the default to 640x480 anyway, any higher resolution isn't really valuable, and is in fact very bad for the software render mode (you get chunky borders).

--ajs.