Should I use Shapes or Sprites?

[madaxe]

Well, I made several tests with different sizes but the result is always the same. It seems no matter what length the shape is. We get that empty space around our shape. Only on horizontal and never on vertical.





I know that some old games written in Blitz like Insectoids and Iridion uses only queue blits do draw and to move the shapes but this empty space doesn't happen. How it can made?

[idrougge]

Do you get that box even if you never unqueue?

[madaxe]

Hi;

No, this only happens after the Unqueue command. After QBlit and before Unqueue the empty space box doesn't appear.

The sequence is something like this:

QBlit 0,#shape,50,50


UnQueue 0


QBlit 0,#shape,50,50


I always thought that UnQueue only erased the size of the shape but it seems that erases a bit more

The problem is when a shape is near another and the empty space erases part of the second shape. But I'll find out how to resolve it

[Daedalus]

It looks like your source shapes might have some blank pixels to the left of the shape as well, because it shouldn't erase more than the width of the shape (rounded up to the next 16 pixels). What does Blitz report the actual width of the shapes as? You can use

sw.w = ShapeWidth(0)

to get the internally stored width of the shape (in this case, shape ID 0), and then NPrint sw to somewhere convenient.

[madaxe]

Originally Posted by Daedalus

You can use

sw.w = ShapeWidth(0)

to get the internally stored width of the shape (in this case, shape ID 0), and then NPrint sw to somewhere convenient.

Thank you for your tip When I get home I'll try it to see what it returns.



I found that @gazj82 reported this problem before

http://eab.abime.net/showthread.php?t=90061

[Daedalus]

Ah, that's interesting... What might also be happening here is that your X coordinate is also rounded to the lower 16 pixel boundary and the width extended to cover the shape (to the nearest higher 16 pixel boundary). What happens if you blit at, say, 32x32?

[Master484]

The problem is when a shape is near another and the empty space erases part of the second shape.

This can happen if you're drawing some objects with "BBlits" and some with "QBlits".

Try to draw the BBlits first, and then the Qblits. And then "Unqueue" the Qblits first, and only after that "Unbuffer" the BBlits.

If you do it the other way around then the QBlit Unqueue "erase box" can destroy the "BBlit" images. But BBlit "Unbuffer" cannot destroy the "QBlit" images, because BBlits don't have that "erase box"; instead they use pixel perfect restore.

And if this doesn't help, then try switching the order of BBlits and Qblits, and the order of Unbuffer and Unqueues too, to see if it makes any difference.

---

But if these Qblit "erase boxes" damage other Qblit objects too, then the problem could be that you use double buffering, but have only one Queue for your Qblits. So in this case try having 2 Queues, that you change at the same time with the Double Buffer bitmap changes.

[Master484]

Also about those empty boxes around the Qblits, I just remembered that I once tried to make a "demo effect" where I tried to make a sort of an "bitmap reveal" using the Qblit "Unqueues" , so that the Unqueue source was an another bitmap.

But I found out that the Unqueues always revealed areas that were larger than the shape that I used. And also the areas seemed to always start from the nearest 16 pixel location. It was as if the Unqueue worked in the same way as the Blitz "Block" command does: 16 pixel areas only, and draw must start from a X location that can be divided by 16.

So I think each Qblit marks 16 pixel blocks of the bitmap as "dirty", and then Unqueue cleans those blocks. And often even a small object is big enough to actually overlap two 16 pixel blocks, so this is why it then needs to clean two blocks, so 32 pixels instead of 16. And this is why the objects have those 32 pixel black boxes around them.

---
---


But about the problem described here, which was Qblits erasing other moving objects, I thought about this, and this sort of thing should never happen if the game engine is designed in a normal way. It should work even if Qblits and BBlits are used at the same time.

So the main game loop should look something like this:

VWAIT
Show bitmap
Change bitmap
Change Qblit Queue
Change Bblit Buffer
Unqueue
Unbuffer
Draw Bblits
Draw Qblits

So there needs to be 2 bitmaps, 2 buffers and 2 queues, if both Qblits and Bblits are used. And Bblits should be drawn before Qblits I think, but I'm not sure, I have never used both at the same time.

Using that sort of main loop, the moving objects should never "erase" each other. But of course Qblit unqueues will still erase non-moving background graphics, and things like score panels too.

[madaxe]

Originally Posted by Master484

But I found out that the Unqueues always revealed areas that were larger than the shape that I used. And also the areas seemed to always start from the nearest 16 pixel location. It was as if the Unqueue worked in the same way as the Blitz "Block" command does: 16 pixel areas only, and draw must start from a X location that can be divided by 16.

