| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Freely moving sprites over a triggered VSP?
The clock slide itself is not a problem since it's outside the sprite DMA area anywas, but we need to kick it off at a well known cycle, regardless of sprite DMA. Is it even possible?
Currently I do a hack by detecting if sprite 0 interfere and adjust appropriately. Double timer won't cut it since the first timer will trigger in the middle of the sprite fetches.
Only idea I have so far is to stabalize before the sprite fetches and the via sprite y-positions perform a series of compares to get a delay value via some table. I did something similar in The Wild Bunch for the sprite multiplexer balls over 4x4-fli, but there I knew the sprites always came in pairs, so the combinations were only 16. |
|
... 34 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
@Skate: your suggestion actually made me remember an option I considered like halv a year ago, so thanks.
Basically ensure there are ALWAYS 8 sprites on that line to get predictable timing. By multiplexing all sprites 21 lines down the raster line before. I'll try that! |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting JackAsserBasically ensure there are ALWAYS 8 sprites on that line to get predictable timing. By multiplexing all sprites 21 lines down the raster line before. I'll try that! I'm not sure i've understood the actual OP problem here, but...
You might want to take advantage of the sprite gap with this approach.
That is, 5 sprites (e.g., 0 2 4 7 and the fifth any of 1 3 5 6) would give you the same effect at potentially less cost, as the CPU isn't running in those measly 2-cycles DMA gaps. |
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Quote: Quoting JackAsserBasically ensure there are ALWAYS 8 sprites on that line to get predictable timing. By multiplexing all sprites 21 lines down the raster line before. I'll try that! I'm not sure i've understood the actual OP problem here, but...
You might want to take advantage of the sprite gap with this approach.
That is, 5 sprites (e.g., 0 2 4 7 and the fifth any of 1 3 5 6) would give you the same effect at potentially less cost, as the CPU isn't running in those measly 2-cycles DMA gaps.
Yeah yeah I know, but in MI I don't know what sprites are where, I can just assume that any 0..7 hit the VSP line at any given time. Solvable you think? |
| |
Skate
Registered: Jul 2003
Posts: 506 |
Quote: @Skate: your suggestion actually made me remember an option I considered like halv a year ago, so thanks.
Basically ensure there are ALWAYS 8 sprites on that line to get predictable timing. By multiplexing all sprites 21 lines down the raster line before. I'll try that!
Even if you start at the correct position, there is always the problematic 168th line issue as you know. But since this is for a game engine, little glitches can be ignored. Of course always go for the perfection but don't let little glitches block you for weeks or months. Monkey Island is a serious project after all.
I'll be looking forward to it, good luck! |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting JackAsserYeah yeah I know, but in MI I don't know what sprites are where, I can just assume that any 0..7 hit the VSP line at any given time. Solvable you think? Missing some context here. :)
VSP (hardware X-scroll) happens in the top border, i guess? And there you may or may not have random sprites reaching into the top border?
And the problem is that the interrupt can be stabilised all right, but you'd need to go across sprite DMA of indeterminate runlength to then do the VSP stuff in the next rasterline? |
| |
oziphantom
Registered: Oct 2014
Posts: 502 |
In S.P.R.E.R.O. V1.4 I have clock perfect timing with arbitrary moving sprites. In case you missed the trick, this a "sprites only" compo entry and hence there is no background, the background is "$3FFF" writes.
The combinations of sprites isn't 256 give the C64 doesn't clock back for missing sprites i.e 0,2 is the same a 0,1,2 etc So I was able to make a bunch of "waste X clocks" and then a 256 entry table for number of clocks I need to waste which it then dynamically updates the code for those lines to compensate for the clocks.
Although to be fair I don't have to worry about badlines, and I think I had some illegal sprite combinations that I could not make a matching clock delay for that I had to have the level data sort the sprites to ensure that said combos could not happen etc.
You could probably do the same thing with the VSP before line and then adjust the VSP delay amount to compensate for how much further the sprites will shunt you clock wise. Might reduce the VSP range from full 40 though. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
Yeah my default plan for sprites over VSP is to multiplex to put blank sprites above/below, so there are actually always the same sprites there - but I can't remember off the back of my head whether I ever got around to trying it. (though, I'm pretty sure I've put a static sprite status display over an AGSP implementation)
You don't need to change the sprite pointer at the start line of the real sprite, as long as you use a transition sprite that's half blank/half data. |
| |
trident
Registered: May 2002
Posts: 101 |
here is a way that seems to work for me:
* stabilize the raster so that you always end up at cycle 50 (i think - just before the sprites start to steal cycles anyway) of rasterline $2f. (for me, i use a cia timer for this, a 63 cycle countdown that i fire off at cycle 16 sometime during initialization, then do a lda #62 / sec / sbc $dd04 / (wait for 30 cycles max) thingy at the middle of line $2f, this gets me to cycle 50).
* use a variable timing mechanism of maximum 19 cycles (a traditional mechanism with a branch instruction that jumps into a series of 2-cycle instructions and a 3-cycle one at the end)
* compute the number of cycles that the sprites will steal (0-19) by computing the number of sprites that will be on line $30:
lda #0
sta spritescover
/* Figure out how many sprites cover the rasterline $30 */
.for (var i = 0; i < 8; i++) {
lda $d001 + i * 2
cmp #$30 - 21 * 2 // y expanded sprites
bcc next
cmp #$30
bcs next
lda spritescover
ora #1 << i
sta spritescover
next:
}
then use a table of cycle values that each sprite combination will steal and index into this table:
ldx spritescover
lda spritecyclestab,x
sta bplcycles + 1
that table is generated like this:
spritecyclestab:
.for (var i = 0; i < $100; i++) {
.byte vic_sprcycles(i)
}
where the magic is done by this function:
.function vic_sprcycles(d015value) {
/*
from https://bumbershootsoft.wordpress.com/2016/02/05/sprites-and-ra..
def sprdelay(active):
return sum(map(int, list((bin(active)[2:] + '00').replace('100', '5').replace('10', '4').replace('1','2'))))
*/
.var d015 = toBinaryString(d015value) + "00"
.eval d015 = str_replace(d015, "100", "5")
.eval d015 = str_replace(d015, "10", "4")
.eval d015 = str_replace(d015, "1", "2")
.var cycles = 0
.for (var i = 0; i < d015.size(); i++) {
.eval cycles += (d015.charAt(i) - '0')
}
.return cycles
}
after this, the code is cycle stable and allows to write into $d011 at the start of the visible screen. (but have only tested this quickly, so i may have missed some quirk.) |
| |
trident
Registered: May 2002
Posts: 101 |
looks like that link got mungled by the csdb forum software. the correct link should be https://bumbershootsoft.wordpress.com/2016/02/05/sprites-and-ra.. |
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Quote: Quoting JackAsserYeah yeah I know, but in MI I don't know what sprites are where, I can just assume that any 0..7 hit the VSP line at any given time. Solvable you think? Missing some context here. :)
VSP (hardware X-scroll) happens in the top border, i guess? And there you may or may not have random sprites reaching into the top border?
And the problem is that the interrupt can be stabilised all right, but you'd need to go across sprite DMA of indeterminate runlength to then do the VSP stuff in the next rasterline?
For context. The whole screen is scrolled using VSP at the top. There sprites are of no concern. The "problem" is counter VSP scrolling the inventory at the bottom. Characters can and will move outside the screen from below.
Currently, as I said, I handle sprite 0 (the mouse pointer) with some $d001-compares. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
