Blitz pang

[seko]

I have been working on the pang game engine with Blitz basic for more than 2 weeks. In the first try, I modeled the movements of the game balls. I created player control. Then I moved more than one colored ball together. Then I wrote the collision controls.


I created the screen as a dual playfiled screen. I used the second screen plane for the player and the balls. However, when there is more than one ball on this second screen plane, the frame rate drops significantly. Apart from that, there was no problem. Now the final game is as shown below.

Note:Frame rate drops on Amiga 500. The frame rate is very good for the Amiga 1200.


first video

[ Show youtube player ]


second video
[ Show youtube player ]


last video
[ Show youtube player ]

[saimon69]

What if you render balls with sprites? Usually are not much that three colors

[DisasterIncarna]

in all these years, i know "of" pang, seen it played by others, but it's weird i have never actually played it myself, i think the closest things to it i have played are Oops Up and Super Obliteration.

[Seiya]

a very nice reworking

[aNdy/AL/COS]

Looking great!

[dreamkatcha]

You have to correct that DI. Pang is one of the few games with a perfect difficulty curve. That's how it lures you in, then you're hooked and find yourself progressing with each try. It's so well designed it should be studied in game dev courses if it isn't already.

[jotd]

Originally Posted by saimon69

What if you render balls with sprites? Usually are not much that three colors

you generally can't as there are max 8 sprites and 16 pixels wide in ECS


I'd go AGA & 16+16 dual playfield to avoid all the cookie cut blitting that WILL slow down if there are too many balls.

[Reynolds]

The soundtrack sounds a bit weird, like multiple playing a sample for one note...?

[Daedalus]

How are you drawing and erasing the balls? I think you should be able to blit them on an A500 without slowdowns, especially when you're using a dual playfield because there's no background to restore.

[jotd]

ECS + dual playfield = 8+8 colors. Very limited unless you're talented & you use colored sprites for main character like they did in Leander.

[TCD]

Originally Posted by Reynolds

The soundtrack sounds a bit weird, like multiple playing a sample for one note...?

Especially in the last video it sounds like the player messes up the song.

Is this a different game or different set of levels to the Pang released by Ocean?

[Daedalus]

Originally Posted by jotd

ECS + dual playfield = 8+8 colors. Very limited unless you're talented & you use colored sprites for main character like they did in Leander.

Yup, but from the OP it sounds like that's what was used. If not, then maybe more clarity is needed... It should still be possible to draw and erase those balls without frame drops on an A500.

[seko]

Originally Posted by saimon69

What if you render balls with sprites? Usually are not much that three colors

Balls must consist of at least 4 colors. Using sprites is a problem in terms of color. Another problem is that the sprites remain within the 16 pixel width limit. Multi-plexing the sprites will significantly reduce the frame rate in the game. balls were created with blitter.

Originally Posted by dreamkatcha

You have to correct that DI. Pang is one of the few games with a perfect difficulty curve. That's how it lures you in, then you're hooked and find yourself progressing with each try. It's so well designed it should be studied in game dev courses if it isn't already.

I agree with what you said. A correction will be made.

Originally Posted by jotd

you generally can't as there are max 8 sprites and 16 pixels wide in ECS I'd go AGA & 16+16 dual playfield to avoid all the cookie cut blitting that WILL slow down if there are too many balls.

I think the same for AMIGA 1200

Originally Posted by Reynolds

The soundtrack sounds a bit weird, like multiple playing a sample for one note...?

mod music file i can be shared with you

Originally Posted by Daedalus

How are you drawing and erasing the balls? I think you should be able to blit them on an A500 without slowdowns, especially when you're using a dual playfield because there's no background to restore.

I used a double play area. background layer 8 color. foreground 8 color. Blitz basic used qbilit for biliter operation

Originally Posted by TCD

Especially in the last video it sounds like the player messes up the song.
Is this a different game or different set of levels to the Pang released by Ocean?

I never noticed this music glitches. I will check it. This will be Super Pang's version or something close to it.


We continue to develop this game. We always see the results as a draw.

[Daedalus]

Originally Posted by seko

I think the same for AMIGA 1200

