Fastest Technique for clipping a screen

[Havie]

Originally Posted by 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.

This is how I had the game working original (except with bobs not sprites). So blitting screen high bobs was far too slow (still thinking in PC mode) hence the move to sprites.

In your example, are you reusing sprites as the pipes are 24 pixels wide so needs two sprites per pipe. Therefore I would need access to 12 sprites - perhaps CustomSprites would do it as this gives an additional 8 sprite channels? There is also the vsprites library that I have played with before although results are a little unpredictable.

Unfortunately, your example is a bit too technical for me - it sounds like something you can do with Blitz but someone with more knowledge will have to explain...

[Master484]

perhaps CustomSprites would do it as this gives an additional 8 sprite channels?

CustomSprites can double the sprites exactly once, at one single Y-line only. In order to do the trick that Roondar described, you would need to be able to multiplex individual sprites at many different Y-lines. So unfortunately you would need to write your own custom copper routine to do that.

---

But another possible solution could be to simply have lots of different sprite graphics, that all have the gap in a different position.

So make sprites that have both the upper and lower pipes at the same sprite image. Maybe something like 16 different versions would be enough; each version has the gap at a different spot.

This way you don't need sprite multiplexing. And the Chip RAM use for 4 color sprites is low. One 32*256 pipe takes 2,1 kb, so 16 pipes take 33,6 kb. And 32 pipe images would take 67 kb.

This also allows the gap to move up and down; just change the sprite image shown on the fly.

Also the same can be done for the moving ground, if it's a rectangular shape that is a multiple of 16 pixels wide, and has a pattern that repeats itself in 16 pixel intervals. You can make 16 different versions of it, and after that you can draw it with "Block" instead of "Blit", which is about 2x faster.

[Havie]

I had thought of pre-shifting as a solution although with only 16 images (for instance) I’m not sure how smooth the movement would be.

If I used CustomSprite - I wonder if I can have 3 top pipes (6 sprites) and 3 bottom pipes?

Or dreaming about the game I do have another plan. If I reduce the pipes to 2 (like in the original version I wrote) then I would have enough sprites. Also, if I change how the pipes leave and enter the screen then I could create the illusion of 3 pipes on screen at once (one entering, one leaving and one in the middle) so it still apes the original mobile game.

So a couple of things to do there.

P.S. Getitng CustomSprites working would be very useful as I could then apply this to my Doddle Jump game and remove the vsprite code (as this ultimately halted development).

[Master484]

If I used CustomSprite - I wonder if I can have 3 top pipes (6 sprites) and 3 bottom pipes?

You could, if CustomSprites allowed individual multiplex Y-lines for each sprite, so that you could freely set 8 Y-lines for 8 sprites.

However, this is not the case. CustomSprites only allows one multiplex Y-line, and this line is the same for all multiplexed sprites.

And this is a big deal, because after multiplexing, the original sprites (0-7) can't go below the multiply line, and the new sprites (8-15) can't go above it.

So after you use the command, you can have as many as 16 sprites, but they'll be divided into two sets of 8, which are "stuck" in their own screen halves.

And because you have 3 pipe pairs, and each one has the gap at a different Y-position, you would need 3 multiplex Y-lines at different positions; one Y-line for each pipe pair. But the CustomSprites command only gives you one Y-line. So for example you can't multiplex sprite 1 at Ypos 50 and sprite 2 at Ypos 100. It's just one Ypos for all sprites.

---

About the command itself, it's quite simple. Here is how to multiplex all 8 sprites:

First put InitCoplists "customs" value to "34". (Blitz manual tells how to calculate this value)

Then give a CustomSprites command: CustomSprites CoplistID, 0, YPos, SpriteAmount.

So for example "CustomSprites CoplistID, 0, 100, 8" will multiply all 8 sprites at Y line 100. These extra sprites have ID numbers 8-15, and you move them around like normal sprites, with the normal sprite commands, just put the correct ID number to it.

The command can be given either before the main loop (this is how I have used it), but it should also work if given every frame (quickly tested this, and it seemed to work). So the Y-line where the multiplex happens can be changed frame by frame.

---

But although CustomSprites can't totally solve your problem, it can at least lessen it, if you use it this way:

