7800basic, under the hood

[RevEng]

I put together some assembly routines for 7800basic that you can use to modify already-plotted DL objects. The reason you might want to do that is to save cycles by baking the object into your screen with a "savescreen", and still have the ability to modify the object later.

 

underthehood.zip underthehood.bas.a78

 

[JS7800 live demo here]

 

This will be in the samples directory of the next official release, but I figured some of you might have use for it. This is basically the same tech that @mksmith and I came up with for Arkanoid, and how that game manages to have uniquely coloured blocks and background without DMA issues - each block is a sprite with it's own palette index.

 

It's easy enough to shoot yourself in the foot with this technique, and you should probably have a general idea of how DLs work, which is why this is "under the hood" and not official 7800basic functionality.

[+mksmith]

22 minutes ago, RevEng said:

I put together some assembly routines for 7800basic that you can use to modify already-plotted DL objects. The reason you might want to do that is to save cycles by baking the object into your screen with a "savescreen", and still have the ability to modify the object later.

 

underthehood.zip 10.63 kB · 1 download   underthehood.bas.a78 32.13 kB · 2 downloads

 

[JS7800 live demo here]

 

This will be in the samples directory of the next official release, but I figured some of you might have use for it. This is the same tech that @mksmith and I came up with for Arkanoid, and how it manages to have uniquely coloured blocks without DMA issues - each block is a sprite with it's own palette index.

 

It's easy enough to shoot yourself in the foot with this technique, and you should probably have a general idea of how DLs work, which is why this is "under the hood" and not official 7800basic functionality.

Great stuff Mike who did all the awesome work on this one! 

 

I've also used this extensively with Millie and Molly to render the entire screen as tiles ie, blocks, ladders, dirt, monster animations (excluding the players which are overlaid). Essentially the screen is laid out like a map and then you can update co-ordinates (tiles) with the new image pointer.  On top of this you can overlay sprites each draw but you will still eventually run out of draw time if you draw too many. 

 

Couple of things to watch out for include 

• using tall sprites (> zone height) - you will need to adjust in this instance to draw each zone
• you can't mix 160A and 160B (did some initial investigations)
• you can't use DoubleBuffer - I would argue you can probably get more onscreen using this!

There would have been no other way to do either Millie and Molly or Arkanoid without this code!!  I also think this would potentially be a great engine for a flick-screen map game - including animated tiles (16x16 probably recommended).

 

[Mord]

Yeah going under the hood to fiddle with the DLs themselves can really save some cycles. I do it in several places in Graze Suit Alpha like for moving the walls in the snapshots I released that use them. I basically have the walls, as well as all the status bar info at top and the indicators at the bottom baked in and adjust them in various ways to avoid replotting them. 

 

Really need to know the formatting of the DLs and DLLs and be able to keep track of the order you're plotting though or it causes more headaches than anything else!

[Mord]

Also, I actually do use double buffering in Graze Suit Alpha as well while tweaking the DLs. It complicates things since you have two different sets of DLLs to maintain, but it is doable.

[TailChao]

I'm not a 7800basic user, but some general stuff for unrolled Display List techniques like this...

 

Quote

I've also used this extensively with Millie and Molly to render the entire screen as tiles ie, blocks, ladders, dirt, monster animations (excluding the players which are overlaid). Essentially the screen is laid out like a map and then you can update co-ordinates (tiles) with the new image pointer.  On top of this you can overlay sprites each draw but you will still eventually run out of draw time if you draw too many. 

Using only 4-Byte Display Lists and grouping your tiles together into larger draws when they're both sequential in memory and share a palette makes the fillrate go way, way, way up. Then you'll have more time to draw foreground items or have Sally actually run the game.

 

 

Quote

I also think this would potentially be a great engine for a flick-screen map game - including animated tiles (16x16 probably recommended).

You can also use it for scrolling by having your unrolled background drawn slightly larger than the visible screen. Nudge your tiles each frame the camera moves while unrolling the Display Lists for the next coarse "step" left or right.

Edited May 30, 2020 by TailChao

[+SmittyB]

Thanks for this.

I've just implemented the x positioning in SotA for the screen shake when you get hit instead of redrawing the walls. This is how I really wanted to do it from the start but didn't know how, and it's now a much better effect thanks to the speed increase.

[RevEng]

Super thrilled you found it useful!

[SlidellMan]

This could be useful for palette swapping for my Shmup's HUD. Thanks, Rev Eng.

[+Karl G]

I've played around with this method, and I mostly have the hang of it, I think. I have a question on how to handle an object that traverses zones, however. Presumably a sprite that straddles two zones needs to be enabled in both zones. Now let's suppose half of the sprite should display in the upper zone, and half in the lower zone. Displaying the top part of the sprite in the upper zone should be easy, as it would just truncate when the edge of the zone is reached. How does one display the bottom of that sprite at the top of the lower zone, though? Does one have to create and plot partial sprites here to do this, or is there a cleaner way?

[+mksmith]

8 hours ago, Karl G said:

I've played around with this method, and I mostly have the hang of it, I think. I have a question on how to handle an object that traverses zones, however. Presumably a sprite that straddles two zones needs to be enabled in both zones. Now let's suppose half of the sprite should display in the upper zone, and half in the lower zone. Displaying the top part of the sprite in the upper zone should be easy, as it would just truncate when the edge of the zone is reached. How does one display the bottom of that sprite at the top of the lower zone, though? Does one have to create and plot partial sprites here to do this, or is there a cleaner way?

I actually haven't investigated what would be required here. The reference of the sprite may/will change based on the zone it finds itself but what it would look like crossing into the next one would be interesting to investigate.  I think you would be right about it requiring multiple updates (one for each zone).

[RevEng]

On 9/14/2022 at 11:08 AM, Karl G said:

I've played around with this method, and I mostly have the hang of it, I think. I have a question on how to handle an object that traverses zones, however. Presumably a sprite that straddles two zones needs to be enabled in both zones. Now let's suppose half of the sprite should display in the upper zone, and half in the lower zone. Displaying the top part of the sprite in the upper zone should be easy, as it would just truncate when the edge of the zone is reached. How does one display the bottom of that sprite at the top of the lower zone, though? Does one have to create and plot partial sprites here to do this, or is there a cleaner way?

DLs don't allow for negative Y, so for the bottom half of the sprite you need to call "SetObjectImage" with an offset to the image. If you change the "IMAGE" example in the underthehood.bas demo from "SetObjectImage smallball" to "SetObjectImage (ball-8*256)" you'll see what I mean.

 

Using the macros, you'll want to change your offset to "(image-16*256)" so it points past the top of the image, and then adjust the Y. Even more efficient would be to write your own assembly routine based on the underthehood ones that just adjusts the DL object hi pointer by itself, leaving the Y at 0.