Fastest Technique for clipping a screen

[Havie]

In an ideal world I would block the sprites on the screen and move them using hardware scrolling but without using a dual playfield, I don't know how to put the backgroud in unless it scrolled with the bars (which isn't what I want).

I can see why using AGA is easier...

[Havie]

Right - have rewritten code with qblit but still slows down with 3 pipes?

[Daedalus]

The time taken to blit is directly influenced by the size of the blit, so blitting large objects the full height of the screen is going to be slow - probably no faster than blitting the two halves. Are you using QBlit, BBlit, or how are you restoring the background image?

[Havie]

Followed Master's advice and tried QBlits. Works but slow.

Have retried sprites and it is much faster and smoother. The issue is that I need 6 sprites for the pipes as they are 26 pixels wide and need to work out how to put a space in them.

Collision should be easy though...

[Daedalus]

It adds to the complexity a bit, but you could always try a combination - blitting some of the pipes and using sprites for the others.

[E-Penguin]

There’s always the ol’ blit ahead and behind and hardware scroll trick for infinite scrolling, but that’s probably another rewrite in itself

[Havie]

Arghhh - I forgot that I can't have 6 16 colour sprites! Not going into multiplexing as my Doodle Jump game goes weird with multiplexing so would just confuse matters.

Could do a combination but am still concerned that might be a bit slow as blitting big shapes but...

Never mind - they look fine as 4 colour sprites - just lose the black.

So plan now is to have pipe on the screen at 0,0 so it doesn't show then everytime I need a new pipe, blit a black space to make the gap, grab shape from screen and copy to sprite. Surely this will be fast enough..?

[Havie]

Originally Posted by E-Penguin

There’s always the ol’ blit ahead and behind and hardware scroll trick for infinite scrolling, but that’s probably another rewrite in itself

