TDirectDrawSurfaces not working in hardware mode?

[Evil_Toaster]

Hi Folks,
(Apologies if this post appears twice. I registered, added the post, and then the site ate my user account. Thus deja vu for me at least)

I'm wondering if there's anyone who could help me find a solution to a problem I'm having with using TDirectDrawSurfaces.

I'm creating a game which makes heavy use of rotation functions to avoid making artwork. One of the things I need to do is run collission detection tests against graphics. I'm doing this by rendering rotated images to a background surface and then checking for a hit.

I've encountered two problems while trying to implement this:
- Surfaces do not work under hardware mode (From what I can gather, they get assigned correctly and you can render to them, but all draws to the surface after the first do not render)
- Reading from the surface pixel/pixels properties seems to cause a massive performance hit. (I.e. 9 checks per loop makes the engine start crawling) This has something to do with the surface being locked/unlocked.

I read in the latest readme.rtf on the unDelphiX site that any surface apart from the DXDraw surface will not work, but perhaps there's someone here who's managed to find a work around for the problem?

[Speeeder]

Surely, I've made my game using TDirectDrawSurfaces, and it works perfectly, so you're mussing something up yourself.

Firstly, check if you have the latest version of UnDelphiX, with the places fixed what I've posted here: http://www.pascalgamedevelopment.com...a4662506d7214e

On the main DXDraw, check if you have doDirectX7Mode, do3D, doFlip, doHardware all on. Othervise hardware mode won't be turned on.

When you're drawing, use the (main) DXDraw.Surface.blahblah functions to draw your graphic, not the DXDraw.Surface.Canvas.blahblah, as those are the simple GDI functions, so they're slow as bloody hell!

If you're doing hit check, you maybe should concider using hitboxes for example, just be sure to store every degree's sin to an array when your game starts and read the values from the array instead of generating them with the Delphi functions as they're slow as hell... (cos is sin(x+90), starting from 0 after 360... You can put in 450¬? if you're lazy for the check )

P.S. I'm sorry if I've said something stupid or what you already know!

[Evil_Toaster]

Heya Speeeder, thanks for the reply.

I downloaded the latest version of unDelphiX a few days ago (1.07), I think surfaces were working in the previous version I had (Possibly 1.0.5). I'll have a look at your code changes and see if they help.

I reproduced the problem in the Prototype project in the main 'Dx' folder of unDelphiX:

I load an image into a TDXImageList:

Var
    IL1 : TDXImageList;

...

IL1 := TDXImageList.Create(Self);
IL1.DXDraw := DXDraw;
IL1.Items.Add;
IL1.Items[0].Picture.LoadFromFile(ExtractFilePath(Application.ExeName)+'/Tmp/Stars1a.bmp');

I create a surface:

procedure TForm1.DXDrawInitialize(Sender: TObject);
begin
  Dxtimer.Enabled := true;
  Surface := TDirectDrawSurface.Create(DXDraw.DDraw);
  Surface.SetSize(255,255);
end;

Then render in the main loop:

Surface.Fill($00FFFFFF);
Surface.Draw(Tmp,100,IL1.Items[0].PatternSurfaces[0]);

DXDraw.Surface.Draw(0,100,Surface);

// Using this doesn't work at all in hardware:
// IL1.Items[0].Draw(Surface,Tmp,100,0);

The Tmp variable is a byte incrementing from 0..255

If you run the project, the surface will render perfectly in software mode, and you'll see an image moving across it. If you press space to switch to hardware mode, the surface stops rendering.

So, it could be the way I'm using surfaces, it could be that the prototype project is wrong, or it could be those changes you mentioned.

At present, I'm implementing checking for mouse overs on game sprites. I'm already using square bounding boxes to limit the number of graphics I need to check against.

I calculate the relative position of the mouse and graphic, then render the graphic to a surface. I then check a single pixel on the surface to determine if there's a collission (I.e. Tip of mouse is on graphic). However, accessing the Pixels property seems to kill performance. I need to have pixel accurate detection though, is there a better way to access the pixels on a surface?

By the way, when you talk about hitboxes, do you mean rotated bounding boxes to check for collissions? (Not sure how to do those, but it would be nice to know...)

P.S. More correctly, cos=sin(x+PI/2), since most math functions work on radians. I suspect degree's were invented by school teachers.

[JSoftware]

P.S. More correctly, cos=sin(x+PI/2), since most math functions work on radians. I suspect degree's were invented by school teachers.

Most likely sailors

"Change course 0.5PI starboard!!"

[Traveler]

Are you constantly checking if your mouse is hovering above a sprite or only on mousedown?

[Evil_Toaster]

P.S. More correctly, cos=sin(x+PI/2), since most math functions work on radians. I suspect degree's were invented by school teachers.

Most likely sailors

"Change course 0.5PI starboard!!"

I think that kinda thing would have made pirates more stylish though.

[Evil_Toaster]

Are you constantly checking if your mouse is hovering above a sprite or only on mousedown?

Constantly at 60fps. At present, I'm checking against at most 8 sprites.

In hardware mode, I can render hundreds of rotates objects directly to the main display... Either rendering to surfaces is slower, or it's accessing the pixels property. I can't really test at the moment though, since rendering to surfaces isn't working...

[WILL]

P.S. More correctly, cos=sin(x+PI/2), since most math functions work on radians. I suspect degree's were invented by school teachers.

Most likely sailors

"Change course 0.5PI starboard!!"

:lol: That'd be a first for me!

[Evil_Toaster]

Ok, lets try a different tack.

Could someone please download and run this project?
http://etgames.q.org.za/tmp/Prototype.zip

The code used is the Prototype project provided with unDelphiX. The sum total of the code added is:

  // in Public Variables
  Surface : TDirectDrawSurface;
  IL : TDXImageList; // Unused
  Temp : Byte;
  ...

  // in DXDraw Initialise
  Surface := TDirectDrawSurface.Create(DXDraw.DDraw);
  Surface.SetSize(256,256);
  ...

  // in DXDraw Finalise
  Surface.Free;
  ...

  // in Timer Loop
  Inc(Temp,10);
  Surface.Fill(Temp);
  DXDraw.Surface.Draw(0,100,Rect(0,0,Surface.Width,Surface.Height),Surface);

When I run this on my machine: In software mode, the surface cycles through shades of blue. If I switch to hardware mode, rendering freezes.

Please, I'd really appreciate some help in fixing this problem?

[Traveler]

I've tried it and it appears to work pretty well for me. However, since you did not include your own exectuable I had to compile it myself with, I assume a different version of delphix, than you have. (Note that users without delphix problably wont test it at all)

In any case because I do not use undelphix, but the origional version of delphix, I had to change a couple things.
Beginscene and endscene are not know to my version and so are doDirectX7Mode, I removed them. Also, the draw function took an extra transparency parameter. After that it compiled without errors.

On my crappy pc (the one I use at work, radeon 7000), runs software mode at around 30 fps. Hardware mode does it a little better at ~400.

I did not see any odd things in your code, except mayby the part where you change the surface color. Since you're changing it at every frame it becomes very hard to see whats happening when using hardware mode.
It would be a typical thing to do timebased instead of framebased. But I doubt thats your problem anyway.

Hope that helps a bit.
In case you want to test the compiled exe, you can grab it here