Upside-down jetpac graphics encoding?

[phillipeaton]

Hi Pob, I was having a look at the binary numbers defining this graphic and they don't seem to match the graphic. Looking a bit closer, I then spotted that the data is upside down and mapped in 16-bit words, not bytes! Is that something you'd previously noticed? I spotted the some thing on one of the rocket bitmaps I looked at. I have found the same graphic in the VIC-20 version and the numbers are the right way up and mapped in bytes only.

My numbers are:

fcb     %00011000 ; 3D83: 18 
fcb     %11111111 ; 3D84: FF 
fcb     %11111111 ; 3D85: FF 
fcb     %10001011 ; 3D86: 8B 
fcb     %10111011 ; 3D87: BB 
fcb     %10011011 ; 3D88: 9B 
fcb     %10111011 ; 3D89: BB 
fcb     %10001001 ; 3D8A: 89 
fcb     %11111111 ; 3D8B: FF 
fcb     %11111111 ; 3D8C: FF 
fcb     %00011000 ; 3D8D: 18 
fcb     %00011000 ; 3D8E: 18 
fcb     %11111111 ; 3D8F: FF 
fcb     %11111111 ; 3D90: FF 
fcb     %10001010 ; 3D91: 8A 
fcb     %10111010 ; 3D92: BA 
fcb     %10001010 ; 3D93: 8A 
fcb     %10111010 ; 3D94: BA 
fcb     %10111000 ; 3D95: B8 
fcb     %11111111 ; 3D96: FF 
fcb     %11111111 ; 3D97: FF 
fcb     %00011000 ; 3D98: 18 

or with the 1's removed:

 fcb     %000  000 ; 3D83: 18
 fcb     %         ; 3D84: FF
 fcb     %         ; 3D85: FF
 fcb     % 000 0   ; 3D86: 8B
 fcb     % 0   0   ; 3D87: BB
 fcb     % 00  0   ; 3D88: 9B
 fcb     % 0   0   ; 3D89: BB
 fcb     % 000 00  ; 3D8A: 89
 fcb     %         ; 3D8B: FF
 fcb     %         ; 3D8C: FF
 fcb     %000  000 ; 3D8D: 18
 fcb     %000  000 ; 3D8E: 18
 fcb     %         ; 3D8F: FF
 fcb     %         ; 3D90: FF
 fcb     % 000 0 0 ; 3D91: 8A
 fcb     % 0   0 0 ; 3D92: BA
 fcb     % 000 0 0 ; 3D93: 8A
 fcb     % 0   0 0 ; 3D94: BA
 fcb     % 0   000 ; 3D95: B8
 fcb     %         ; 3D96: FF
 fcb     %         ; 3D97: FF
 fcb     %000  000 ; 3D98: 18

[pobtastic]

Mr Eaton!!! Well hey!!! I hope you are well 😄

Yeah, all of these write-ups are half-finished and that they're vertically flipped is something I should really point out...

https://github.com/pobtastic/ultimate/blob/main/sources/jetpac/jetpac.ref#L80

Which is ...

#UDGARRAY($size,attr=$attr,scale=4,step=$size,mask=1,flip=2)

(Notice the "flip" ~ https://skoolkit.ca/docs/skoolkit/skool-macros.html#udgarray)

flip is 1 to flip the array of UDGs horizontally, 2 to flip it vertically, 3 to flip it both ways, or 0 to leave it as it is (default: 0)

So it is intentional honest! 😆

Now, I can't speak for the VIC-20 but a lot of Spectrum games store their sprites like this. I couldn't exactly tell you why though, just that for sure all the Ultimate games do, Dizzy as well I believe.

It's likely to do with optimising of rendering them to the screen, but I'm not really at the critique point of writing it all up yet. That'll come later I'm afraid.

[phillipeaton]

Yes, all good at this end, I hope at your end too!

Interesting, given smooth-scrolling sprites must have a lot of copying of data from somewhere to another, maybe it's faster to do a countdown to zero and use it as an offset when copying, something like that.

In the VIC-20 version, they're the right way up, but they don't line up at all, working through the code will be challenging!

Yours may be a WIP, but I'm sure it'll take a long time for me to get the VIC version anywhere close.

[pobtastic]

Yeah, we're okay thank you! Just working far, far too much!

I do plan to look into all of this at some point - I really truly adore working these disassemblies out, so I will get back to it when I have more free time. This would be an excellent thing to step through and let it draw one line at a time (we're so spoiled with the tools we have these days!!!) for the write-up - I'll definitely keep this in mind!

Hope to see you when you're over some time 😄