| |
johncl
Registered: Aug 2007
Posts: 37 |
Raster bars, chars screen and sprites
I have been searching a bit and it seems most stable raster modes use the $d011 trick but at the xpense of no character screen (only sprites).
I am making a platform game where I use some raster bars to indicate the ground (extending out into the border). I was able to render these fine (with 63 cycle delays between color changes) and set it up so that the top of the characters are drawn 1 line before my raster bars begin to avoid bad lines.
Well, now I added my hero sprite which is standing on the ground (data crossing my raster lines) and suddenly I have unstable rasters again - the sprite fetches has affected the amount of cycles available per raster. Furthermore it doesnt seem to be a stable "shift" but the lines flickers somewhat.
How can I get around this? It would be nice if I could call an alternate raster method for these "ground" raster bars and maybe have a permanent sprite crossing them (a transparent one perhaps).
I am using KickAssembler and my current raster bar macro looks like this:
.macro CopperLines( colors, endcolor ) {
.for(var i=0;i<16;i++) nop // initial delay
.var NOPS=25
.var len = colors.size()
.for (var l=0;l<len;l++) {
lda $10 // 3 cycles
lda #colors.get(l) // 2 cycles
sta BORDER_COLOR // 4 cycles
sta BG_COLOR // 4 cycles
// 50 cycles of nops - sum = 63 cycles (1 scan line)
.for(var i=0;i<NOPS;i++) nop
}
lda #endcolor
sta BORDER_COLOR
sta BG_COLOR
}
|
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
there are two things you need:
- a so called "stable raster interrupt" (you should be able to find some examples online, check codebase64)
- a differently timed loop to display the actual rasterbars. (each sprite will steal 2 cycles, plus 1 additional cycle for dma setup)
however you should keep in mind that moving sprites over those rasterbars will always influence timing - in demos a common idea is not to move the sprites at all, the only alternative beeing a huge mess of selfmodifying code in many cases. |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
jackasser, time to finish your article on codebase, innit ?;)
edit:
as each sprite steals 2-3 cycles on the lines it is displayed this is far from being a trivial task. consider changing colors only once in a while, and using CIA timers to stabilize your rasters.
btw, the flicker you get is not caused by the sprites its always there if you dont use stable rasters. |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
Quote: jackasser, time to finish your article on codebase, innit ?;)
edit:
as each sprite steals 2-3 cycles on the lines it is displayed this is far from being a trivial task. consider changing colors only once in a while, and using CIA timers to stabilize your rasters.
btw, the flicker you get is not caused by the sprites its always there if you dont use stable rasters.
Yeah I know... :(
Anyways, consider not using fancy raster splits that should extend perfectly in the side border for a game. I mean, what value does it add to the game really? Consider only switch $d021 instead, that gives you plenty of "timing slack" in the side border to do the update f.e. A well placed CIA timer ~12 cycles before the right border should be able to handle a $d021 switch with any number of sprites (assuming no bad line of course). |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Thanks all. JackAsser, I think I will do as you recommend. I guess I just got a bit hung up on the idea of having these raster lines (transitions between areas) and wanted to make them part of the game somewhat. I guess I can save those fancy things for the intro and hiscore screens. :)
Atm the whole game is contained in raster irq called blocks where I just forward the raster irq to a new block. By inc and dec of the border I can see the CPU time used for my game code/music etc to get an idea what I have got computation wise.
I am not familiar with CIA interrupts and how you set that up. Any reference to an article that? Would it be hard to do this but with only raster irq and some "nop"s until it passes the right border (i am using 38 char wide screen) and then changing bgcolor without the flicker even with some sprites there? (There wont be any bad lines from chars involved here). But if CIA interrupts is easy I guess thats the way to go. |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
probably you can get away without using the CIA. try timing an irq to change d021 close after the right border display started, then see if it gets away with 1 - 2 - 3 -..8 sprites displayed over it.
the CIA method would still rely on raster interrupts, dont confuse CIA timers with CIA interrupts. it works roughly this way: you set up a CIA timer which is in total synch horizontally with the raster beam, counting 62->0, then in a raster irq you can see how many cycles is the flicker, and add further delays according to it, thus at the end you get a stable raster.
edit: for the first part: this may work only on non badlines. |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Only setting the bgcolor and not the border worked wonderfully - at least with 2 sprites so far. I guess maximum amount that will cross the boundary between the two colors are 3 sprites.
Another question. A bad line always has the same amount of cpu cycles right? I want to add a couple of smooth scrolling raster bars to "wipe" the screen for a transition effect between mainscreen, gamescreen (and levels) and hiscore. (no sprites will be visible then).
I also assume there will be no problems switching between a normal charset and a bitmap mode and back to charset again for my mainscreen? I want the mainscreen to contain both a charset gametitle, a center area with some bitmap graphics (that will be "wiped" into a demo area), and bottom with a simple upscroller. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
The upscroller will make things more challenging, as bad lines move around. This gets especially tricky if you allow sprites over the split between bitmap and scroller. |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Well my upscroller will be on the bottom of the screen between two raster bars set up using raster irq's and no sprites around there (only in the area above). So I should be fine! As any decent programmer I have to have a place for some greetings and credits. :) |
| |
Richard
Registered: Dec 2001
Posts: 619 |
Quote: there are two things you need:
- a so called "stable raster interrupt" (you should be able to find some examples online, check codebase64)
- a differently timed loop to display the actual rasterbars. (each sprite will steal 2 cycles, plus 1 additional cycle for dma setup)
however you should keep in mind that moving sprites over those rasterbars will always influence timing - in demos a common idea is not to move the sprites at all, the only alternative beeing a huge mess of selfmodifying code in many cases.
I'm using the double IRQ method for one of the raster splits, but I cannot time the rasters correctly when sprites go over the split, Basically, inside the IRQ, if the sprite touches any part of the raster split, the split will jump to the next bad line, therefore a flicker occurs.
Is there an example routine about timing rasters with sprites going over them, the most simplest way as possible? |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
that would be the CIA timer method, ask jackasser to finish his article on codebase ;) |
... 2 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
