| |
wbochar
Registered: May 2002
Posts: 26 |
C64 32 Sprites 8x4 and Gaps
I have an ASM program that is trying to display 32 Sprites. I get all 32 on the screen as long as there is a 2px width gap between them. They are laid out in a grid (see below) so each line group has the same xpos (set once)
The moment I either make the raster happen earlier (corrupts the sprite) if not I get a horizontal gap between each grouping.
Fussing with the rasterline and Ypos of the sprites is not working.. is this possible?
Notes:
Numbers are sprites slots, Letters are sprite bitmaps in non-stretched mode (21px tall). I have also turned off the top/bottom borders.
AA:0-AB:1-AC:2-AD3-AE4-AF5-AG6-AH7
AI:0-AJ:1-AK:2-AL3-AM4-AN5-AI6-AO7
BA:0-BB:1-BC:2-BD:3-BE4-BF5-BG6-BH7
BI:0-AJ:1-BK:2-BL:3-BM4-BN5-BI6-BO7
Raster IRQ fires at:
BorderTopIRQ:
0 : turn off upper border
: Set Sprites 0-7 (No Stretch, Enable, X-pos)
: Update RasterIRQ Line to LogoIRQLine1
LogoIRQLine1:
10 : Set Sprites 0-7 y-position (RasterLine+2)
: Set Sprites 0-7 bitmaps (AA,AB,AC,AD...)
: Update RasterIRQ Line to LogoIRQLine1
LogoIRQLine2:
10+(21*1) : Set Sprites 0-7 y-position (RasterLine+2)
: Set Sprites 0-7 bitmaps (AJ,AK,AL,AM...)
: Update RasterIRQ Line to LogoIRQLine2
LogoIRQLine3:
10+(21*2) : Set Sprites 0-7 y-position (RasterLine+2)
: Set Sprites 0-7 bitmaps (BA,BB,BC,BD...)
: Update RasterIRQ Line to LogoIRQLine3
LogoIRQLine4:
10+(21*3) : Set Sprites 0-7 y-position (RasterLine+2)
: Set Sprites 0-7 bitmaps (BJ,BK,BL,BM...)
: Update RasterIRQ Line to BorderBottomIRQ
BorderBottomIRQ:
250 : turn off lower border
: Update RasterIRQ to the BorderTopIRQ
|
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
you should start with making the Y-pos updates and sprite pointer updates two different things.... Y-pos is totally non critical, you can set the new Y-pos anywhere in the next 20 lines or so after the current Y pos. make this work first, with a static graphic/sprite pointer. it should be very easy :)
then when this works, interleave the sprite pointer updates into your routine. this can be a bit more tricky, as the update happens immediately and takes effect at any time - so you want to push the update to the point when the current sprite has just ended. for large blocks of sprites you'll have trouble doing it 100% correctly, because the badlines come in the way - which means you dont have enough cycles there to update all pointers in time. one common "trick" is to use two videorams then, so you only have to switch $d018 and all sprite pointers change. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
if you do/can not use the $d018 trick and stay away from badlines, you might want to do it like the following to save cycles on sprite pointer changes:
lda #$01
ldx #$fe
sax screen + $3f8 ;00
sta screen + $3f9 ;01
lda #$03
sax screen + $3fa ;02
sta screen + $3fb ;03
lda #$05
sax screen + $3fc ;04
sta screen + $3fd ;05
lda #$07
sax screen + $3fe ;06
sta screen + $3ff ;07
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
what everyone said plus:
if I get it right you only have 4 rows of sprites, if first sprite row starts on a badline it should be possible to do it without any tricks, because the 3 next sprite row will not start on a badline. except you have to make it as fast as possible + you need to fine tune the timing of the writes horizontally
bad lines are first pixel row of a character row, where the cpu is stopped for 40 cycles from the available 63 per raster line. also 8 sprites make the cpu stop for another ~20 cycles, thus you have no cycles left to change the sprite pointers ON a badline. you might start on the prvs line tho as Groepaz says.
this may sound very hi tech, but all you need is to change background color to see where the cpu is on the screen, then some trial and error with nops + lda #sprptr sta scr+3x |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
@Bitbreaker: cool trick!! With that code you can have 8 sprites and waste just one $3fx area for pointers. Moreover, LDX can even be put *before* the critical code and you get 40 cycles against 48 of a normal lda+sta approach: that means 4 free cycles (63-19-40) for ie FLD (hence you can avoid idle mode). Thanks for sharing! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
another thing you can do, depending on what you want to achive at the end.... just dont put all your sprites on the same Y position, but for example move down 4 of them 2 lines or so |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
I agree with Oswald that with careful Y positioning you can make the timing of the updates a lot less critical, and agree that starting with the sprites on a badline (rc=0) will work. I'd dispute the reasoning though; starting on badlines is fine, ending sprites on badlines is bad.
The sprite data is fetched starting at the end of the preceding line (hence having to set MOBy to one lower than the raster line you want to display on), so what you really want is to avoid having the *last* lines of each of the first three rows of sprites landing on badlines, as that's when you want to be setting up the pointers for the next row.
Place the first set on a badline, and you have rows starting at rc=0,5,2 and 7 respectively - all good!
Of course, you can make the timing a lot less critical with a little duplicated data, and untethering the sprite pointer update from the physical sprite boundaries. Pretty sure this technique's been mentioned a few times already on these forums, but in short:
- Change sprite definitions every 19 or 20 lines, instead of every 21
- ensure the last few pixel lines of sprite row 0 are copied into the last few lines of sprite row 1
- then the last three or for lines of row 1 copied into row 2, so you can do that switch even earlier etc
Whether that's more or less work than just getting the interrupt timing right depends on the coder. The duplicated data technique is generally more useful when you've got moving sprites or a scrolling background, so you don't know when the badlines are going to occur... |
| |
wbochar
Registered: May 2002
Posts: 26 |
Thanks,
Groepaz: Great suggestions, I would have said that to someone else in the same situation.. I wish I'd thought of it. I started simple and moved up.. The Video Ram switcher is a great idea, I have another segment that already uses that for scrolling large segments of text. I'll see if I can mix them together..
Bitbreaker: I have never used SAX, so thanks for giving me a reason to. I tried it out, but in the end the startline and badline combos worked out.
ChristopherJam: Yes, you were right about the badlines and starting points.
So it worked out that....
I set up a static image for all sprites and figured out the positioning.
Then began by replacing the first line with Sprite A0,A1,A2..then did each line after that.
When things started to go wonky with the line I was working on, I would adjust the start line of everything.
Then got the timing right for the last one.. which was on a bad line.. more adjusting the start Y pos and it worked..
It ended up being (SpriteY-2) as the raster line start for the top three sprite lines, then (SpriteY-3) and some padding nops..
Thanks for the tips, you guys really helped.
--Wolf |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
great test gfx there :) |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
Just one more note here: Sometimes using test sprites like these can mask the problem of sprite pointer changes not happening on exactly the right spot.
In your example the bottoms of all the test sprites are identical, I'd try to avoid that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
yeah, i usually use some kind of diagonal stripes, then you can spot problems easily |
... 11 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