Multiplex only 2 sprites instead of all 8 (sprites 0 and 1 are cloned to sprites 8 and 9). This way you can create the first top-bottom pipe pair with sprite channels 0,1 and 8,9. Now 4 pipe parts remain and you still have 6 normal sprites. And each pipe part requires 2 sprites. So after using all remaining 6 sprites, only 1 pipe part remains. And this you can draw with QBlit. Should be fast enough for 50 FPS.

[Havie]

Thanks for this - makes sense and I will have a go.

[Havie]

Had a go but there was a problem - which I should have spotted straight away!

Going back to using 190 pixel high sprites does work but as the bottom clipping is needed as the floor is not at the bottom of the screen.

That's why using a screen high pipe worked well as there was no clipping needed.

Trying not to compromise my game...i.e. get rid of area below floor!

So - I could have a number of pipes with holes in different places pre-shifted (and as was suggested these could then be used for pipe movement). If I had 30 pipes and the pipe is 190 pixels (and I subtract 20 from top and bottom to make sure pipe end is always on screen) then I would get 5 pixel movement for the gap. Would be ok (ish) but not ideal as it won't look great. This would only need 6 sprites.

Please tell me if my logic is wrong?

Or
I try and get a proper multiplexer (Earok has one but I can't get it working) - must be missing something.

Or reduce pipes to 2 but fudge it so it looks like 3 (will make gaps between pipes larger though).

Or
I go the whole hog and rethink (using Daedalus' suggestion from earlier int he thread). Stop with the sprites and go for a hardware scroll and a tile map. I could then go dual playfield and have 8 colours for the background, 8 colours for the pipes (+4) and 16 colours for the bird. I could animate pipes using sprites (up to 4 pipes - 2 sprites per pipe). This would also give me the added ability to increase pipe density without any overheads and even have slanted pipes etc. I could also scroll the background using a hardware scroll too to add proper parallax.

Obviously this is a bit more work - I have some tile map code already that I need to optimise and have never used dual playfields before but basically the rest of the code should be usuable. This is probably the best plan?

[Havie]

I will rebuild my last code tomorrow and upload it to the zone so you can see where the game has got to.

Thanks for all your help and support.

[Havie]

Had a rest day!

Have uploaded the latest demo to the zone. Let me know what you think.

https://eab.abime.net/zone/Flappy.adf

[E-Penguin]

Originally Posted by Havie

Going back to using 190 pixel high sprites does work but as the bottom clipping is needed as the floor is not at the bottom of the screen.

You don't have to make them the full 190px high... Alternatively you could draw them between playfield 1 and 2, and use playfield 2 for the bottom of the screen

[Havie]

Thanks - so many ways to do he same thing.

I have now spent a few nights on a dual playfield, tile mapped scroll with sprite flappy version.

Dual playfield was a bit of a headache as I hadn't realised I needed to 6(planes) in the InitCoplist command so spent quite a while trying to workout while the palette was all wrong (the bane of my life but I think I am finally understanding palettes).

Have a demo of three scrolling pipes, over the background and a sprite flappy. Have to say it looks pretty good compared to my old version and now it is tile mapped I can fill the screen with pipes. Just need to get the tile map code working properly and then collisions and pop in my old flappy code and I'll have a working demo.

Just for fun I popped a few pokes in to see the bars and at the moment they are virtually non-existent (not a surprise as I am hardware scrolling and using 1 sprite and don't even have the tile blits in place) and looks promising! Now I have joined the 50fps obsessed brigade!

Here is image of what it looks like:

[Havie]

Compared to old version - slower, less colours and less flexibilty.

[E-Penguin]

Looking much better!

[Havie]

Thank - and moves better too!

[Daedalus]

Excellent, I think you made a wise choice!

[Havie]

Thanks for the suggestion - 16 colour slow jerky game - now 32 colour 50fps!

Using the Amiga how it's meant to be used!!!

[ReadOnlyCat]

Great effort!

[Havie]

Here is the latest WIP - needs a bit of tidying up but you can see the progress. Hopefully it will run ok on A500 and beyond.

It's pretty tricky (but then Flappy Bird always was).

Is it too hard? Is the screen too narrow (trying to emulate phone screen)? Is the bounce ok? Is it smooth? Any glaring issues?

http://eab.abime.net/zone/Flappy.adf