Inconsistent Graphics

[+Karl G]

I was doing a little experimenting with 7800 Basic, drawing a character background, a ship, and a row of 3 aliens in 160A mode. Depending on the Y value chosen for plotsprite, either 1 or all 3 aliens show up (e.g. all 3 do for a Y value of 80, but only one does for a Y value of 90).

 

The symptoms match what the docs say about MARIA running out of render time, but I wouldn't think that 3 sprites + character background would be enough to cause this.  Also, why the inconsistency with the Y position?  My first thought was that this is due to the sprites getting doubled-up due to crossing zone boundaries, but even when I set each sprite to Y values meant to put each in their own zone, it still is an issue (although perhaps I was off by one on the zone boundary).

 

I've attached the zipped project, and also am putting the source inline, since it is short.

Spoiler

	set zoneheight 16
	set doublewide on
	displaymode 160A
    set romsize 48k
    set screenheight 192
    set pauseroutine on
    set basepath gfx
    dim ShipX = a
    dim PlayerWidth = b
    dim ShipInc = c
    dim Boolean = d
    dim FireButtonPressedBit0 = d
    dim Clock = e
    const screen_right = 159
    const screen_left = 0
    const offscreen = 200
    const ship_y = 176
    
    P0C1=$0B: P0C2=$28: P0C3=$0F
    P1C1=$06: P1C2=$02: P1C3=$24
    P2C1=$78: P2C2=$75: P2C3=$69
    incgraphic ship.png
    incgraphic stars.png
    incgraphic oct1.png
    incgraphic oct2.png
    ShipX = 80
    PlayerWidth = 8
    ShipInc = 2

	characterset stars
	
	clearscreen

	plotmap stars_map 1 0 0 20 12

	savescreen

	drawscreen
	
Main
    BACKGRND=$00
    Clock = Clock + 1
    if Clock > 100 then Clock = 0
    if joy0right then ShipX = ShipX + ShipInc
    if joy0left then ShipX = ShipX - ShipInc
    if ShipX >= offscreen then ShipX = screen_left
    if ShipX > screen_right - PlayerWidth then ShipX = screen_right - PlayerWidth
    if !joy0fire then FireButtonPressedBit0{0} = 0 : goto ____skip_joystick_button
    if FireButtonPressedBit0{0} then goto ____skip_joystick_button
    playsfx sfx_shoot
    FireButtonPressedBit0{0} = 1
____skip_joystick_button
    restorescreen
    plotsprite ship 0 ShipX 176
    if Clock > 50 then temp9 = 1 else temp9 = 0
    plotsprite oct1 2 62 90 temp9
    plotsprite oct1 2 78 90 temp9
    plotsprite oct1 2 94 90 temp9
    drawscreen
    goto Main


	alphachars 'a'

   alphadata stars_map stars
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
   'aaaaaaaaaaaaaaaaaaaa'
end

    data sfx_shoot
    16, 4, 1
    $3, $1, $D
    $2, $1, $F
    $2, $1, $D
    $3, $1, $C
    $4, $1, $B
    $5, $1, $A
    $6, $1, $8
    $7, $1, $8
    $7, $1, $6
    0, 0, 0
end

 

 

 

space-7800.zip

[RevEng]

Like in bB, in 7800basic you aren't guaranteed that temp variables keep their values across certain commands. In your case, plotsprite is stepping on temp9, and unintended things.

 

There's a lot more memory in the 7800 than the 2600, so treat yourself to a bunch of your own temp variables. I usually call mine mytemp1, mytemp2, ...

 

After avoiding temp9, your demo shows all sprites with consistent y positioning.

[+Karl G]

Ahh! I thought I was safe going as high as temp9, though I shouldn't be making assumptions about how things are implemented under the hood, since those could change, anyway.  Thanks! 

[RevEng]

You're welcome!

[+mksmith]

Awesome to see you in here Karl! Think you'll enjoy the relative freedom of the 7800 ?

[+Karl G]

Well, thank you.  Right now I'm just dabbling, but I've had some ideas for 7800 projects for quite a while. I'm in the midst of a big project for the 2600, but I figured working on a port of Space Game (Space: 7800?) would be a good way to learn and get my feet wet.  ?

 

By the way, I am using your image editor, even if I'm not yet using the whole IDE (I'm a creature of habit, and like my existing editor with its command-line integration). The editor is nice and simple, and works well.

[+mksmith]

6 hours ago, Karl G said:

Well, thank you.  Right now I'm just dabbling, but I've had some ideas for 7800 projects for quite a while. I'm in the midst of a big project for the 2600, but I figured working on a port of Space Game (Space: 7800?) would be a good way to learn and get my feet wet.  ?

 

By the way, I am using your image editor, even if I'm not yet using the whole IDE (I'm a creature of habit, and like my existing editor with its command-line integration). The editor is nice and simple, and works well.

Great - it's a fun game and there isn't any real shooters from what I can tell.

 

The editor does the job - still needs a few more features such as importing (not sure how the color mapping would work though), copy/paste and export all frames would be the most required things I have found. Just having it produce pngs compatible is the biggest win ?

[+Karl G]

On 8/17/2019 at 6:04 PM, mksmith said:

The editor does the job - still needs a few more features such as importing (not sure how the color mapping would work though), copy/paste and export all frames would be the most required things I have found. Just having it produce pngs compatible is the biggest win ?

I was thinking a bit about this, and maybe for importing you could have it look for specific colors to correspond to specific palette entries. #FF0000 could always be palette entry 1, #00FF00 could always be palette entry 2, etc. A good number of editors don't seem capable of producing indexed PNGs, so it would be nice to be able to have a workaround that allows others to be used and converted to the correct format. In the meantime, your simple editor is getting the job done. ?

 

One small feature request: it would be handy to have 4 buttons scroll the whole image in the specified direction by one pixel.

[+mksmith]

9 hours ago, Karl G said:

I was thinking a bit about this, and maybe for importing you could have it look for specific colors to correspond to specific palette entries. #FF0000 could always be palette entry 1, #00FF00 could always be palette entry 2, etc. A good number of editors don't seem capable of producing indexed PNGs, so it would be nice to be able to have a workaround that allows others to be used and converted to the correct format. In the meantime, your simple editor is getting the job done. ?

 

One small feature request: it would be handy to have 4 buttons scroll the whole image in the specified direction by one pixel.

The indexed pngs is the biggest issue for mine and was one of the reasons I started the editor in the first place and delayed starting a game.  Thanks for the suggestion about the conversion - will definitely investigate.

 

Interestingly the 4 button scroll was in the early releases of the base editor and was just removed when I picked up the source.  Will get that into the next build for you - the existing feature works pretty well but both options work well for different reasons.