Ogre performance and 2D newbie questions.

[bradnerdhss]

Hi there,

I'm new to 3D gfx programming and Ogre. I've got a question about 2D games and performance. I know Ogre is 3D, but can one 'emulate' a 2D game, like the player controlling a sprite in a horizontal scroller?

I've had a play with Allegro, and found too sluggish when there are more than 5 sprites on the screen simultaneously. (On a p4 3ghz, 4MB, Windows XP, GeForce FX 5700). I was thinking if one creates a 2D game using Ogre, then all optimised performance of the 3D hardware will be fast enough for the multiple sprites.

I also noticed that there arn't any scenes geared towards sprite collision.

Again, I'm a cliched newbie and keen to research all this with a little guidence from you experts and other alike. I considered programming in Dx10 raw, but came across Ogre and can see the significant benifits it can provide - although I'm concerned with performance.

Also, does Ogre and/or 3D have the concept of 'paging'?

Thanks.

[fzh]

I was using allegro for 2d games as well a while ago, it's not really sluggish, you just need some multithreading and double buffering. Though the reason i gave up on it is because 2d sprite drawing is too tedious for me compared to 3d modeling.

I was planning on using native dx as well, but there are many beneficial features to ogre like all those cullings and optimization features especially which you don't have to reinvent the wheel on, the cross platform compatibility with openGL rendering is another plus. There really isn't much of a performance issue using ogre compared to native directx, you will find that you will probably be doing the same thing, albeit less optimized and mature compared to ogre if you were to code an engine from scratch with directx.

Yes, I guess you can emulate 2D with a 3D engine, i thought of it before as well to save sprite drawing time, you could just use a 3D scene and place the camera such that it's a 2D scrolling screen, or you could just use perhaps plane models.

As for collisions, ogre provides some simple collision detection but not complex ones since it's only a rendering engine, if you want precise collision detection with the methods I mentioned above you could plug in a physics engine or just use some collision detection functions.

Well, yes, there is a paging scene manager plug in for ogre, though it's for 3D, i guess it should work for 2D as well with the above methods.

However, for performance, I don't think emulating 2D with 3D is really optimal.

[Kojack]

Ogre can do it, it's got billboards which can be used like sprites and a much more powerful material system than most 2d engines (put shaders on your sprites, so they get real time per pixel lighting even though they are still 2d images). But there's probably a large amount of stuff in ogre which isn't going to be used.

For a pure 2d game, I'd use either:
- Haaf's Game Engine, an extremely fast and easy 2d engine based on directx 8. The demos include thousands of moving/rotating/scaling transparent sprites onscreen at once. The best 2d engine I've used.
- Simple Fast Multimedia Library. This is an opengl based 2d sprite engine, with sound and networking. It has shader support, and can interface with opengl code. Cross platform too.

Both are good, but SFML is still very new (only about 6 months old) and I've never used. Both are open source too.


So Ogre can do it, but you might be better off using a dedicated 2d engine.

I actually use 3 engines depending on my needs. Ogre for 3d stuff, HGE for 2d, and Pixel Toaster for manual pixel rendering.

[voxel]

Personally, I think OGRE is terrible for 2D. It shouldn't be, but unless I'm missing something there is a lack of drawing order control and the use of alpha_rejection in the material causes horrible pixelation.

In OGRE you can do 2D using the following:

Billboards - nice framework, but render order is not under your control
Manual objects - nice high level vertex/index buffer, but same render order problem.
Entity + SceneNodes - somewhat better IMO as you can force entities into different render queues, but that's a horrible solution.
Hardware Buffer - unless you avoid materials, same render order problem

Ideally, all transparent sprites:

1) Use materials
2) Don't use alpha_rejection in materials
3) Are fully orderable.
4) Allow for pixel accurate blitting/drawing.

There really needs to be Sprite type that uses materials which can be tightly ordered and controlled and not-scaled (or scaled by fixed factors). I can see this Sprite type being used for UI and HUD also.

OGRE is fantastic for 3D. The material framework really integrates shaders and multiple techniques/passes well.