Snes9x.COM: Developers Journal


October Update
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 value zero!
  • 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 it)
  • Reverted back to FMod version 3.20 after reports that version 3.33 broke AD3 support.
  • 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:
  1. Ditch Windows ME so C++ Builder works again.
  2. 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).
  3. Rewrite the GUI using the Microsoft foundation library but face Snes9x  crashing often due to the many incompatible versions of the library installed on machines.
  4. Rewrite the GUI in Java.
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 code
put together.
Java is my preferred choice, since the GUI will then work on Linux and Solar

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 project files.

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 enabling triple-buffering.

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 06:35:00

Go back in time


Filter on
7/4/2006 9:51:00 PM
10/15/2001 1:20:00 PM
6/8/2001 10:22:00 PM
12/4/2003 6:59:00 PM
4/20/1999 6:13:00 AM

DisclaimerView our Privacy Policy
The Snes9X team is not connected or affiliated with any mentioned company in any way. The opinions of the Snes9X team do not reflect the views of the various companies mentioned here. Companies and all products pertaining to that company are trademarks of that company. Please contact that company for trademark and copyright information.

Copyright 1998,1999 Webmaster