[Spanner]

Testing Sonic The Hedgehog: Harder Levels v1.0 on Ubuntu 10.04 beta 1 (Linux). Looks good n stable

The only bad thing there is the Ubuntu button placement.

[Corner-Face-Jacks]

Yeah Mark Shuttleworth says he wants to put a feature on the right side bar at release time.

[sonicblur]

Some fixes were needed for this to build on Mac OS X Snow Leopard.

First of all, the 64-bit thing that you're already aware of that was solved by the m32 flags.

cpuflags.c in gens_core/misc
check_os_level_sse is failing to compile because it doesn't know what sighandler_t is for some reason. I just made this return true since we know all Intel Macs have SSE. There's probably a correct way to fix this.

gens_menu_callbacks.cpp
Line 843
Move #endif below the case IDM_HELP_REPORTABUG, because IDM_HELP_REPORTABUG isn't defined on OS X per your #ifdef in another file.

scalebit_4x.c
Line 48
Change #include <malloc.h> to #include <malloc/malloc.h>

scalebit_4x_mmx.c
Line 40
Change #include <malloc.h> to #include <malloc/malloc.h>


With that, the build completed successfully. Doesn't run though, appears crash inside of SDL while trying to create a window. Error (1002) creating CGSWindow

Edit: It looks like the SDL problem is common. SDL applications need to be started from SDL_Main on OS X because otherwise it doesn't get a chance to initialize some of the Cocoa stuff. The other option is to have a main declared in Objective C. I wonder why I never ran into this problem in m5.1? I guess I'll work on a separate main class, unless you have other ideas.

Edit 2: Success!


In g_main_unix.cpp, add
#ifdef GENS_OS_MACOSX
#include <dlfcn.h>
#endif
to the includes section

And
#ifdef GENS_OS_MACOSX
void* cocoa_lib;
cocoa_lib = dlopen( "/System/Library/Frameworks/Cocoa.framework/Cocoa", RTLD_LAZY );
void (*nsappload)(void);
nsappload = (void(*)()) dlsym( cocoa_lib, "NSApplicationLoad");
nsappload();
#endif
Somewhere near the beginning of main. I put it right after the end of the first if block. This is probably a very bad solution though, because it spews memory leak warnings to the console every time it draws a frame. Memory use doesn't appear to rise as you play though.

Edit 3: The reason I never ran into this before was because I was using the native quartz port of GTK, instead of the X11 version. I was having some problems with recent versions of Quartz GTK sucking, which is why I switched to X11. In other words, if you manage to build with Quartz GTK, this problem won't exist. (On port, the command is 'port install gtk2 +quartz +no_x11')

This post has been edited by sonicblur: 14 August 2010 - 11:58 AM