Doom SNES player data in RAM

[lunaark]

So, I took the liberty of going into Geiger's SNES9X Debugger and opening the Doom SNES ROM (I used Geiger's SNES9X Debugger because doing memory editing/viewing is alot easier and potentially more reliable than with BSNES-Plus.)

I went to around 0x6F0 in memory, and started moving.

I noticed some bytes that were not changing changed. I let go of the button and the byte went back to default. I pressed the same button again, and it changed. I paid close attention to detail, and paid attention to synchronization of byte changing to stuff happening on screen.

I managed to find some stuff out.

1. Near the beginning of RAM, there is a slowly changing byte. Because I was curious, I changed it, and the screen did something weird. It cut off the right part of the screen (about 40% I would say) and moved it to the left, it is hard to explain. It made it awkward to control, and often you would run into walls.

2. I know it is pretty obvious, but some confirmation. Weapon bobbing is not tied to how long you go forward, but tied to speed.

3. For some things, there is 2 or more locations in RAM that all change to the same byte at the same time, which leads me to believe that this might slightly impair ROM hacking for these things, as it may cause some confusion and a bit of searching

4. The most important and wondered of all, I found out why circle strafing is not possible and I will go into a short amount of detail that should speak for itself.

There appears to be 2 bytes in RAM that hold what button is being pressed.

The first one (I think it is the first but might be the second) holds whether you are pressing up, down, left, or right, and the second holds whether you are pressing A, B, X, or Y. You have one guess as to where whether you are pressing L or R is held.

If you guessed the one for up, down, left and right, you are right!

This seems to imply that unlike the Doom wiki says about circlestrafing in SNES Doom to be removed due to the lack of monster infighting, it simply appears that it is because if you are circlestrafing, you will be using up both bytes because of the fact you are moving and strafing, which is 2 inputs it has to handle. As such, since there would be nowhere to hold if you are shooting, they just decided to put L and R with the byte that handles up, down, left and right.

Think about it. If you can't shoot while circlestrafing, that completely destroys the purpose.

5. There is only 16 movement speeds for the player. While doing the movement test, when going at max speed it was only 16 bytes higher than the default.

6. I found something funny. At a certain point in RAM, there is a byte that if you change, then press something on the controller it won't work. Naturally, I got intrested and just started going nuts on all the buttons, then I changed it back to the byte it was before, and I literally did everything I pressed all at once.

Because of this, I will name it the Doomguy Seizure Byte.

Now, here is the offsets for any of you nerds.

NOTE: I might accidentally be one byte off for most of them, try going one byte back if it doesn't work.

0x710 in the BSNES-Plus debugger (S-CPU bus)
0x7E0710 in RAM

It goes up every time you move, and when you slow down and/or stop it goes back.

It appears to be a speedometer, and if you manually set it in the ram you will start getting weapon bobbing

0x6F7-6F8 in the BSNES-Plus debugger (S-CPU bus)
0x7E06F7 - 0x7E06F8 in RAM

Changes when you turn, changing them will make you turn

0x6BC in the BSNES-Plus debugger (S-CPU bus)
0x7E06BC in RAM

Goes up everytime you press a button on the controller.

Change this hex value, spam the controller, and then set it back to the default value and you will do everything you pressed at once

0x6E6 and 0x705 and in the BSNES-Plus debugger (S-CPU bus)
0x7E06E6 and 0x7E0705 in RAM

Controls the status bar face.

22 is looking left, 24 is looking at the center, 26 is looking right

0x02B in the BSNES-Plus debugger (S-CPU bus)
0x7E002B in RAM

Not exactly player data, but kind of. Changing this to 00 will split your screen and swap it a bit. Hard to explain.

I'm still not as good at ROM hacking as that mopoz guy who figured out all the level data on his own.

P.S. I can't figure out how to freeze a byte in RAM, because sometimes it makes the emulator crash or doesn't work (I do a breakpoint, and boom it crashes. Any SNES nerds please tell me how I do a proper breakpoint that can't be written to but can be read from.)

[Quasar]

http://doomwiki.org/wiki/Super_NES#Details

Hmm I don't see anything here about circle strafing having anything to do with monster infighting being disabled.

You sure you're using the correct and proper website?

[Revenant]

TheLoneSurvivor said:

So, I took the liberty of going into Geiger's SNES9X Debugger and opening the Doom SNES ROM (I used Geiger's SNES9X Debugger because doing memory editing/viewing is alot easier and potentially more reliable than with BSNES-Plus.)

