Design choice to render bullets?

[abstauber]

Okay, this might be a bit of a stupid question, but it's bothering me since AeroNuts.

In AeroNuts I had two GUIs and each had 30 transparent buttons. In my bullet struct I only had a reference to the mapped button, because this button has all the cool attributes, like x,y, Graphic and so on. It can even be animated and or checked if it's animating.

The only drawback I know about is the 30 Button limit per GUI limit, but I think that's sufficient for a low res game (30 bullets for the player, 30 bullets for everyone else)
The other possibility would be to include those attributes in the bullet struct, do the animation handling myself and draw them on a GUIs background surface.

I wonder which one's faster and/or the better solution. Do you have any hints? 


Thanks!

[GarageGothic]

Yeah, just use DrawingSurfaces. They work fine to particle systems up to 150-200 particles, so bullets should be no problem. I'm sure you're doing most stuff (collision detection etc.) in script already, so why restrict yourself by using GUI elements?

[abstauber]

Hmm... I could imagine the internal animate command is faster than my scripted method.
That's about my biggest concern, pixel perfection isn't possible with both methods, but I refuse to use room objects

edit

They work fine to particle systems up to 150-200 particles

Argh, I've read to fast. Of course I could beef up Jarakeen's particle module some more and simply use that. Thanks for that hint!

[Ryan Timothy B]

pixel perfection isn't possible with both methods

Not unless you write your own pixel perfect collision scripts.  But using Game.SpriteWidth or Game.SpriteHeight can get the rectangle boundaries.

I definitely agree with drawingsurface.  It's not all that hard to animate something by using drawingsurfaces.  You simply just need to have a counter per 'object' that once it hits the certain count it changes to the next frame.  If it's on the last frame of the loop, it starts back at the first frame - if it's supposed to repeat.

[GarageGothic]

I would even call a particle system overkill - unless you're doing some really funky bullet trajectories, most of what you need could be handled with simple integer maths even for angled shots, and there's certainly no need to involve force vectors like gravity.

Most likely what you're doing at the moment would still work fine. Simply draw the bullet at its coordinate instead of moving the button there.

Also, using DrawingSurfaces and the GetPixel command, you *could* do pixel perfect detection drawing the enemy planes first, then checking the bullet coordinate on the DrawingSurface to see if it's transparent or not, and if it isn't, run your normal rectangular collision detection to see what enemy is at that spot.

[Calin Leafshade]

My platformer engine does actually have some drawing surface bullet code in it.. since mario could throw knives!

[abstauber]

Yeah, after thinking this particle stuff through again - yep way to much overhead and I'm sure I won't need gravity.

As for pixel perfection: isn't GetPixel one of the slowest commands, AGS has to offer? I use it in a dissolve module and I'd rather stay away from it when it comes to real time action.
If course this issue can be solved by using circular bullets

Anyway thanks for your input. I guess, you've convinced me to stick to drawing surfaces. (aww.. no copy and paste from Aeronuts)

@Calin
I know, I've read your code so many times

[Calin Leafshade]

@Calin
I know, I've read your code so many times

That's depressing. 

Messiest code ever.

[abstauber]

Pah, don't be shy. It's still readable and the concepts are cool no matter what.

[GarageGothic]

As for pixel perfection: isn't GetPixel one of the slowest commands, AGS has to offer? I use it in a dissolve module and I'd rather stay away from it when it comes to real time action.

Yes, it is indeed quite slow. I've been using it for some experiments with realtime lighting of bumpmapped 2D sprites, and sampling more than a couple of hundred pixels per loop does cause a framerate hit even on a fast CPU. However, if you use it after a rectangular collision check has returned true (never mind what I said before about doing this in reverse order) you could probably keep it under 10 bullets to check for per loop. Other optimizations include checking bullets closest to the enemy first, so you don't waste CPU cycles on checking collisions for an enemy that was already destroyed.

since mario could throw knives!

...and still some people claim that games have gotten more violent. 

[Calin Leafshade]

This is why CJ should make the pixel shader interface available to devs. The engine already has pixel shading it seems silly to keep it hidden.

imagine bloom in 320x200.. it would be a thing of beauty.

[GarageGothic]

imagine bloom in 320x200.. it would be a thing of beauty.

Amen, brother. And that's why CJ, our almighty but merciful lord and savior, gave us the plugin API
(and why I, his humble disciple, will be spending my summer writing a really neat rendering plugin)

[Calin Leafshade]

if you give me pixel shaders I shall give you my devotion

[abstauber]

err... yes
(and keep in mind that a lot of mac and linux users have now tears in their eyes )

Other optimizations include checking bullets closest to the enemy first, so you don't waste CPU cycles on checking collisions for an enemy that was already destroyed.

I'm already doing the fast box collision check - but how to manage this one? And since the bullets need to be aware of solid walls, I'll have to check each bullet anyway, right?

[GarageGothic]

Well, I don't know the scope of what you're trying to implement - I imagined just a more a sophisticated version of AeroNuts, so I was thinking iterating through the bullet array back-to-front (based on an assumption that bullets fired first would be closer to your target than those fired later - which may still hold true).

How are the solid walls implemented?

if you give me pixel shaders I shall give you my devotion

cash would be better  

[abstauber]

Ah, now I see. That bullet array is already being iterated back to front. But it's also possible, that those bullets don't line up in order since the 30 button limit is pretty tight.

As for those walls: It's a tile based map and each tile has a flag whether it's solid or not. My plan is to check the space in front of the bullet:

if it's a solid tile,  remove the bullet
if it's an enemy, do a collision check, if collision add damage and  remove the bullet
if it's the screen border...remove the bullet.

[Monsieur OUXX]

(and keep in mind that a lot of mac and linux users have now tears in their eyes )

...And this is why a primitive rendering library will be inside AGSHack :-)

[GarageGothic]

Ah, tile based, excellent. I don't think there's much point in struggling with further optimization since tiles make the rectangular collision check so very basic - and 30 bullets is hardly anything at all. The technique you're using should still work fine.

(and keep in mind that a lot of mac and linux users have now tears in their eyes )

... and that'll teach those whiny bastards not to expect compatibility standards from indie developers that commercial games haven't offered in decades. 

[abstauber]

most of what you need could be handled with simple integer maths even for angled shots

*cough*

I know how to move the bullets in a 45° angle, so 8 way shooting is easy. But for those other angles, is there any smart way to avoid calculating triangles and such?

For 45° angles I simply give the bullet the same vertical speed as horizontal speed. I know I should work with inclination, but I'm afraid I overslept that in school too

[Calin Leafshade]

look at the AGSeggle code in the tech forum.. that has pretty extensive code on calculating vectors and stuff.