Multiple Surfaces Does Not Work with Hardware Acceleration

[gregchant]

I recently upgraded to version 1.07 of unDelphiX because I wanted to take advantage of the graphic acceleration for alpha blending, only to find that if I activate the 3D/hardware acceleration, then it no longer supports multiple surfaces which I do use.

My game is a 2D turn based map game (division level WWII game). I don't need a high FPS, just need to be able to scroll the map and zoom in and out quickly. When the user moves his cursor over the map, then map is updated to show where the cursor is and display information re: the hex, and I do this using multiple surfaces as follows: (1) draw the map to a background surface, (2) when the cursor moves, draw the background surface to the dxdraw.surface and then update the dxdraw.surface to reflect what the cursor is doing, and (3) flip the dxdraw.surface to the screen. I use other surfaces for other effects too.

Maybe I could copy the canvas of dxdraw.surface to a graphic (instead of a background surface) and then load the graphic into dxdraw.surface whenever the user moves the cursor. And instead of having a surface with a hex grid, I could just redraw each time I render the map. But this seems to gut most of the advantages of DirectX. The tdirectdrawsurface methods are all based on another surface being drawn to the surface, and not being able to use this removes much of the functionality of DelphiX.

Alternatively, I could not use the acceleration, but the alpha drawing is so slow. My game shades certain hexes to show which are friendly and which are enemy hexes. However the alpha blending is so slow (without acceleration) that currently I copy the surface.canvas into a bitmap and then I do a pixel by pixel alpha blend in a method I wrote, and this works 2 or 3 times faster than when using the alpha drawing method in unDelphiX!

Any suggestions? I feel like I should switch to another graphics library, but I am reluctant to have to port all my code to a a new graphic system. I took a quick look at Asphyre Casual Framework, but there does not appear to be any documentation and it does not have Delphi components like DelphiX. The examples I saw did not appear to use surfaces either (though I only spent a short time looking through the examples). Any suggestions?

[waran]

As far as I know DirectDraw isn't HW-acclerated at all.

I recommend leaving DirectX as well as specific "frameworks"
or graphic engines aside and switch over to direct using OpenGL.

This may sound somewhat radical, but you will get several advantages:

- OpenGL isn't specific. So you will be able to use what you learned for a
long time.

- Crossplatform (May not sound important if you think of Linux, but whats
about any normal Windows? Current versions of DirectX are Vista only).

- Full HW-accleration and possibility to exploit latest HW-features.

- Acclerated 2D is very very very easy with OpenGL. I don't think you
will encounter any serious problems.

- Very fast rotation, scaling, translation, filtering, blending ... (using HW)

I guess there are even more advantages, but this are the most important
ones

A pretty good header containing all gl-funcs up to 2.1 is DGLOpenGL.pas

[chronozphere]

You could also try Direct3D. It's hardware accelerated too.

Maybe it's best to get another Direct3d or OpenGL library to work with, instead of beginning from scratch. Maybe you should try PhoenixLib or Andorra 2D?? Those seem really nice to me.

and it does not have Delphi components like DelphiX.

You absolutely don't need component's to write a game. A good library with some documentation will do the job. You will not need any VCL stuff, because it's just extra ballast, and not optimized for game-development.

but I am reluctant to have to port all my code to a a new graphic system.

It's always good to make your code as "modulair" as possible. That means that the code doesn't have many dependancies, and can be used in different context's without many problems. It's a good idea to seperate different part's of functionality, in such a way that you can easily replace them, or rewrite them. When you write good, modulair code, you can avoid or reduce these problems. I don't know what your code looks like, but i just wanted to tell you this

Good luck. hope you can find a nice lib, and speed things up! :thumbup:

[czar]

Just a warning about OpenGL - most computer users do not have great video cards and use the microsoft reference drivers for OpenGL which are basically useless. We had to give up on OpenGL because so many of our customers had problems. We switched to DX9 which can also problematic from support point of view but much less so.

[waran]

OM>F<G :doh:

Actually this isn't a warning about OpenGL, but about stupid users

[Traveler]

OM>F<G :doh:

Actually this isn't a warning about OpenGL, but about stupid users

Hmm, mind you, not everyone is willing to understand the technicall issues behind software. A game is a game to many people, and they dont care if it runs under D3D or Opengl. There really is nothing stupid about that.

[waran]

Stupid is the wrong word, I admit.

However I thought all the time MS' OpenGL-driver-crippling
wouldn't be that serious all the time since I thought people use
manufacturer-drivers anyway.

But now Im litteraly scared :!:

[User137]

Just a warning about OpenGL - most computer users do not have great video cards and use the microsoft reference drivers for OpenGL which are basically useless. We had to give up on OpenGL because so many of our customers had problems. We switched to DX9 which can also problematic from support point of view but much less so.

Useless? Was there some specific thing microsoft drivers couldn't do? I'm still using OpenGL but will not touch shaders or barely any extensions :roll:

[gregchant]

Thanks for the responses. It sounds like I should decide between either a different DirectX header library or an OpenGL library.

After I posted my message last night, I took another look at Asphyre and downloaded Asphyre Extreme, which looks like a better fit for me than Asphyre Casual as there is some minimal documentation and there are VCL components (which I like though I understand they are not necessary). Do people think Asphyre is the best DirectX library or should I look at PhoenixLib or Andorra 2D?

As for OpenGL, do people think DGLOpenGL.pas is the way to go if using OpenGL?

As to whether DirectX or OpenGL, I liked the advantages waran listed re: easy and good 2D acceleration and very fast rotation, scaling, translation, filtering, blending. Cross-platform or more marketable skill is not important as I am designing this as a Windows only game in my spare time. About two years ago I ported my game from the regular windows/delphi graphics to DelphiX and at the time I debated between DirectX and OpenGL (can't honestly remember why I choose one and not the other). My code is pretty modularized, but it still will take time to change so I want to make sure I make the "right" decision this time.

One final note: I would put some value on being able to eventually add some 3D to my map, so being able to perform 3D and not switch libraries is a plus, but it sounds like all choices would allow this.

Thanks in advance for any more thoughts you may have.

[waran]

The speed-features I mentioned are valid for Direct3D as well, no worries
(since these are features in Hardware, not OpenGL specificly). BUT:
"Crossplatform" wasn't important to me either some time ago. However things changed:
Future versions of DirectX won't be able to run on any 'serious' Windows
anymore but Vista only. So you either exclude all non-Vista users with your
decision or freeze with DirectX 9.0 (remember: DirectX, in opposite to OpenGL,
is NOT extendible by HW-manufacturers).

DGLOpenGL is a nice header because you don't need to deal with
Extensions seperately - they are included. Also the initialization is a
piece of cake. Its not a complete framework or engine - its just a
way of directly accessing OpenGL (which gives you an extra of control).

The choice is upon yours. But I *strongly* recommend OpenGL or
some OpenGL-based engine.