TDirectDrawSurfaces not working in hardware mode?

[Evil_Toaster]

Hi Traveler, thanks for having a look.

Are you using the original original DelphiX? (I.e. Hori's 2000.07.07 version?) As I remember, I stopped using it because pretty much all advanced draw functions killed performance if you rendered 10 or more sprites using them.

Your version works fine on my pc, with 126fps on software, and about 1600fps in hardware.

I think there's a bug in unDelphiX v1.0.7, or perhaps it doesn't like Delphi 6? *sigh*.. who knows. :/

The only purpose behind changing of the surface colour is so one can see if the surface is rendering. If it's flashing or you see screen tearing, great, it's working. If it's static, bad, it's broken.

I've uploaded the project again including the exe:
http://etgames.q.org.za/tmp/Prototype2.zip

[Traveler]

I believe its an even older version from october 1999. I've never used alpha blending so I really didn't have any problems when using a lot of sprites.

Your sample didn't work for me either. The exe didn't seem to freeze when using hardware mode, its just that the square didn't fade in/out anymore. Odd enough the fps was even lower than my sample. Around 320 fps using hardware mode.

In any case, from what you've written, I'd say there's something wrong with your undelphix version.

[Evil_Toaster]

Ah well I'm pretty pathetic at graphics, so I prefer to get the computer to do as much work for me as possible.

I rolled back to the previous version of unDelphiX that I was using. That fixed the surface rendering problem, but I was still having major speed hits when rendering to a surface. It seems that point I made in my original post was correct, that hardware acceleration is not available on any surface other than DXDraw:

TDirectDrawSurface.DrawRotate Function:
...

  If AsSigned(D2D) Then Begin
   If D2D.CanUseD2D Then Begin
    If D2D.FDDraw.Surface = Self Then Begin
      D2D.D2DRenderRotateDDS(Source,X,Y,Width,Height,CenterX, CenterY,Angle,Transparent);
      Exit;
    End;
   End;
  End;

  // Else render using software

The line "If D2D.FDDraw.Surface = Self Then Begin" is checking if the current object doing the rendering is the DXDraw object. If it isn't, then the graphic is drawn to the surface using software, which is ludicrously slow.

I've found a solution, but it's a bit of a hack. I'm now running two scenes per frame. In the first, I run all the collission detection using the DXDraw's surface, but never flip anything to the main display. Not exactly the ideal I was looking for, but it's much faster than software rendering to surfaces.

[Traveler]

Good to see you got things sorted out now...

In any case If all things fail, you might want to consider moving to the new opengl based wrapper thats being build by Andreaz and his team. They appear quite active the last few weeks and are rapidly moving to a fully functional system for creating 2d (possibly 3d too?) based games.

[Evil_Toaster]

Yeah, I'm quite relieved to have found a solution. I'm busy making a game for a competition, the cut off date for which is a little over a month away. With all the other things I need to get in, fighting with technical issues like this is frustrating.

I saw that thread, looks like there's been a lot happening. I'll definately check it out at some point, the feature list looks great.

[Speeeder]

Seems like I wasn't listening for some time

Well, the way it was meant to work with DirectDrawSurfaces is to allocate them in objects you store the pictures of in, loading when your program does the loading and freeing when it won't be used again (thus avoiding the many allocating, constructing and image loadings) and draw them directly on the main surface.

As for the "hit boxes", I did mean rotated bounding boxes, yes. And to check if they're inside or outside of them, you need to use the normal vectors of the edge vectors cast on the point, then you can count if the point is on which side of the original vector quite CPU efficiently I guess. At least this would be the way I'd do it, instead of pixel-checking ^^ However, for hit checking, you can as well draw the needed-to-check pictures on the main surface when the frame starts then just draw a fillrect on them. However I'm not sure it'd be much diff from your way

[Evil_Toaster]

I assume you mean the functionality that's built into the TDXImagelist object? I use them extensively, but I was wanting to use surfaces for the following two reasons:
- Maintain pre-rendered versions of a group of images (Great for improving performance), or pre-rendered rotations/alpha/etc
- Using them for pixel accurate collission detection checks (Using the DXDraw surface works, but it's not as efficient or convenient)

Ah, ok then I probably do know how to implement those hit boxes, I just haven't done it before. I'll go have a look through my 3D math references again sometime.

I've implemented the pixel checks in exactly the way you've described, the only difference is that I'm running them in a separate point in the program from the render function.

Anyhow, the result of this whole saga is that I've found two bugs within UnDelphiX 1.07, and two features I'd like to see implemented. I know you do have (or have had) some involvement with its development, so if there are plans for another version, it would be great if the following could be done:

Bug to Fix (The two bugs below are not present in the older version of UnDelphiX that I'm running. It's either v1.0.5 or v1.0.6)
- Surfaces fail to render in hardware mode (See that project I uploaded for an example)
- You cannot use more than one TDXImagelist class in your project, rendering fails. It's quite possible this bug is related to the first one.

Features
- Hardware rendering to surfaces
- DrawSkew functions (Basically, the ability to draw an image warped into a parallelogram/rhombus. Needs to be able to stretch):

|--------|          /--------/
|        |         /        /
|        | -->    /        /
|        |       /        /
|--------|      /--------/

[Speeeder]

uhm, as for the Surfaces failing to render in hardware mode, I'm absoletely sure that they work perfectly using TDirectDrawSurfaces. Using a TImageList... Well, I somehow doubt that it isn't working, I think you mused something up. More than one DXImageList - I have no idea, but I can't imagine why you'd really need two of them

As for what I mean, here's a little illustration:


I hope it's about understandable, that'd be the rotated rectangle. You know its corners and a dot you want to know if it's in it or outside of it. You can count which side of a rectangle-side it is on with the described way, you need to count it for 2-4 sides, whichever would be faster for the computer... (Guess it's probably the 4 sides)

If you wish to see if a line intersects the rectangle, that's even more easy. You count the equation for all rectangle edges and the line, count the variables from the two equation for the intersection coordinate, then compare it to the line's ending points.

If you wish to see if rect hits rect, then you need to follow about the same logic as with the line.

This algo wouldn't be much easy, but written well, I'm pretty sure it'd be much faster than per pixel checking, and it'd be a bit scalable, say, you wouldn't want to call it a hit if you want to make the target image look like it's in 3D, so it could as well hit it at its middle or so.

And now, let's see that uploaded project.......................

[Speeeder]

aahhh, yupp... You're drawing the image transparently. The transparent colour will be the picture's upper-left pixel's colour. If you do not wish to draw with transparency, then in the drawing method set false to the appropriate parameter.

[Evil_Toaster]

Thanks for the reference. I understand in theory what needs to be done, but I don't quite follow the maths. I follow that a, b is translating x1, y1 and x2, y2 into a vector, and -b,a or b,-a gives you a vector perpendicular to a, b. I assume creating the equations would mean something like:
x = by + a, or y = ax + b (Line on box)
x = ay - b, or y = -bx + a (Line Perpendicular to box line)

I'm not sure what is meant by "count their equations to get the intersection point" though? I have a feeling I should know, but my maths is a bit rusty.

Uh, did you try this project?
http://etgames.q.org.za/tmp/Prototype2.zip

I'm not even drawing an image here, it's just a surface being plotted to the DXDraw surface. Switching to hardware mode causes rendering of the surface to fail. (Try the .exe I provided with the project) Drawing via TDXImagelists works fine (as long as I don't create more than one).

The reason for me having multiple image lists is a custom graphics storage format I created which allows me to address images from the context of sets of images. This was of course done before I found out that you can have multiple images per item in an image list, but since I built a custom image set creator program to easily put together my graphics sets, I'm still using my format. Under this format, having all the images for a game within a single image set loses me the ability to have sets of sets of images. (I.e. Unit > Walking Animation > <set of images>) Instead, everything would be mixed up in one long list of sets. Anyhow, it's not the end of the world or anything, but the functionality was working in previous versions and now it isn't.