Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draw the sprites to the LCD #4

Open
2 tasks
EphraimB opened this issue Mar 8, 2015 · 1 comment
Open
2 tasks

Draw the sprites to the LCD #4

EphraimB opened this issue Mar 8, 2015 · 1 comment
Assignees
Labels
Milestone

Comments

@EphraimB
Copy link
Owner

EphraimB commented Mar 8, 2015

  • Copy the sprite to the Buffer
  • Copy the Sprite in the Buffer to the LCD
@EphraimB EphraimB self-assigned this Mar 8, 2015
@EphraimB EphraimB added this to the v1.0 Alpha 1 milestone Mar 8, 2015
@chickendude
Copy link

Rather than draw the sprites directly to the LCD, you should draw them to what is called the graphbuffer (or gbuf or plotSScreen). Drawing directly to the LCD isn't that common on the 83+. To copy the data in the gbuf, you can use a routine like ionFastCopy. Get some ideas from here: http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:Fastcopy

To draw the actual sprites, each byte on the LCD corresponds to 8 pixels and each row in the LCD has 12 bytes worth of pixels. 12 bytes of 8 pixels each = a total of 96 pixels.

If you want to draw an 8x8 sprite at the position 0x0, you draw the first byte of the sprite at the first byte of the gbuf. The second byte of the sprite gets drawn in the second row of the graph buffer. To move down one row, we need to add the width of the graph buffer. Since the LCD is 12 bytes wide, the second byte gets drawn at (gbuf+12). The third byte at (gbuf+12_2), the fourth at (gbuf+12_3), etc.

If you want to draw at pixel 8, you just add one to the graph buffer pointer. So instead of drawing the first pixel to (gbuf) you draw it to (gbuf+1). The second byte in your sprite gets drawn to (gbuf+1+12). The third to (gbuf+1+12*2) and so on. If you want to draw to a pixel that isn't aligned to a byte, for example to pixel 4, it gets much more complicated. I recommend just drawing to aligned X values for now.

EDIT: To start with, for practice use one of the fastcopy routines in the link i gave you. Then try copying some random values into the graphbuffer, using fastcopy to display it, then pause the program. If you are in an emulator, using the instruction "jr $" will pause your program. If you test it on your calculator, however, it will put your program into an infinite loop and you'll have to remove the batteries. Otherwise, you can use this pause routine i wrote (to use, put it in your source file and do "call pause", it will wait for you to press and release a key before continuing execution):

;######################
getKey:
;# input:
;#  - a = key group to read from
;# output:
;#  - a = keys pressed ($FF = no keys pressed)
;######################
    out (1), a              ; opens the key group we want to read from
    push af                 ; a delay for 84+/SE calcs
    pop af                  ; (unnecessary for 83+/SE calcs)
    in a, (1)               ; read value from key port
    ret

; a should hold the value of the key you pressed +1
pause:
    call releaseKeys
pause_loop:
    xor a
    call getKey
    ld b, a
    inc a
     jr z, pause_loop
releaseKeys:
    xor a
    call getKey
    inc a
     jr nz, releaseKeys
    ret

@EphraimB EphraimB added UI and removed help wanted labels Apr 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants