savescreen / restorescreen question

[fultonbot]

I have a seemingly simple question.

Does it matter how I build a bitmap screen before I save it?

My test bed right now is zoneheight 8 to see how many 8x8 sprites I can get on the screen

I created a background using 16x16 sprites and did savescreen

There is a HUGE difference between the amount of 8x8 sprites I can get in a zone with and without a background

I get about 5 with the background, and about 15 without the background

Will I see a difference if I build the background using plotmap/plotmapfile or if I change the size of the bitmaps I used for the background?

 

 

 

[+SmittyB]

When you call one of the many plot functions in 7800BASIC what it's actually doing for you behind the scenes is setting up instructions for how the 7800 should draw what you want called 'Display Lists' and it's these display lists that it's making a copy of when you call savescreen. How you choose to draw your graphics on the 7800 is important because you can do things in different ways and some are less efficient than others.

 

I'll go into more detail below, but there are 2 main limitations with how much you can draw on the screen:

 

The first is how many display lists your game can keep track of at any one time for a given zone. If you go over the limit then either no other objects will be drawn in the zone, or if zoneprotection isn't enabled it will start corrupting the other zones below it. The limit depends on a few things (I think including zone height) but 7800BASIC will tell you what it is when you compile. In the example below it's saying I can draw 12 things in a zone.

 $18e0 to $1fff used as zone memory, allowing 12 display objects per zone.

 

The second limit is how many bytes of data the graphics chip MARIA has to read on a given line. As the screen is being drawn it loads the graphics for the next line and if it runs out of time it'll just draw what it's managed to do so far.

Different graphics modes have an effect on the amount of data needed to draw as 320A can represent 8 pixels with a byte, 160A represents 4 pixels, and 160B represents 2 pixels per byte so you need more data to cover the same area of the screen.

Another thing is 'indirect mode' which is what's used when you draw something that uses a tile map and will also require more data to be read as rather than just saying "Draw this and make it that wide" it has to first read the tile map, and then get the graphics for the tile so it's closer to "Read this, draw what it tells you, then do it that many times". Some homebrew avoid using tile maps to squeeze a bit extra out of the system by using a few wide sprites instead.

The other thing to be aware of is that the display lists I mentioned before also count, so drawing one 16 pixel wide sprite actually requires less data than 2 8 pixel wide sprites.

[fultonbot]

19 hours ago, SmittyB said:

 

The other thing to be aware of is that the display lists I mentioned before also count, so drawing one 16 pixel wide sprite actually requires less data than 2 8 pixel wide sprites.

Wow!  Yes, this is what I wanted to explore.
So if I read  that right, savescreen/restorescreen don't save/restore a bitmap. but a displaylist, so the way it's created could certainly affect performance.
 

My guess is then, if I had a background made of wider (32-96 pixel) , 16 pixels high sprites saved to as a background, I'd see a performance boost. 

 

Would loadbanner help here too?  Could I load a background that was 160x192 saved a single entry on the display list?  That would probably slow everything to a crawl.

 

Another related question.
The doublebuffer function obviously uses some kind of system clock to calculation delta-time.  Is there anyway to access this/
I want to display an FPS counter on the screen for my tests.

Thanks!!

-Steve
 

 

 

Edited July 18, 2020 by fultonbot
more questions...

[+SmittyB]

I'm on my phone at the moment so I'm being brief through necessity and might ramble a bit.

 

Yes savescreen stores the display lists for how to draw the graphics rather than the graphics themselves.

 

Reducing the number of objects to draw won't necessarily improve the performance of your game (beyond the time needed to initially plot them) but it would affect how much data needs to be read by MARIA and therefore how much you can get away with drawing before hitting the data limits.

 

Everything the 7800 draws is exactly one zone high and aligned vertically with the zone. When you draw something taller than a zone or draw something not aligned to a zone it's actually creating multiple display lists to draw each part in a different zone. As the object limit is per zone you don't need to worry about tall objects as they would only count as one for each zone.

 

Instead of a clock, doublebuffer is actually counting frames as regardless of how many frames your game needs to be ready to update the screen there's a lot of other maintenance and processing going on in the background that 7800BASIC needs to do. It's then just up to you to know that a PAL console will be running at 50 frames per second and an NTSC one at 60 frames per second.

