Hello there. Lately I've been playing Battletoads (Arcade), and there's one thing about memory (well, I think it's memory) that I can't really understand, and I was wondering if you might have the answer...
In short words, if you press the attack button near an object that can be grabbed (be it a weapon or an enemy), you grab it, but when there are two possible objects that can be grabbed, there's a logic I can't really understand. If I create a savestate just before picking one of the objects, I will absolutely always pick up the same one. No matter what I do (jump, walk all around the screen then reposition, press combinations of buttons...), I will always continue to pick up the same object. But if I play from an earlier savestate, then there's a chance that now I will absolutely always pick up the other object. My theory is that the game gives priority to the object that was loaded first, but if the screen scrolls automatically, is there still a chance of this happening? Another theory I have is that the objects are loaded in a somewhat random order, but is that also possible? Are there any other possibilities of how the game solves this problem?
EDIT: What I mean in other words is if you know why sometimes I pick one object, and other times the other object, being that they should always load the same way and they should always be in the same position, so the priority should always be given to the same object, but that's not the case.
Many games use a "sprite slot" system where each sprite on screen has an ID number, but there are only a very small number of possible ID numbers and so they get recycled a lot. When an object loads, therefore, it'll typically be given the lowest ID number that isn't in use at the time (but then that number will stay stable as long as the object stays loaded). This is particularly common on older platforms (like NES) due to the way that those platforms' graphics works.
My guess is that the object that's being targeted is always picking the object with the (highest/lowest) ID number, which is why you can't see a pattern but also can't get the results to change. In games where "which object goes in which slot" is important, it's normally a good idea to set up a memory watch to allow you to keep tabs on it; often you'll need to unload specific objects at specific moments to get other objects to load into the slot you want.
I guess you're using MAME? Its savestates are non-deterministic, they change the amount of cycles left to be executed basically every time you load them. A certain value doesn't get updated. So if there's some randomness to what you grab, it gets messed up on such state reloads.
I had a patch that fixed this, and you could probably try a build with it, but getting around to making it is problematic for me atm. There's a place where interim MAME builds are hosted, if you're willing to look for a commit where this patch is present (if got reverted eventually), I'll give you the clues.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Many games use a "sprite slot" system where each sprite on screen has an ID number, but there are only a very small number of possible ID numbers and so they get recycled a lot. When an object loads, therefore, it'll typically be given the lowest ID number that isn't in use at the time (but then that number will stay stable as long as the object stays loaded). This is particularly common on older platforms (like NES) due to the way that those platforms' graphics works.
My guess is that the object that's being targeted is always picking the object with the (highest/lowest) ID number, which is why you can't see a pattern but also can't get the results to change. In games where "which object goes in which slot" is important, it's normally a good idea to set up a memory watch to allow you to keep tabs on it; often you'll need to unload specific objects at specific moments to get other objects to load into the slot you want.
That makes sense. Thanks for the reply.
Well, while I've done some work on memory watch and was able to find a bit hard RAM Addresses, I'm still new to this and aren't too sure about how to search for such slots/objects. My guess is that I should watch at the changes of values before and after a loading, but is there some clue as to when the loading actually starts? Is it as soon as the object appears onscreen, or could it be before? Also, what numbers do ID normally have? And do objects have their own RAM Address? I guess they do as absolutely everything seems to have a RAM Address (which makes sense considering everything has to be saved somewhere), but I'm just guessing so I ask just in case.
feos wrote:
I guess you're using MAME? Its savestates are non-deterministic, they change the amount of cycles left to be executed basically every time you load them. A certain value doesn't get updated. So if there's some randomness to what you grab, it gets messed up on such state reloads.
I had a patch that fixed this, and you could probably try a build with it, but getting around to making it is problematic for me atm. There's a place where interim MAME builds are hosted, if you're willing to look for a commit where this patch is present (if got reverted eventually), I'll give you the clues.
Thanks too for the reply.
Yes, I'm using MAME. What you say about savestates makes a lot of sense actually. Before Battletoads (Arcade), I made lots of testing with Haunted Castle (also Arcade), and lots of weird things happened with savestates (including graphics, sound, etc.). Randomness really seemed messed. But... so there's a chance that the picking of objects is actually random? I don't think that's the case, but, is it possible?
And yes, while I'm still new at these things, I'd still like to know more about that patch. Could be a nice opportunity to keep learning about emulators and programming in general. So I'll appreciate any information on it. Thanks for telling me about it.
By the way, I just decided to look for Battletoads (Arcade) on Pugsy's Cheats Forums, and I found one cheat that is apparently related to the picking of weapons. It might refer to something else, but this could be it. Now the problem I have is that I don't understand how to get these cheats working. They are probably included in the cheats file, but I'd still like to know how to set cheats separately. Could you help me? Is there some post where this is discussed? (I'm reading a post about XML though... that may help a bit, but I'll still appreciate any help.)
Crap, the link I needed is dead. I'd have to build mame from source. This won't be soon at all :(
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Oops, that's bad. Well... for now it won't matter that much though. I'll see what I can do. Thanks.
By the way... Could savestates be also bound to randomness even after starting MAME again? That looks really crazy, but... could it be? It's just that when I used to play Haunted Castle, I really had this feeling that at times, I would most of the time get a certain pattern, but then, after some time passed, I would most of the time get another pattern. In the end I got to the conclusion that it was just me, but could it be that loading savestates (or doing other things) messes up with randomness even after closing MAME and starting again?
The thing is, the state doesn't update a certain variable, and it changes really often. It changes how much code is executed per frame. Literally EVERY time you load a state is unique, it's impossible to get identical outcome.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Sorry, I think I didn't explain it right. What you replied still helped me to better understand how savestates work though. I didn't fully understand what you meant in a previous reply, but now I understand.
What I was wondering was if the loading of savestates affects MAME long-term. In other words, if even after restarting MAME, the results will depend on the previous savestates you loaded in another MAME session, Honestly it doesn't make much sense, but I like having opinions. In theory, MAME completely resets the whole game (including scores and such, so in theory you are playing as if it was the first time), so as long as you don't load a savestate again, loaded savestates from another session shouldn't affect... right?
Non-determinism means anything can happen. They don't depend on proper savestates, so they don't really use/test them. Otherwise they'd have been fixed years ago.
My fix got reverted because some other consoles broke, and fixing them broke the savestates for yet other consoles. It's a mess, and you shouldn't imagine limits to what can happen. Even memory corruption in the app, and this can result in literally anything.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
So... To make sure nothing's changing, and that I'm playing the game pretty much as in the original version, I should download MAME again, and not ever use a savestate, so memory is always working correctly?
You can do that to verify some theories. Overall, it shouldn't be required of course. Not loading the existing states is the key.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Well, while I've done some work on memory watch and was able to find a bit hard RAM Addresses, I'm still new to this and aren't too sure about how to search for such slots/objects. My guess is that I should watch at the changes of values before and after a loading, but is there some clue as to when the loading actually starts? Is it as soon as the object appears onscreen, or could it be before?
There's no hard rule that forces games to do it a certain way, but most 2D games will load an object when it reaches a particular point relative to the camera. That might be the moment the object is visible onscreen, slightly earlier, or in some cases even slightly later (in these games you can see the object loading in). Bear in mind that the view shown onscreen might not go right to the edge of the screen, too (many games will have some sort of frame around the edge of the screen, maybe just a black rectangle, to hide objects that are in the process of loading so that people can't see them suddenly appear).
In 3D games, objects are more likely to load based on the player's position than on the camera's position (because otherwise, the console would have huge lag issues if the player decided to spin the camera round quickly).
Also, what numbers do ID normally have? And do objects have their own RAM Address? I guess they do as absolutely everything seems to have a RAM Address (which makes sense considering everything has to be saved somewhere), but I'm just guessing so I ask just in case.
Normally, an object's address will depend on its ID number; there'll be some place in memory that, say, stores information about the object with ID 5. Part of the reason to have a system like this is that not all the objects in the game can fit into memory at the same time, so the ID number system prevents two objects trying to use the same bit of memory. The ID numbers themselves are often just small integers (0, 1, 2, etc.), and might not be stored explicitly in memory (i.e. you determine an object's ID number by looking at the address where its data is stored, rather than the other way round).
Actually finding the memory addresses in question can be fairly hard; I can't think of a simple way to do it offhand. On some consoles, there'll be memory addresses reserved for sprite coordinates (e.g. the NES's OAM); you may be able to find the object loading code by monitoring for writes to that, but you'd likely need to decompile the code in order to figure out where it's storing the information about objects.
A self-fulfilling prophecy! :)
Use the command line to create MAME-RR.INI:
mame-rr -createconfig
or
mame-rr -cc
This will create MAME-RR.INI in the MAME-RR directory.
Modify MAME-RR.INI as follows:
cheat 1
Download Pugsy's MAME cheat database. MAME-RR uses MAME 0.139. MAME 0.145 and prior can not use the 7-Zip file format, so MAME 0.145 is the most recent version of the cheat database that can be used with MAME-RR. Extract CHEAT.ZIP from the downloaded file and place it in the same directory as MAME-RR.EXE.
Although MAME 0.145 is the most recent version of the cheat database that can be used with MAME-RR, cheats for an individual game can be manually extracted from any newer 7-Zip version of the cheat database and can thus be used with an older version of MAME that does not support the 7-Zip file format. Cheats for an individual game are stored as an XML file within the database. Place a game's XML file in the CHEAT subdirectory of MAME-RR to use it. A game's XML file in the CHEAT subdirectory will override that game's XML file contained within the database.
Well, I downloaded the latest version of WolfMAME (I was recording with that one, but will be using MAME-RR to try and find the RAM Addresses for the 'slots'), which is 0.200, and noticed something a bit weird. First of all, now the game needs an extra file (bmst2000.bin if I remember right), which I had to download to play the game. The game runs a bit faster, has a bit of differences in sounds and graphics but nothing too significant. However, regarding this 'targeting' problem, it looks like now the game has a tendency towards picking one of the objects. I still got the other object a few times, but it looked more random on WolfMAME0.106 (the other version I was using). As for MAME-RR, it seems to run similar to 0.200. Probably due to my MAME-RR version being 0.139, which is when more changes were made for ROMs I think. There are some things that look a bit odd, but as I was saying it's nothing significant and it's probably just me (well, probably). The randomness regarding targetting is still there, too. But I wonder if the loading being faster is affecting this. That could mean that the problem really is loading.
By the way, do you know why could this game have low volume on 0.200? It has the right volume even in MAME-RR, but volume is pretty low on 0.200. I tried increasing volume by other means but didn't seem to work. It looks like the game is 'supposed' to run that way, but it shouldn't, since it runs alright on other versions.
ais523 wrote:
ErisK wrote:
Well, while I've done some work on memory watch and was able to find a bit hard RAM Addresses, I'm still new to this and aren't too sure about how to search for such slots/objects. My guess is that I should watch at the changes of values before and after a loading, but is there some clue as to when the loading actually starts? Is it as soon as the object appears onscreen, or could it be before?
There's no hard rule that forces games to do it a certain way, but most 2D games will load an object when it reaches a particular point relative to the camera. That might be the moment the object is visible onscreen, slightly earlier, or in some cases even slightly later (in these games you can see the object loading in). Bear in mind that the view shown onscreen might not go right to the edge of the screen, too (many games will have some sort of frame around the edge of the screen, maybe just a black rectangle, to hide objects that are in the process of loading so that people can't see them suddenly appear).
In 3D games, objects are more likely to load based on the player's position than on the camera's position (because otherwise, the console would have huge lag issues if the player decided to spin the camera round quickly).
So in theory, if the camera is always fixed in one place, no other loadings should occur? Well, I'm not sure about the backgrounds and such but... The objects that I want to keep track of (or rather, the 'slots' containing them), they should keep the same value as long as the camera is still in the same place, right?
ais523 wrote:
ErisK wrote:
Also, what numbers do ID normally have? And do objects have their own RAM Address? I guess they do as absolutely everything seems to have a RAM Address (which makes sense considering everything has to be saved somewhere), but I'm just guessing so I ask just in case.
Normally, an object's address will depend on its ID number; there'll be some place in memory that, say, stores information about the object with ID 5. Part of the reason to have a system like this is that not all the objects in the game can fit into memory at the same time, so the ID number system prevents two objects trying to use the same bit of memory. The ID numbers themselves are often just small integers (0, 1, 2, etc.), and might not be stored explicitly in memory (i.e. you determine an object's ID number by looking at the address where its data is stored, rather than the other way round).
Actually finding the memory addresses in question can be fairly hard; I can't think of a simple way to do it offhand. On some consoles, there'll be memory addresses reserved for sprite coordinates (e.g. the NES's OAM); you may be able to find the object loading code by monitoring for writes to that, but you'd likely need to decompile the code in order to figure out where it's storing the information about objects.
I think I got it... The game loads the screen. Objects with ID 1 are saved in the memory address that tells information about objects with ID 1, objects with ID 2 are saved in the memory adress that tells information about objects with ID 2, etc. However, the data inside such memory adresses is not necessarily the ID number. It's just a number telling information about the object with such ID. Did I get it right?
£e Nécroyeur wrote:
ErisK wrote:
Is there some post where this is discussed?
A self-fulfilling prophecy! :)
Use the command line to create MAME-RR.INI:
mame-rr -createconfig
or
mame-rr -cc
This will create MAME-RR.INI in the MAME-RR directory.
Modify MAME-RR.INI as follows:
cheat 1
Download Pugsy's MAME cheat database. MAME-RR uses MAME 0.139. MAME 0.145 and prior can not use the 7-Zip file format, so MAME 0.145 is the most recent version of the cheat database that can be used with MAME-RR. Extract CHEAT.ZIP from the downloaded file and place it in the same directory as MAME-RR.EXE.
Although MAME 0.145 is the most recent version of the cheat database that can be used with MAME-RR, cheats for an individual game can be manually extracted from any newer 7-Zip version of the cheat database and can thus be used with an older version of MAME that does not support the 7-Zip file format. Cheats for an individual game are stored as an XML file within the database. Place a game's XML file in the CHEAT subdirectory of MAME-RR to use it. A game's XML file in the CHEAT subdirectory will override that game's XML file contained within the database.
Haha, a self-fulfilling prophecy, yeah, I guess so :) .
Thanks! I really was wondering about how to use these cheats. I didn't try for some days, but now I'll try again. It looks like the reason why they didn't work is because I was using 0.106. I had done everything as explained, but MAME would say I should 'unzip' them. So that's why.
As for using MAME0.145 with MAME-RR, what do you mean? If MAME-RR uses 0.139, is it still possible to 'combine' MAME.0145 with MAME-RR? Sorry for the question, I'm still not too used to these things.
As for using these cheats, I need to create a file called, for example, btoads.xml, and inside I need to copy all the code from Pugsy's Database? I looked for 'btoads' there and it's where I found an XML code with the cheats. Then, I need to create a subdirectory called cheats (I don't find it so I guess I need to create it), and put 'btoads.xml' there?
It looks like the reason why they didn't work is because I was using 0.106.
MAME-RR uses MAME 0.139. MAME 0.126 and prior can not use the XML file format, so MAME 0.130u2 is the earliest version of the cheat database that can be used with MAME-RR.
ErisK wrote:
As for using MAME0.145 with MAME-RR, what do you mean? If MAME-RR uses 0.139, is it still possible to 'combine' MAME.0145 with MAME-RR?
Yes, it is possible to use cheats from the MAME 0.145 version of the cheat database with MAME-RR, even though MAME-RR uses MAME 0.139, although the XML file for a game must be manually added. The version of the cheat database does not need to match the version of MAME that is being used, provided the version of MAME is capable of using the same cheat format. MAME 0.139 uses XML, but it can not use the newer 7-Zip database file that contains the XML files.
ErisK wrote:
As for using these cheats, I need to create a file called, for example, btoads.xml, and inside I need to copy all the code from Pugsy's Database? I looked for 'btoads' there and it's where I found an XML code with the cheats. Then, I need to create a subdirectory called cheats (I don't find it so I guess I need to create it), and put 'btoads.xml' there?
This will work. Alternatively, btoads.xml can be manually extracted from CHEAT.ZIP or CHEAT.7Z and then placed in the CHEAT subdirectory. The new XML code can then be appended to the exisiting file.
ErisK wrote:
By the way, I just decided to look for Battletoads (Arcade) on Pugsy's Cheats Forums, and I found one cheat that is apparently related to the picking of weapons.
This cheat is included in the current version of Pugsy's cheat database. Extracting btoads.xml from this database would elminate the need to copy and paste code, and also provides many other cheats.
So in theory, if the camera is always fixed in one place, no other loadings should occur? Well, I'm not sure about the backgrounds and such but... The objects that I want to keep track of (or rather, the 'slots' containing them), they should keep the same value as long as the camera is still in the same place, right?
In most 2D games, no objects that are currently onscreen will load into different memory locations as long as the camera doesn't move. (It's frequently the case that there are short-lived objects, like animations as the player's character moves, that load in and out even without the camera moving. But those rarely affect anything that was onscreen already.)
This will work. Alternatively, btoads.xml can be manually extracted from CHEAT.ZIP or CHEAT.7Z and then placed in the CHEAT subdirectory. The new XML code can then be appended to the exisiting file.
Alright, I was able to get the btoads cheats to work. However, what text editors are good for writing XML code? I used Notepad but I guess it doesn't really work for XML. MAME-RR actually started, but then an error message appeared, saying something about 'parsing', and MAME-RR closed. I guess that's because of spaces errors? So I couldn't make it work that way, but instead I looked for btoads.xml in the cheat file and copied it to the cheat subdirectory. That did work! Still, for copying XML code, is there some program that has to be used for it to be copied correctly?
Now I'm trying to understand what the script means. So far I think I get it, but I still have to do a few tests. The weapons cheat is actually a cheat to get a certain weapon when you press 'Enter' on the cheats select screen, but the RAM Addresses as well as the values from the XML file may be helpful for solving the targeting problem with loading.
Speaking of which, I was rereading an old post I had done some time ago asking about RAM Addresses in Haunted Castle. There, you gave me the Stage Select Address, which worked great. But back then I didn't know anything about XML so I couldn't really understand where you got it from. You said that from Pugsy's Database but I still didn't understand. Well, now I can see where you got it from. I took a look at hcastle.xml and indeed, you can tell which is the Stage Select Address (it's not that explicit but you can tell if you understand the script, which I do now). However, you also found an RNG Address. Do you remember where did you get that one? For what I read it seems like you had to search a bit more, but where?
(I know it's not really related to btoads, but it's still something that could help me.)
ais523 wrote:
In most 2D games, no objects that are currently onscreen will load into different memory locations as long as the camera doesn't move. (It's frequently the case that there are short-lived objects, like animations as the player's character moves, that load in and out even without the camera moving. But those rarely affect anything that was onscreen already.)
I was thinking about first finding the memory address for the camera. Then, by watching at that address, I may be able to figure out when it is actually moving and thus when objects could begin loading. I'm not sure it could work, but what do you think? I'll also try to apply the addresses/values I found in Pugsy's Cheat Database.
