Wolfenstein3D - SNES Uncut hack

[Shadowhazard]

Testet the new version and its very cool

Weaponswitch: it is possible to make the weaponswitch feature like in Doom for Snes?
If you pick up a stronger weapon that it will be used immediately. However, if you already own this weapon, it will only count as ammo. if you are out of ammo and run around with the knife and collect new ammo of a type then it shoud jump automatically to the strongest weapon of the ammo type you have.
Otherwise the big smile of BJ when you pick up a chaingun makes less sense^^


Stalking around with the knife is funny, it could be a bit faster if possible or it could make more damage. The Undead Soldiers for example, you cannot prevent them from attacking by stabbing them. So in later levels the Knife dosent save your life at the moment, it never does on snes but if it would more powerfull than it would help. The stronger knife should not work on bosses, at least only as usual. Even if it would have more power it would not possible to make the game end with it

The Machingun and Chaingun also a bit faster if possible.  cosmetically and sound faster and functionally just a bit more damage at least for the machinegun.

I think this changes would make the gameplay more fluent but not easy. Difficult will remain original snes.

Sometimes I have the feeling that the opponents can shoot through half-open doors or around the corner through the wall.  thats a thing on what we could keep an eye.

[DarkSamus993]

@DarkSamus993
Since now with the expansion, Sprites were moved to a different location, is it enough to change the starting address from $30000 to the new location? Have you changed the address of the table that points them?

Sprites can be moved to anywhere in the rom. The ptr table that links to them all is still at the same address (0xFDA6E - add 0x30000 to each ptr for true address). It's also "zero" compressed as it gets loaded and read from RAM.

The data transferred to RAM at bootup starts at 0x0FC002 - 0x0FFF42, with the preceding 2 bytes indicating when to stop reading data.

Code Select Expand


00FDB9 JSR $FED0     [00FED0] A:0FFA X:0000 Y:D0F9 S:0FFF D:0000 DB:00 nvmxdIzc  // entry point

// "Zero" decompression routine
00FED0 LDA #$0000             A:0FFA X:0000 Y:D0F9 S:0FFD D:0000 DB:00 nvmxdIzc
00FED3 TCD                    A:0000 X:0000 Y:D0F9 S:0FFD D:0000 DB:00 nvmxdIZc
00FED4 PEA $0FC0              A:0000 X:0000 Y:D0F9 S:0FFD D:0000 DB:00 nvmxdIZc
00FED7 PLB                    A:0000 X:0000 Y:D0F9 S:0FFB D:0000 DB:00 nvmxdIZc
00FED8 PLB                    A:0000 X:0000 Y:D0F9 S:0FFC D:0000 DB:C0 NvmxdIzc
00FED9 LDA $0FC000   [0FC000] A:0000 X:0000 Y:D0F9 S:0FFD D:0000 DB:0F nvmxdIzc  // load # of reads
00FEDD CLC                    A:EC61 X:0000 Y:D0F9 S:0FFD D:0000 DB:0F NvmxdIzc
00FEDE ADC #$1000             A:EC61 X:0000 Y:D0F9 S:0FFD D:0000 DB:0F NvmxdIzc
00FEE1 STA $02       [000002] A:FC61 X:0000 Y:D0F9 S:0FFD D:0000 DB:0F NvmxdIzc
00FEE3 SEP #$20               A:FC61 X:0000 Y:D0F9 S:0FFD D:0000 DB:0F NvmxdIzc
00FEE5 LDY #$C002             A:FC61 X:0000 Y:D0F9 S:0FFD D:0000 DB:0F NvMxdIzc
00FEE8 LDX #$0000             A:FC61 X:0000 Y:C002 S:0FFD D:0000 DB:0F NvMxdIzc
00FEEB LDA $0000,y   [0FC002] A:FC61 X:0000 Y:C002 S:0FFD D:0000 DB:0F nvMxdIZc
00FEEE BEQ $FEF8     [00FEF8] A:FC00 X:0000 Y:C002 S:0FFD D:0000 DB:0F nvMxdIZc  // if $00, get length...
00FEF0 STA $7E1000,x [7E1007] A:FCFF X:0007 Y:C004 S:0FFD D:0000 DB:0F NvMxdIzc  // else, write as is...
00FEF4 INX                    A:FC12 X:0043 Y:C05E S:0FFD D:0000 DB:0F nvMxdIzc
00FEF5 JMP $FF09     [00FF09] A:FC12 X:0044 Y:C05E S:0FFD D:0000 DB:0F nvMxdIzc

