When you are in Mednafen, if you press Alt + d, it will bring up the debugger. Then, if you press 2 or 3, it will show you something else. 2 takes you to the sprite sheets currently in use. 3 shows you all the bytes in the game. If you happen to have a cheat sheet of what each byte represents (say you hypothetically had the link https://datacrystal.romhacking.net/wiki/Super_Mario_Bros.:RAM_map ), you can change things in the game. Some important ones: 016 is enemies, 039 toggles the power-up currently on screen, 704 is swim when set to 0, 754 is the size of the current player. 0 is big, 1 is small, and there are other values that do weird things. 756 is power-up state. 75A is lives, 75F and 760 represent world and level. 79F controls how long you will be invincible. There are many other fun things, but these are the ones that you will probably tinker with the most.
Update time! So, this week, we looked at how each byte in memory can control different parts of a game. As you can guess from the paragraph above, we did this on Super Mario Bros. (Oh, quick note, this may cut off abruptly, because I am writing this past 12, and I don't know if Matt is at this minute rolling everything back; if he does, this will be an interesting entry.) It was pretty cool to see a goomba just suddenly turn into a piranha plant. The best part was typing in random values for the world and level, so you would get worlds that aren't normally in the game, but are still playable. Some are extremely interesting. If at all possible, you should try it out! I also enjoyed making myself invincible for as long as I wanted; I suspect that this could make the levels boring if over used… Oh well!
Now, what have I accomplished in Portal Kombat this week? Well, I'm glad you asked. What I have done is get a major chunk of those aforementioned if statements done! For the first player, I have managed to get the Firesquid's weapons working perfectly well, in addition to the Guy and Gal's sword. I can't tell you how much time I spent troubleshooting why the weapon froze at a certain part or moved in the wrong direction. It was quite the challenge (and quite a lot of code) to be able to get the two sprites making up the sword to move in unison. Once I got all those sprites to work well for player one, I decided it would be a brilliant idea to just copy/paste those sections into the player 2 part. Well, it might still be, but I should probably make sure next time that I change all the player specific variables to the right person before trying it out next time. I ended up freezing player 1 while player 2's weapon was active because of this. More work! Yay!
But that's not all! As I hinted at above, the player 1 sprite now freezes whenever their weapon is in use. It makes sense to me! The longer your weapon, the longer you're stuck. I also have the basics of collision detection set up. At the moment, all it does is send player 2 straight to the point (100, 100). I've also realized that due to the way the code runs, player 1's stuff always goes first, so unless we go over synchronicity soon (maybe still not even then), player 1 will have a distinct advantage. Although, I could just overcome that with some more if statements… AHHHHH!! FRUSTRATION!!!!