Q-Bert mockup screens and X-mas version

Zach · April 11, 2005

Thanks, TJ. I think I've got something that can draw sprites. I'll have to see if I can get them moving. The beauty of Retrofan's playfield design is that every other scanline has fewer color changes, so there is time for other tasks.


                ;;same code as before
                  lda #%11110111 
                  sta PF1       
                  lda #%00001110
                  sta PF2     
                  lda #$00    
                  sta COLUBK   
                  ldx #$3a       
                  ldy #$c3       
                  SLEEP 4        
                  stx COLUPF     
                  lda #%00010000
                  sta PF0
                  sty COLUPF
                  lda #%10001000
                  sta PF1
                  lda #$00
                  stx COLUBK
                  sta COLUPF
                  sty COLUBK
                  lda #$ff
                  sta PF2

                ;; new code for drawing sprites
                  ldy santa_current_line
                  lda santagrp,Y
                  sta GRP0
                  lda santacolu,Y
                  sta COLUP0
                  stx WSYNC

                  lda #%11110000
                  sta PF1
                  sta PF2
                  lda #0
                  sta PF0
                  sta COLUBK
                  stx COLUPF
                  iny
                  lda santagrp,Y
                  sta GRP0
                  lda santacolu,Y
                  sta COLUP0
                  iny
                  sty santa_current_line
                  ldy jack_current_line
                  lda #0
                  sta PF1
                  sta PF2
                  lda jackgrp,Y
                  sta GRP1
                  inc jack_current_line
                  stx WSYNC

Edited April 14, 2005 by Zach

Retrofan · April 15, 2005

Hey, that's nice. I'm happy to see that my mockup screen is inspiring Zach to code someting challenging with it. It's good that there will be some more days to Christmas.

Zach · May 5, 2005

I made some recent progress. The sprites are moving now, and the background consists of the row shown previously, plus the row below it (stretched out, of course).

I've got two sprites in the kernel, but the timing is so tight, there is no room for any missiles or balls or anything else. The question will be whether a fun game can be made with just the background and two sprites.

xbert.zip

Edited May 5, 2005 by Zach

Thomas Jentzsch · May 5, 2005

I've got two sprites in the kernel, but the timing is so tight, there is no room for any missiles or balls or anything else.

Can you post some (kernel) code?

Zach · May 5, 2005

My method for drawing sprites is a little unorthodox. The data for each sprite consists of an entire 256 byte page filled mostly with zeros. That way, I don't have to determine where to draw the sprite - just draw it on every line. The idea was inspired by an email by Manuel a couple months ago where he explained the fastest way he knew to draw a missile.

Although you stated that this kernel would probably be impossible, Thomas, I'm sure you could have solved the problem in half the time it took me. I'll be wildly impressed if you can squeeze in a missile or something.

Here is the code for the first row.

                ;-----------------------------------------
                 ; Loop starts on cycle 69 with Y set to santa_current_line
                 ; and A set to 0.
loop
                  ldx santagrp,Y        ;73
                  stx GRP0              ;76
                  ldx santacolu,Y       ;4  ; First line updates the pun'kin
                  stx COLUP0            ;7
                  sta PF0               ;10
                  sta COLUBK            ;13
                  ldx #%11110000        ;15
                  stx PF1               ;18
                  stx PF2               ;21
                  ldx platformcolor1    ;24
                  stx COLUPF            ;27
                  ldx jack_current_line ;30
                  lda jackgrp,x         ;34
                  ldx.w platformcolor2  ;38
                  stx COLUPF            ;41
                  inc jack_current_line ;46
                  sta GRP1              ;49
                  lda #0                ;51
                  sta PF1               ;54
                  sta PF2               ;57
                  iny                   ;59
                  sty santa_current_line;62
                  ldx santagrp,Y        ;66
                  stx GRP0              ;69
                  ldx santacolu,Y       ;73
                  stx COLUP0            ;76           
                      
                  ldx #%11110111        ;2 ; Second line draws the green blocks
                  stx PF1               ;5
                  ldx #%00001110        ;7
                  stx PF2               ;10
                  sta COLUBK            ;13 
                  ldx platformcolor1    ;16
                  SLEEP 3               ;19
                  stx COLUPF            ;22
                  ldy #$c3              ;24 ;Green
                  ldx #%00010000        ;26
                  stx PF0               ;29
                  ldx #%10001000        ;31
                  sty COLUPF            ;34
                  stx.w PF1             ;38
                  ldx platformcolor2    ;41
                  stx COLUBK            ;44
                  sta COLUPF            ;47
                  sty COLUBK            ;50
                  ldx #$ff              ;52
                  stx PF2               ;55
                  ldy santa_current_line;58
                  iny                   ;60
                  dec counter           ;65
                  bne loop              ;69 assume branch crosses a page boundary
                ;---------------------------------------