So I think each Qblit marks 16 pixel blocks of the bitmap as "dirty", and then Unqueue cleans those blocks. And often even a small object is big enough to actually overlap two 16 pixel blocks, so this is why it then needs to clean two blocks, so 32 pixels instead of 16. And this is why the objects have those 32 pixel black boxes around them.

Exactly, you are right! Thank you for your good explanation @Master484

I made this little code where we can see this happening:

BitMap 0,320,256,4

Boxf 0,0,15,15,1
GetaShape 0,0,0,16,16

BitMapOutput0
Locate 0,2

InitCopList 0,$4

InitPalette 0,16

PalRGB 0,0,0,0,0
PalRGB 0,1,15,15,15
PalRGB 0,2,0,0,15

BLITZ

CreateDisplay 0

DisplayBitMap 0,0
DisplayPalette 0,0

Boxf 0,0,319,255,2
Colour 1,2
Print "0123456789012345678901234567890123456789"

Queue 0,1

For x=0 To 302 Step 2
  UnQueue 0
  QBlit 0,0,x,0
  VWait 5
Next

MouseWait

End

I wonder if this happens with buffer blits too! Does the UnBuffer restores areas that were larger than the shape that we used? I'll give a try

[madaxe]

Originally Posted by Master484

If you do it the other way around then the QBlit Unqueue "erase box" can destroy the "BBlit" images. But BBlit "Unbuffer" cannot destroy the "QBlit" images, because BBlits don't have that "erase box"; instead they use pixel perfect restore.

Thanks again @Master484
In fact, I found out that my Unqueue was placed wrong in my code.
I moved it to the right place and now no shapes are erased

[Master484]

I wonder if this happens with buffer blits too! Does the UnBuffer restores areas that were larger than the shape that we used?

I think UnBuffer uses a pixel perfect background restore, meaning that only the "solid" pixels of the Shape are "restored" when Unbuffer is executed. So transparent pixels in the Shape ( color 0 pixels ) are not restored, and the restored area will never be larger than the Shape itself.

But I'm not 100 % sure.

The problem is when they move they damage with empty space some stuff like the score panel

This happens if the score panel is located in the same bitmap as the moving graphics. QBlits are hard to use if the bitmap where you draw them has any background graphics or panels.

The best solution is to put your score panel to a separate screen area. So for your game screen, use either two Coplists or two Slices, depending on which Blitz graphics library you use. So for example you can have a 320*200 main game area Coplist and under that put a 320*32 size score panel Coplist. This is how score panels are done in most games. Also notice that the two Coplists need to have a few empty lines between them, usually 2 or 3.

Also if you're doing a shoot'em up, then this thread might be useful:
http://eab.abime.net/showthread.php?t=92900&page=6

Scroll down on that page, and you'll see posts where I uploaded a small collision test demo with Blitz source code included on disk. It uses Dual Playfield and QBlits, and shows how to use a second Coplist for the score panel, and also it has fast collisions code and sprites.

---

QBlits are much faster than BBlits, so if you need to draw lots of stuff I would recommend QBlits. And Dual PF is ideal for QBlits, because you can have the background on the back bitmap and the moving objects on the front bitmap.

Also BBlits need those Buffers, which consume lots of Chip RAM. And if you draw more BBlits during a frame than your Buffers can handle, then there'll be memory overflow and the computer can crash.

But with QBlits you can draw hundreds of objects with ease; the Queues don't use much RAM.

[madaxe]

Originally Posted by Master484

Also if you're doing a shoot'em up, then this thread might be useful:
http://eab.abime.net/showthread.php?t=92900&page=6

Wow, thank you very much for all of your great help and tips

Yeap, I'm converting to Amiga a little and simple shoot'em up that I made to PC Windows and Speccy. This is a vertical shoot'em up and I would like to have my score panel on left or right side of the screen. How can I achive this? I know that using a new InitCopperList I can get a panel on top or bottom of the screen, but I don't know if this helps when the panel is on the side. Any ideas?




Thanks in advance,
José Mário aka Madaxe

[Master484]

I know that using a new InitCopperList I can get a panel on top or bottom of the screen, but I don't know if this helps when the panel is on the side. Any ideas?

That's right, splitting the screen with Copperlists won't help here. You can split the screen only vertically, but not horizontally.

If you want a side panel, then I think the only way is to draw the entire score panel every frame, just like the game objects are drawn. Although this can be a little bit slow.

But Blitz has one very fast drawing command called "Block", which can be used to draw the panel. But the "Block" command can only draw Shapes that have an X width that is a multiple of 16. So the Shape Width has to be 16 or 32 or 48 and so on. And also the X location where you draw the Shape has to be a multiple of 16. So possible X locations are 0,16,32 and so on.

