||Snes9x.COM: Developers Journal
Things are getting busy at work again and I've had to stop work on Snes9x again for a few weeks.
Before stopping I was helping The Dumper with Street Fighter Alpha 2. SFA2 is an S-DD1 game and, like Star Ocean, its graphics have been compressed using an unknown compression algorithm. However, The Dumper had worked out a method of feeding the compressed data into a hacked S-DD1 game pack and capturing the decompressed data at the other side.
I had been wondering why there had been no graphics pack release for this game - it turned out that even with all the graphics decompressed major graphics glitches were still occuring. zsKnight had been investigating the problem before his tragic departure from the ZSNES team; he had come up with the theory that maybe not enough decompressed data had been captured.
The Dumper asked me to help; a quick hack of Snes9x later, and sure enough, the game was requesting variable amounts of decompressed data from the same compressed block. If SFA2 requested a shorter block of data first, ZSNES - the tool The Dumper was using to find compressed data blocks in the ROM - would record only the shorter length and would not spot the game requesting a longer data block from the same source.
The Dumper and beta testers are now using the hacked Snes9x to spot all the variable length blocks and The Dumper will building a new graphics pack. Except a release soon...
I've also started implementing OpenGL hardware-accelerated SNES graphics rendering to Snes9x. Currently, even if you select the OpenGL output image filter, Snes9x renders the SNES game image using 100% software only, which is very CPU intensive; its only the final copy-to-screen that is hardware-accelerated in this case. With OpenGL direct rendering, Snes9x will make use of your PC's graphics hardware to render the SNES game image, ultimately making the process a lot faster.
I've got rendering working, of sorts, but there are still lots of bugs and glitches and its slow because I haven't implemented any texture caching yet. Also, I haven't figured out how to support all the SNES colour blending modes yet, but its a start.
Once I've got OpenGL rendering perfected - the Windows, Mac and Linux ports will be able to make use of this - I'll try my luck at DirectX3D support, which the Windows and Dreamcast ports can make use of.
I'm also still looking for a willing volunteer to look after, or more like, rewrite, the Snes9x Windows port. Any takers?
Gary, 15-10-2001 13:20:00
|If you haven't noticed...
... there has been new Windows, Linux i386 and Solaris Sparc
Snes9x releases. I've also released the source code. I'll make a separate
Windows port source code release, hopefully tonight - still busy writing
a how to compile file and tracking down web locations of various bits of
software needed to build Snes9x.
I'm also on the look out for a willing volunteer to take over the Snes9x
Windows port - basically I think the GUI is missing many useful features
and desperately needs a complete rewrite, so its no easy task. You'll need
C/C++ and Windows API skills; i386 assembler knowledge would help. Drop
me an e-mail if you're interested.
New in this release:
Added SDD-1 unknown graphics data logging at the dumper's request. A bit
late but might help with Street Fighter 2 Alpha's data dumping. Creates
a romname.dat file in the freeze file folder.
Implemented 16-bit texture support for OpenGL modes in Windows and Linux.
Had to support a new pixel format type to do it - RGB5551 (one bit of alpha)
which caused me some major problems - black was no longer always pixel
Removed the Bump map OpenGL mode from the Windows port (didn't look so
good anyway and was slow).
Added a hidden novelty OpenGL mode (clue: a keyboard shortcut activates
Reverted back to FMod version 3.20 after reports that version 3.33 broke
Implemented a better work-around for the broken select system call in the
Linux kernel - the original work-around was long-winded and stopped working
when I implemented OpenGL support under Linux.
Added the same speed-up hack to the OpenGL code that the Glide code already
supported. Basically, if your OpenGL implementation supports 16-bit textures
then OpenGL mode should be as fast, or faster than the 3dfx Glide mode.
Hopefully fixed Glide support.
Reverted back to the original colour blending code. The newer code, although
more accurate in most cases, had too many glitches and was slower.
Included multiple Japanese games fixes from Iwashi San.
Fixed a timing problem caused by a speed up hack that was affecting Top
Gear 3000. No the game still isn't playable yet, but I noticed the problem
while investigating the DSP-4 chip used by the game.
Gary, 26-9-2001 15:33:00
My heart goes out to people who have lost friends and relatives following Tuesday 11th September's events. The world will never be the same again. Lets hope some good can come from these tragic events.
Today is Snes9x release day. I'll upload the Windows, Linux and Solaris ports when I get time and post a news message updating you on what's new. Source code will follow in a day or two.
Gary, 19-9-2001 13:15:00
I start my first update in a very long time by passing on my condolences
to zsKnight for the loss of his father, something most of us dread happening.
zsKnight, as a result, has retired from the emulation scene and that is
a great loss to us all. Goodbye zsKnight, and thanks for all the fish :)
(Hitchhiker's Guide to the Galaxy reference)
As for myself, I was once again considering giving up Snes9x development:
things have been crazy at work; so much so that I've had to do some work
on the journey to and from work - the time I normally work on Snes9x. But
things have started to become a bit more normal now (except for the longer
hours at work), so Snes9x development has resumed.
As a priority I was investigating the broken Glide support, but while
doing this I noticed that I could use the same speedup hacks with OpenGL
- as long as I could figure out how to support 16-bit textures in OpenGL.
Turned out to be an extension in OpenGL 1.1 or built-in support in version
1.2 that provides 16 bit texture support (thanks to the three people who
pointed me in the right direction).
Now OpenGL support is as fast as Glide support - if your OpenGL implementation
supports 16 bit textures (most do).
I also implemented OpenGL support in Linux, but it didn't help that
16 bit texture handling was broken for the GeForce 2 Go chip in my laptop
computer and would crash the X server if I tried to test for its support.
In the last few days Nvidia has released a new driver set for Linux and
I'm happy to report that 16 bit textures are now working fine.
There's been a long-standing bug in the Linux kernel that Snes9x keeps
hitting - if a signal occurs during a select system call with a zero time-out
then the select is restarted (as it should) but with an infinite time-out!
I had implemented a workaround in Snes9x but the workaround broke when
I added OpenGL support. A little head scratching later and I came up with
a much simpler work-around that works with OpenGL and raw X. Its strange
how sometimes you can't see the forest for the trees!
Windows ME has raised is ugly head. My new notebook computer came with
Windows ME pre installed and, against my better judgement, I decided I
run with it; anyway, Dell said that no versions of Windows prior to Windows
ME were supported on the computer. Some weeks later, when I came to update
the Snes9x GUI, I discovered that C++ Builder 3 didn't work on Win ME.
C++ Builder 4 did work but it generated code that crashes Snes9x when you
destroy a dialog box and sometimes bring down Windows as well! You could
call me cynical, but don't you think its odd how vendor products that rival
Micro$oft's own tend to have a hard time with each new Windows release?
At the moment I haven't updated the Windows GUI in months, but I would
like to. I have several choices:
C++ Builder is not without its problems - due to its inability to link
with some types of object files I have to generate the GUI into a DLL and
then compile the rest of Snes9x using Visual C++. But the separate DLL
makes the GUI very detached from the emulation core making some features
I would like to add almost impossible to implement. Also, C++ Builder generates
very bloated code - the DLL is almost the same as the all the other Snes9x
Ditch Windows ME so C++ Builder works again.
Rewrite the GUI using Visual C++'s "GUI designer" (if you can call it that,
since it does the absolute bare minimum to be described as one).
Rewrite the GUI using the Microsoft foundation library but face Snes9x
crashing often due to the many incompatible versions of the library installed
Rewrite the GUI in Java.
Java is my preferred choice, since the GUI will then work on Linux
Gary, 10-9-2001 12:59:00
|Long Time No Hear...
Life has been a bit busy
of late. 300+ unread e-mails. I thought I was unable to upload new stuff
onto the web site, but it looks like some sort of maintenance happens at
certain times of day and ftp accounts are blocked during this time; I'd
been trying to upload a German translation of Snes9x and had been unlucky
about the times I chose. Also, a couple of the files that Microsoft's Visual
C++ needs to build Snes9x got corrupt and to my horror I hadn't backed
them up - I thought they were just automatically generated stuff. I had
to spend a few hours (= several days available development time) rebuilding
A new Windows port was ready to go several weeks ago - its just I couldn't
release it, or so I thought. While waiting for the ftp account to be
sorted out, I got bored and started adding new functionality, but I forgot
to build a releasable package/zip file first and at the moment I can't
build a 100% working version.
The thing that's breaking the Windows port at the moment is triple-buffer
support in full-screen mode - I thought I'd added triple buffer support
a long time ago, but while scanning the code I discovered it was commented
out - now I know why. Windows implements double and triple buffering by
stacking drawing surfaces one on top of the other like pieces of paper
- the trick is to draw on the piece of paper under the one of top, then
flip piece of paper (the surface) on top to the bottom of the pile. This
stops screen tearing - when the part of the screen that is being displayed
gets updated the program, especially noticeable on scrolling games. The
surface flipping can only take place during the screen vertical blank period,
so if only two surfaces are used (double-buffering) it might slow the program
down because it has to wait for the flip to happen before it start drawing
the next frame. Enter triple-buffering.
My problem is that while I've got triple buffering working, I can't
seem to clear the buffers initially or get the Windows menu bar to appear
on all buffer surfaces - causing flickering junk and a flickering menu
bar. Windows provides an API call to walk down all the "attached" surfaces
calling a user supplied function for each one - but this API call always
stops after the first hidden surface has been processed. :(
I did try just clearing the top surface, drawing the menu bar, then
flipping the next surface to the top and repeating, but that didn't seem
to work. Oh no! I've just realised why that might not have worked - I for
forgot to wait for the flip to actually happen! Oh well, I was going to
try creating my own surfaces next, and attaching them to each other myself;
maybe I don't have to do that now...
If triple-buffering surface clearing problem can be fixed, that only
leaves one more problem - Windows lets you create a triple-buffered surface
whether it will fit in video memory or not - if the it doesn't fit, enabling
triple-buffering actually slows down the emulation rather than speeding
it up as Windows uses systems memory as a overspill area and data has to
be copied from system memory to video memory. I'll need to add some code
to make sure that all the buffer surfaces will fit in video memory before
I've also been trying to get Sanma Iwashi's unofficial Windows port
up and running for the source code he supplied - I'm toying with the idea
of switching to use his GUI in the official Windows port - but the program
crashes every time I try to start a game, and Micro$oft's debugger crashes
Windows if I try to debug it!
John Weidman thought he might have made a big break through with the
S-DD1, but the trail has gone cold. John and I also had the idea of trying
to extract the Nintendo specific code from the DSP-1 and then using it
to write a 100% perfect emulation of the chip - the DSP-1 is actually just
an old, standard, NEC DSP chip with custom code bur
Gary, 29-3-2001 6:35:00
Go back in time