00FEF8 INY                    A:FC00 X:0000 Y:C002 S:0FFD D:0000 DB:0F nvMxdIZc
00FEF9 LDA $0000,y   [0FC003] A:FC00 X:0000 Y:C003 S:0FFD D:0000 DB:0F NvMxdIzc  // load length byte
00FEFC STA $00       [000000] A:FC07 X:0000 Y:C003 S:0FFD D:0000 DB:0F nvMxdIzc
00FEFE LDA #$00               A:FC07 X:0000 Y:C003 S:0FFD D:0000 DB:0F nvMxdIzc
00FF00 STA $7E1000,x [7E1000] A:FC00 X:0000 Y:C003 S:0FFD D:0000 DB:0F nvMxdIZc
00FF04 INX                    A:FC00 X:0000 Y:C003 S:0FFD D:0000 DB:0F nvMxdIZc
00FF05 DEC $00       [000000] A:FC00 X:0001 Y:C003 S:0FFD D:0000 DB:0F nvMxdIzc
00FF07 BNE $FF00     [00FF00] A:FC00 X:0001 Y:C003 S:0FFD D:0000 DB:0F nvMxdIzc  // if not done, loop...
00FF09 INY                    A:FC00 X:0007 Y:C003 S:0FFD D:0000 DB:0F nvMxdIZc
00FF0A CPX $02       [000002] A:FC00 X:0007 Y:C004 S:0FFD D:0000 DB:0F NvMxdIzc 
00FF0C BCC $FEEB     [00FEEB] A:FC00 X:0007 Y:C004 S:0FFD D:0000 DB:0F nvMxdIzc  // if not end of data, loop...
00FF0E PEA $007E              A:FC00 X:FC61 Y:FF43 S:0FFD D:0000 DB:0F nvMxdIZC
00FF11 PLB                    A:FC00 X:FC61 Y:FF43 S:0FFB D:0000 DB:0F nvMxdIZC
00FF12 PLP                    A:FC00 X:FC61 Y:FF43 S:0FFC D:0000 DB:7E nvMxdIzC
00FF13 REP #$20               A:FC00 X:FC61 Y:FF43 S:0FFD D:0000 DB:7E nvmxdizc
00FF15 RTS                    A:FC00 X:FC61 Y:FF43 S:0FFD D:0000 DB:7E nvmxdizc  // exit routine

With the added room from expanding the rom, we could store this data as uncompressed to make editing things easier (or at the very least, make a tool to decompress/compress it). It's a very simple routine to modify to make all data read as uncompressed.

@Shadowhazard
I'll look into your suggestions, can't promise they'll be merged into the main branch (it is Fire-WSP's project, so he gets the final say), but I can start with at least seeing what's possible. As for the weapon switching, I could make it more like Doom. I'll see what others think first.

[Fire-WSP]

Sorry, I am a little late to the party. Internet failure for several hours.
Was not able to test the new patch yet but will do after this post.

@DarkSamus993 @Squall_FF8
I would opt for packing all the sprites uncompressed into the rom.
This way we don't need a seperate programm to import/export it.
There are people who would like to mod the game more than I intend to.
Making the sprites directly accessible will help everybody in the end.
Be able to touch the sprite is vital.
This way we only need TileMolester or similar to make changes.
(Zelda64 is doing the same. The debug rom is uncompressed while the final is compressed)
I understand why they tried to save as much rom space as possible. Cartridges were expensive.
This won't matter today at all. If we need 16Mbit or 32Mbit for it, so be it.
I dont know how complicated this is for you but it sounds like a bigger procedure. We should test the game
very good to spot any possible problem.

How is the game loading the sprites?
will it load everything it needs for a level in ram before starting the level or is it loading stuff likes sprites only on demand?