So first draw all your moving graphics, and then draw the score panel with one huge Block. This way the moving graphics can never destroy the panel, because the panel is drawn last.

And when you draw the number values for score, lives etc, do this after the Block...although this will be slow because you need to draw lots of numbers every frame. Doing many blits is slow, and also the Print command is slow; printing one character is as slow as Blitting one character.

Also about the Block command: it draws all "color 0" pixels as "solid" pixels...so Shapes won't have transparent pixels like in QBlit and BBlit. However, on Dual Playfield displays, if Block is used to draw stuff to the Front Playfield, then everything that is in Back Playfield will still "show through" those color 0 pixels. And this can be either good or bad, depending on the situation.

So if you use Block to draw the score panel to the Front PF, then the Starfield in the Back PF will "show through" the color 0 pixels. But of course this only happens if you use Dual PF, and if the Back PF starfield is so big that it goes "under" the panel too.

---

So, in a nutshell, having a score panel in the side can be done, but it requires that you draw it, and all the numbers too, every frame. So it can be done, but at a price.

The alternative method, splitting the screen and having the panel in a separate screen area, would be much faster, because then you only need to draw the panel only once when the game begins, and the score numbers and other stuff need to be updated only when the values change, instead of drawing them too every frame.

Although the same might be achieved with the side panel too, if it's a dual PF game and only the back PF scrolls, and if you design the enemies moving patterns so, that they never go to the panel area. Then you would only need to draw the panel once, and only update the numbers when needed.

Most commercial Amiga games which had panels in the sides were direct Atari ST conversions, which scrolled the screen by blitting every tile every frame, and a big score panel made the scrolling game area smaller, and so the games gained more speed this way.

But most games that were designed for the Amiga, and which scroll, almost never have a side panel. Although there are some exceptions like Banshee and Rod-Land, but in these games the panels were made of Sprites. And this is the second way to do it: use sprites. However, you need a lot of them, because all those score numbers then have to be sprites. And so you would need advanced sprite multiplication, which in turn needs assembler routines or maybe some crazy Blitz extra commands library.

[Daedalus]

If you're using the Block command for the score panel, instead of actually drawing each object, it makes sense to keep a copy of the score panel as a separate bitmap which you update as needed, then block the whole thing in one go, rather than rewriting all the numbers each frame. That will save some (or lots of) time, depending on how much of the panel needs to be re-rendered. Check out the ShapesBitMap command for this sort of method. Sacrificing a pen of the palette as a second black will allow you to stop any background showing through on the panel.

If you use sprites for the panel, it's actually not that complicated. On OCS/ECS, you can join sprites for double width sprites, so a panel 64 wide with 3 colours is made from just two double sprites (4 channels). The palette will be restrictive in this configuration however. If you can get away with a 32-pixel-wide panel, even better as it's much simpler to deal with. The same issue with the background showing through applies here, so you'd need to sacrifice one of your pens if needed, leaving just 2 colours for the panel. Doubling up the sprite channels would let you use 15 colours for the panel, alleviating the issue with limited pens being reused for other sprites.

You don't need separate sprites for the scores, the same applies as the Block process: Simply draw the values to a ShapesBitMap and update the sprites from that each time they're needed.

[idrougge]

Similar games use sprites for the side panel.

[madaxe]

@Daedalus
@Master484

Hi guys;

Thank you very much for your great help and nice ideas

I'll try a bottom panel with a new InitCopList and a side panel with Block/ShapesBitMap. Then I'll decide which of them I like more and wich of them will be more fast and more easy to implement

It's just my opinion, but a for a vertical shoot'm'up I like to see a side panel like in the PC and Speccy versions. But I think a bottom panel will be more easy to implement and to manage and I don't need that all the versions be exactaly equals

[Daedalus]

Yeah, for vertical scrollers it's always good to have as much vertical resolution for the game area as possible. If you're targeting PAL machines though, you can still have 200 pixels of space for the game, as is often found in games, and use the extra 56 pixels for the panel. Once the game is running, you can always try modifying it for a side panel using sprites.

[Havie]

If you are using dual play fields could you not just have the panel on the play field that you don't blit the Bob's to and this way they won't affect it? Obviously I don't know the inner workings of your game so this may not be possible?

[Daedalus]

True, if you can ensure that nothing gets drawn in that area then there's no reason it can't be static. Fair point.

[madaxe]

Hi, greetings to everyone.

Finally I completed my little shoot'em'up coded in Blitz Basic 2.
I want to thank you all in EAB for your great help, support and nice ideas

More info on this thread:
http://eab.abime.net/showthread.php?t=97026

Best Regards and Happy Easter,
José Mário Machado a.k.a. MadAxe