| |
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....
|
| |
Oswald
Registered: Apr 2002
Posts: 5110 |
thats a neat idea |
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Quote: Hm, maybe I'm missing smth but couldn't you use the timer for the calculation of active sprites on that relevant line?
My thoughts are as follows: you usually have a 63-cycle-timer running, which is used for dejittering and stabilising. Now if we set up an IRQ to fire at the line before the relevant one, we can reach cycle#55 (starting cycle postions count with #1) in stable state. There we put a 19-cyc-sequence, ending with LDA timer, to effectively "bridge" the cycles in which the sprite accesses take place. E.g. we use smth like
nop
nop
nop
nop
nop
nop
nop $ea
lda timer
Now the last R-cycle of the LDA-command will end up at different cycle positions, depending on the no. of active sprites. You can directly use the read value to determine the no. of delay cycles needed for the sprites (by using LDX timer and then read a delay value from a table, or using SBC timer followed by STA bra+1 bra: BNE cycleslide, whatever suits your needs). However, the no. of delay cycles needed for the actual DMA-delay-neutralisation still needs to be added (might be solvable by a cycle slide cascade, in which the second branch-offset is set by the routine in which the DMA-delay at the top of the screen is done).
Another approach (which I couldn't really test, same with the idea above) could be to use the background collsion register. If my quick tests with VICE were correct, the collision register can be used rasterline-wise; so, clearing the collision register and reading it directly after the relevant line (which has to be filled with "invisible" foreground pixels ofc) should give you the active sprites on that line. However, for the delay now a 256-byte-table is needed...
Hope this is not completely off-
Cheers
CF
I considered this and my bro thought of it aswell. It will limit the sprite Y-pos to every second line though as the read of either timer or collision register will need to happen the line before the actual VSP clock-slide. |
| |
Copyfault
Registered: Dec 2001
Posts: 481 |
Quote: I considered this and my bro thought of it aswell. It will limit the sprite Y-pos to every second line though as the read of either timer or collision register will need to happen the line before the actual VSP clock-slide.
Yes, in both cases we need to invest a "test line" and take action in the next rasterline. Depending on the no. of "DMA-delayed columns", the STA $D011 might fit directly (in the line with the NOP:LDA timer-sequence), but not all cases can be covered, so no win really.
Then again, I guess you'll have at least one black line to separate the game gfx from the inventory gfx. The test line could be the line before it, so the "DMA-delay-countering" will happen in that black line. We got to ensure that in both the test line and that black line there's the same no. of active sprites, which should be doable by activating y-expand for all sprites in the test line (given that all used sprites are non-y-expanded).
It feels tempting to take that VSP-clock-slide into the same line (the one I called "test line" above), but besides some loose ideas to choose the opcodes for that "bridge code" in a more clever way, I did not really see a way to do it. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1416 |
Nice work, JackAsser! |
| |
Fungus
Registered: Sep 2002
Posts: 714 |
I still want a scroller split that's stable no matter how many sprites are over the split or what $d011 value is current. Tried now for decades and can't manage it perfectly. |
| |
Martin Piper
Registered: Nov 2007
Posts: 735 |
Quote: He's extremely on topic Oswald. :) And the topic to begin with is not for beginners anyway. Feel free to start another topic about how sprite DMA works, for beginners.
https://bumbershootsoft.wordpress.com/2016/02/05/sprites-and-ra..
Yeah the "number of cycles stolen by sprites" is very relevant to this specific topic.
The continuous 63-cycle timer is about the best way I can think of to deduce the two cycle jitter, when it's not feasible to test the raster with an end of line jitter check. The bonus is that the timer method allows the jitter to be deduced at any time in the raster, instead of having to save time until the raster end of line. |
| |
WVL
Registered: Mar 2002
Posts: 914 |
How do you determine if sprites are really covering the area when multiplexing is involved? If YPOS is already updated before the sprite ends, the determination will fail. Like so:
Top of screen : YPOS is 150
At line 151, YPOS is set to 171
Determination is done in line 160 (say) and it is determined the sprite is below the current position, except it isn't. |
| |
Jetboy
Registered: Jul 2006
Posts: 343 |
By using different data structure than sprite registers? |
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Quote: By using different data structure than sprite registers?
Exactly |
| |
WVL
Registered: Mar 2002
Posts: 914 |
Uhr.. ofcourse. I had Trident's example code in my mind and couldn't figure it out.. but it's obvious ofcourse.. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
