Author Topic: Sprite Rendering  (Read 3346 times)

0 Members and 1 Guest are viewing this topic.

ACagliano

• Posts: 919
• Rating: +32/-2
Sprite Rendering
« 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?

thepenguin77

• z80 Assembly Master
• LV10 31337 u53r (Next: 2000)
• Posts: 1591
• Rating: +823/-5
• The game in my avatar is bit.ly/p0zPWu
Re: Sprite Rendering
« Reply #1 on: September 09, 2011, 03:50:52 pm »
Lucky for you, that routine has already been made. With just a little tweaking you can have it do exactly what you want.
zStart v1.3.013 9-20-2013
All of my utilities
TI-Connect Help
You can build a statue out of either 1'x1' blocks or 12'x12' blocks. The 1'x1' blocks will take a lot longer, but the final product is worth it.
-Runer112

Hot_Dog

• CoT Emeritus
• LV12 Extreme Poster (Next: 5000)
• Posts: 3006
• Rating: +445/-10
Re: Sprite Rendering
« Reply #2 on: September 13, 2011, 11:33:48 pm »
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.

NanoWar

• LV4 Regular (Next: 200)
• Posts: 140
• Rating: +18/-6
Re: Sprite Rendering
« Reply #3 on: September 15, 2011, 06:01:30 am »
I code like this:

Code: [Select]
 clearScreen putS 34, 75, 11, deck.load.logo update
SPASM macros make this possible. No more thinking of loading the right registers .

Code: [Select]
#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.)

• Guest
Re: Sprite Rendering
« Reply #4 on: September 15, 2011, 07:10:20 am »
The macro doesnt really help until you have the actual routine, though.

thepenguin77

• z80 Assembly Master
• LV10 31337 u53r (Next: 2000)
• Posts: 1591
• Rating: +823/-5
• The game in my avatar is bit.ly/p0zPWu
Re: Sprite Rendering
« Reply #5 on: September 15, 2011, 03:02:17 pm »
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.
zStart v1.3.013 9-20-2013
All of my utilities
TI-Connect Help
You can build a statue out of either 1'x1' blocks or 12'x12' blocks. The 1'x1' blocks will take a lot longer, but the final product is worth it.
-Runer112

Eeems

• Mr. Dictator
• LV13 Extreme Addict (Next: 9001)
• Posts: 6253
• Rating: +318/-36
• little oof
Re: Sprite Rendering
« Reply #6 on: September 15, 2011, 03:30:30 pm »
I code like this:
Heh, that's how I code too
/e

NanoWar

• LV4 Regular (Next: 200)
• Posts: 140
• Rating: +18/-6
Re: Sprite Rendering
« Reply #7 on: September 16, 2011, 06:12:57 am »
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 of an AsmApi.

For beginners, something like this isn't bad:
Code: [Select]
#include ti83plus.inc#include asmMacros.inc .asmprog clearScreen echo "Hello World!" exit _NoDoneFlag