Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: ACagliano on September 08, 2011, 03:42:28 pm
-
I need a z80 routine that renders an 8x8 sprite to the screen. The upper left corner of the sprite should be at a,b and the hex for the sprite in hl?
-
Lucky for you, that routine (http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:put8x8sprite) has already been made. With just a little tweaking you can have it do exactly what you want.
-
I would recommend that you use a different register for the Y coordinate if you can...and with a little bit of tweaking and help it can be done. Register B is often used as a loop counter in sprite routines.
-
I code like this:
clearScreen
putS 34, 75, 11, deck.load.logo
update
SPASM macros make this possible. No more thinking of loading the right registers :) .
#macro putsmall(_putsmall_down, _putsmall_right, _putsmall_size, _putsmall_address)
#ifndef _putsmall_down
call putsprite
#else
ld a, _putsmall_down
ld l, a
ld a, _putsmall_right
ld b, _putsmall_size
ld ix, _putsmall_address
call putsprite
#endif
#endmacro
#define putS putsmall(
#define update call fastcopy
#define clearScreen call clrgbuf
(The open bracket above is intended.)
-
The macro doesnt really help until you have the actual routine, though.
-
I code like this:
That's... definitely an interesting way of coding. You managed to code asm like basic in a way. Of course the obvious drawback with that technique is that you have a lot less flexibility with what you can do and your actual code size will be enormous. (For instance, if you want to display something with d = x and e = y, that's an entirely different macro you'll have to code for.)
The macro doesnt really help until you have the actual routine, though.
My guess is that he's using the ION routines or something similar.
-
I code like this:
Heh, that's how I code too :P
-
My guess is that he's using the ION routines or something similar.
Yes, I think those are pretty standard.
That's... definitely an interesting way of coding. You managed to code asm like basic in a way. Of course the obvious drawback with that technique is that you have a lot less flexibility with what you can do and your actual code size will be enormous. (For instance, if you want to display something with d = x and e = y, that's an entirely different macro you'll have to code for.)
But from my experience the advantage of being able to code a lot faster outweights that drawback. When you code a big program and it's maybe an APP that has access to 32KB, the time you need to adjust every appearance of a routine you just changed does matter compared to the few bytes you lose. In ASM it's mostly degree of abstraction and ease of use versus code size and speed. In a graphics-heavy game you would go for optimization, but really, who understands these rolled-out parallax scrolling routines I saw from JimE.
If you use a macro twice, you already get a benefit in actual size of written code, since my putsmall macro from above is just a text-replacing one.
Providing a language on top of ASM that is highly optimized for z80 is THE goal of the TI community these days. Failed BasicToAsm and CToAsm compilers, FastRPL or the successful AXE all underline this. Macros are somewhere in the middle I think. Like Timendus appoach (http://api.timendus.com/) of an AsmApi.
For beginners, something like this isn't bad:
#include ti83plus.inc
#include asmMacros.inc
.asmprog
clearScreen
echo "Hello World!"
exit _NoDoneFlag