Thomas Jentzsch · May 5, 2005

I'll be wildly impressed if you can squeeze in a missile or something.

Well, you have three(!) counters (jack_current_line, santa_current_line and counter). Use (ind),y adressing for the sprite graphics and only one single counter (counting down). That alone should save you a lot of cycles.

And if you can avoid using Y for something else than counting, then you can remove the remaining counter and save some more cycles.

Zach · May 6, 2005

So by using (ind),Y you mean that Y will represent the current scanline as counted from the bottom? And ind will point to an address within the 256 bytes of sprite graphics? In this case, Would'nt there be a problem with sometimes crossing a page boundary, costing indeterminantly 5 or 6 cycles?

Here is how Santa's sprite data looks now:

ORG $FC00
santagrp
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00
          .byte #%00000110
          .byte #%00011100
          .byte #%01111110
          .byte #%01111110
          .byte #%01111110
          .byte #%01111110
          .byte #%01010110
          .byte #%01111110
          .byte #%01000110
          .byte #%01111100
          .byte #%00111100
          .byte #%01111110
          .byte #%01111111
          .byte #%01101101
          .byte #%11111101
          .byte #%11101100
          .byte #%01111100
          .byte #%01111100
          .byte #%00101000
          .byte #%01101000
          .byte #%00001100
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
          .byte $00,$00,$00,$00,$00,$00,$00,$00,$00

Edited May 6, 2005 by Zach

vdub_bobby · May 6, 2005

So by using (ind),Y you mean that Y will represent the current scanline as counted from the bottom? And ind will point to an address within the 256 bytes of sprite graphics?

Yes and yes.

In this case, Would'nt there be a problem with sometimes crossing a page boundary, costing indeterminantly 5 or 6 cycles?

Yes, kinda, not really.

If you only read sprite graphic data when you are drawing the sprite (i.e., not on every scanline), then you only need to be concerned with the area in front of your sprite graphic data.

Worst-case example:

You are displaying a sprite at scanline 192.

So you read sprite data with this:

lda (ind),Y

where Y is 192.

So ind needs to be an address from $xx00 - $xx63. So you've still got 64 bytes of room there, so even in the most extreme case (where you are using the entire visible display to draw a sprite) you can still have 64-line tall sprites.

The real key is that you only read data when you are drawing the sprite.

Here's some fake-y code I slapped together (warning: untested!)

  ;--this is in VBLANK

  lda #<SpriteData
  sec
  sbc SpriteYPosition
  clc
  adc #SPRITEHEIGHT
  sta SpritePtr
  lda #>SpriteData
  sta SpritePtr+1


 ;--snip

 ;--this is part of the kernel

  lda #SPRITEHEIGHT
  dcp SpriteYCounter
  bcc SkipDraw
  lda (SpritePtr),Y
  sta GRP0
ReturnFromSkipDraw


 ;--snip

 ;--this is data:

  org $FEF0

SpriteData
       .byte #%00000000
       .byte #%00011000
       .byte #%00111100
       .byte #%01100110
       .byte #%01111110
       .byte #%01011010
       .byte #%00111100
       .byte #%00011000

