Posted: 12/21/2015 10:22 AM
(Edited: 12/21/2015 10:49 AM)
Post subject: Ram "flickers" at Tetris World
Quote
Tavados
Joined: 12/21/2015
Posts: 5
Hi there, hopefully I chose the correct category. So, I want to implement some machine learning and I chose Tetris World for the GBA as platform to do so. By now I got several ram addresses that contain the x and y of the current blocks vertices. Unfortunately the values "flicker" a lot. For example x is 32(goes in steps of 8 when moving left or right) and y is 10(decrements whenever the block goes down) and in the next tick they suddenly are at seemingly arbitrary values and then go back to normal. If I go for 4Byte unsigned they jump to several millions, if I go for signed, then obviously also to negative millions and even if i set the size to 2 or 1 Byte, the values jump around a lot and don't stay at the values that would make sense. Has anybody got an idea, why that happens and how I could fix that? It would suck if I had to make a sanity check for each value every time. Edit: I made a gif, so you can see what i mean. here
Posted: 12/21/2015 10:38 AM
Quote
Invariel
He/Him
Editor, Site Developer, Player (171)
Joined: 8/11/2011
Posts: 539
Location: Toronto, Ontario
Arcade TAS of 2023
I don't have access to Tetris Worlds at the moment, so I can't directly test this, but just to clarify, when you are looking at one-byte addresses, are you adding entries for each of the four bytes that you are looking at, or just retaining that list?
I am still the wizard that did it. "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." -- Satoru Iwata <scrimpy> at least I now know where every map, energy and save room in this game is
Posted: 12/21/2015 10:52 AM
Quote
Tavados
Joined: 12/21/2015
Posts: 5
When I change to 1Byte, I look at each quarter of the 4Byte address. So when 7754@4Byte flickers, then I will look at 7754,7755,7756,7757@1Byte! Edit: Either way, the important information seems to be only in the first Byte (for 7754 [0,18] would be in sane range) but it "flickers" to several hundreds when looking at 1ByteUnsigned.
Posted: 12/21/2015 12:55 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
What is the maximum useful value that x and y would contain? Perhaps the byte is being used for more than 1 thing. For instance, maybe the first 7 bits are the x value, and the 8th is being used for some flag.
It's hard to look this good. My TAS projects
Posted: 12/21/2015 1:03 PM
Quote
Tavados
Joined: 12/21/2015
Posts: 5
x goes from 0 to 9 and y goes from -1 to 19 (-1 is for when e.g. the square spawns at the very top, only showing the lower half). As I said I also looked at the values Byte by Byte and it doesn't make sense either. For example the x-coordinate of part0 (of the 4 part object) is at 0x7750, then the actual position is in 7750 itself, not in 7751,7752,7753. Also that value jumps from e.g. 7 to 0 then to 24 etc. Is the IWRAM the only legit domain to find those values?
Posted: 12/21/2015 1:20 PM
Quote
TASeditor
Editor, Skilled player (1536)
Joined: 7/9/2010
Posts: 1319
Glitchy TAS of 2015 NES TASer of 2014 Speedy TAS of 2014 NES TAS of 2013
You set them to 4 bytes, try 1 or 2 bytes.
Favorite animal: STOCK Gt(ROSA)26Sortm1.1(rtTA,EGFP)Nagy Grm7Tg(SMN2)89Ahmb Smn1tm1Msd Tg(SMN2*delta7)4299Ahmb Tg(tetO-SMN2,-luc)#aAhmb/J YouTube Twitch
Posted: 12/21/2015 1:37 PM
Quote
Tavados
Joined: 12/21/2015
Posts: 5
I said twice that I did that already, maybe I'm formulating it wrong. I tested 4Bytes, I tested 2Bytes, I tested 1Byte. In each case the memory jumps around to values that don't make sense.
Posted: 12/21/2015 5:04 PM
Quote
zeromus
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
This is completely typical results. You're looking at the stack. It's full of temporary values. For this game, look in EWRAM instead. $5040 seems promising
Posted: 12/22/2015 4:37 PM
Quote
Tavados
Joined: 12/21/2015
Posts: 5
Believe it or not, but I already looked to the EWRAM. Yea, 005040 contains x and 005044 contains y, but only of the center of rotation. There doesn't seem to be x and y for all parts, which I definately need. With another variable telling the rotation of the block it would technically be possible aswell, although I really hope to straightup get four x and y coordinates.
Posted: 12/22/2015 4:53 PM
Quote
Masterjun
He/Him
Site Developer, Skilled player (1987)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Exotic platforms TAS of 2020 Speedy TAS of 2018 PC TAS of 2018 Glitchy TAS of 2015 TASer of 2014 SNES TASer of 2014 TAS of 2014 SNES TAS of 2014 Funny TAS of 2014 Glitchy TAS of 2014 TASer of 2013 SNES TASer of 2013 NES TAS of 2013 SNES TAS of 2012 Funny TAS of 2012
Tavados wrote:
With another variable telling the rotation of the block it would technically be possible aswell, although I really hope to straightup get four x and y coordinates.
You can hope all you want. If the game calculates it by using the center of rotation, rotation position and block id, then there won't be any useful address for you to hope for. This is where a lua script can solve the issue by recreating how the game calculates the positions. Or you can hope.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)