Lemmings Remake

[Momor]

I would suggest to create a graphic functions unit for your project, where you will define all the graphics functions & structures that you will need:

- Initialize window/video mode function
- LoadImage function
- RenderImage(x,y)
- and so on ...

Is it important that you only use the functions & structures of this unit to make all the graphics operations of your game.

Then, you will be able to code your game using this "abstract" layer. You can first create the Graphics32 implementation of the unit, and if you want to create an OpenGL renderer you will have to write specific versions of the functions only - no impact on your game.

About input handling, it may mostly rely on the libraries you plan to use - Win32, SDL, VCL manage events in their own way.

Dunno if this is what you're looking for, but here's a tutorial about ortho projection in OpenGL : http://gpwiki.org/index.php/OpenGL:T...rtho_and_Alpha (sorry it's in C, but it's the same in Pascal).

[EricLang]

Ok thanks. The example of the sprites is not what I am looking for. I am looking for a simple example with:
1) a large background bitmap
2) with small sprite-bitmaps moving around.
Just flat stupid bitmaps running around.

And handling the input is more a general question:
The mouse/keyboard messages are usually catched by some window with a handle, but this window or displayscreen does not know what to do with the mouseclicks: in my opinion the game-engine is the entity that "knows" everything. I am having lots of that kind of OOP problems and always working on my own. Sometimes you go blind then

[LP]

Restarted the clone project. It will be further expanded.
I want to make the graphic output optional: using Graphics32, OpenGL or DirectX.

Why do you need OpenGL and DirectX for? You won't be using hardware acceleration anyway. IMHO adding optional support to these is a waste of time.

I've played your game and it was pretty neat. Why do you want to start over?

[EricLang]

First: The editor and the clone game do not make use of the same code. When making the clone I copied all code and changed/added a lot of things. I want to change that

Next: The next version will be able to edit terrains / objects, add new lemming-styles etc. etc. Also higher resolution will be possible.
The "lemming framework" has to be rewritten to support old styles AND new ones.

Now you get me really confused. I know the Windows API is extremely slow, when it comes to drawing to the screen. So I was actually hoping the DirectX / OpenGL would eliminate this problem. Why won't the game be using hardware acceleration? (I'm an almost complete Noob to OpenGL and DirectX).

With the Graphics32 (TImage32) I use the "Dirty Pixels" scheme. Erase animations - process mechanics - Draw animations. That's why it has an acceptable speed.

[User137]

I wonder.. maybe TImage with TBitmap's as sprite and back buffers would be sufficient for this. Because back buffer only needs to be 320x240, then set TImage property stretched to make it feel the nostalgy
SDL may be good choice (never used myself), where OpenGL and DirectX suffer in speed if you need to manipulate texture pixels on fly. Ofc if you have levels made of small elements/grid then manipulating isn't necessary.

Edit: API isn't slow. Like said before, use buffers: Draw everything in memory, then draw it all in 1 call to screen. That's what OpenGL and DirectX does.

[EricLang]

in "Window API" mode my dirty pixels scheme is needed, otherwise i even can't make the needed speed in some cases!
So API is slow. Very slow.
I am drawing everything to a virtualscreen first. But the BitBlt function just is not fast enough. That's why I only update the screen where needed.

BTW: Stretching the bitmap with graphics32 is faster than stretching it "onscreen". So I stretch in the virtual screen and then graphics32 uses bitblt.

But when I draw my virtualscreen in OpenGL / DirectX and then use some "Flip" method. Isnt that much much faster than in normal windowed mode??
Because that is what I want.

[User137]

in "Window API" mode my dirty pixels scheme is needed, otherwise i even can't make the needed speed in some cases!

When it comes to hardware acceleration, you see all textures are stored in 3D card memory. Loading them in is slow process, especially if you have destructible large map that does it all the time, even every frame. In my game experiments it really slow it down.

But it is possible for even OpenGL with certain optimizations:
- Split map into smaller pieces, like 64x64
- Store pieces in raw data format that are in directly loadable into graphics card (RGBA bytes for example)
- Keep track on which piece needs updating and skip rest
- Have update delay, maybe every 3rd frame
(These things helped me to have destructible maps of very large size, even 3000x3000)

But because of this complexity i'd still suggest unDelphiX or other 2D engine for task they are made to Hardware acceleration really shines in 3D, blending effects, rotating etc.

[EricLang]

I almost can't believe what I am reading
I thought graphics were insanely fast these days.
I seriously need to go and study this things.

In fact: The repaintoptimizer of Graphics32 splits up the map in 32x32 pieces. The only replacement I need then is using some RefreshInvalidRects method instead of the default BitBlt

[User137]

They are insanely fast with triangles and polygons generated of them but when it comes to single pixels it's "oldschool" and unsupported tech Pixel shaders although are a different case i haven't studied, my old Radeon 9200 can't even display them.

[LP]

Now you get me really confused. I know the Windows API is extremely slow, when it comes to drawing to the screen.

Define "slow"? Actually, I think Windows API is quite fast and efficient. Are you sure that your performance bottleneck is API itself and not your code?

If I were you, I would store the game pixel map in a large bitmap; when drawing on the screen, I would draw only subset of such bitmap. For modifying map, I would simply get direct access to all pixels and modify them once per frame. You won't get 500 FPS this way, but for what you need it's one of the best approaches.