The first snippet shows how you would set up your pointers correctly.

The second snippet shows how (using SkipDraw) you would draw your sprite during your kernel.

The third snippet shows how your sprite data needs to be upside down and, generally, positioned near the end of a page.

Zach · May 6, 2005

Thanks, vdub_bobby. Unfortunately, I'm not convinced that there is time for Skipdraw in this kernel. In particular, the line where the green blocks are drawn requires many color changes. In that line, I use the following:

ldy santa_current_line ;3
iny                    ;2
ldx santagrp,Y         ;4
stx GRP0               ;3

It only takes 12 cycles to update GRP0 on that line. The new value of santa_current_line is saved on the next line. If I counted correctly, Skipdraw takes 17 cycles when the branch is not taken.

Edited May 6, 2005 by Zach

vdub_bobby · May 6, 2005

Thanks, vdub_bobby. Unfortunately, I'm not convinced that there is time for Skipdraw in this kernel. In particular, the line where the green blocks are drawn requires many color changes. In that line, I use the following:
ldy santa_current_line;3
iny                  ;2
ldx santagrp,Y       ;4
stx GRP0             ;3
It only takes 12 cycles to update GRP0 on that line. The new value of santa_current_line is saved on the next line. If I counted correctly, Skipdraw takes 17 cycles when the branch is not taken.

850706[/snapback]

SkipDraw does indeed take 17 cycles, whether the branch is taken or not.

But if that isn't fast enough, you can use SwitchDraw, which only takes 15 cycles:

 ;--SwitchDraw
;    TopLine == top line of sprite
;    BottomLine == bottom line of sprite ORed with $80
;   requires scanline counter < $80 (i.e., 128 lines, though you
;   can get around this by interlacing your graphics)



  cpy TopLine       ;+3    3
  beq SwitchDraw    ;+2    5
  bpl Wait          ;+2    7
  lda (ind),Y       ;+5   12
  sta GRP0          ;+3   15
ReturnFromSwitchDraw



;--snip

SwitchDraw
  lda BottomLine    ;+3    9
  sta TopLine       ;+3   12
  bmi ReturnFromSwitchDraw  ;+3   15    branch always


Wait
  SLEEP 4           ;+4   12
  bpl ReturnFromSwitchDraw  ;+3   15    branch always

Edited May 6, 2005 by vdub_bobby

Zach · May 6, 2005

Switchdraw might work. It's worth a try.

dm4714 · May 7, 2005

Hello, here are mockup screens for a new Q*Bert. Yes I know: the game exists for the 2600 and there are copyrights on it. But I want to try to make graphics better (but it's not easy). Please give comments:

Version 1:

Version 2:

And if the copyrights are a problem: Here is Santa-Q (or X*Bert?, he jumps on a X-mas tree and turn on the lights):

743490[/snapback]

Hi --

what are you using to design your mockup images?

Retrofan · May 9, 2005

I'm using Photoshop/Mac for my mockup screens.

dm4714 · May 12, 2005

Hello, here are mockup screens for a new Q*Bert. Yes I know: the game exists for the 2600 and there are copyrights on it. But I want to try to make graphics better (but it's not easy). Please give comments:

Version 1:

Version 2:

And if the copyrights are a problem: Here is Santa-Q (or X*Bert?, he jumps on a X-mas tree and turn on the lights):

743490[/snapback]

Hi --

what are you using to design your mockup images?

851084[/snapback]

I'm curious -- what settings within Paintshop are you using for the graphics? I mean, are is it a one-for-one in size or are you converting it or something?

Can you share the png?

Retrofan · May 13, 2005

I'm not using Paintshop, I'm using Photoshop (Adobe). I'm drawing the graphics in 160 x 200 (RGB) using a VCS color table (internet download) and a 4 x 4 pixel grid. Then I'm reducing the colors to only the used (2 - 8 bit), stretching the image horizontal to 320 x 200 pixels and saving it as a GIF file.

Q-Bert mockup screens and X-mas version

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members