7800basic beta, the release thread

[+Karl G]

Is there any way to constraint a sprite to only be drawn to the current zone, regardless of positioning? I was thinking setting the optional tallsprite parameter of plotsprite would do this, but it seems like that only work for tallsprites (go figure!).

 

Failing that, I could use some advice on how to avoid having sprites bleeding into the area at the bottom of a screen that would be used for a HUD or the like?

 

The only idea I have is to draw the HUD last so that it would cover any sprites that would bleed into that area, but that would mean that the HUD couldn't be saved with savescreen, thus saving cycles.

 

Is there perhaps some magic that could be done with a bottomscreenroutine, or are there any other approaches that might work for a case like this?

[RevEng]

Have a look at lockzone and unlockzone. You should be able to lock the zones involved in the hud, and the sprites will appear to disappear as they move into the locked hud zone.Then you can unlock the hud if you need to plot hud elements on top of it.

 

Locking and unlocking is a relatively cheap activity.

[+Karl G]

54 minutes ago, RevEng said:

Have a look at lockzone and unlockzone. You should be able to lock the zones involved in the hud, and the sprites will appear to disappear as they move into the locked hud zone.Then you can unlock the hud if you need to plot hud elements on top of it.

 

Locking and unlocking is a relatively cheap activity.

It works perfectly! Thank you muchly.  🙂 

[+Atarius Maximus]

RevEng beat me to it.   Using lockzone/unlockzone is how I handled sprites scrolling behind the HUD in Alpine Avenger.

[RevEng]

It's a niche application, but I always though it would also be useful to allow characters on a "lower level" to go underneath an overpass...

But for sure, HUDs are the main application.

[+frankodragon]

While it's no cause for alarm, sometimes when compiling,  I get a syntax error that results when I use "$09". I.E. "error:syntax error #09.....aborting assembly. " But then it goes ahead and compiles it anyway.  It doesn't pick all of the decimal $09's in the code.  Just seems to be some quirk 7800Basic has?

[RevEng]

7 hours ago, frankodragon said:

While it's no cause for alarm, sometimes when compiling,  I get a syntax error that results when I use "$09". I.E. "error:syntax error #09.....aborting assembly. " But then it goes ahead and compiles it anyway.  It doesn't pick all of the decimal $09's in the code.  Just seems to be some quirk 7800Basic has?

The 7800basic compile process checks if the produced rom from the underlying dasm assembly looks to be the right size. The messages you're quoting are from dasm, but if the produced rom looks right (it happens, but it's rare) then 7800basic isn't aware of the problem. That produced rom is definitely broken in some way.

 

There isn't a general problem with using "$09" in 7800basic source code. Your dasm error indicates that you've used "09" somewhere instead of "$09". If I use "09" in source I can replicate your error. It looks like dasm doesn't accept zeroes in front of decimal values.

[+Karl G]

I have encountered this with dasm before myself. If there is a leading zero, and it is not a hex digit, then the assembler assumes that it is an octal value. This is fine for 00 - 07, but it chokes on 08 and 09 as invalid octal values. 

[RevEng]

18 minutes ago, Karl G said:

I have encountered this with dasm before myself. If there is a leading zero, and it is not a hex digit, then the assembler assumes that it is an octal value. This is fine for 00 - 07, but it chokes on 08 and 09 as invalid octal values. 

Ahhhh, thanks for that explanation. Makes sense. I originally figured it was a dasm parser issue, rather than something intentional.