Snes9x.COM: Developers Journal


About source archives.
In previous releases, Gary released a porters source tarball, and a windows one.

For 1.40 and later, whenever that may be, you'd get a single source tarball... the windows and porter's tarballs in one. Its a very oddly layed out tarball, but you can understand why Gary put two out when you look at it.

releases post 1.40 will be a single tarball, in a more sanely laid out structure that will be easier to maintain and add to.

Funkyass, 22-7-2003 00:56:00


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

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