| |
Axel
Account closed
Registered: Apr 2006
Posts: 42 |
Sprite multiplexer
I am trying to do simple multiplexer using "Zone split" technique. Something like this:
1 2
1 2
1 2
...
I found in codebase that: "The Y-coordinate for a sprite must have been set before the raster line reaches that Y-position, or the re-used sprite won't display at all" What does it mean?
I wrote this piece of code:
lda $d001
clc
adc #21
sta $d001
sta $d003
ldx spriteindex
lda frametable,x
sta $07f8
lda frametable+1,x
sta $07f9
txa
clc
adc #2
sta spriteindex
How exacly can I get it to work?
|
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you have to set Y pos before the electron beam stops drawing the current sprite(s) and after it have started drawing them. its about timing. |
| |
Axel
Account closed
Registered: Apr 2006
Posts: 42 |
Ok, but how achieve this timing,
How to code this? Could you give me some example? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
this is what raster interrupts are for. you can make the cpu to execute a piece of code each frame, tied to a designated raster line. more at codebase ;) |
| |
Axel
Account closed
Registered: Apr 2006
Posts: 42 |
I tried to change $d012 register in raster routine but it doesn't work. How to update raster line where this routine is triggered?
Stable raster is needed? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
if you want to do different changes on different lines each frame, then you should do it like this:
irq1 do shit
lda #irq2$d012val
sta $d012
lda #<irq2
sta $fffe ;(assuming we have turned kernal rom off)
lda #>irq2
sta $ffff
rti
irq2 do shit
lda #irq1$d012val
sta $d012
lda #<irq1
sta $fffe
lda #>irq1
sta $ffff
rti
irq1 will always be triggered at raster line #irq1$d012val, irq2 similarly. I think you should start with some colored rasterlines at various positions (=more visual feedback&helps to learn some basic timing), and if you can get that right move on to sprites.
stable raster is NOT needed. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
you forgot DEC $D019 :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
thats in "doshit" :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
|
| |
Axel
Account closed
Registered: Apr 2006
Posts: 42 |
Thanks for explaination.
So if I want to reuse sprite1 and sprite2 for example 10 times, I need 10 raster interrupts ? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you dont get the basic concept of this. the electron beam draws the screen on a real CRT (non lcd/tft displays) left to right top to bottom. The c64s video chip reads and sends data in synch with this to display the picture. if the video chip finds that the vertical raster position ($d012 upon read gives you that, upon write it sets raster interrupt line) is the same as one of the sprites' Y coord then it starts to display the given sprite. this mechanism makes it possible to multiplex sprites. after the rasterbeam&vic started drawing a sprite during one screen scan, with correct timing you may set a new Y pos further down, and when the electron beam matches this position again, the sprite will be redisplayed since sprite Ycoord will match vertical raster position again. thus if you want to display a sprite X times you have to do this 'trick' x times.
so dont think of the c64's video display as something static, its being drawn left to right top to bottom 50 times each second, and by manipulating VIC registers timed correctly to this behaviour you may create rasterlines, rastersplits, sprite multiplexing, etc. |
| |
Axel
Account closed
Registered: Apr 2006
Posts: 42 |
I got the idea, but I don't know how to use it in code ;)
I made sprite multiplexer using multiple iterrupts and it works quite good but few virtual sprites aren't displayed,
it depends on raster line where I start reusing sprites. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you may be late by rewriting the Y coords then. the first line of each char row is a bad line meaning you have there 40 cycles less cpu time, maybe those are the specific lines things go wrong. |
| |
Axel
Account closed
Registered: Apr 2006
Posts: 42 |
Yes you are right. I change sprite position a bit late, becouse of these badlines.
What is the solution? |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
set the raster interrupt to trigger one line earlier and wait in a loop to change the Y pos when needed. or use CIA interrupts. |
| |
Skate
Registered: Jul 2003
Posts: 494 |
you can change sprites' Y position right after sprite is displayed but don't forget that you have to change the sprite address (which sprite data to be displayed) at the exact raster position. so, if you need all 8 sprites, change Y coordinates before the multiplexing position and change sprite addresses at the multiplexed raster position.
0: ******** <-- this is where first sprites are displayed
1: ++++++++ <-- this is where new Y coordinates are set. this line can be any line available between 1 and 20.
...
...
20: oooooooo <-- this is where you change sprite datas (at the end of the raster line)
21: ******** <-- our new sprites are shown here
22: goes same like "1:" |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
This old thread is worth reading:
http://noname.c64.org/csdb/forums/index.php?roomid=11&topicid=3..
The half-shape trick is very nice |
| |
Axel
Account closed
Registered: Apr 2006
Posts: 42 |
Thanks now it works :) |