I will also look into @Shadowhazard's suggestions.

Nice to see the project progressing.
Thanks everybody!

[DarkSamus993]

How is the game loading the sprites?
will it load everything it needs for a level in ram before starting the level or is it loading stuff likes sprites only on demand?

The game has a frame buffer in RAM ($7F2000 - $7F42FF) where it generates what is to be seen on screen (textures, sprites). Sprites are decompressed into this frame buffer and then the whole thing is uploaded to VRAM for the game to display it. It's a pretty interesting process.

Here's two examples of the frame buffer:


I can work on disassembling the routine for sprites (I have some notes already), and if storing sprites uncompressed would even be possible. Let's see what Squall_FF8 thinks, his tool may eventually support importing sprites.

[Squall_FF8]

@DarkSamus993 @Squall_FF8
I would opt for packing all the sprites uncompressed into the rom.
This way we don't need a seperate programm to import/export it.
There are people who would like to mod the game more than I intend to.
Making the sprites directly accessible will help everybody in the end.
Be able to touch the sprite is vital.
This way we only need TileMolester or similar to make changes.

I totally agree with you. Storing the sprites uncompressed will solve plenty of problems, without creating new ones (at least I cant think of any)

Sprites are decompressed into this frame buffer and then the whole thing is uploaded to VRAM for the game to display it. It's a pretty interesting process.

Yes its called 'double buffering' and is widely used in PC world even today. Actually in Version 3 of my tool I use it to make thing pleasant for the eye 

... and if storing sprites uncompressed would even be possible. Let's see what Squall_FF8 thinks, his tool may eventually support importing sprites.

Sure I can do import, but if sprites are uncompressed, this will not be necessary. You can set the uncompressed sprites to start at specific address, reserve the necessary space (fill with 0 if you wish) and then in already available editing tools the Sprites could be edited and re-inserted (imported).

[DarkSamus993]

Alright, sounds like we're in agreement then. I'll see what I can come up with. I'm thinking I might be able to just hook into the wall/floor texture loading routine since it is already capable of loading uncompressed graphics.

[Fire-WSP]

Okay, I have checked out the weapon switching.
This is a bit more complex it seems.
Your code works well, but it takes away a few important original features.
The original system is made so, that you always have the best possible weapon on screen automaticially.
In the unpatched game, if you start a new game, you have only the Handgun. You can not switch to the Knife
The knife is the last resourt if you are out of ammo. It is actually not there to be a full weapon. It is to weak.
in its current state. You can not make a play through with the knife like in resident evil.
That is why you can not choose it manually.

Also Handgun, Sturmgewehr and Chaingun is the same type of Weapon and use the same type of Ammo.
If you collect a new weapon like the Sturmgewehr in the first Level, the game switches directly
to the new and more powerful weapon. And you can not go back. Its like a permanent upgrade of the weapon type.
You can also say he throws the old weapon away and takes the new one.
If you have the Chain Gun for example and you are depleating your ammo,
the game switches to the knife (when there is no Flame Thrower and/or the Rocket Launcher in your arsenal).
If you now collect new ammo for the weapons, the game is directly switching back from the knife
to the Chain Gun.

If you have the Chain and find the Flame Thrower or the Rocket Launcher, it switches
to them but also enables weapon manual switching because you need to use them more carefully
There is less available ammo for them.

If you have the Flame Thrower and/or the Rocket Launcher in your arsenal already
and you depleating your ammo for the chain gun it won't switch to the knife but
instead to the Flame Thrower or the Rocket Launcher. It seems it switches
in this case to the next more powerful weapon available.

If you have wasted all your ammo for all weapons, the switches to the knife until you
found ammo for either the Guns, the flame thrower or the Rocket Launcher.

So switching through all weapons is actually not a feature of the game.
If we do that, it needs to be optional without changing the original way you collect guns.

In the V6 patch manual weapons switching is now a must.
I actually forgot to switch and was
playing until the end of level 2 just with the Handgun XD
In its current state the weapon change hack is not usable in the pure uncut.
But it could be very interesting for future haks since this alters the gameplay quite a bit.
It makes the game harder aswell since you need to take care about your weapon.