I'd like to use hardware scrolling but can't see how I can put pipes over background fast enough without using dual playfied and then I might struggle with colours (although if I'm splitting background and foreground colours then this might not be a problem) - I'll come back to this only if I need to! Although this method would mean that I only draw spaces every so often and could use a sprite for the bird (giving me more colours) and I could have more pipes if I needed and maybe even pipes at an angle...starting to talk myself into this!!!

[Daedalus]

Might be worth knocking up a test case to see how it looks. If you use a sprite for the bird, you can use all 7 available foreground colours for the pipes, which might not be too bad. Some dithering could be used if needed too... You still then have 8 background colours and 16 to cover the bird and any other sprites you might use.

[Havie]

Adjusted my plan and put the pipe on a 4 colour screen of 32 width and 190 height. Adding holes and grabbing sprites as needed seems to work really well and using pokes shows colour bars but no flashing so guess the game is running at 50fps?

Got collision detection working as spriteshape detects the pipe even if it is the gap but then once collision has happened I can check to see if bird is within the gap. Need to fiddle with it slightly to make it fairer (maybe a smaller hit box?).

My only other issue is the sprite colours for the pipes! I know that sprites take the top 16 colours of a 32 colour palette ie, 16-31 but the pipes are definitely taking colours form the 0-15 colours!

I have drawn my pipe in 4 colours and then saved the pipe (in 4 colours. I have then saved a 32 colour palette which has the same four colours as colours 16,7,18,19. I then load the palette in bltz before displaying the pipe but this doesn't work and the colours are wrong. I remember having terrible trouble with colours with my Dinorun game (all sprites) so there must be something I am doing wrong???

[Havie]

Originally Posted by Daedalus

Might be worth knocking up a test case to see how it looks. If you use a sprite for the bird, you can use all 7 available foreground colours for the pipes, which might not be too bad. Some dithering could be used if needed too... You still then have 8 background colours and 16 to cover the bird and any other sprites you might use.

When you put it like that - good thinking. Might move on to this - depends how I feel as the game is coming together pretty well now and is much improved from the original version I made.

[Havie]

We have had the sprite colours discussion previously but have never fully got my head round it - help!

[Master484]

So plan now is to have pipe on the screen at 0,0 so it doesn't show then everytime I need a new pipe, blit a black space to make the gap, grab shape from screen and copy to sprite.

"GetaShape" and "GetaSprite" are slow commands, especially GetaShape is very, very slow. But I think you can use them to create the pipes, if you use them only when a new pipe appears, and not every frame.

An alternative method could be to have the whole pipe (without the gap) in a Shape that you create before the main loop begins. And then during the game, you QBlit this pipe, and then create the gap into it by copying a rectangular area from the third bitmap using the "Scroll" command.

But if you want to use sprites for the pipes, and want to have the ability to freely place the gap anywhere in the pipe, then I guess the GetaShape-GetaSprite combo can't be avoided.

My only other issue is the sprite colours for the pipes! I know that sprites take the top 16 colours of a 32 colour palette ie, 16-31 but the pipes are definitely taking colours form the 0-15 colours!

Make sure that your palette object has 32 colors, and that in the "InitCoplist" command the "colors" value is set to "32".

Also make sure that you repeat the 4 sprite colors for all colors between 16-31, not just the first four. Sprites 0 and 1 take colors from 16-19, sprites 2 and 3 take colors from the 20-23, and so on.

And if it still doesn't work, then try setting the colors 16-31 manually with the "PalRGB" command.

It should work, OCE/ECS always takes sprite colors from 16-31, only in AGA this can be different.

using pokes shows colour bars but no flashing so guess the game is running at 50fps?

There is a way to test this in WinUAE, and it is this:

First, turn cycle exact mode OFF, and start the game.

Then, go to the WINUAE "Display" menu, where you have that "Refresh" slider. Try moving it one step to the right. And then check if this has any effect to your game. If movement now seems less smooth, then your game is running at 50 FPS. And if nothing seems to change, then it runs at 25 FPS or slower.

And also try switching between cycle exact ON and cycle exact OFF. If the game runs at 50 FPS, you should see no difference between the two.

---

Also are you printing the score to the screen every frame ? If so, then change it so that it updates the print only when the score changes. All print commands are slow, because every letter printed is separate blitter operation.

[Havie]

Sadly - in my tests. QBlitting was too slow as the pipes are too big! But I have kept the blit code for other shapes.

and that in the "InitCoplist" command the "colors" value is set to "32".

This is what I did wrong - only 16 not 32! Hopefully I will remember in future?

I will try out your suggestion re: 50fps. Thanks and thanks for all your help.

[Havie]

here is a way to test this in WinUAE, and it is this:

First, turn cycle exact mode OFF, and start the game.

Then, go to the WINUAE "Display" menu, where you have that "Refresh" slider. Try moving it one step to the right. And then check if this has any effect to your game. If movement now seems less smooth, then your game is running at 50 FPS. And if nothing seems to change, then it runs at 25 FPS or slower.

And also try switching between cycle exact ON and cycle exact OFF. If the game runs at 50 FPS, you should see no difference between the two.

Done and now I am a fairly confident that it is 50FPS on a 500.

Tried adding code to make pipes move but really slow: It is true that getashape and getasprite are too slow to do this every frame. Is there anyway to write to the sprite directly?

The only other option I can see is if I use a sprite on top of a sprite to make the gap but I am down to 2 sprites and need 6 - 2 for each gap (damn OCS and it's 16 pixel sprite width). Maybe multiplexing is my only solution? IN fact, if I get this working then I don't need to do any getashapes at all!

If so how using the new display library - help again!

I have used vsprites in the past but seems a bit flakey?

[Havie]

CustomSprites seems to be the solution but need help implementing it.

[Daedalus]

Originally Posted by Havie

Tried adding code to make pipes move but really slow: It is true that getashape and getasprite are too slow to do this every frame. Is there anyway to write to the sprite directly?

Well, you can write directly to a shape's bitmap data, which will at least eliminate the GetaShape step (which is in essence another large blit). You use the ShapesBitmap command to assign a dummy bitmap number to a shape object and then draw to it like any other bitmap. You need to do a MakeCookie on the shape once the drawing is complete however, otherwise the previous bitmap contents will still be there.

I don't know of a simple way of writing to a sprite's bitmap directly, but it's probably doable by using CludgeBitmap and the address of the sprite data from the struct. I haven't tried it but it's worth a go...

The only other option I can see is if I use a sprite on top of a sprite to make the gap but I am down to 2 sprites and need 6 - 2 for each gap (damn OCS and it's 16 pixel sprite width). Maybe multiplexing is my only solution?

Perhaps. You can reuse the sprites easily at a given Y position on the screen, but they can't overlap.

[roondar]

I've been trying to get my head around how you're drawing the pipes. If I understand your current method, you are using hardware sprites for the pipes and are trying to blit the different images/gaps as needed every frame.

Now, I am no Blitz expert, but that does seem like an inefficient way to go about it to me. What I'd probably do myself if I where to create something like this in assembly is having two large but pre-built sprite images in memory: one for the top and one for the bottom. These would end in whatever imagery is used for the top and bottom part of the gap.

For maximum performance, I would probably copy these images so that I can simply assign them to all the sprite channels as needed. (i.e. such that all sprites could display a top and a bottom pipe segment without needing additional blits).
Edit: I made a small error there... Because multiple sprite pointers can be set to the same image, you do not need more than a single top and bottom image this way.

These would be as tall as they could possible need to be (my guess would be the height of the screen, but it depends on the game).

For drawing them, I'd use the Copper (this is where I'm not sure if this is possible using Blitz, but let's at least look into it):

• At the start of the copper list, set the sprite pointers so that the top of the pipes are each cut to the correct height
• Next, still at the start of the copper list, set the sprite position & control words so that the sprites will show in the correct location and have the correct size for the first section.
• Now we have the top pipes taken care of. Next the bottom ones.
• For the bottom pipes, order them in vertical order and use the Copper to wait for the correct position to start displaying the individual bottom sprites (this is one wait for every pipe, although care has to be taken in case several bottom pipes start on the same height).
• Now update the sprite pointers/control words for each bottom pipe section in order as needed.
• Now the bottom parts are shown.

Thanks to the gap between the top and bottom pipe sections, the Copper timing required should be fairly loose, so you can probably get away with resetting a single pipe per Copper wait.

Again, not sure if this is possible with Blitz, but the above way will cost virtually no raster time for displaying the pipes.

[Havie]

When you say 'overlap' do you literally mean overlap or be on the same scan line?

[Daedalus]

They can't be on the same scanline, so all 8 sprites must be above a certain line, and all 8 of the second set must be below that line. Now, there are ways of doing it that mean only the sprites on the same sprite channel need to be kept separate, but that's beyond the capabilities of the Blitz commands and so you'd have to handle that yourself.