ZSNES for Intel Mac ready for consumption!
Moderator: ZSNES Mods
And by the way, I just tested and switching those two function calls around in sdllink.c doesn't change anything, everything (white screen, wacky colors on non-OpenGL Full Screen -> OpenGL Full Screen, segfault in Interpolation) is still there.
Come to think of it, those are the only three bugs (that were detected, at least) in 1.51 on OS X, and only the white screen is a complete show stopper.
Come to think of it, those are the only three bugs (that were detected, at least) in 1.51 on OS X, and only the white screen is a complete show stopper.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Huh, that's weird. From all three non-OpenGL modes that allow filters, only 512X448 W and 512X448 F segfault. Interpolation in 640X480 F works fine.
EDIT: On a second note, reading documentation does help:
Mach sucks.
EDIT: On a second note, reading documentation does help:
Code: Select all
krade@singularity ~/zsnes_1_51/src $ nasm -f macho -y
valid debug formats for 'macho' output format are ('*' denotes default):
* null Null debug format
Last edited by Krade on Sat Apr 09, 2011 2:29 pm, edited 1 time in total.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Does the same happen when MMX support is disabled?
In any case try this patch:
In any case try this patch:
Code: Select all
Index: copyvwin.asm
===================================================================
--- copyvwin.asm (revision 4790)
+++ copyvwin.asm (working copy)
@@ -952,7 +952,7 @@
je near .scanlinesquart
cmp byte[scanlines],3
je near .scanlineshalf
- inc ebx
+ ;inc ebx
mov [lineleft],dl
; do scanlines
mov edx,[spritetablea]
@@ -1070,7 +1070,7 @@
ret
.scanlines
- inc dl
+ ;inc dl
mov [lineleft],dl
; do scanlines
mov eax,[esi+510]
@@ -1120,7 +1120,7 @@
ret
.scanlineshalf
- inc dl
+ ;inc dl
mov [lineleft],dl
; do scanlines
.ahb
@@ -1183,7 +1183,7 @@
ret
.scanlinesquart
- inc dl
+ ;inc dl
mov [lineleft],dl
; do scanlines
.ahb2
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Paying attention also helps, I already told you their junky broken tools don't support debugging.Krade wrote: EDIT: On a second note, reading documentation does help:
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
Interpolation works on all three modes if MMX support is disabled, regardless of the scanlines setting. Huh.
And I know you did, but "junky broken tools" is far too broad. At that time, I thought you were talking about a proper debugger, which does exist. It's their nasm port that sucks. I was talking about myself when I made that documentation comment, I was implying that I posted a stupid question (about the nasm debug options in the previous page) instead of reading the docs myself.
I'll try that patch in a second.
EDIT: Gah. It did fix interpolation with MMX support for all three modes, but I'm still getting segfaults on a couple of hard to reproduce occasions. It seems to be related to mode switching, though. Like you said, something is probably not being reset/refreshed right when switching video modes, which is causing all these weird bugs. I'll edit this post again when I can tell what action exactly is causing the crash.
EDIT #2: The original interpolation segfaults are also present in Hector's build. Funny how no one reported that all this time.
And I know you did, but "junky broken tools" is far too broad. At that time, I thought you were talking about a proper debugger, which does exist. It's their nasm port that sucks. I was talking about myself when I made that documentation comment, I was implying that I posted a stupid question (about the nasm debug options in the previous page) instead of reading the docs myself.
I'll try that patch in a second.
EDIT: Gah. It did fix interpolation with MMX support for all three modes, but I'm still getting segfaults on a couple of hard to reproduce occasions. It seems to be related to mode switching, though. Like you said, something is probably not being reset/refreshed right when switching video modes, which is causing all these weird bugs. I'll edit this post again when I can tell what action exactly is causing the crash.
EDIT #2: The original interpolation segfaults are also present in Hector's build. Funny how no one reported that all this time.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Let me write things down before I forget them. With all the patches so far applied against 1.51:
- 640X480 F never segfaults.
- Interpolation + 25% - 100% scanlines never segfault in any of the three modes
- Loading an OpenGL mode at any point when the program is open will cause 512X448 F and W to segfault if interpolation is selected with scanlines set to none
- If the program is started in 640X480 F (non-OpenGL) mode, 512X448 F and W segfault if interpolation is selected with scanlines set to none again
- If the program is started in 512X448 F or W, interpolation + scanlines: none will not crash 512X448 F and W, as long as an OpenGL mode isn't selected. 512X448 F or W -> 640X480 F -> 512X448 F or W will not crash with interpolation + scanlines: none.
- Picking any full screen non-OpenGL mode at any point when the program is open will cause 512X448 W only to display wacky colors on every scanline mode if interpolation is on and on scanline modes 25% and 50% if interpolation is off. Scanline modes none and 100% with interpolation off look fine.
- Changing from any full screen non-OpenGL mode to any OpenGL mode will cause wacky colors. The weird colors will go away if a non-OpenGL mode is picked. (Therefore, the only way to switch from non-OpenGL to an OpenGL mode without getting weird colors is to pick the only windowed non-OpenGL mode before switching)
- Variable mode causes the white screen problem when resizing the window manually. It can be fixed (if the video config window is still open) by pressing enter twice (which will cause ZSNES to reload the variable video mode). This white screen on resizing with the variable mode on bug is also present on Hector's build (the main white screen on changing modes isn't), which makes me wonder again if he didn't fix the white screen problem by himself and overlooked the variable resizing special case. It was probably overlooked because using the variable mode on OS X isn't obvious; with the mouse inside the ZSNES GUI, you have to click on the right bottom corner (even if there's nothing there) and drag it.
- Having MMX Support enabled or disabled doesn't seem to affect anything after the last patch.
I believe there's also a couple of other weird colors bugs that only affect the game when it's running, not the GUI+game like all the others I described so far, but I'm going to take a while to figure them all out.
Long short story: Every single bug seems related to and/or triggered by video mode change now. Even 8-point interpolation sound that is broken in Hector's build is working fine on 1.51.
- 640X480 F never segfaults.
- Interpolation + 25% - 100% scanlines never segfault in any of the three modes
- Loading an OpenGL mode at any point when the program is open will cause 512X448 F and W to segfault if interpolation is selected with scanlines set to none
- If the program is started in 640X480 F (non-OpenGL) mode, 512X448 F and W segfault if interpolation is selected with scanlines set to none again
- If the program is started in 512X448 F or W, interpolation + scanlines: none will not crash 512X448 F and W, as long as an OpenGL mode isn't selected. 512X448 F or W -> 640X480 F -> 512X448 F or W will not crash with interpolation + scanlines: none.
- Picking any full screen non-OpenGL mode at any point when the program is open will cause 512X448 W only to display wacky colors on every scanline mode if interpolation is on and on scanline modes 25% and 50% if interpolation is off. Scanline modes none and 100% with interpolation off look fine.
- Changing from any full screen non-OpenGL mode to any OpenGL mode will cause wacky colors. The weird colors will go away if a non-OpenGL mode is picked. (Therefore, the only way to switch from non-OpenGL to an OpenGL mode without getting weird colors is to pick the only windowed non-OpenGL mode before switching)
- Variable mode causes the white screen problem when resizing the window manually. It can be fixed (if the video config window is still open) by pressing enter twice (which will cause ZSNES to reload the variable video mode). This white screen on resizing with the variable mode on bug is also present on Hector's build (the main white screen on changing modes isn't), which makes me wonder again if he didn't fix the white screen problem by himself and overlooked the variable resizing special case. It was probably overlooked because using the variable mode on OS X isn't obvious; with the mouse inside the ZSNES GUI, you have to click on the right bottom corner (even if there's nothing there) and drag it.
- Having MMX Support enabled or disabled doesn't seem to affect anything after the last patch.
I believe there's also a couple of other weird colors bugs that only affect the game when it's running, not the GUI+game like all the others I described so far, but I'm going to take a while to figure them all out.
Long short story: Every single bug seems related to and/or triggered by video mode change now. Even 8-point interpolation sound that is broken in Hector's build is working fine on 1.51.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Before I start commenting, know that the OpenGL white screen bug is independant of the interpolation bug.
I'll look over this behavior, but the fact is that SDL under Linux seems to be fine. It could be that there is some leniency on memory access in Linux than in OS X. (It isn't an evil thing... it just means bugs are being exposed that shouldn't have been allowed in the first place.Krade wrote:Let me write things down before I forget them. With all the patches so far applied against 1.51:
- 640X480 F never segfaults.
- Interpolation + 25% - 100% scanlines never segfault in any of the three modes
- Loading an OpenGL mode at any point when the program is open will cause 512X448 F and W to segfault if interpolation is selected with scanlines set to none
- If the program is started in 640X480 F (non-OpenGL) mode, 512X448 F and W segfault if interpolation is selected with scanlines set to none again
- If the program is started in 512X448 F or W, interpolation + scanlines: none will not crash 512X448 F and W, as long as an OpenGL mode isn't selected. 512X448 F or W -> 640X480 F -> 512X448 F or W will not crash with interpolation + scanlines: none.
- Picking any full screen non-OpenGL mode at any point when the program is open will cause 512X448 W only to display wacky colors on every scanline mode if interpolation is on and on scanline modes 25% and 50% if interpolation is off. Scanline modes none and 100% with interpolation off look fine.
My blame is put on SDL at the moment. There is nothing that I'm aware of in the current code that should cause that.- Changing from any full screen non-OpenGL mode to any OpenGL mode will cause wacky colors. The weird colors will go away if a non-OpenGL mode is picked. (Therefore, the only way to switch from non-OpenGL to an OpenGL mode without getting weird colors is to pick the only windowed non-OpenGL mode before switching)
Should be an easy fix actually. I'll deal with it when I get around to it.- Variable mode causes the white screen problem when resizing the window manually. It can be fixed (if the video config window is still open) by pressing enter twice (which will cause ZSNES to reload the variable video mode). This white screen on resizing with the variable mode on bug is also present on Hector's build (the main white screen on changing modes isn't), which makes me wonder again if he didn't fix the white screen problem by himself and overlooked the variable resizing special case. It was probably overlooked because using the variable mode on OS X isn't obvious; with the mouse inside the ZSNES GUI, you have to click on the right bottom corner (even if there's nothing there) and drag it.
The interpolation+scanlines code run different paths while MMX Support is toggled.- Having MMX Support enabled or disabled doesn't seem to affect anything after the last patch.
It helps to be specific here.I believe there's also a couple of other weird colors bugs that only affect the game when it's running, not the GUI+game like all the others I described so far, but I'm going to take a while to figure them all out.
I don't recall it being "broken"... the guy claims "it doesn't sound right" which really doesn't matter anymore since all the sound filter code has been removed (in SVN) anyways. As I said at the beginning of this post, don't confuse the two different bugs.Long short story: Every single bug seems related to and/or triggered by video mode change now. Even 8-point interpolation sound that is broken in Hector's build is working fine on 1.51.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Yes, I know that. I was just making a huge post with all the tiny and not-so-tiny bugs so far.Deathlike2 wrote:Before I start commenting, know that the OpenGL white screen bug is independant of the interpolation bug.
No, I mean, it fixed stuff, but after that last patch, all the bugs that occur, occur with both MMX Support on and off.Deathlike2 wrote:The interpolation+scanlines code run different paths while MMX Support is toggled.
I'm trying to pinpoint every bug that I find, but most of the new stuff I'm finding occurs when I'm testing other stuff and then when I try to do it again, I can't reproduce it. :/ Most of these are triggered by a insane combination of video modes + filters.Deathlike2 wrote:It helps to be specific here.
It is broken, I just tested it. On his build, picking 8-point interpolation sound and pressing ESC while sound is outputting will cause ZSNES to hang and become unresponsive with the spinning beachball of doom.Deathlike2 wrote:I don't recall it being "broken"... the guy claims "it doesn't sound right" which really doesn't matter anymore since all the sound filter code has been removed (in SVN) anyways. As I said at the beginning of this post, don't confuse the two different bugs.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Try this patch for the interpolation issue.
Edit: Still another revision
Note: This is to be patched against whatever is in SVN at the moment.
Edit: Still another revision
Note: This is to be patched against whatever is in SVN at the moment.
Code: Select all
Index: copyvwin.asm
===================================================================
--- copyvwin.asm (revision 4795)
+++ copyvwin.asm (working copy)
@@ -952,13 +952,13 @@
je near .scanlinesquart
cmp byte[scanlines],3
je near .scanlineshalf
- inc ebx
+ ;inc ebx
mov [lineleft],dl
; do scanlines
mov edx,[spritetablea]
+ ;add edx,512
+ mov eax,[esi+510]
mov ecx,64
- mov eax,[esi+510]
- add edx,512
mov [esi+512],eax
.a2
movq mm0,[esi]
@@ -999,7 +999,7 @@
mov ecx,64
mov [esi+512],eax
mov edx,[spritetablea]
- add edx,512
+ ;add edx,512
; Process next line
.a3
movq mm0,[esi]
@@ -1049,7 +1049,7 @@
jnz near .a3
add edi,[AddEndBytes]
mov edx,[spritetablea]
- add edx,512
+ ;add edx,512
mov ecx,64
.a4
movq mm0,[edx]
@@ -1070,7 +1070,7 @@
ret
.scanlines
- inc dl
+ ;inc dl
mov [lineleft],dl
; do scanlines
mov eax,[esi+510]
@@ -1120,7 +1120,7 @@
ret
.scanlineshalf
- inc dl
+ ;inc dl
mov [lineleft],dl
; do scanlines
.ahb
@@ -1183,7 +1183,7 @@
ret
.scanlinesquart
- inc dl
+ ;inc dl
mov [lineleft],dl
; do scanlines
.ahb2
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Ugh, I committed enough to get the scanlines w/interpolation working.. but not strictly interpolation...
Anyways, a more complete patch for the white box problem - this should be patchable against 1.51:
![Confused :?](./images/smilies/icon_confused.gif)
Anyways, a more complete patch for the white box problem - this should be patchable against 1.51:
Code: Select all
Index: gl_draw.c
===================================================================
--- gl_draw.c (revision 4798)
+++ 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)
Index: sdllink.c
===================================================================
--- sdllink.c (revision 4798)
+++ sdllink.c (working copy)
@@ -422,6 +422,10 @@
if(!GUIRESIZE[cvidmode])
{
surface = SDL_SetVideoMode(WindowWidth, WindowHeight, BitDepth, surface->flags & ~SDL_RESIZABLE);
+#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();
break;
@@ -431,6 +435,10 @@
SetHQx(SurfaceX,SurfaceY);
SetHiresOpt(SurfaceX,SurfaceY);
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);
@@ -1021,6 +1029,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);
@@ -1069,6 +1081,7 @@
glFlush();
}
#endif
+ Clear2xSaIBuffer();
clearwin();
}
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
At the moment, I am calling the white box a SDL/ATI/OS X bug. The only realistic workaround is hitting the enter key/space bar a few more times and the screen should not be white anymore.
http://www.idevgames.com/forum/archive/ ... 12204.html - this thread doesn't make me happy at all.
http://www.idevgames.com/forum/archive/ ... 12204.html - this thread doesn't make me happy at all.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
It makes it worse. I just checked out SVN to a new dir, didn't apply any patches and now I get a white screen when I start ZSNES -- if ZSNES is set to start in an OpenGL mode. Pressing enter twice to open the "Load Game" menu and then load the first ROM in the last directory I had open loads the game and the screen comes back.
I still get white screens when changing modes.
I still get white screens when changing modes.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Alright, I backported Deathlike's OS X fixes to 1.51. Here's a binary that should work out of the box on any Intel Mac out there.
http://krade.com/zsnes/ZSNES-1.51.dmg
Enjoy! (Also notice the pretty background of the volume :D)
I force_arch'd it to pentium-m instead of i586, since all of Apple's Intel Macs are Intel Core/Intel Core 2 CPUs. If this turns out to cause problems for anyone, I can recompile it.
I also tried to use IntelRequired, which was suggested in this post (link), but it didn't work. After lipo'ing the zsnes x86 binary and the ppc IntelRequired binary, nothing would show up on a PPC Mac. I figured out that a cryptic error message is better that no error message at all, so the executable in that .app is the x86-only one generated by the regular compilation process.
For you people who don't use OS X (and therefore can't open disk images), that dmg file contains the docs folder present in the 1.51 release, the ZSNES.app file (the standard way of distributing OS X applications) containing the same ZSNES icons Hector used, the SDL.framework (version 1.2.11) and the zsnes 1.51 binary and a file called Readme - OS X that contains this text (link) (TextEdit, which is what that file is going to open with, will wordwrap it automatically).
I'll edit this post with a link to the diff file between the 1.51 source release and the one I used in a bit.
EDIT: Here you go, the diff (link). It goes without saying that this file is only useful for someone trying to compile ZSNES 1.51 for OS X himself. Anyone else can just use the .dmg file I posted above.
http://krade.com/zsnes/ZSNES-1.51.dmg
Enjoy! (Also notice the pretty background of the volume :D)
I force_arch'd it to pentium-m instead of i586, since all of Apple's Intel Macs are Intel Core/Intel Core 2 CPUs. If this turns out to cause problems for anyone, I can recompile it.
I also tried to use IntelRequired, which was suggested in this post (link), but it didn't work. After lipo'ing the zsnes x86 binary and the ppc IntelRequired binary, nothing would show up on a PPC Mac. I figured out that a cryptic error message is better that no error message at all, so the executable in that .app is the x86-only one generated by the regular compilation process.
For you people who don't use OS X (and therefore can't open disk images), that dmg file contains the docs folder present in the 1.51 release, the ZSNES.app file (the standard way of distributing OS X applications) containing the same ZSNES icons Hector used, the SDL.framework (version 1.2.11) and the zsnes 1.51 binary and a file called Readme - OS X that contains this text (link) (TextEdit, which is what that file is going to open with, will wordwrap it automatically).
I'll edit this post with a link to the diff file between the 1.51 source release and the one I used in a bit.
EDIT: Here you go, the diff (link). It goes without saying that this file is only useful for someone trying to compile ZSNES 1.51 for OS X himself. Anyone else can just use the .dmg file I posted above.
-
- Rookie
- Posts: 11
- Joined: Mon Jun 19, 2006 10:05 am
I may have screwed up somehow, sorry. I didn't have any other Intel Macs to test. Do you mind opening Console.app (should be in your utilities folder) and telling me if any error messages show up there when you start ZSNES?polyh3dron wrote:Krade: Thank you for your work! However, on my 17" MacBook Pro with 2.16 Ghz Core Duo CPU, your binary will not load. I double-click it and nothing happens. Is this happening to anyone else?
-
- New Member
- Posts: 3
- Joined: Thu Mar 01, 2007 4:15 am
- Location: Hermitage, TN, USA
- Contact:
Code: Select all
Command: ZSNES
Path: /Applications/ZSNES.app/Contents/MacOS/ZSNES
Parent: WindowServer [91]
Version: ??? (1.51)
PID: 15629
Thread: Unknown
Link (dyld) error:
Library not loaded: /opt/local/lib/libSDL-1.2.0.dylib
Referenced from: /Applications/ZSNES.app/Contents/MacOS/ZSNES
Reason: image not found