Any particular reason(s) why?

There appears to be 2 bytes in RAM that hold what button is being pressed.

The first one (I think it is the first but might be the second) holds whether you are pressing up, down, left, or right, and the second holds whether you are pressing A, B, X, or Y. You have one guess as to where whether you are pressing L or R is held.

If you guessed the one for up, down, left and right, you are right!

This seems to imply that unlike the Doom wiki says about circlestrafing in SNES Doom to be removed due to the lack of monster infighting, it simply appears that it is because if you are circlestrafing, you will be using up both bytes because of the fact you are moving and strafing, which is 2 inputs it has to handle. As such, since there would be nowhere to hold if you are shooting, they just decided to put L and R with the byte that handles up, down, left and right.

Think about it. If you can't shoot while circlestrafing, that completely destroys the purpose.

Those two bytes are just a mirror of the controller 1 input flags, which are updated once per frame. Nearly every game keeps something like this in RAM, with the bits in exactly the same order.

The fact that the bits for L/R and the D-pad make up different parts of the same byte has absolutely nothing to do with the (in)ability to circle strafe. It's perfectly possible for the game to handle more than two inputs at once; otherwise how would you be able to run, shoot, and open doors at the same time?

The truth is that the game's movement system just wasn't designed to allow the player to turn and strafe at the same time. In fact, the same 16-bit variable (7E06F6-06F7) is used for both strafing speed and turning speed, depending on which one you're doing; they could have just as easily used two different variables for this but apparently being able to strafe and turn at the same time isn't something the developers expected people to actually do.

P.S. I can't figure out how to freeze a byte in RAM, because sometimes it makes the emulator crash or doesn't work (I do a breakpoint, and boom it crashes. Any SNES nerds please tell me how I do a proper breakpoint that can't be written to but can be read from.)

That's because Geiger's debugger is very... buggy (imagine that). There are far too many ways to crash it or otherwise make it stop working, which is one of the big reasons I started bsnes-plus instead.

[lunaark]

Revenant said:

Any particular reason(s) why?

Those two bytes are just a mirror of the controller 1 input flags, which are updated once per frame. Nearly every game keeps something like this in RAM, with the bits in exactly the same order.

The fact that the bits for L/R and the D-pad make up different parts of the same byte has absolutely nothing to do with the (in)ability to circle strafe. It's perfectly possible for the game to handle more than two inputs at once; otherwise how would you be able to run, shoot, and open doors at the same time?

The truth is that the game's movement system just wasn't designed to allow the player to turn and strafe at the same time. In fact, the same 16-bit variable (7E06F6-06F7) is used for both strafing speed and turning speed, depending on which one you're doing; they could have just as easily used two different variables for this but apparently being able to strafe and turn at the same time isn't something the developers expected people to actually do.

That's because Geiger's debugger is very... buggy (imagine that). There are far too many ways to crash it or otherwise make it stop working, which is one of the big reasons I started bsnes-plus instead.

So, if there is a 16-bit variable at 6F6-6F7 for strafing and turning speed, it would theoretically be possible to make them into 2 8-bit variables, modify the code to use 8-bit variables, make some adjustments to compensate for there being only 255 values rather than 65535, store the strafing speed at 6F6, and store the turning speed at 6F7.

This would save 2 bytes of space (barely anything, but you can at least make another 16-bit variable or 2 8-bit variables), but the only problem is that it might lead to problems, because you would have to reprogram the game to store those variables as 8-bit, but even if you compensate for it, it might lead to the reduced turning resolution problem while recording demos vanilla doom had, on a lesser or greater level depending on how well you compensate for it.

I'm not sure how well it would work, but if done right it could work.

I honestly go way too far when it comes to this kind of thing.

[fraggle]

It's great that you're doing this investigation. But posting threads on Doomworld might not be the right place for it - if people need to find these details in the future they'll have to dig through a ton of old forum threads. How about you detail all this on the Doom Wiki instead?