| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
Faster charmap scrolling
Some interesting asides over in the Pixeling forum about speeding up charmaps (cf Graphician for intense EF game). As Oswald pointed out, switching from tiles to a straight unpacked charmaps doesn't really save you much, as you can avoid dealing with tile indices for most of the screen by just copying most of the chars from within VM. Besides, even tile index reads can be amortised over multiple VM writes.
However, there are other possibilities. If you've got a little RAM to spare (eg because all your level data is in EF), then why not unroll the update loop into one hardcoded routine per column?
Could easily dedicate 5k to
lda#$xx
sta vm,x
lda#$xx
sta vm+40,x
lda#$xx
sta vm+2*40,x
..
lda#$xx
sta vm+24*40,x
which gets you down to 7 cycles per char (14 if you also do video ram)
You only need to update one column of source each time you scroll one char, and call the columns in sequence with increasing values of X.
Might have to do divide into upper/lower half of screen to avoid tearing.
Of course, if you want to be really extravagant, you could generate a routine per column of level data, and skip any redundant loads by grouping identical indices; kind of like compiled sprites on PC.
That would eat shedloads of flash if you stored them all in advance of course (a tad less with duplicate removal), or you could try generating them on the fly
|
|
... 20 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
dudes, for simple horizontal scroller neither vsp nor reu nor whatever is needed.... unless you want to scroll way too fast =) it can be done easily in 2 frames, even more easily in more frames. |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
Compyx: re-entrant IRQ should not mess with the multiplexer as long as IRQ source is acknowledged and CPU registers are stored properly. I've got a test scroll/sprite engine going where exactly the color-RAM scroll happens in IRQ and no problems so far. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: dudes, for simple horizontal scroller neither vsp nor reu nor whatever is needed.... unless you want to scroll way too fast =) it can be done easily in 2 frames, even more easily in more frames.
I know, the problem is the colorram updates. Double buffering removes most of the raster time problems, especially when scrolling at 1-4 pixels.
For me, the colorram has always been the problem. Although I managed to avoid that using VSP and linecrunch (infinite scrolling in all directions), but that disabled any use of sprites. |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
Typical approach is to split color-RAM update in two halves, you can start updating the top half already when raster beam is in the bottom half. This may be critical if you're after NTSC compatibility. Though in the "color-RAM update in IRQ" method I start simply at the bottom of the scrolling area, because I don't fire an IRQ earlier. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Yes, doing the colorram update somewhere half-screen worked for me. Although I never considered NTSC systems. I'm a demo coder, so for me PAL is all I care about. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
yup just double buffer the screen and then update colorram as cadaver said.... not really hard to do at all :) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: yup just double buffer the screen and then update colorram as cadaver said.... not really hard to do at all :)
except with a multiplexer + game logics I'd guess. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
multiplexer is no problem really - just use re entrant interrupts like cadaver said |
| |
oziphantom
Registered: Oct 2014
Posts: 480 |
In the context of my Project as posted in the Graphics forum
I don't think an REU is the better choice. REU and EF are different and have different capabilities. To which at the moment I feel the EF wins, it might be the case I get 3/4 through it realise, I don't need the EF benefits over the REU's and switch, but at the moment I think the EF wins.
In the context of somebody who wants to scroll super fast or needs every last drop of CPU and has a scroller then yes, using a REU gets you insane scrolling speed, you can start in the lower border and be done in the lower border and it takes 36 bytes or something equally minute to do the scroll code. If the map was stored in the REU probably half of that.
If you just need speed and not worried about length or needing extra RAM then VSP can be an option. It is a pain in the butt, but it does save you a lot of raster most of the time. You need to do a lot of juggling to get things in the right place and you get the "this game is stupid you can't jump off the top of the screen, so lame" comments ;) Also worth noting with an REU you get the "this is not a real 64, it is cheating, not standard man..." comments ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: multiplexer is no problem really - just use re entrant interrupts like cadaver said
the problem is to reach constant 50fps with all the shit - plexer-scroller-logics. Cadaver shows this in his rants nicely. Certainly not a walk in the park if you have to resort to doing things like not running AI in each frame, etc. |
| Previous - 1 | 2 | 3 - Next |
