| |
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. |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11540 |
I'd just say it is impossible and wait for crossbow to do it anyway :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Quote: I'd just say it is impossible and wait for crossbow to do it anyway :)
A sound idea! Not sure I wanna wait 15-20yrs though. :D |
| |
Skate
Registered: Jul 2003
Posts: 508 |
You'd probably considered this but wasting one or more sprite rows and a few extra cycles, $d017 stretch would stabilize the timings. I wouldn't call it "freely moving sprites" but it looks like it at the end. It may not be suitable in your scenario but it'd give it a go if it's possible. |
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Quote: You'd probably considered this but wasting one or more sprite rows and a few extra cycles, $d017 stretch would stabilize the timings. I wouldn't call it "freely moving sprites" but it looks like it at the end. It may not be suitable in your scenario but it'd give it a go if it's possible.
Yeah I know. But in this case I can’t have look’a’like.
It’s for Monkey Island. There are other workarounds, but solving this would be the clean solution. |
| |
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: 3106 |
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: 508 |
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: 3106 |
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. |
... 34 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
