[F8] Just how many bullets can be poured in a shmup ?

...this is a question which has been running in my mind for a few nights so I've decided to give it a go and see for myself.
I have coded a small AS2 mockup which fires 7 different patterns. Most of it would not be usable in a game, but the number of bullets is a significant data.

Now, I am quite disapointed by the results, which are really slow, because I thought it was possible to make a hectic manic shooter in AS2.
But I know that my computer sucks so I've decided to bring my test here so I could get some more FPS values.
Here's the app :
http://fil.razorback.free.fr/0.html
Use right and left arrow keys to change patterns.
Number of bullets on screen (from leftmost pattern to rightmost) :
0 - 70
1 - 150
2 - 200
3 - 370
4 - 500
5 - 700
6 - 4400(BEWARE, this one is not your friend. Try at your own risks)


I'm not only interested in the results you get but also in ways to improve the way I coded it.
Here is the source : http://fil.razorback.free.fr/0.fla

I'm more into AS2, but if someone wants to give it a go in AS3...I'd like to compare the results.

1 - 60+
2 - 60+
3 - 60+
4 - 40-45
5 - 30
6 - 7

I'd suggest re-making it in AS3 if possible. Otherwise, the only thing I'd suggest would be to re-use the objects instead of deleting/creating them every frame; it might speed it up a bit.

Seriously, this is exactly the type of thing where AS3 will be much faster.

What Schfifty Five is referring to is called sprite pooling, and it's pretty effective. You'll only need to create the objects once so the only overhead will be at the start of the file. When sprites go off screen, you simply pull them out of the plasma array and push them into a pool array. When a "new" bullet is created, you just grab the first object in the pool array and push it back to the plasma array.

Also, I've had better luck using while() instead of for..in. Might look into switching it over.

Lastly, you can remove the overhead of the key detection onEnterFrame by creating an object to handle onKeyPressed events instead, which may be slightly faster.

If that is the target screen resolution for a "hectic manic shooter in AS2", I highly doubt you need that many bullets anyhow. :)

tonypa: If you were going to do something like this in AS3, what method would you use? Would you have each bullet as a single Shape, or would you draw them all to a master bitmapdata, or what? I know a number of ways to accomplish it, but I don't know which way is best.

I would surely use one bitmap and update only that at each frame. Every display object, specially vector shape, takes time to draw. Even if you used bitmaps as single bullets, each display object still need to register for events and display list needs to be managed etc, meaning less separate objects on screen is always faster.

These things start to matter once you need hunderds of display objects. With <100 things it doesnt really matter that much, with fewer objects and larger stage redrawing screensized bitmap may be even slower.

For example Shapes experiment here
http://www.tonypa.pri.ee/eyecandy/index.html
uses simplest Shapes (moveto, lineto, beginfill) and handles each of them separately. It can easily manage 200 objects.

Very interesting, and helpful. I will definitely spend some time looking over those experiments, and conducting a few more of my own. Anyways, I appreciate the answer.

eh? How did you achieve that full-screen mode when you click on the swf Tony?

Quote:

---

Originally Posted by EvilKris

eh? How did you achieve that full-screen mode when you click on the swf Tony?

---

Its the standard AS3 method:
stage.displayState = StageDisplayState.FULL_SCREEN;

Sprite pooling sounds fun, I'll try this :P

Quote:

---

Originally Posted by ImprisonedPride

If that is the target screen resolution for a "hectic manic shooter in AS2", I highly doubt you need that many bullets anyhow. :)

---

Ever heard of good ol' Dodonpachi ?
http://www.shmup.com/doss/ddp/dodon-add-14.jpg http://www.shmup.com/doss/ddp/dodon-add-10.jpg http://www.shmup.com/doss/ddp/dodon-add-6.jpg
(and so on and so forth)

Obivously, not every frame is that crowded but there's no point in testing non critical situations, is it ?

The last game i made had the ability for a lot of projectiles on the screen at once. I found that the main bottleneck is when the amount of enemies increases. So if you have one ship fighting one enemy, no problem - however in my game you can have 50-60 or more enemies in the stage, if you then spray 60 bullets out that is 3600 collision tests per frame.. even if it is basic circle/circle detection this can add up.

