ZSNES for Intel Mac ready for consumption!

General area for talk about ZSNES. The best place to ask for related questions as well as troubleshooting.

Moderator: ZSNES Mods

Locked
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

Nach wrote:BRPXQZME:
Make sure you see http://board.zsnes.com/phpBB2/viewtopic ... 1&start=75
Okay. libao works with two minor problems: the only supported rate under OS X is 44100Hz, and has bizarre problems when deinitializing (ranging from ZSNES just hanging to inane statements such as "ao_macosx_close: AudioDeviceRemoveIOProc returned 1970171760"). Sounds like bugs in libao, but I didn't look into it too hard. Other than that, it works excellent!
Deathlike2 wrote:BRPXQZME:

Does the NTSC filter version 2 work for you now?
Like a champ. I didn't test it thoroughly enough to say it with 100% confidence, but I daresay it's working perfectly.
pagefault wrote:Send me a mac mini.
Working on it, but it's kind of hard since I'm still looking for a job....
Only a couple screws loose.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Not to be a nuisance, but mind posting a compiled binary? The last working one posted was a WIP for 1.43, which is pretty old.

I can't say I've been successful trying to compile it from source myself following the linux/sdl instructions.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

IIRC, you would still need some of the libs installed on your system so the binary would work.

Read this to compile from source: http://board.zsnes.com/phpBB2/viewtopic.php?t=7371
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Well, I just went ahead and attempted to compile it again. But I'm having issues getting it to recognize/find zlib, (sdl aswell, but I just bypassed it by disabling sdltest).

zlib is installed correctly... and it is the required version 1.2.3.

checking for zlib - version >= 1.2.3... no
configure: error: zlib >= 1.2.3 is required
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

I'll post a binary someday, I promise!
... yeah, okay, my word doesn't mean jack when it comes to delivering products. I'm used to it, you should be used to it, too :wink:

Here's what you should try, because it's What I Do and Therefore The Right Way (because I am ALWAYS RIGHT!! HA!!):

Use fink or darwinports to install SDL. (I work with fink unstable because I like it better, but I can't think of a single darn reason why DP wouldn't work if you prefer not to waste space on having both; I know there must be some DP fan or other reading this, right?). This isn't necessary if you can make your own, but durn burn it if I like keeping track of these things. That's why I use package managers, or else I'd compile my linux box from scratch instead of using a riced-up Gentoo install.
Use same to install autoconf and automake (I don't know what version of automake to use, but I currently have 1.8 at the moment).

I think that may solve your problem, but I'm not willing to do the experimentation to find out (my setup is working fine enough, of course, and I'd hate to break it!).
Only a couple screws loose.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

I did use Fink to get SDL... I also just now took your recommendation to install autoconf/automake via Fink -- which I did just now. No changes, whatsoever.

It still fails to recognize SDL (so I went ahead and set --disable-sdltest again), and then it continues to fail to see that I have zlib aswell.

checking for zlib - version >= 1.2.3... no
configure: error: zlib >= 1.2.3 is required
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

It almost sounds like you installed the libs in the wrong folders, but that's just my guess.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Well, I'm using the default paths set by Fink ...

Going by what BRP said, he used Fink aswell -- so that shouldn't be a problem?

Here are the paths set by Fink:

/sw/bin:/sw/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
bobablob
New Member
Posts: 8
Joined: Tue Jan 02, 2007 11:49 pm

Post by bobablob »

As an FYI: OpenGL doesn't work on my Macbook Pro with ATI Radeon 1600x.

I know you are aware that the problem exists, but someone requested feedback on which cards were effected.
polyh3dron
Rookie
Posts: 11
Joined: Mon Jun 19, 2006 10:05 am

Post by polyh3dron »

Does anyone have a current Mac ZSNES binary they can post?
Krade
Rookie
Posts: 31
Joined: Mon Feb 19, 2007 11:23 am

Post by Krade »

Gah, compiling is not as straightforward as in Linux (it never is, is it?).

I tried Hector's Xcode project + latest SVN revision, but Xcode breaks right in the beginning when linking parsegen with an "Undefined symbols: _crc32" Well, it gave out another error, but I have no idea what it means: "JamToolExecution parsegen (1 error) Command /Developer/Private/jam failed with exit code 1" (I hate Xcode).

