Opengl for zsnes under win.

[Nach]

Neither does Mario Kart.

I'm just wondering if he's really using the term Virtual Reality to describe 3D, or of there's some SNES term that I'm not aware of.

I mean, am I missing something big when I say "WTF" to this post of his?

Dude, has any of you actually DUMPED a SNES rom and viewed it's source code?

Dump a ROM and get source code? That's got to be quite a feat, how do you manage that?

If you mean scan the binary, well...

Code: Select all

/home/nach/CVS/zsnes/src> strings /mnt/D/roms/nintendo/snes/fzero.smc | grep -i ACK
/home/nach/CVS/zsnes/src> strings /mnt/D/roms/nintendo/snes/fzero.smc | grep -i VR
VRbJVX]X
\QRVRc^
Pb^VRTX
vvrvwwwv
"1232223swswswswsvr2wwsss333333333{{s3
/home/nach/CVS/zsnes/src>    

So yeah, right, VR and all that, sure, uh huh, gotcha, right, comprendo.

[byuu]

Dude, has any of you actually DUMPED a SNES rom and viewed it's source code? If you havn't done that, I can't explain this to you.
If you have, I can't believe you wouldn't know about it!

It's called: ACK8 and sometimes VR16_

It's for VR ground manipulation. and F-ZERO was not meant to use mode7!

Yeah, they don't know what they're talking about. When I used a CR168427G and ran the SNES rom through its statistical probability-based decompiler, the VR16_ functions were the first thing output! Three pages down and you have your ACK8 rendering functions that perform the anti-aliasing on the textured F-ZERO quads used for the ground manipulation. Like mode7 could perform real-time anisotropic filtering like ACK8. As if.
ATi: You should port ZSNES to PowerPC G4 assembler, and use the AltiVec instruction set to emulate the VR16_ functions. With that, you could even upscale them to VR32_ functions and feed the results through a bicubic analyzer. If you throw in dynamic opcode translation matrix functions, then you could even run the resulting program on Mac OS 6 or above! The only downside there is that the CRT dot matrix resolution on the old Apple6 monitors lack stereoscopic depth rendering (SDR) support, which is essential for VR32_, but you could probably fake it using the x2_VR16_ driver, maybe... what do you think?
Keep us updated on your progress, please.

[Nach]

I think there can be only one conclusion here.

It's my opinion so it's not wrong
A like a just so you know, I missed school for this, and I'm porting this post as well don't argue with me.

Jack, Louis, Tigerguy, ATiRAGEPRO.

[Starman Ghost]

I think there can be only one conclusion here.

It's my opinion so it's not wrong
A like a just so you know, I missed school for this, and I'm porting this post as well don't argue with me.

Jack, Louis, Tigerguy, ATiRAGEPRO.

OMG PWNED!!!!!!11

[bohdy]

If you check the last page of the linked thread (7) you'll see that the author just made a sdl version of the patch. This is good for dosbox, and maybe to the sdl version of zsnes, but not i think, to the main zsnes executable yes?

Yep, this should mean that the SDL version of Zsnes could use this scaler without any porting effort. All it needs is to be compiled with a patched SDL, then have an environment variable set. What could be simpler?

[blackmyst]

Wow, so we can make the SNES into a full color Virtual Boy? When do I get to play it?

[ATiRAGEPRO]

Dump a ROM and get source code? That's got to be quite a feat, how do you manage that?

If you mean scan the binary, well...

Code: Select all

/home/nach/CVS/zsnes/src> strings /mnt/D/roms/nintendo/snes/fzero.smc | grep -i ACK
/home/nach/CVS/zsnes/src> strings /mnt/D/roms/nintendo/snes/fzero.smc | grep -i VR
VRbJVX]X
\QRVRc^
Pb^VRTX
vvrvwwwv
"1232223swswswswsvr2wwsss333333333{{s3
/home/nach/CVS/zsnes/src>    

So yeah, right, VR and all that, sure, uh huh, gotcha, right, comprendo.

Oh for the love of all things sacred, WTF is that???

I have a mac and use CodeWarrior 6. So i get to actually EXPAND the binary of these things. This program is soo awsome, that it actually referrenced errors made and how to correct them.

ATi: You should port ZSNES to PowerPC G4 assembler, and use the AltiVec instruction set to emulate the VR16_ functions. With that, you could even upscale them to VR32_ functions and feed the results through a bicubic analyzer. If you throw in dynamic opcode translation matrix functions, then you could even run the resulting program on Mac OS 6 or above! The only downside there is that the CRT dot matrix resolution on the old Apple6 monitors lack stereoscopic depth rendering (SDR) support, which is essential for VR32_, but you could probably fake it using the x2_VR16_ driver, maybe... what do you think?
Keep us updated on your progress, please.

