#1300 pokemon ranger graphic bug

[asl97]

from what i can find out, this bug happen to 'Sub BackGround 0'(the top screen)
on the pokemon ranger game(the first one), the map thing isn't aline properly,
in the picture 4, you can see in the map viewer, it show how it should aline but it aline a little too up or down, when move select up or down to next entry(as shown in first picture and second picture), it jump ether a little higher or lower, third picture show it effect the words in the game and sometime block the radar thing.

try changing the settings, nothing seem to fix it, it been there since version 0.9.7, i think

picture 1

picture 2

picture 3

picture 4, note: picture not show fully in preview, see here if needed:
http://asl97.blog.com/files/2013/06/0986-Pokemon-Ranger-EFireX.png

sorry for the bad english, not so good at explaining things in good english.

[zeromus]

link broken. inline pictures mising.

[asl97]

omg, it happening again...
i will upload those pictures to a other site in maybe a few mins

[asl97]

i uploaded new pictures a few weeks ago already,
bump the bug report a few times already
can someone at least reply?

[zeromus]

looks like a timing bug, but im not sure...

the game is continually manipulating the sub BG0 scroll register to make the screen have a warpy effect while transitioning. the math and register writes for this happen during a hblank interrupt, which is gated by a check for vcount<192. somehow the math is getting off-phase.. its supposed to be ending with a scroll of 0, but its ending with some weird random scroll. this despite the fact it's always doing 192 writes per frame.

it looks like after the game thinks the BG is scrolled into position, it disables the hblank interrupt. perhaps it is disabling it a little bit too soon

[asl97]

i am guess there a way to temp fix this with lua?
maybe force the BG scroll to be 0 after the hblank interrupt?
or maybe forcing it only for this series cause the whole series got this bug.

[zeromus]

you could definitely solve this with a lua script which just reset the BG scroll values to be appropriate after each frame. maybe you could hook the BG scroll read/write operations, detect the pattern, and correct it.

we're not going to add a hack of that type to the emulator to solve this type of bug in a game.

[asl97]

i thought as much, adding a hack just for a game is kind of unrealistic, there might be other game that got this bug too

it better to fix it at the source of the problem,

i notice that the scroll move about* the same space as the last,
after making it do the warpy effect a few times, it would move back to the start

eg:
let say the scroll start at 0,
then it move up a little, but the amount move is the same
so let say the max is 99, after that it would go back to the start, 0

start:
0
20
40
60
80
0  // return to start and start from top again

so i guess there might be some exception/error happening with the math that get the value off by the same (about*) amount each time

*i ain't so sure it 100% the same

[zeromus]

it is a timing issue and will never be solved except accidentally when timing improves

[asl97]

iirc, the lua on desmume is undocumented, i tried for a long time but nothing seem to work...

so, can you whip up some lua code that force it to be 0 and stay at 0 for me please?

edit: after talking and researching a whole lot more,
here the lua script to temp fix this error:

local function AwesomeFn()
memory.writeword(0x04001012, 0002)
end
gui.register(AwesomeFn)

[zeromus]

the lua is similar to every other emulator's lua. there are plenty of examples on the web for snes9x, fceux, bizhawk, gens, etc. good luck.

[Gameskiller01]

Hey, I know this thread is literally years old at this point, but I was wondering if you still had any knowledge as to how to find the memory address for this? It seems like the issue is fixed in DeSmuME by default now, but it still persists in DraStic, and it seems like the reason I can't get this Lua to work is because the memory address is different in my ROM. What I've got so far is:

function on_load(game)
end

function on_unload()
end

function on_frame_update()

  memory.writeword(0x04001012, 0002)

end

which should work fine, but when I look at that memory address in the exact same ROM in DeSmuME, it's completely empty. The memory addresses only seem to go up to 027C3FFF in my ROM, so it would be extremely helpful if you could remember how you found the original memory address in the first place. Thanks!

[zeromus]

That's a hardware register. The memory address isn't different in your rom. The address was found by thinking "I want to change X" and finding the hardware register for X.

[Gameskiller01]

OK, thanks! I really didn't think anyone would respond at all to this, let alone so quickly! Do you know exactly how I would find the hardware register then, or, if the hardware register is correct even in DraStic using my ROM, why it's not working? The Lua code should be fine as I just modified the default example script from the DraStic team (which I confirmed did work) to write that value to memory on every frame update, which it seems is like what the gui.register() function was doing in the original script. Again, thanks for the help!

[zeromus]

I don't see "memory.writeword" in the drastic docs. your script should actually be crashing. figure out how to check a log for crashing scripts

[Gameskiller01]

I wasn't able to figure out how to log for crashing scripts, but your comment did actually lead me to looking for DraStic's version of memory.writeword, which then led to me actually getting a working script! Kinda. It seems to have a problem with transitions, so it'll work fine when the game is loaded, or if I open the menu screen which reloads the top screen, or if I switch entry in the Browser. However, when I first load up the Browser, or whenever I go through a door or transition into a new area, it'll become all messed up again. Thanks for all the help - I doubt I would've even got a semi-working script without it, but if you do have any ideas on how I could fix this issue then the help would still be greatly appreciated. This was the simple script I managed to throw together to get it semi-working:

function on_load(game)
end

function on_unload()
end

function on_frame_update()

  drastic.set_ds_memory_arm9_8(0x04001012, 0004)

end

[zeromus]

you adapted desmume's writeword (16bit) to drastic's 8bit write. That register might not accept 8bit writes.

[Gameskiller01]

Thanks! Unfortunately, chaging it to drastic.set_ds_memory_arm9_16 yields the exact same results as before. I made a quick video to show exactly what I'm talking about: https://i.imgur.com/HqJtoL0.mp4

[asl97]

picture 1
http://i40.tinypic.com/mwac5g.jpg
picture 2
http://i43.tinypic.com/rruzv5.png
picture 3
http://i42.tinypic.com/316p6k0.png
picture 4
http://i44.tinypic.com/mmrl6o.png

instead of using inline pictures, i will just post the link to it
don't think people would like to waste bandwidth by loading the same picture from different source once the pictures from my blog start working again.

[asl97]

is the picture loading now?

[asl97]

anyone?