HelloYou may be wondering who I am.
I am a relatively new ROM hacker, I started ROM hacking in late 2014. I had only started Doom ROM Hacking around 1 and a half months ago, I had not started with doom. However. In this time I have achieved things on the legendary status of ROM hacking. I had hacked the Doom SNES sounds, text, and most importantly graphics. I also found the music data. I am only a teenager and I have done this all.
But let us begin with my documentation and IPS patches for the ROM.
How did I do this?
The sounds and text were the easiest. I used a tool called SNESSor and I was able to successfully replace the BRR samples (Bit Rate Reduction, which is an ADPCM format which compresses every 32 bytes of sound data to 9 bytes, while still sounding clear.) The text was a matter of replacing text with a hex editor (HxD is my personal choice of hex editor)
The graphics took me about 2 weeks to find. I used a tool called Tile Molester, and the reason it took so long is I had no access to a computer for a while so I was using DOS tools on my android tablet. And when I did get my computer problems fixed, I had then used Tile Molester, and after screwing around with the bitplanes I had successfully found the textures. I only edited the Knee Deep in the Dead skybox texture, because the other textures had dots all over them and appeared to be using RLE (Run Length Encoding) like the Wolf3D SNES sprites, but the Skybox was perfectly clear, and just had to be rotated. Due to the different way the skybox works in the SNES version than the PC version the Doom 2 skybox texture I used did not connect well, due to the sky in the PC version of doom being a cylinder, and the SNES version using a cube shaped skybox, so it does not connect well like in the PC version, but it is what it is. The textures start at hex offset 8000 in the ROM and they use 8bpp linear, and the font graphics are 8bpp also, but use 8bpp planar (I think, I have not looked at the font in a while.) The weapon sprites appear to be using RLE (run length encoding) and they use the 4bpp planar composite codec.
The music data was fairly advanced, yet easy if you know how pointers and general hex works. It was as simple as this. I searched the E1M1 SPC for some 20 CD FF bytes, due to those being the starting bytes of the SPC engine in EVERY standard SPC file. I found them, and from there searched for the first 00 byte after the 20 CD FF, due to 00 being the end byte of a pointer. I found it, then did reverse order on the 2 bytes before the 00, and I opened up the search tab, clicked goto and entered the reversed 2 bytes before the 00 for the end of the pointer in the SPC file but did not enter the 00. I was brought to the hex address 8F10 in my SPC file, and I then selected a big chunk of hex from that address and opened up my Doom SNES ROM, opened up the search tab, pressed find, pasted the block of hex code and I found an exact match. The thing about this is that HxD, if you use find, and there is not an EXACT match of what you search for in the file, it just says "whatever you searched for here not found." So I knew I had found the music data. I even checked the bytes after the chunk of hex I pasted in the SPC file, they were the same as in the ROM.
This concludes this post for now, I will update but here is the IPS file for the skybox texture hack.
=0
How to patch your ROM with the hack.
1. Get Lunar IPS
2. Make sure your Doom ROM is an unmodified USA version ROM (USA version used in all of north america.)
3. Select the unmodified ROM
4. Select the IPS patch
5. Hit apply
6. Open the new ROM you have in an emulator.
7. Look at the sky.
On August 13, 2015, I found something amazing. I was looking for the official SNES SDK and I found and downloaded one. It was a DOS tool and I pressed the help button. Guess what it said? Sculpted Software's SSBUG. Sculpted Software was involved in porting Doom to the SNES. They published Doom SNES (I think they programmed some parts of Doom SNES too, but they are in the credits, hidden in the ROM and are credited elsewhere) Guess what other files there were? Super FX documentation among other documentation on SNES chips and hardware, and also there was an assembler. DOOM SNES development jackpot or what?
Somebody realized it and tested the rom against existing and proven rom hacking tools ! Praise he who bumped a seven year old thread !
its kind of funny how long it took before somebody did it.
Well, it is more then that. It is difficult. You have to make sure you comply with the extreme limitations of the SNES, you have to go through the ROM with every single bitplane, and there is over 20 bitplane codecs in tile molester, and find which bitplanes have what. Then you have to keep note of all of the bitplanes and any graphics they have, if any at all. You then have to import the pallette every time you load the program up, and manually go to the directory with the zsnes save state for the pallette, which is tedious. Then you have maximum graphics size and palettes and loss of colour depth and run length encoding to deal with.
Well, it is more then that. It is difficult. You have to make sure you comply with the extreme limitations of the SNES, you have to go through the ROM with every single bitplane, and there is over 20 bitplane codecs in tile molester, and find which bitplanes have what. Then you have to keep note of all of the bitplanes and any graphics they have, if any at all. You then have to import the pallette every time you load the program up, and manually go to the directory with the zsnes save state for the pallette, which is tedious. Then you have maximum graphics size and palettes and loss of colour depth and run length encoding to deal with.
I know how irritating or time consuming it can be. even with all those great tools. Using them often comes down to having the patience to test everything when the locations or formats are not obvious... and taking notes of offsets and whatnot. i would not have the patience anymore, and i cant blame anyone else when they have none either.
Kickass. I suppose there's never been quite enough interest, but you've taken the initiative and I appreciate it.
I think it'd be fun if there was a modified version of Chocolate Doom with gameplay behavior and outward appearance identical to SNES Doom, yet can run PC data without whatever limits actual SNES Doom may have.
That way, whatever merit the off-brand knockoff gameplay may have can be better utilized. Not that it undermines your reverse engineering efforts, of course!
Thanks. The SNES version is the first version I played, so I've always had an interest in it and wanted to see something more done with it but never pursued any reverse-engineering efforts.
About the PC-SNES idea: maybe there could be a 30hz mode (actual SNES game runs @ 15hz), hi-res mode (instead of double-width columns) and the ability to actually circle-strafe.
No, the Super FX 2 (GSU-2) chip used in Doom runs at a clock speed of 21.7 mhz.
You can get higher FPS in the SNES version of doom on a real console by overclocking the Super FX chip (40mhz runs smoothly) and the benefit is that the Super FX should not overheat anymore than 21.7 mhz according to a starfox overclocking video, which also uses the Super FX. Only problem with overclocking is that when the enemies are standing, you know how they look like they walk in place I am assuming, well when it is overclocked their walking in place looks faster than sonic on meth, and the imp fireballs go faster. You can also use zsnes, which is a good emulator, which I find runs Doom like it was overclocked.
Some other emulators have Super FX overclocking emulation. Just google (snes super fx overclocked emulator)
Hi-res mode would be irrational. Single-width columns may make it look smoother, but it may cause performance issues and glitches, due to the fact they wrote the ASM code to use double width column rendering so this may require a whole render engine rewrite, which is HIGHLY illogical due to our lack of knowledge on how the ROM works, and the sheer amount of time it would take.
Also, about circle strafing. This would, again take time due to our lack of knowledge on the ROM, and would require a considerable reprogram of player controlling. It would also potentially lead to glitches, because for example the hit detection might be screwy, due to the rendering engine potentially not being able to handle rendering while turning and moving, and shooting. The player may also encounter issues such as bad hit detection, due to the fact we would have to make the hitboxes move with the player who is moving in circles at a fast rate. This would lead to game imbalance and potentially going through walls.
Overall, I think that what you are saying is illogical from the viewpoint of a ROM hacker. Please take the time to actually learn how the SNES and the ROM work internally before making suggestions. Not trying to be rude, but seriously though.
3a8082e126