You could use the topscreen routine which is called every frame to increment a counter, then when you draw the screen you draw that number and reset the counter. That way if the number goes from 1 to 2 (or 0 to 1, I'm not sure) then you know your game has slowed down a bit.

 

[fultonbot]

1 hour ago, SmittyB said:

 

 

Reducing the number of objects to draw won't necessarily improve the performance of your game (beyond the time needed to initially plot them) but it would affect how much data needs to be read by MARIA and therefore how much you can get away with drawing before hitting the data limits.

 

You could use the topscreen routine which is called every frame to increment a counter, then when you draw the screen you draw that number and reset the counter. That way if the number goes from 1 to 2 (or 0 to 1, I'm not sure) then you know your game has slowed down a bit.

 

By limiting the displaylist (two 80x16 sprites instead of ten per zone) saved with savescreen I can now get about double the 8x8 sprites in a zone.  It seems like there is a near direct relation to the number of sprites used in savescreen and the number I can get to display with drawscreen.  I have not tried with doublebuffer yet.

I will try the  topscreen bit that looks useful.

Another question:

What is the relationship between the course characters drawing and the sprites. 
Is there a performance benefit to using plotchars to draw background than to use plotsprite?
 
Thanks,

Sorry for so many questions.  I was in the middle of making a game, and decided to pull back and build some demo apps to see how to get the best performance.

[RevEng]

 

1 hour ago, fultonbot said:

By limiting the displaylist (two 80x16 sprites instead of ten per zone) saved with savescreen I can now get about double the 8x8 sprites in a zone.  It seems like there is a near direct relation to the number of sprites used in savescreen and the number I can get to display with drawscreen.  I have not tried with doublebuffer yet.

 

To underscore what SmittyB said earlier, there's different factors than may limit the number of objects that can be drawn in a zone. Trying to make rules about these things without reference to the 3 limiting factors will result in contradictory rules, and it will just be confusing when you don't see results because you're tuning for problems you may not have. The factors:

1. The memory available to hold how many objects Maria should display in any given zone
2. The DMA time available for Maria to render the objects into bitmaps
3. The 6502 time to build DL structures (aka the drawsprite commands.)

Using 2x80 pixel wide sprites before savescreen helps mostly with #2, and some toward #1.  Each sprite or character object has a 4 or 5 byte DL structure that Maria needs to chew through first, before it gets to rendering the graphics bytes. Fewer DL objects to process means Maria can do the rendering work quicker before it runs out of time and gives up. Also, fewer overall background objects means Maria has more memory for foreground objects.

 

The effect of using zoneheight=16 vs 8 is a bit more nuanced. With half the number of zones, a zoneheight of 16 gives you twice as much memory per zone, which goes only to the first factor. If the sprites you're drawing are actually 8 pixels tall with 8 pixels of transparency, using a zoneheight of 16 isn't gaining anything for #2 and #3.  If you the sprites you're drawing are actually 16 pixels taller or more, then using zoneheight=16 goes toward factor #3.

 

The point is figuring out which of the three factors your game will run into first. And if it's #1, it's worth pointing out that there are commands in 7800basic that will let you assign more memory toward zones.

 

1 hour ago, fultonbot said:

What is the relationship between the course characters drawing and the sprites. 
Is there a performance benefit to using plotchars to draw background than to use plotsprite?

For the same area of coverage, characters are a bit more expensive for DMA (factor #2) than sprites, because each character index needs to be looked up before Maria fetches the graphics for the character. If you're comparing multiple small sprites vs a character set, then the characters win for DMA (factor #2) and zone memory (factor #1). When the sprites get up to about 3 or 4 bytes of graphics space, then they start to win with regards to DMA (factor #2), while still still costing more zone memory. (factor #1)

 

Sorry for the lack of simple rules, but it's really not a simple situation.

[fultonbot]

19 minutes ago, RevEng said:

 

 

Sorry for the lack of simple rules, but it's really not a simple situation.

no, this is cool!  I'm not looking for rules.  I'm looking for ways to understand.  the three factors above help very much.

 

So how does DMA time relate to refresh rate?
Do they combine to make an effective frame rate?
 

I've noticed that with 14x23 8x8 sprites with a zoneheight of 8, I'm seeing a "7" in my skipped frames calculations, but it takes almost a second to refresh the screen.

From that I'd say the effective frame-rate is about 8fps.

What am I missing?

Sorry for being a dumbass on this.  

 

-Steve

[RevEng]

DMA doesn't relate to, or otherwise impact frame rate. DMA (Direct Memory Access) is the time that Maria stops the 6502 and reads the RAM for your display list for purposes of rendering it, and this happens on each scanline for some small period of time. If the DMA time reaches a maximum, Maria gives up trying to render any more objects for that line, because the next line is about to to begin.

 

If you're running into frame rate issues, then it's all about factor #3, CPU usage. The other two factors relate to objects that you wanted to have on the screen, but are absent.

 

That said, objects which have been savescreen'ed shouldn't impact your CPU at all. Are you doing something like the following?

 

[plot 14x23 8x8 sprites for the background]

savescreen

mainloop

  restorescreen

  drawscreen

  [game logic]

  [plot moving objects]

  goto mainloop

 

If you're trying to plotsprite 14x23 8x8 sprites each and every frame, that's not going to happen. The 7800 doesn't have enough CPU to pull that off.

 

Side comment: if your game design allows it, you should increase the sprite width so you have fewer sprites for Maria to chew through. This still won't affect framerate (factor 3) if you're savescreen'ing, but it will help with the other two factors.

[fultonbot]

42 minutes ago, RevEng said:

 

 

That said, objects which have been savescreen'ed shouldn't impact your CPU at all. Are you doing something like the following?

 

[plot 14x23 8x8 sprites for the background]

savescreen

mainloop

  restorescreen

  drawscreen

  [game logic]

  [plot moving objects]

  goto mainloop

 

 

 

Yes, exactly.

 

Quote

If you're trying to plotsprite 14x23 8x8 sprites each and every frame, that's not going to happen. 

Yeah, I know. This is actually not a game.  I built a utility so I could push the display as far as possible in various scenarios and see how well it performs.   As I'm watching the results. I have these questions.  My goal is to really understand the trade-offs involved.  It started with the save/restore.  

 

So you are also saying I should play with this and see the results too:

set extradlmemory on

 

?

 

 

[RevEng]

That's only useful if you're needing to go past the maximum objects per zone, as advised by the 7800basic compile messages.

[fultonbot]

16 hours ago, RevEng said:

That's only useful if you're needing to go past the maximum objects per zone, as advised by the 7800basic compile messages.

 

A couple more questions.
1. Is this a good place to start to get a better understanding of all this?: http://7800.8bitdev.org/index.php/7800_Software_Guide

2. I'm wondering if need to get my tests onto real hardware to understand how things will perform.  What is the easiest way to do that? 

 

[RevEng]

#1 - Reading the 7800 Software Guide will give you a better low-level understanding of the hardware, which can only help, but it's not going to connect the dots on how to best do things for a given game design.

 

#2 - While real hardware testing is always recommended, A7800, Mame, and Bupsystem are all very faithful to real hardware in terms of performance. Other emulators are less reliable for this purpose, at this point in time.

 

Presently we're in a "between flash cart" phase, so for now you're stuck with the second hand market. CC2, Mateos, MPC DevCart, and the Concerto early-design-release are the ones that some members are using. If you can't snag one of those (it might be tough or expensive, because supply is lower than demand) then you may need to wait, or rely on the kindness of forum members for the hardware testing.

[fultonbot]

I'm using Atari 7800 Dev Studio with A7800

 

So right now I want to build a side-scrolling shooter.  I started a bit here 

https://raz0red.github.io/js7800/?cart=https://intotheverticalblank.com/downloads/itvb5.bas.a78

But now I've gone back to find out the best mode and bitmap size to use to get the best FX.  That's what these test are for.

From what I can tell, using the character mode graphics is best for an adventure game where I want to check the values of distinct tiles but I don't need to perform explicit collision detection on each one.

For a side scrolling game, it feels like 16 pixel zones are the best, with scrolling background made-up of  wide (48/96pixels)  bitmaps to allow for a maximum number of "sprites" on top without glitching out.   

Doublebuffering appears to really smooth things out.

I'm going to keep that "topscreen" calculation in all my games, and when I see the numbers go from "0" to"1" (or above) I will know that things need to be optimized.  My supposition is that any number above "0" is might be  problematic, but no matter what, the game should stay at the same number the whole time to be consistent.

Edited July 19, 2020 by fultonbot

[SlidellMan]

You have a nice foundation for a great shooter. I, too, am working on one.

[fultonbot]

2 hours ago, SlidellMan said:

You have a nice foundation for a great shooter. I, too, am working on one.

Oh cool, do you have a thread here for it?

[+Muddyfunster]

Really nice start @fultonbot Title screen is very neat and I love that rolling colour effect.  In game, the explosions are nice and meaty and when I saw the boss ship, it instantly reminded me of the battleships in Uridium. 

 

The text seems to fly past a bit quick, maybe slow that down so it's easy for my old eyes to read

Edited July 19, 2020 by Muddyfunster

[fultonbot]

5 minutes ago, Muddyfunster said:

Really nice start @fultonbot Title screen is very neat and I love that rolling colour effect.  In game, the explosions are nice and meaty and when I saw the boss ship, it instantly reminded me of the battleships in Uridium. 

 

The text seems to fly past a bit quick, maybe slow that down so it's easy for my old eyes to read

Oh thanks.  Yeah, I'll take that advice and slow it down.   I have the AtariVox voice saying those messages in my new build.  It's a gimmick but it's fun.