 |
 |
|
 |
| 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 |
|
|
|
|
|
|
|
|
|
| News |
|
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 |
|
|
|
|
|
|
|
|
|
| September |
|
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:
-
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
on machines.
-
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
|
|
|