The A1200 can use 64-pixel-wide sprites. It's probably still not enough to use the sprites for all the balls because for 15-colour sprites you can still only have 4. 3-colour sprites you could have 8...

But instead of using sprites for the balls, what about using sprites for the player and the harpoons? That would free up some blitter time and also allow for the player to have different colours to the foreground playfield.

I used a double play area. background layer 8 color. foreground 8 color. Blitz basic used qbilit for biliter operation

Hmmmm, that should be quick enough. Perhaps it's not the blitting that's taking up most of the time, but the other stuff? Are you calculating with quick or float variables? It might be worth poking the background with different colours at different steps of your main loop to see what's taking up most of the frame time.

[seko]

Originally Posted by Daedalus

The A1200 can use 64-pixel-wide sprites. It's probably still not enough to use the sprites for all the balls because for 15-colour sprites you can still only have 4. 3-colour sprites you could have 8...

But instead of using sprites for the balls, what about using sprites for the player and the harpoons? That would free up some blitter time and also allow for the player to have different colours to the foreground playfield.


Hmmmm, that should be quick enough. Perhaps it's not the blitting that's taking up most of the time, but the other stuff? Are you calculating with quick or float variables? It might be worth poking the background with different colours at different steps of your main loop to see what's taking up most of the frame time.

the hooks are made from sprites. only full length hook graphic block starting point multiplied by number 8 pixel height pieces step by step incrase are shown in sprite. simple method easy. there is no blitter operations for hooks.



Attached sprites made for player character tryed result low frame rate


The best way is to use the qbit command. However, more than five blitter objects reduce low frame rate . When I tried it on Amiga 500 standart 1 mb chip ram .


The game consists of simple arithmetic and logical operations, comparisons and loops that are not very complex.


It consists of game subroutines. Subprograms were created with very short codes. The longest is twenty-five lines.


If I had designed this game for the Amiga 1200, it would definitely have better gameplay and graphics. This is due to Amiga 1200 hardware efficiency and AGA chipset.


Below New video show Sound fx test. Hook sound fx and bursting balloon.




[ Show youtube player ]

[saimon69]

Another way is still dual playfield but use a similar method to what Ocean did for the original pang and make custom copperlists changing the palette on the fly.

I would get in touch with colin vella to have insight on how to accelerate the rendering, though; you could update enemies position not every frame but every two

And i could help with the soundtrack but this time will use my own samples or melodies to make it more relevant

[Daedalus]

Hmmm, if you're still getting slowdowns when using joined sprites, something else is causing the slowdowns. Sprites are more or less free to display, so the slowdown must be caused by the game logic somewhere.

Are you doing any multiplication or division? They're very slow on a 68000 and much faster on a 68020. Also, make sure you're defining variables as words or bytes where possible, because Blitz uses "quick" variables by default and these are also much slower to deal with on a 68000 than a 68020.

[seko]

Originally Posted by Daedalus

Hmmm, if you're still getting slowdowns when using joined sprites, something else is causing the slowdowns. Sprites are more or less free to display, so the slowdown must be caused by the game logic somewhere.

Are you doing any multiplication or division? They're very slow on a 68000 and much faster on a 68020. Also, make sure you're defining variables as words or bytes where possible, because Blitz uses "quick" variables by default and these are also much slower to deal with on a 68000 than a 68020.

Daedalus, you are right. When I convert the variable value of the vector speed value types of the codes that model the movement of the balls from a float number to an integer type, the frame rate improves.




Now there is a problem here. When the variable vector velocities are integers, the ball's movements are very fast.
and at the same time the ball moves linearly.
I will fix the code for linear motion.


Thanks.Daedalus

[seko]

Ball move and reaction fixed and balls move speed up. Tested on Amiga 500. You need enough 1mb chip ram and kick rom 2.04 version. If you try it on Amiga 1200 you will see speed issues.Player and balls collision detection disabled. Sound fx mode. No music.


Adf disk image : https://drive.google.com/file/d/1YVc...ew?usp=sharing

[ Show youtube player ]

[seko]

Shoot the balloons and balloon splitted.


New Video



[ Show youtube player ]