LOL

[Jipcy]

It's for VR ground manipulation. and F-ZERO was not meant to use mode7!

[byuu]

...so is this guy for real or not? Can someone please fill me in here? :/

[Noxious Ninja]

It's for VR ground manipulation. and F-ZERO was not meant to use mode7!

I agree with your method of quotation.

[Snarius]

Neither does Mario Kart.

If you mean scan the binary, well...

Code: Select all

/home/nach/CVS/zsnes/src> strings /mnt/D/roms/nintendo/snes/fzero.smc | grep -i ACK
/home/nach/CVS/zsnes/src> strings /mnt/D/roms/nintendo/snes/fzero.smc | grep -i VR
VRbJVX]X
\QRVRc^
Pb^VRTX
vvrvwwwv
"1232223swswswswsvr2wwsss333333333{{s3
/home/nach/CVS/zsnes/src>    

Code: Select all

zach@zpmorgan:~/snes/roms$ strings Yoshi\'s\ Island.smc |grep lo
llo'6
llo'6
llo'6
llo'6
llo'6
lloo
ollollllooolllll
ollolooooloolloo
ollolllolloollob
oolloollob
oolloollob
lollooolob
lolob
lllo
ollo
_kkkojollo
_kkkkollllloloom
_kkkkoeloooleomo
lo`c
36lo

mmmmm

[grinvader]

It's for VR ground manipulation. and F-ZERO was not meant to use mode7!

I agree with your method of quotation.

However, this seems unlikely at first glance.

[Jipcy]

However, this seems unlikely at first glance.

I know. Controlled Force didn't have a clue as to what he was talking about. He just wanted to raise his post count as fast as (in)humanly possible.

ATiRAGEPRO!!!! seems to have slight expertise in some areas of programming but is otherwise spouting off complete bullshit in regards to SNES-sepcific stuff.

[hpsolo]

Note: Current OpenGL code is slated to be updated eventually with an implementation that didn't come directly from Hell [aka hpsolo].

The OpenGL code done by me was done ONLY for the Linux port. So if you're referring to the Windows port, then I have no idea... Moreoever, I was a hack put together because (back then) my Celeron 400MHz and Nvidia TNT2 simply could not churn out 60 FPS using the (back then) current XFree86 drivers if I wanted any resolution larger than the (if I recall) default resolution. Software rendering just sucked ass in full screen -- even at 640x480. Slapping the image buffers onto a quad and then having it scaled automagically meant I got full 60 FPS with OpenGL, plus free bilinear filtering. The OpenGL code that exists now is not mine -- in fact very little of it remains. The original hack simply copied vidbuffer into a texture, and mapped it onto a quad. That was it.

I haven't messed with ZSNES in a while. As far as OpenGL is concerned, there really isn't a need for OpenGL if you already get 60 FPS. Besides being able to scale relatively easy, there really isn't much to be gained from OpenGL. It's only really useful when your FPS drop significantly without it there (i.e. software rendering and scaling to high resolutions resulting in dropped FPS).

[grinvader]

Now, hpsolo, take responsibility and commit ritual seppuku to atone for the unholy amount of highly radioactive bullcrap also known as src/linux/gl_draw.c

I'll help you to do it.

[hpsolo]

http://cvs.sourceforge.net/viewcvs.py/z ... iew=markup

Hehe. But if you are truly interested in what happened, check the link above.

That was the bit of code I had originally -- the stuff in between the #ifdef __OPENGL__ and #endif. This code previously lived in sddlink.c At some point another person (for some reason I want to say zinx) decided to modify it so that scanlines and all the other video-enhancing features could be added; later this bit of code would be separated into a software rendering file (sw_draw) and opengl rendering file (gl_draw). The result is what you see now. Unfortunately, this person did _not_ have CVS at that time (or perhaps, forunately =). So he sent me the patches which were ok'd by other people; I then agreed to update the tree with the patch. Back then I could just look and understand what was going on in the opengl code. But now, I myself have absolutely no idea what is going on in the current opengl code without studying it.

If you look at the history of the file for sdllink.c, you'll see the slow mutation of the opengl code done by zink =) Notice the update notes for Revision 1.102 attributes zink with the changes, though the submission was done through me (see link below)

http://cvs.sourceforge.net/viewcvs.py/z ... 0&view=log

Anyway, I just wanted to set the story straight =)

[grinvader]

ALL IS FORGIVEN