peekchar not giving expected values

[+Karl G]

I'm trying to use peekchar to determine which tile a sprite is overlapping, and the tile number I am getting back does not match the tile numbers as I see in Tiled, or in the skyscrapers.tmx file. There are actually two issues: the numbers imported from the map file do not match, and my value from peekchar seems to add 32 ($20) to the already incorrect result.

 

I have broken out my code into a sample program that shows the value returned by peekchar at a given screen character X,Y coordinate. The first two numbers are the X and Y character coordinates passed to peekchar, and the third number on the right is the number returned by peekchar.  All numbers are in hex.

 

I've attached a zip of my directory with source/data files.

 

Any ideas?

 

peekchar-problem.zip

[RevEng]

The character index values look normal to me, at least at first glance. You've put hiscore.png first in the same graphics block, which will take up the first bunch of character indexes.

[+Karl G]

34 minutes ago, RevEng said:

The character index values look normal to me, at least at first glance. You've put hiscore.png first in the same graphics block, which will take up the first bunch of character indexes.

Thanks for the tip about the graphics block. Putting the "incgraphic skyscraperstiles.png" first solved the first issue, but the index values still appear to be wrong to me (the same as I saw in the assembly). Looking at the first row only Y=0:

 

X=0: Value 2, expected 1

X=1-7: Value 6, expected 3

X=8: Value 12, expected 6

X=9-10: Value 0, expected 0 (correct)

X=11: Value 14, expected 7

X=12-18 Value 6, expected 3

X=19 Value 10, expected 5

 

My "expected" values are what I'm seeing in Tiled for the tile ID, as well as in skyscrapers.tmx (subtracting one from the values in the source file as Tiled does).

[RevEng]

"set doublewide on"

 

The 7800 still uses the byte index in the graphics block of the character set as the character index, even with doublewide on. So the first double-wide character is index 0, the second double-wide character is index 2, and so on.

 

peekchar and pokechar need to reference the absolute hardware character indexes used. They don't know or care if the character buffer came from tiled or some other source. I can add a note to the docs, so that's clear.

[+Karl G]

D'oh! Thanks. In retrospect, I should have noticed that my expected value was always half of what was being shown.

[RevEng]

You're welcome. I've added a note to the docs for peekchar+pokechar along these lines, which will show up in the next release.