I want to propose something for the weapon switching. This is an improvement also for the Uncut.
The unpatched game uses Select for weapon switching.
This is not the best choice.
Most people use the left thumb to control the D-Pad and Select.
So if you switch the weapons, you can not walk for a moment.

The game uses X and Y for fast run. It is quite pointless to use two
buttons for that.
I would instead use X button for weapon change.
We could use only X and disable Select or we use both so that
Select switches back and X forth.

@DarkSamus993
Thanks for the explaination of the sprites.
Okay, lets wait for Squall_FF8s feedback
Edit: his feedback was faster than my post
Okay, lets see.

[Squall_FF8]

Alright, sounds like we're in agreement then. I'll see what I can come up with. I'm thinking I might be able to just hook into the wall/floor texture loading routine since it is already capable of loading uncompressed graphics.

Yeah it should be similar to the walls, except:
- Sprites were held as 8bpp bitmap (linear), while Wall are 4x4 tiles (32x32 pixels).
- Walls have internal size of 32x32 pixels, while Sprites are 64x64 pixels.
- Walls have 'normal' and 'dimmed' version.
- Walls are rotated at 90 degree

These old engines uses variations of what is called 'ray-cast' - the buffer is assemble by columns. Maybe that's why the walls are 90 degree rotated. Sprites are stored in 'compressed' variant by columns too. We might need to rotate our sprites at 90 degree too.

[Fire-WSP]

Yeah it should be similar to the walls, except:
- Sprites were held as 8bpp bitmap (linear), while Wall are 4x4 tiles (32x32 pixels).
- Walls have internal size of 32x32 pixels, while Sprites are 64x64 pixels.
- Walls have 'normal' and 'dimmed' version.
- Walls are rotated at 90 degree

These old engines uses variations of what is called 'ray-cast' - the buffer is assemble by columns. Maybe that's why the walls are 90 degree rotated. Sprites are stored in 'compressed' variant by columns too. We might need to rotate our sprites at 90 degree too.

as far as I know, the walls are rotated 90° counter clockwise and I think the are mirrored compared to the pc version walls.
I have made my wall textures in the same way.
From what I can see, the Sprites are in the same way stored.
Its actually like the frame buffer pictures above.

[Squall_FF8]

When 'compressed', Sprites were stored by columns, but that hardly could be called 'orientation'. Since we all want uncompressed, they should be stored rotated 90 degree, similar to Walls.

