| |
Taskmaster
Account closed
Registered: May 2012
Posts: 12 |
Clearing bitmap screen quickly
I've begun tinkering with drawing software sprites to the bitmap screen and I'm already running into serious problem. Good ol' 64. Nice and challenging, just how I remember it.
At any rate, my thought was to take my PC mentality into the rendering here and clear the screen each frame and redraw all the graphics from scratch. This is proving a challenge because ... well, clearing the bitmap memory takes the entire screen refresh and THEN some. Makes for kind of a boring game.
Anyhoo, I tried several methods of loop unrolling and self modifying code but it's just too much. Always too slow.
So I started to think about maybe drawing back over the graphics I drew the last frame and turn those bits off before drawing the new frame. Essentially drawing the frame once so the player can see it, and then inverted to erase it when the time comes.
Is this the generally accepted method on the C=64? I'm running out of options here... |
|
... 11 posts hidden. Click here to view all posts....
|
| |
Taskmaster
Account closed
Registered: May 2012
Posts: 12 |
I appreciate the link, but my hard copy of that book is one of the ones I was looking at. I guess I'll go over it again. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
http://codebase64.org/doku.php?id=base:vicii_memory_organizing&.. |
| |
Taskmaster
Account closed
Registered: May 2012
Posts: 12 |
So I need to switch the Vic bank then. :) OK, will try that next time I'm at my home computer. Thanks all!
EDIT : Hey thanks for that link Oswald, that make it click in my head finally! |
| |
Taskmaster
Account closed
Registered: May 2012
Posts: 12 |
OK, so I switched the Vic bank and got it rendering on another bitmap screen. Now I just need to toggle the bank each frame to eliminate the flicker.
Shame this eats so much memory. And it really sucks to have to duplicate the screen memory as that's basically just color data that will never change. Blah... Price of the machine I guess.
Anyway, thanks all! On to the next stage of this thing... |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Well, this is why we have char mode - 8x improvement in speed and memory usage. |
| |
Taskmaster
Account closed
Registered: May 2012
Posts: 12 |
Can someone break that down for me? I'm not getting that.
Bitmap memory is laid out exactly the same as character memory (8 vertical bytes, etc) and to cover the screen with characters would be pretty memory consuming so ... I don't understand where the savings come from. It should be the same speed to copy to/from it so ... ?
Is the C=64 just inherently faster at character graphics or something? I was never aware of this and I feel that I've been cheated. :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Can someone break that down for me? I'm not getting that.
Bitmap memory is laid out exactly the same as character memory (8 vertical bytes, etc) and to cover the screen with characters would be pretty memory consuming so ... I don't understand where the savings come from. It should be the same speed to copy to/from it so ... ?
Is the C=64 just inherently faster at character graphics or something? I was never aware of this and I feel that I've been cheated. :)
Well imagine the following (a possible use for char mode and software bobs):
Let's say your object spans 1x1 characters or when unaligned to the character grid 2x2 characters. And say you can move these in half resolution steps. Then you need 2*2*4*4 = 64 different chars to describe all possible combinations. This gives you 256/64=4 different possible background blocks to play with. Splitting the screen every character row into an odd / even charset would double that to 8 different background blocks.
So, in char mode you can very quickly move around an 8x8 pixel object in half resolution motion over a background consisting of 8 various chars if you like. This method would allow you to have "tons" of objects flying around (but they can't intersect each other).
But the normal use on a c64 for a game would of course to use charmode as background and a sprite multiplexer for objects that need pixel precision motion. Use chars for objects that do not need pixel precision objects, like a fast shooting bullet or so. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quoting TaskmasterIs the C=64 just inherently faster at character graphics or something?
Basically:
STA $0400 ; updates 64 pixels
STA $2000 ; updates 8 pixels
Let's say you want to move 16x16 pixels bobs around on a black background with 2 pixel horizontal resultion and single pixel vertical resolution. For each bob, allocate 9 characters arranged like so:
036
147
258
For each bob, keep four copies of the source graphics in memory, shifted 0, 2, 4, and 6 pixels. Now, to draw the bob into the character buffer, do something along the lines of:
; Call with position in X/Y
; X: 0-158
; y: 0-199
draw_bob_0:
lda screen_line_lo,y ; get screen coordinates
sta @screen_line
lda screen_line_hi,y
sta @screen_line + 1
txa
lsr
lsr
sta @screen_offset
txa ; select source image
and #3
tax
lda bob_src_lo,x
sta @bob_src
lda bob_src_hi,x
sta @bob_src + 1
tya
and #7
sta @save_y_and_7
jsr erase_bob_0 ; erase unused lines in buffer
@save_y_and_7 = * + 1 ; get offsets for source and dest
lda #$5e
ora #$40
tay
ldx #$3f
@copy: ; copy shifted image
@bob_src = * + 1
lda $5e1f,x
sta bob_0_buf,x
dey
dex
bpl @copy
You can now plot these 9 chars into the screen using the address in @screen_line + @screen_offset. To erase it again all you have to do is zero out those 9 chars on the screen.
There is a lot of room for optimization here and you can do a lot of unrolling - it's just a question of how much memory you can spare. If you don't need smooth movement it gets a lot easier of course, e.g. for bullets it's common to just plot 8x8 chars on the grid. |
| |
Taskmaster
Account closed
Registered: May 2012
Posts: 12 |
Ahh OK. This code assumes no overlap though, right? If a blob touches another blob, it will just overwrite what's there as opposed to OR'ing anything together. Choices and compromises... |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
You also have to manage backgrounds and masking manually if you don't want a blank background.
Meanwhile a 32-sprite multiplexer manages all of this without breaking a sweat at 50 fps. |
| Previous - 1 | 2 | 3 - Next |
