next »

[accordionfolder]

Hello all, kinda new here, frequent reader, infrequent poster, great lover of commas.

I'm working on a 2d shooter within the xna frame work. It's my "capstone" project for my csc degree. My primary focus within the game is machine learning and swarm intelligence (possibly some flocking behavior), the caveat, I want my game to be a crazy intense shmup. I have most of my basic architecture working,  the player can fly about, I have created a simple AI that rotates to the player and chases him, etc.

My question currently pertains to image storage and retrieval for drawing. Keep in mind, first game, I have taken in all the material I can whilst keeping on a strict dead line and taking 19 hours this semester. I would prefer to be working in pure C++, but within my time frame is seemed less than feasible.

I keep up with all images loaded into a simple static class called Global, to access and image there are several defined static integers descriptive of the image with it's place in the array. To draw, the object looks up it's image and draws. I know, not the way it's usually done, but is this hindering performance to a noticeable level?

When testing I could place roughly 250 of said simple skull AIs on screen without lag, past that it simply bogged down. Currently I am using per-pixel collision detection with no pruning, which probably is causing the majority of my slow down. I plan on switching to a pruning rectangular collision algorithm asap, but for the time being, I was just trying to ensure my way of loading images was not contributing to the problem.

Thanks for reading.

[Zachary Lewis]

I don't see any problem with how you're doing it. It's good to have a texture manager, even if your manager is relatively simple.

You're going to run into a bottleneck with drawing eventually, but not with 250 draw calls. I believe XNA will batch your calls if you draw the same texture many times in a row (doing a loop through all your enemies or whatever). You might want to look into optimization of your draws at a few thousand draws/tick, but until then, I think you're doing it fine.

[Mikademus]

It seems you're currently looping over your entities and calling draw(mypos.x, mypos.y) (or whatever) for its image. Not very efficient. You could optimise this in two fundamental ways:

1) Sort all drawing by image so the underlying render context will not have to change texture. That is, first draw all entities using texture A, then all using texture B, etc.
2) Better still: if you're using the fixed pipeline, create a vertex buffer of quads, where one quad represents one entity. All the entities using the same image are placed adjacently in the buffer. Then render each strip (all quads using the same image) in one go, then change texture and render the next strip etc.

This will boost your geometry throughput significantly.

[accordionfolder]

You guys are magnificent. 

If you know of any open source examples of your second idea I would love to see this idea implemented. Regardless these thoughts helped a lot. 

@Zach - Do not know if you realized it, but I am Noah's friend Andy. Small world, right?

Thanks a bunch

[drChengele]

It seems you're currently looping over your entities and calling draw(mypos.x, mypos.y) (or whatever) for its image. Not very efficient. You could optimise this in two fundamental ways:

1) Sort all drawing by image so the underlying render context will not have to change texture. That is, first draw all entities using texture A, then all using texture B, etc.
2) Better still: if you're using the fixed pipeline, create a vertex buffer of quads, where one quad represents one entity. All the entities using the same image are placed adjacently in the buffer. Then render each strip (all quads using the same image) in one go, then change texture and render the next strip etc.

This will boost your geometry throughput significantly.

Quick question. Would you perchance know if this is what ID3DXSprite does internally? I *think* I read somewhere that it is as optimized as can be when batching sprites by texture, and I use ID3DXSprite extensively (even for particles in my 3d games...)

But if I knew I could squeeze additional frames per second by rewriting to use my own quads instead of D3DXSprite, I'd totally do it.

[Zachary Lewis]

@Zach - Do not know if you realized it, but I am Noah's friend Andy. Small world, right?

Haha, awesome deal. You lived with him, right?

[Mikademus]

Hmm, it has been years since I worked with raw Direct3D. Afairemember D3DXSPRITE manages its own texture batching and sorts by texture as well as scene depth (which is why it requires its own begin() and end() calls). The two main drawbacks of using it are--again from a distant memory that might be wrong--that it by default works with screen and upper-left-is-zero coordinates (which is good for 2D-in-3D tile systems, but worthless for true 3D spriting or billboarding etc) and that it will output only equilateral quads. I never used it because while fast it imposed too many limitations.

It seems you're currently looping over your entities and calling draw(mypos.x, mypos.y) (or whatever) for its image. Not very efficient. You could optimise this in two fundamental ways:

1) Sort all drawing by image so the underlying render context will not have to change texture. That is, first draw all entities using texture A, then all using texture B, etc.
2) Better still: if you're using the fixed pipeline, create a vertex buffer of quads, where one quad represents one entity. All the entities using the same image are placed adjacently in the buffer. Then render each strip (all quads using the same image) in one go, then change texture and render the next strip etc.

This will boost your geometry throughput significantly.

Quick question. Would you perchance know if this is what ID3DXSprite does internally? I *think* I read somewhere that it is as optimized as can be when batching sprites by texture, and I use ID3DXSprite extensively (even for particles in my 3d games...)

But if I knew I could squeeze additional frames per second by rewriting to use my own quads instead of D3DXSprite, I'd totally do it.

[drChengele]

but worthless for true 3D spriting or billboarding etc) and that it will output only equilateral quads. I never used it because while fast it imposed too many limitations.

Thanks for that! I got around the limitations, and am in fact quite happy with what I can do with them, so I guess that means I will continue using them instead of trying to roll my own sprite class which would probably not behave much faster.