Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: ZippyDee on March 26, 2011, 04:58:58 am
-
I'm working on a game in which I want to use 12x12 sprites, and I would REEEEEEEEEEALLY rather not have 48 wasted bits for every sprite, so I'm looking for an efficient method of displaying 12x12 sprites. If I knew how to access data from an Axe program, I'd just figure out a 12x12 routine using my small knowledge of ASM. Sadly, I don't know how to do that, so I can't. :P
Any suggestions?
Thanks!
-Zippy Dee
Edit: I know how I'd write one in Axe, I just don't know if it would be very optimal, so I guess that's really what I'm looking for: either an assembly routine or an optimized axe routine.
-
I'm working on a game in which I want to use 12x12 sprites, and I would REEEEEEEEEEALLY rather not have 48 wasted bits for every sprite, so I'm looking for an efficient method of displaying 12x12 sprites. If I knew how to access data from an Axe program, I'd just figure out a 12x12 routine using my small knowledge of ASM. Sadly, I don't know how to do that, so I can't. :P
Any suggestions?
Thanks!
-Zippy Dee
Edit: I know how I'd write one in Axe, I just don't know if it would be very optimal, so I guess that's really what I'm looking for: either an assembly routine or an optimized axe routine.
If you know how to make it using Assembly, I suggest Axioms, in case you don't know what they are, they are subroutines coded in pure Assembly but that can be used in Axe.
-
I could probably write a crude routine in assembly, but as I said I don't know how to access data defined within the Axe program.
-
I could probably write a crude routine in assembly, but as I said I don't know how to access data defined within the Axe program.
There's an example on how to use Axioms in Axe 0.5.0's download and I guess you can find some explanations there...
-
Great, thanks! Runner12 suggested that I could just save 12x16 sprites and display them as 16x16 and therefore only end up with 6 bytes wasted. I think I'll live with that for now. But this Axiom system is really well defined! I'll certainly be using them for other things at some point.
-
You might consider storing them in a packed form and only uncompressing them when your program starts up.
Or I could write a routine for you. What type of sprites are we talking about (OR, XOR, masked, grayscale, clipped, ...?)
-
Yeah, I did think about decompressing on runtime, and that could work...The sprites I'm thinking of using would be masked 4-level grayscale, because I'm too ambitious for my own good. :P
-
Oh, OK. So you'd be looking at 18 bytes of wasted space per sprite, not 6. Would you give every sprite its own mask, or share a mask between multiple sprites?
Also, I don't really know how grayscale works in Axe. Which buffers do you use?
-
Also, I don't really know how grayscale works in Axe. Which buffers do you use?
appBackUpScreen (L3 to Axe users) is the back buffer.
plotSScreen(L6 to Axe users) is the front buffer.
-
Oh, this is confusing, but I think I understand now. That's not what "back" and "front" mean in normal usage. So is appBackUpScreen "light" and plotSScreen "dark", or vice versa?
-
plotSScreen "black and white"
appBackUpScreen "light/dark grey"
EDIT: Actually that's not strictly true. plotSScreen and appBackUpScreen combine to make dark grey and black.
plotSScreen + appBackUpScreen = Black
plotSScreen = Dark Grey
appBackUpScreen = Light Grey
0 = White
-
But what I'd be using is 3 12x12 sprites. The first two sprites would each be drawn to their corresponding buffer (plotSScreen/appBackUpScreen), but they'd first be masked using the third sprite. That allows me to use 4 levels of grayscale and still preserve the background (which I'd keep in another place, probably an appvar or something then delete at the end).
-
That's sort of what I was asking before, about whether you'd want to have the mask as part of the sprite or as something separate.
I was assuming you'd want to draw everything (mask and both image planes) in one pass, but using multiple passes is also an interesting idea; it would make the code much simpler (hence smaller), as well as more flexible, but also somewhat slower.