Which new games would you like to see on your VIC20?

[TBCVIC]

Very nice looking levels.
Jeff, it looks like it's (a member of?) TRSI's- the group responsible for the demo Going Lowres earlier this year.

But I somehow doubt if he will have enough VIC processing time left to put reasonable and fluent action (without sprites) into these wonderful scrolling backgrounds - and how much RAM he will need in the end.

I wouldn't doubt (a member of?) TRSI. I'm guessing scrolling is done with the VIC register $9000. If that's the case then there should be a very respectable amount of CPU time left.

If scrolling is done with VIC register $9000, then it would scroll half a character each frame. That's pretty fast at 50 fps and jerky at 25 fps or lower. You would also have problem at the left and right border (unless you overscan so much it'll be outside of most displays).

[MrSterlingBS]

Mike,

the Demo Start Screen says you have ~4.5 fps.
What can we aspect if the Code is Running with 2 buffers @ 128x128 pixels each. Then we dont need the blitter Time, Right?
Did we save 192x160xLDAxSTA for each frame?

BR
Sven

I noticed the C64 cheats by only drawing about half the lines of an object each frame - with movement this looks like a whole object anyway.

This would be the hidden line removal you're speaking of - I wouldn't call this cheating, rather an advancement over a simple wireframe display.

While we're at it ...

<fx sound="me rummaging through the depths of my HD">
AH! There it is!
</fx>

This one requires +24K, and (with VICE 2.2) is best viewed with aspect ratio 0.75 (really 1.5:1 as compromise between PAL, and NTSC):


(download)

It is actually 7 years old, and the arithmetics inside could be streamlined a lot for much lesser storage requirements, but for a demo ...

[Mike]

Did we save 192x160xLDAxSTA for each frame?

More like 192x20x(LDA+STA) cycles. Anyhow, clearing the shadow bitmap and copying it to the screen bitmap only take roughly 20% of the total time for each frame, even totally eliminating that part increases the speed only to 5.5 frames/s.

The other 80% of time are spent doing geometry processing and drawing the vectors.

What can we [expect] if the Code is Running with 2 buffers @ 128x128 pixels each[?]

Of course things generally can be sped up by reducing the problem size, but that's not the approach I normally take. But here is the opportunity for you to try it out from first principles. Putting two 2K bitmaps at $1000 and $1800 will require you to have the "text" screen at either $0000 or $0200. Take your pick.

[MrSterlingBS]

Hello Mike,

What routines do you use to draw the points and lines?
I implemented the routines from CodeBase64. Are these the fastest possible?

I implemented the integration of the two screen memories at $1000 and $1800. I can't test the speed because I still don't have the routines for calculating the 3D functions. I'll try to get it done this week.

Code: Select all

Plot:
	LDA HighByte,X
	STA $FC
	LDA ($FB),Y
	ORA XTable,X
	STA ($FB),Y
	RTS

Code: Select all

draw_line:
;init
        ldx #$e8        ;inx
        lda y_2
        sta to_y+1
        sec
        sbc y_1
        bcs skip1
        eor #$ff
        adc #1
        ldx #$ca        ;dex - change direction
skip1:
        sta d_y+1
        sta t_y_1+1
        sta t_y_2+1
        stx incx1
        stx incx2
 
        ldx #$c8        ;iny
        lda x_2
        sta to_x+1
        sec
        sbc x_1
        bcs skip2
        eor #$ff
        adc #1
        ldx #$88        ;dey - change direction
skip2:
        stx incy1
        stx incy2
 
        ldy x_1
        ldx y_1
;loop
 
;start y in x-register
;start x in y-register
;delta x in a-register
 
d_y:    cmp #0
        bcc steep
 
        sta t_x_1+1
        lsr
        sta errx+1
loopx:
        clc                 ;needed, as previous cmp could set carry. could be saved if we always count up and branch with bcc;
        ;lda x_char,y
        ;adc y_char_lo,x
        ;sta plot_lo
        ;lda y_char_hi,x
        ;sta plot_hi
 
        ;lda x_pixel_char,y
        ;ora (plot_lo),y
        ;sta (plot_lo),y     ;Remember that the y_char_lo table in this example starts at $20 (which center hires mode plotting). If you lower the start of table to below $08 (say for multicolor purposes where x steps are in doubles), you will get high-byte issues when you $FE in the adc x_char with the sta (),y  
		
;---------------------------------
; the core routine to plot a pixel

		lda highb,x
		sta $fc
		lda ($fb),y
		ora xtable,x
		sta ($fb),y

;----------------------
 
 
errx:    lda #$00
        sec
t_y_1:   sbc #0
        bcs skip3
 
        ;one might also swap cases (bcc here) and duplicate the loopend. saves more or less cycles as the subtract-case occurs more often than the add-case. Copying the whole loop to zeropage also save cycles as sta errx+1 is only 3 cycles then. (Bitbreaker)
 
t_x_1:   adc #0
incx1:   inx
skip3:   sta errx+1
 
incy1:   iny
to_x:    cpy #0
        bne loopx
        rts
 
steep:
        sta t_x_2+1
        lsr
        sta erry+1
loopy:
        clc                 ;needed, as previous cmp could set carry. could be saved if we always count up and branch with bcc;
        ;lda x_char,y
        ;adc y_char_lo,x
        ;sta plot_lo
        ;lda y_char_hi,x
        ;sta plot_hi
 
        ;lda x_pixel_char,y
        ;ora (plot_lo),y
        ;sta (plot_lo),y
		
		;---------------------------------
; the core routine to plot a pixel

		lda highb,x
		sta $fc
		lda ($fb),y
		ora xtable,x
		sta ($fb),y

;----------------------
 
erry:    lda #0
        sec
t_x_2:   sbc #0
        bcs skip4
 
t_y_2:   adc #0
incy2:   iny
skip4:   sta erry+1
 
incx2:   inx
to_y:    cpx #0
        bne loopy
        rts

[Mike]

[...]

PM sent.