Upside-down jetpac graphics encoding?
Opened this issue · 3 comments
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
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.
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.
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 😄