Technically speaking rotating an image to 90 degree, guarantee that columns of the image are stored consequently in the memory - easy to implement, fast speed in ray-casting (rendering the "3d" column by column). The orientation (clockwise or counter) is determined by how you render the image (left to right/right to left and/or how the buffer is transferred in VRAM.

But don't worry, you don't need to understand above info in order to make the hack. Most important is DarkSamus993 to find the routine that draws a wall. In best case he will able to use it without modification or writing a new one.

[Shadowhazard]

https://ibb.co/iPodzx

All Sprites cleaned and done.

[DarkSamus993]

Just wanted to say I'm still working on analyzing the old sprite routine. There's just a few things left to understand about how it scales the sprites, and then I can start coding the new routine. I also got the uncompressed sprites inserted into the ROM, all ready to go.

I should also mention that the wall texture loading routine is not going to be able to handle the sprites. This is due to sprites now having transparency to account for and that wall textures are 32x32 and sprites are 64x64.

[Squall_FF8]

Just wanted to say I'm still working on analyzing the old sprite routine

If old routine scale the sprites after they were 'decompressed', then you don't need a new routine, you already have it, just relocate the pointer to a ROM address (or copy a sprite from the ROM to where in RAM the routine expect to be).

I should also mention that the wall texture loading routine is not going to be able to handle the sprites. This is due to sprites now having transparency to account for and that wall textures are 32x32 and sprites are 64x64.

I already told you about the dimension, but you could copy the whole routine and change the dimension. Now, transparency is a different thing. What will happen if you use the the transparent color index on a wall?

DarkSamus993, could you post here the disassembly of the old sprite routine?

[SCD]

I checked out the latest patch, I noticed when you pick up the machine gun, it doesn't automatically select it for you, is there a way to fix this?

[Fire-WSP]

@SCD

this is the new manual weapon select function.
It is not yet finished.
DarkSamus993 is working on the new Sprite Function at the moment.
It looks like we should have editable sprites quite soon.

[DarkSamus993]

If old routine scale the sprites after they were 'decompressed', then you don't need a new routine, you already have it, just relocate the pointer to a ROM address (or copy a sprite from the ROM to where in RAM the routine expect to be).

The sprites are scaled as it is being decompressed, and written directly into the frame buffer. This means it will read and print the same column of pixels multiple times to make sprites larger. Here's an example:

I already told you about the dimension, but you could copy the whole routine and change the dimension. Now, transparency is a different thing. What will happen if you use the the transparent color index on a wall?

Sprites and walls do not have transparency, any color used will be printed to the screen. The frame buffer is used as a Mode 7 background image (so it uses all 256 colors). Technically, these are the only sprites on screen:

I'll have to code a check for the transparent color and tell the game not to print it to the frame buffer.

DarkSamus993, could you post here the disassembly of the old sprite routine?

Here's my notes on the routine so far: https://pastebin.com/z0M44NAc

[Shadowhazard]

Although I'm not a coder but still that is very interesting.

Here is a thing what i have in mind for later.
When Bj gets hit you see it on his face. But they made it so that bj gets bleeding very late 30% i guess.
It would be cool if we change that. He start bleeding at 50% the and Dead is dead.
Dont know if the orginal setting is also a censor enchancment but i never liked it.

Here is a Example how Gretel Grösse could look on snes^^
https://ibb.co/dfJT1c

Status Faces:
https://ibb.co/bYPSux

[SCD]

@Fire-WSP

Alright, I knew the new weapon system was added to the hack, but I didn't know it still needs some tweaks. Sorry about that.

@Shadowhazard

That's a neat rendition of how Gretle Grosse would look like if she was in this port that you made.

That is neat idea to add a set of faces for BJ when he hits 70% of his health bar, but I don't think there's room for it.

I don't think the original setting is a censor enhancement, I think they set it up like that because of cartridge space.

Another neat idea for this hack is maybe add the PC status bar faces to it, I found these from a sprite sheet in the ZDoom forums:


Including give the exclusive SNES items PC style colors for the optional PC VGA color patch, I also found these in the ZDoom forums as well:

[Shadowhazard]

to put more face in game would be cool but basicliy not possible because the pc and jaguar faces have other or less colors. the two faces i changed are there that BJ can show some teeth like in all other versions.
On snes he never shows teeth, i think that was to aggessive for nintendo
The other face are to much work to make them fit to snes version. I wanted to keep the Sprites as untouched as possible otherwise it would be my mod creation.

BUT...there is one face i would like to see in the snes version and this face would be not to hard to alter so it doesent loose its orginal form.
The face when the player shots rapid fire, changes to an angry face like in doom. This animation of bj is only in the jaguar version. This animation could play on snes when the player uses the chaingun or machinegun 2-3sec permanent fire.
A second face what would be portable is the zombie deadface when you get killed by Dr.Schabbs. After my Daywork i will try to convert it maybe we can also build it in later

For the my left picture for example i only had to copy and paste the Mouth from jag to snes sprite that was all. The right one with the shadow is to snes unique to change also the left bloody picture below. I tried but i had to change a lot to look really cool. It looked cool but i scrapped that.



Its very interesting they animated every Detail in Jaguar version. Bj can smile even he is almost dead...an how this looks

@scd when your pc version moddificaion is ready i will have a look because i want to know how the sprites look in game with those colors. But you wont get all colores in, you can test it. chose one snes sprite and put the similar pc sprite in. Do it quick with paint and you will see a lot of colors are not there. thats why gretel looks like this. She was basicly a mess after converting to snes colors...i had to change a lot.
All this green in those Weapons and Ammo you wont get it in the game without palette change.

[SCD]

I took a closer look at your edited version of the SNES status bar faces, you did a good job on adding more detail stuff to them.

You mean these ones:


I don't how to add sprites into the game, but I am experimenting on the colors, so far I made the Mutant look more like his PC counterpart: