| |
Oswald
Registered: Apr 2002
Posts: 5094 |
the holy gray of HW scroll: how to avoid spr pointers becoming visible
Hi!
Lately playing with game coding ideas fascinated me. However scrolling games are hitting the wall of the evil non-bufferable $d800, not to talk about the time needed to copy around scr ram even when buffered. I have thought up ways to divide the scr ram copy into several frames, but $d800 must be moved in one frame no matter what.actually it takes about 126 rasterlines to move all the $d800 data, even using a speedcode!
full hw scrolling is nice, and char bullets are even nicer (ie: I'd like to have char mode for my theoretical game). but this is where something horrible happens: the sprite pointers will become visible, and unless we accept the 8 char wide bug on the screen I see no way around.
or is there ?
I heard there's something tricky going on in WVL's PD to circumvent this. Jack, WVL, whats that ? I'm afraid not something usable in a freescrolling game.
the closest I came is to build a screen with stretching a full char row down in bitmap mode, and shuffling around VIC's scrram pointers to get the colors working. this is the best one I could come up with, but the memory layout and the code is messy (multiplex sprites on that baby, and where are my char bullets?)and needs a lot of mem.
sorry this became quite lengthy :) waiting for suggestions.
|
|
... 60 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:
I'm also frustrated by not being able to deal with restore in a satisfactory manner either for that matter.
why is that? checking if an nmi comes from restore or somewhere else is easy enough, whats the problem? |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Quote:
I'm also frustrated by not being able to deal with restore in a satisfactory manner either for that matter.
why is that? checking if an nmi comes from restore or somewhere else is easy enough, whats the problem?
My funky charmode thingie triggers an timer NMI interrupt once every five scanlines or so (every four scanlines in a 16-pixel char actually, except on the first line), and each interrupt takes somewhere between 12-18 cycles.
There's just no way I'm sticking a restore test in there. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
ah ok, i see the problem... what i have done in a similar situation before was resyncing the timer to the raster somewhere else (in border or whatever), so hitting restore will still trigger an unwanted nmi, and disturb the timer driven routine, but it will go into sync again with at most one frame delay, so its not terribly critical. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: ah ok, i see the problem... what i have done in a similar situation before was resyncing the timer to the raster somewhere else (in border or whatever), so hitting restore will still trigger an unwanted nmi, and disturb the timer driven routine, but it will go into sync again with at most one frame delay, so its not terribly critical.
No, but it doesn't look very professional either :(
And even then it took some doing to support it ($00/$01 needs to be executable). Life would've been so much easier if the Commodore engineers had just decided to trigger a reset instead, though to be fair they could hardly have been expected to predict this kind of hardware abuse. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:
No, but it doesn't look very professional either :(
still a lot better than having to restart the entire game when you accidently hit restore :) |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Quote: My funky charmode thingie triggers an timer NMI interrupt once every five scanlines or so (every four scanlines in a 16-pixel char actually, except on the first line), and each interrupt takes somewhere between 12-18 cycles.
There's just no way I'm sticking a restore test in there.
Is there no way for you to use IRQ instead, and leave NMI in unacknowledged state? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
irq is used to plex sprites, while nmi does the vic tricks. anyway disabling restore is absolutely not needed, its just like you want to disable the reset button on a pc. if the user presses it --> he wanted it. it was 15-20 years ago when being able to disable runstop or restore made you the cool kid of the block imho. ;) its not like being able to feed the addy of an rti into 2 memory vectors or never acknowledging an nmi is a huge achievment... |
| |
Fungus
Registered: Sep 2002
Posts: 686 |
Oswald, as I was mentioning on IRC, you can go ahead and have part of the game running in real time loop (outside IRQ) , this would be say... you $d800 moving. Keep a switch to say "Move colors now?" and you modify this switch from inside the IRQ. In this way you can have the routine synced to frame. Yet, it is not inside any IRQ, so you can go ahead an multiplexer or whatever over the top of it. You can either have it wait, or just skip the routine if you want to do some calculations real time (enemy movement, AI, etc). This also makes it easier to have different routines for different enemies, seamless integration of different types of on screen action, and many many other things. Things like sprite animation do not need to be done every frame. Things like movement also do not need to be done every frame. You can also "interleave" routines easier this way and make the game seem like it is doing more than it actually is. Many commercial games are coded in this fashion. :)
These and many other reasons I am sure you can come up with, are why I mentioned this to you. I'm sure you can come up with many ways to use such a technique. (Game coding is not demo coding ;D )
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Oswald, as I was mentioning on IRC, you can go ahead and have part of the game running in real time loop (outside IRQ) , this would be say... you $d800 moving. Keep a switch to say "Move colors now?" and you modify this switch from inside the IRQ. In this way you can have the routine synced to frame. Yet, it is not inside any IRQ, so you can go ahead an multiplexer or whatever over the top of it. You can either have it wait, or just skip the routine if you want to do some calculations real time (enemy movement, AI, etc). This also makes it easier to have different routines for different enemies, seamless integration of different types of on screen action, and many many other things. Things like sprite animation do not need to be done every frame. Things like movement also do not need to be done every frame. You can also "interleave" routines easier this way and make the game seem like it is doing more than it actually is. Many commercial games are coded in this fashion. :)
These and many other reasons I am sure you can come up with, are why I mentioned this to you. I'm sure you can come up with many ways to use such a technique. (Game coding is not demo coding ;D )
I still need both IRQs and NMIs. IRQs are used for the multiplexer and NMIs to hack the charmode together. But beyond that I also run all the game logic from inside reentrant IRQs so I can do background tasks outside of them.
Right now the "main loop" as it were, in other words the code executing outside of any interrupt handlers, only increments a counter so I can measure the number of idle cycles. But it's my intention to eventually run background disk-streaming from there whenever the CPU isn't otherwise occupied. Note that you need a simple lock (a pair of INC/DEC instructions) to make sure you're not already in an update.
Actually if you wanted to you could run any number of tasks from within IRQs in this fashion. Preemptive multitasking. Sort of.. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
indeed, a game being able to properly frameskip while keeping the logical movement/spr anim speed constant would be nice. This introduces new problems which I should think about throughoutly I dont see a clear solution for them atmo. Fex. $d800 copy, or what if you have to move screen&d800 by more than 1 char steps. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