Obviously there are optimisations to be done, but it would be interesting to see your demo's with some form of collision detection :-) With the new bitmap abilities it seems the projectiles on screen isn't as much of a limitation..

Of course I've heard of Dodonpachi, fil, but I suppose I jumped the gun assuming that it was a pipe dream for flash. :p

Quote:

---

Originally Posted by random10122

The last game i made had the ability for a lot of projectiles on the screen at once. I found that the main bottleneck is when the amount of enemies increases. So if you have one ship fighting one enemy, no problem - however in my game you can have 50-60 or more enemies in the stage, if you then spray 60 bullets out that is 3600 collision tests per frame.. even if it is basic circle/circle detection this can add up.

Obviously there are optimisations to be done, but it would be interesting to see your demo's with some form of collision detection :-) With the new bitmap abilities it seems the projectiles on screen isn't as much of a limitation..

---

Well, you can go with regional collision checks and then you will rarely have to check for more than a few collisions (usually 0) per bullet.

Just split the stage into regions of X by X pixels. Each region is an array of 'hittable objects' and then assign your enemies to all the regions they are in (pretty fast to check which region you are in with simple math and rounding). Then the bullet just has to check which region it is in and then collision check vs that region's array. The benefit is that most of the time, the bullet isn't very close to an enemy and no collision check is needed at all. The main overhead is in tracking which region arrays the enemies belong to as they move. But you can get sloppy with that if you like, since you will be doing a real collision check anyway, so it is more to list where the enemy ISNT than where it is.


That object pooling sounds pretty neat. I would not have guessed that pulling an existing object from an array and re-assigning all the values would be faster than creating a new object from scratch. It would be a snap to implement though, so I'll give it a try on my current game. Any speed boost is welcome even though I don't have TOO many particles on screen.

About collisions, manic shooters can afford a neat trick which saves 99% of the time and resource usually involved.
Most ships' hitbox are not bigger than 20 pixels and it's very quick to use getPixel and see wether the colors in the hitbox are as they should be or different (=covered by a bullet).

At least I think it works this way, i'll have to try that too :P


PS :
IP >> What's a pipe dream ?

Quote:

---

Originally Posted by fil_razorback

PS :
IP >> What's a pipe dream ?

---

Quote:

---

Originally Posted by Wikipedia

A pipe dream is a fantastic hope or plan that is generally regarded as being nearly impossible to achieve.

---

:D

A pipe dream is a game that my grandma was addicted to on the NES and my grandpa is a grand master of....*ahem*

What, no love for the Touhou series?
http://youtube.com/watch?v=hHmzO2RI1fs

What about DeathSmiles? :)
http://youtube.com/watch?v=wyfXGT2X04Q

Anyhow, although I have not done any bullet maze/hell things yet, if all the enemy bullets are in just one BitmapData, couldn't you do one simple bitmapData.hitTest for all the bullets, and then worry about removing them from screen if AND ONLY IF the hit test is successful?

Sorry to keep showing this example, but here's what you can do with sprites with AS3:

http://www.birchlabs.co.uk/Invasion5.html
http://www.birchlabs.co.uk/Invasion5CP.swf

7,000 animated, rotating sprites and it doesn't break a sweat. Even 3,000+ with (optimized) collision detection isn't a problem.

As for object pooling... not as fast as copyPixels(). Not even close. Object creation slowdown is when you create a really heavy object like a MovieClip or Sprite with loads of properties. In a copyPixels() engine, instead of clipping Bitmaps to a bunch of Sprites, you'd create a very simple object to track the coordinates and frame of any given arrow, and then run a loop through all the objects and plot the images onto the stage using that information.

Quote:

---

Originally Posted by ColbyCheeze

A pipe dream is a game that my grandma was addicted to on the NES and my grandpa is a grand master of....*ahem*

---

:doughnut:

"As for object pooling... not as fast as copyPixels()."

You can still use object pooling mate. For my shooter I have bullet objects and baddie objects ( Particles too ), and use pooling on those, they just happen to use copyPixel / draw to plot themselves.

"you'd create a very simple object to track the coordinates and frame of any given arrow"

Yeah, you pool those objects rather than making a new instance every time you need one.

Squize.