Compiling the old fashioned way breaks with tons of "error: binary output format does not support external references" for about every single asm file. And no, it doesn't matter if I use the Apple supplied NASM or a MacPorts compiled one. I was able to solve this particular problem, I just edited the make file to add the "-f macho" flag In fact, I had to ditch the MacPorts one completely, because Apple's NASM is the only one that supports Mach-o as a output format.

It finally broke again at gui.asm with this:

Code: Select all

nasm -f macho -o gui/gui.o gui/gui.asm
gui/guiwindp.inc:3691: error: symbol `GUIGUIAboutTextA2' undefined
gui/guiwindp.inc:3691: error: symbol `GUIGUIAboutTextA2' undefined
gui/guiwindp.inc:4049: error: short jump is out of range
gui/guikeys.inc:1456: error: symbol `Triplebufen' undefined
gui/guikeys.inc:1474: error: symbol `GUITBVID' undefined
gui/guikeys.inc:1476: error: symbol `Triplebufen' undefined
gui/guikeys.inc:1640: error: short jump is out of range
gui/gui.asm:1090: error: short jump is out of range
gui/gui.asm:3765: error: phase error detected at end of assembly.
I'm going to try making a new Xcode project by looking at Hector's one, but I can't guarantee anything (Did I mention how much I hate Xcode?).

On a unrelated note, who made the ZSNES icon? OS X uses 128 x 128 as the size of its larger icon, so the icon is a little bit pixelated on Hector's build. (easily noticeable by Alt^WCommand-Tabbing when ZSNES is open.) A 128 x 128 transparent PNG image of the ZSNES icon would be great.

EDIT: Scratch that, I just noticed I'm getting lots of stupid errors when running the configure script. It seems that the bash that comes with OS X (2.05b.0) doesn't support VARIABLE+="whatever" o_O? I'm getting bash 3.2.9 off MacPorts and I'll edit this post later if it solves the broken configure script.

EDIT 2: Bash 3 solved my problem, configure ran just fine and ZSNES compiled without messing with the Makefile manually (I'm an idiot). However, OpenGL is broken, like some people mentioned all I get is a white window. If I switch to an OpenGL mode, save (by saving I mean pressing a key to make ZSNES accept the new mode and then close the white ZSNES window) and reopen ZSNES, ZSNES crashes (with a crash log this time!).
This is what I get on the terminal:
Fatal signal: Floating Point Exception (SDL Parachute Deployed).

And this is what I get on the OS X console:
Feb 19 13:46:20 calacirya crashdump[10893]: zsnes crashed
Feb 19 13:46:21 calacirya crashdump[10893]: crash report written to: /Users/miguel/Library/Logs/CrashReporter/zsnes.crash.log

zsnes.crash.log

And this is the info about my machine's specs that Apple's Crash Report tool appends to the crash log. (I obviously didn't send the report to Apple, I just wanted to see what was it going to send)

Thing is, OpenGL modes work just fine with Hector's build. Well, some of them work, at least.
bobablob
New Member
Posts: 8
Joined: Tue Jan 02, 2007 11:49 pm

Post by bobablob »

I've had some of the major compiler errors you have run into Krade. Strangely enough, until about the second week of January, I could compile from SVN with absolute ease. Not no more!

Have you attempted to build with the nightly version of SDL to see if OpenGL works?
Krade
Rookie
Posts: 31
Joined: Mon Feb 19, 2007 11:23 am

Post by Krade »

Yes, I pulled it straight from SVN today, that's all I tried. It compiles just fine, but OpenGL is broken. Starting ZSNES with an OpenGL mode on crashes with that log I posted above.

I haven't done much tinkering with it yet, though.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Make sure you are compiling for a 32-bit target.

Anyways... see if this patch works for any of you (and if ZSNES already works fine for you in OpenGL, does this improve performance?):

Code: Select all

Index: gl_draw.c
===================================================================
--- gl_draw.c	(revision 4782)
+++ gl_draw.c	(working copy)
@@ -63,7 +63,7 @@
 
 int gl_start(int width, int height, int req_depth, int FullScreen)
 {
-  Uint32 flags = SDL_DOUBLEBUF | SDL_HWSURFACE | SDL_HWPALETTE | SDL_OPENGL;
+  Uint32 flags = SDL_OPENGL;
   int i;
 
   flags |= (GUIRESIZE[cvidmode] ? SDL_RESIZABLE : 0);
@@ -81,6 +81,7 @@
   SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
 #if (SDL_MAJOR_VERSION > 1) || ((SDL_MINOR_VERSION > 2) || ((SDL_MINOR_VERSION == 2) && (SDL_PATCHLEVEL >= 10)))
   SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1);
+  SDL_GL_SetAttribute(SDL_GL_ACCELERATED_VISUAL,1);
 #endif
 
   if (!glvidbuffer)
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Krade
Rookie
Posts: 31
Joined: Mon Feb 19, 2007 11:23 am

Post by Krade »

I don't think ZSNES would even start if I wasn't compiling for a 32 bit target. o_O

Ok, after poking around a bit (and compiling against the proper SDL version, configure was picking up an old fink SDL installation I had -- this is what I get for having both fink and MacPorts installed), I found out that OpenGL modes do work just fine -- it's switching the modes that causes the white screen problem BRPXQZME and I are getting (he didn't solve it yet, did he?). Here's a workaround to switch to an OpenGL mode with 1.51/1.50:

1. Load any ROM
2. Pick an OpenGL mode
3. When the white screen shows up, press spacebar (to get ZSNES to accept the new mode)
4. Press ESC twice (one to close the options window, another to resume emulation)
5. The game will be running under an OpenGL mode just fine now. Pressing ESC to pause emulation and open the menu won't have any undesired effects, everything works fine now.

Also, switching from an OpenGL mode to a non-OpenGL mode and then switching back to an OpenGL mode again seems to make the colors all wonky, which can only be fixed by restarting ZSNES. This last bug is also present in Hector's build (1.43), anyone can reproduce it by downloading the .dmg he's providing on his page.

This is for 1.51, because sound seems to be very broken in the SVN trunk revision I pulled today (I had my headphones on and I almost went deaf when I started ZSNES), but the OpenGL bugs seems consistent with 1.50 and 1.51.

I tried that OpenGL patch, it didn't make the "white screen on changing video modes" problem go away, but it didn't seem to introduce any other bugs either.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

I'm not surprised with the OpenGL bugs in 1.50+1.51, since they aren't really different in their codebases.

However, I think I have an idea on where the corruption is coming from.

Edit:

Try this patch first:

Code: Select all

Index: sdllink.c
===================================================================
--- sdllink.c	(revision 4789)
+++ sdllink.c	(working copy)
@@ -1070,6 +1070,7 @@
     }
     #endif
     clearwin();
+    Clear2xSaIBuffer();
   }
 
   if (FirstVid == 1)
If that doesn't work, try this patch with the above patch.

Code: Select all

Index: sdllink.c
===================================================================
--- sdllink.c	(revision 4789)
+++ sdllink.c	(working copy)
@@ -1021,6 +1021,10 @@
     if(OGLModeCheck())
     {
       surface = SDL_SetVideoMode(WindowWidth, WindowHeight, BitDepth, surface->flags);
+#if (SDL_MAJOR_VERSION > 1) || ((SDL_MINOR_VERSION > 2) || ((SDL_MINOR_VERSION == 2) && (SDL_PATCHLEVEL >= 10)))
+      SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1);
+      SDL_GL_SetAttribute(SDL_GL_ACCELERATED_VISUAL,1);
+#endif
       adjustMouseXScale();
       adjustMouseYScale();
       glViewport(0,0, WindowWidth, WindowHeight);
All 3 of these patches (2 here and 1 previous) should be able to patch against 1.51.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Krade
Rookie
Posts: 31
Joined: Mon Feb 19, 2007 11:23 am

Post by Krade »

Alright! The combination of those three patches, patched against 1.51 seemed to fix the wacky color problems when switching from between OpenGL and non-OpenGL modes that has been around since 1.43 at least. Well, partially fixed. I just found out that switching from any non-OpenGL to a Windowed OpenGL mode will work just fine and switching to a Full Screen non-OpenGL mode to a Windowed OpenGL mode also works, but switching from a Full Screen non OpenGL to a Full Screen OpenGL brings the weird colors again.

If the white screen on switching modes problem gets fixed, we'll have a kinda ready for consumption Mac build, pretty much. Considering Hector's build doesn't suffer from this problem. I wonder if he found a way to fix the white screen problem himself or if this is just a regression.

Other stuff I noticed:
- If an OpenGL mode is selected, when the program starts, the window glitches for a split second with garbage of whatever was already on the screen while making a static/gunshot-like noise. It's hard to describe, so here's a screenshot.
Selecting a non-OpenGL mode doesn't cause the video bug, but the sound bug is still there while the screen is black (loading).
The sound glitch is also somewhat present in Hector's build, but it doesn't happen all the time; I have to quit and restart it several times to hear it. The video glitch isn't present in his build.
This is probably a non-issue, I'm just including it in case it helps diagnosis of whatever is causing that nasty white window bug.

- Selecting the Interpolation filter in a non-OpenGL mode causes a Segmentation Fault. o_O

- Under a non-OpenGL mode, the NTSC filter works just fine in windowed mode, but in Full Screen mode, the colors go all wacky (a different kind of wacky) again. Disabling the filter makes this go away, so I'm really not worried about this one.

- Changing from an OpenGL mode to the same OpenGL mode (ie: the exact same mode with the same resolution) doesn't cause the white screen bug. In fact, this is another way to change video modes without loading a ROM. Changing from any mode to another OpenGL mode will get you the white screen, but pressing spacebar (to make ZSNES accept the mode) and then pressing enter twice (to make ZSNES set the same mode again) will successfully change the video mode. Isn't it weird that setting the mode once will cause the screen to go completely white, but setting the same mode again will cause it to work?
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Krade wrote:Alright! The combination of those three patches, patched against 1.51 seemed to fix the wacky color problems when switching from between OpenGL and non-OpenGL modes that has been around since 1.43 at least. Well, partially fixed. I just found out that switching from any non-OpenGL to a Windowed OpenGL mode will work just fine and switching to a Full Screen non-OpenGL mode to a Windowed OpenGL mode also works, but switching from a Full Screen non OpenGL to a Full Screen OpenGL brings the weird colors again.
The only idea I have at the moment is trying this patch instead of the patch that looks familiar to this:

Code: Select all

Index: sdllink.c
===================================================================
--- sdllink.c	(revision 4789)
+++ sdllink.c	(working copy)
@@ -1069,6 +1069,7 @@
       glFlush();
     }
     #endif
+    Clear2xSaIBuffer();
     clearwin();
   }
If the white screen on switching modes problem gets fixed, we'll have a kinda ready for consumption Mac build, pretty much. Considering Hector's build doesn't suffer from this problem. I wonder if he found a way to fix the white screen problem himself or if this is just a regression.
It is hard to determine what caused this to begin with since I don't know what exact revision that changed this behavior. There has been a number of changes since that version anyways...
Other stuff I noticed:
- If an OpenGL mode is selected, when the program starts, the window glitches for a split second with garbage of whatever was already on the screen while making a static/gunshot-like noise. It's hard to describe, so here's a screenshot.
It updates a second time to work around a bug that prevents bilinear filtering applying properly the first time ZSNES is loaded.
Selecting a non-OpenGL mode doesn't cause the video bug, but the sound bug is still there while the screen is black (loading).
The sound glitch is also somewhat present in Hector's build, but it doesn't happen all the time; I have to quit and restart it several times to hear it. The video glitch isn't present in his build.
This is probably a non-issue, I'm just including it in case it helps diagnosis of whatever is causing that nasty white window bug.
The sound glitch is probably related to the status of audio in ZSNES. It will probably get corrected, when the changes are complete.
- Selecting the Interpolation filter in a non-OpenGL mode causes a Segmentation Fault. o_O
It doesn't happen here.... a debug build and a backtrace of it crashing would be nice.

To build a debug build, make sure you pass in --enable-debug to configure or autogen.sh.
- Under a non-OpenGL mode, the NTSC filter works just fine in windowed mode, but in Full Screen mode, the colors go all wacky (a different kind of wacky) again. Disabling the filter makes this go away, so I'm really not worried about this one.
That doesn't seem to occur here... hmmm
- Changing from an OpenGL mode to the same OpenGL mode (ie: the exact same mode with the same resolution) doesn't cause the white screen bug. In fact, this is another way to change video modes without loading a ROM. Changing from any mode to another OpenGL mode will get you the white screen, but pressing spacebar (to make ZSNES accept the mode) and then pressing enter twice (to make ZSNES set the same mode again) will successfully change the video mode. Isn't it weird that setting the mode once will cause the screen to go completely white, but setting the same mode again will cause it to work?
It's a nice workaround, but that doesn't really solve a thing atm. The only thing that comes to mind that the screen gets refreshed again... so there's a fair chance something didn't get refreshed/cleared the first time around.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Deathlike2 wrote: It doesn't happen here.... a debug build and a backtrace of it crashing would be nice.

To build a debug build, make sure you pass in --enable-debug to configure or autogen.sh.
Why are you asking him for something he can't do?

Apple's junky broken tools don't support debugging.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Nach wrote:
Deathlike2 wrote: It doesn't happen here.... a debug build and a backtrace of it crashing would be nice.

To build a debug build, make sure you pass in --enable-debug to configure or autogen.sh.
Why are you asking him for something he can't do?

Apple's junky broken tools don't support debugging.
I keep forgetting this detail. Stupid Apple.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

I'm not sure if this is related, but it might as well be posted anyways:

http://www.libsdl.org/release/SDL-1.2.11/BUGS
SDL 1.2.11 Release Notes wrote:Mac OS X:

Fullscreen drawing has some artifacts.

Fullscreen OpenGL for the software renderer is broken.
That's all that I think is relevent atm.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Krade
Rookie
Posts: 31
Joined: Mon Feb 19, 2007 11:23 am

Post by Krade »

Deathlike2 wrote:
Nach wrote:
Deathlike2 wrote: It doesn't happen here.... a debug build and a backtrace of it crashing would be nice.

To build a debug build, make sure you pass in --enable-debug to configure or autogen.sh.
Why are you asking him for something he can't do?

Apple's junky broken tools don't support debugging.
I keep forgetting this detail. Stupid Apple.
Umh, sure I can, Apple even supplies their own gdb. The only problem is that I get a ton of these at compiling time if I --enable-debug:
"nasm: fatal: unrecognized debug format `stabs' for output format `macho'
type `nasm -h' for help"
Help? I'm decent at C, but I never touched nasm or x86 Assembly in my whole life, I'm at a complete loss here. Is there any other debugging format I can try to enable or something? That's Apple's nasm, btw, the regular nasm doesn't even have Mach-O as an output format.

Here's a backtrace of zsnesd, but it doesn't seem too useful. Mostly because of the reason above.

Code: Select all

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0eb55000
0x002d99a2 in MMXInterpolwin.a4 ()
(gdb) bt full
#0  0x002d99a2 in MMXInterpolwin.a4 ()
No symbol table info available.
#1  0x002df679 in sw_drawwin ()
No symbol table info available.
Previous frame inner to this frame (corrupt stack?)
(gdb) 
Mach is such an outdated, obsolete, piece of crap kernel. ._. Apple should ditch it for Xen already.

I'll try that first patch and see if it solves the Full Screen mode switching problem.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Krade wrote:Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0eb55000
0x002d99a2 in MMXInterpolwin.a4 ()
(gdb) bt full
#0 0x002d99a2 in MMXInterpolwin.a4 ()
No symbol table info available.
#1 0x002df679 in sw_drawwin ()
No symbol table info available.
Previous frame inner to this frame (corrupt stack?)
(gdb)
Read the text in bold. That's the problem when trying to debug. Only Apple's debugger tools fail to do while other tools have this down pat.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Krade
Rookie
Posts: 31
Joined: Mon Feb 19, 2007 11:23 am

Post by Krade »

I know that backtrace provided no info, but I thought that was related to nasm refusing to use stabs as a debug format when outputting Mach-O binaries. So it can't be solved to get a decent backtrace out of it?
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

I think I have an idea actually... I'll have to look at this a bit more.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Locked