Author Topic: Sprite Rendering  (Read 3796 times)

0 Members and 1 Guest are viewing this topic.

Offline ACagliano

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 919
  • Rating: +32/-2
    • View Profile
    • ClrHome Productions
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?

Offline thepenguin77

  • z80 Assembly Master
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1594
  • Rating: +823/-5
  • The game in my avatar is bit.ly/p0zPWu
    • View Profile
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

Offline Hot_Dog

  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3006
  • Rating: +445/-10
    • View Profile
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.

Offline NanoWar

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 140
  • Rating: +18/-6
    • View Profile
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.)

Ashbad

  • 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.

Offline thepenguin77

  • z80 Assembly Master
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1594
  • Rating: +823/-5
  • The game in my avatar is bit.ly/p0zPWu
    • View Profile
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

Offline Eeems

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

Offline NanoWar

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 140
  • Rating: +18/-6
    • View Profile
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