| |
ready.
Registered: Feb 2003
Posts: 441 |
full screen sprite mux scroller
hello all,
I am coding an upscroller but I'd like to put it in upper and lower border, thus I am using sprites for displaying text, just like +2K end part.
I got the main code to work: I have a stable irq (1-cycle jitter), I move up by one raster line all raster IRQs when I want to move up the text/sprites and that works. I use the $d018 trick to change sprite pointer and that works.
But I am having trouble with bad lines, which still cause flickering when I change $d018 during one of them.
How could I have the $d018 write happen when I want? I tried to move the IRQ entry point earlier in the position of a bad line, but that does not help: then $d018 changes too early and sprites are displayed wrong.
I cheked the +2K code but I could not get out with it.
thanx for help,
Ready.
|
|
... 20 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
that means there should be 4 cycles free for a d018 write on a badline + 8 sprites. Maybe I was doing something wrong :) |
| |
ready.
Registered: Feb 2003
Posts: 441 |
wow, a full bunch of replies! Thanx.
Actually I experienced exaclty what Oswald said:
Quoting nameI once made a stable IRQ for this and on badlines with the d018 "trick" I was always either too late or too early, when just changing the timing by 1 cycle!
just adding one more NOP after the IRQ stabilizing code (double IRQ method) would either get rid or mantain the flickering. And the flickering flickers between correct sprite data and wrong sprite data, so it is the $d018 which seems to be "locked" if written at the wrong moment.
Since I was getting stable results by just adding 1 NOP after the stabilizing code, I thought about adding or not adding that NOP depending on the need (thus on the vertical position of the scroll). In fact the NOP sometimes is good, sometimes is bad. Adding a lookup table for the NOPs to add might do the trick.
Still I didn't quite get the RMW trick, any coding reference for it? Any demo using it? I will give it a try anyhow.
|
| |
algorithm
Registered: May 2002
Posts: 705 |
It should not flicker if the irq is stable. you may need to change the timing in the stable irq routine. dynamically adjusting when the raster IRQ takes place would require adjustments to the stable routine depending on the line/whether it matches with the same line as sprites etc. once solid, If one nop is too less and two nops is too much have you tried removing a nop and including something such as a bit $ea (3 cycles)? |
| |
Skate
Registered: Jul 2003
Posts: 494 |
I had a similar problem using 4 sprites + sideborders. I still don't know what to do at the 168th line. 168th line is the killer for me. It comes from sprite height (21*8). even if you start from a badline (setting everything earlier), at the 168th line relative to your starting point... there you go, a badline which you need to change sprite pointers and open sideborders at the same time. tadaa.... :) Maybe answer to your question also solves my problem. I know there is a dirty trick for that but couldn't figure out myself. Since I don't examine other coders' demo codes, I was helpless. :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
@Skate: Could you not use the partial sprite method so that the sprites below have part of the bottom few data (same as the data at the bottom of the current sprites) this way you can change sprite pointers earlier rather than at a badline? |
| |
algorithm
Registered: May 2002
Posts: 705 |
@ready. I should read properly. hehe. I had a similar issue with the multiplexer (the interference sprite underlay) in Algodancer 2 in regards to what oswald had mentioned. $d018 was either too early or too late. This was padded with i believe an inc/dec or something similar along the lines which latched $d018 to the correct area. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
@Algorithm: I could also use the trick you suggested to Skate of partial sprites, but then I'd have almost no RAM left for the VIC, since I have to double the sprites and I want to use some chars/bitmap too (@Mr.SID first post).
The sprite multiplexer is quite feasible with $d018 if you want it static, all you have to make sure is that you don't change $d018 on badlines.
I have to think more about how to solve this issue. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@Ready: For a sprite upscroller the extremly simple solution is not to pack the sprites back 2 back, nobody will notice nor care anyway. Have a gap of 2 raster lines or something and get on with it. |
| |
algorithm
Registered: May 2002
Posts: 705 |
@ready. You dont need to double the amount of sprites. The duplication would only be around two lines of sprites. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
@algorithm: yes if I used a static screen with fixed y-sprite positions, but since sprites are moving up, a bad line can happen at any sprite line. |
| Previous - 1 | 2 | 3 - Next |
