TDirectDrawSurfaces not working in hardware mode?

**Speeeder** · 28-08-2006, 11:15 AM

errrr, let's begin at the start... From a point on a line and a normal vector to it (a perpendicular vector), you can make an equation that's the line itself. I do not know the exact formula right now, and I'm kindof lazy to dig it up as I'm going in 10, but you can just prolly google it with something like... "line's equation formula" or something... You then get the equation for 2 lines. You can for example count the X (with a Y variable) from one of the equations, put it into the second, where you can then get the Y value. And then the X from using the Y's value you got. The X; Y you have is the intersection point of the two lines. From there, you can guess all.

In UnDelphiX, the hardware mode cannot process the transparent colour setting of an image, so instead it uses the upper-left corner by default, and it does so on ANY surface! Even if you've drawn it, not loaded it as a bitmap. As your Surface is 1 colour only, it's totally transparent. To draw it non-transparently, Draw(0, 0, Surfacename, !!!FALSE!!!); Voila, it's working well!

Lastly... If you wish to organize your pictures as so, I'd recommend you storing images in your own classes in your own structures in TDirectDrawSurface objects. Loading them from files or resources runtime when your program loads. (There, you can optimize memory usage too, by loading the only needed pictures) I'm using this method, and it's working juuuuuust nicely. Also, for a game, I think it's probably best if you do not put your images into the EXE file as resources, just leave them outside the program as whatever format (but prolly one that packs well) and loading them runtime. Phisically you can organize images into directorys, and logically into classes, it's cool ^^. One last thing you can do is put animations into ONE picture file that will contain x frames of the animation, and it'll just draw the picture cutting the correct frame out (this is probably a better solution in storage-space too). If you happen to use this method, note that in hardware, UnDelphiX will somehow fail to draw images longer in width than 2048 pixels when you cut a subpart out of it. Haven't tried on the height tho!

**Evil_Toaster** · 02-09-2006, 12:14 AM

Cool, that makes sense, except what value to use for counting. Doesn't that mean I'd need to know either the interection point's X or Y value beforehand?

Ok, I follow that transparency colours are a problem when rendering images in hardware mode, but I don't think that you looked at the sample I put up? Please take a look at the code in this project (Also, try running the .exe):

http://etgames.q.org.za/tmp/Prototype2.zip

I am not using any images in this example, and the problem is not caused by transparencies. I am cycling a value through the shades of blue, then clearing a surface to that colour, then rendering the surface to the main DXDraw surface:

Code:

    Inc&#40;Temp,10&#41;;
    Surface.Fill&#40;Temp&#41;; 
    DXDraw.Surface.Draw&#40;0,100,Rect&#40;0,0,Surface.Width,Surface.Height&#41;,Surface&#41;;

In software mode: You see the surface cycling through shades of blue
In hardware mode: The surface gets "stuck" on the last colour that it was changed to in software mode.

So, that is what I mean by rendering failing is that any drawing to the surface in hardware simply doesn't happen. I get exactly the same behaviour if I try to render an image to the surface.

This functionality is definately working in the older version of unDelphiX that I am using, and no longer works in 1.0.7. (I've verified this on more than one computer)

Thanks for the suggestion regarding storing of images. I'll look into putting together something like that in the future. (No time to revise my image storage system at the moment)

**Speeeder** · 02-09-2006, 11:13 AM

Okay, I'll try to write this down... AGAIN...

Wrong drawing code:

Code:

DXDraw.Surface.Draw&#40;0,100,Rect&#40;0,0,Surface.Width,Surface.Height&#41;,Surface&#41;;

Right drawing code:

Code:

DXDraw.Surface.Draw&#40;0,100,Rect&#40;0,0,Surface.Width,Surface.Height&#41;,Surface,False&#41;;

Logically right drawing code:

Code:

DXDraw.Surface.Draw&#40;0,100,Surface, False&#41;;

And as I've said before... In hardware mode, a SURFACE's transparent colour will be the top-left pixel's colour. You have a 1 colour surface, so the top-left pixel's colour is the same as all of the image. Thus it's totally transparent. With the upper drawing procedures it won't draw with transparency.

For the upper geometry, you need to know the points of the rectangle, and the point(s) of the object(s) you wish to see if they're intersecting the rectangle. The rectangle's points - you rotate those too.

**Evil_Toaster** · 02-09-2006, 05:13 PM

Alright, look, I'm not looking for an endless war here. So here's my last attempt to explain what's happening:

Old Version in which surfaces render correctly:
http://etgames.q.org.za/tmp/unDelphiX/unDelphiX-Old.zip

New version in which surfaces no longer render correctly:
http://etgames.q.org.za/tmp/unDelphiX/unDelphiX-07a.zip

Updated prototype project which uses the drawing method you suggested:
http://etgames.q.org.za/tmp/Prototype3.zip

The problem I'm having has nothing to do with transparencies. In software, rendering works, in hardware, it doesn't. If you switch to hardware, the surface is still rendered to the DXDraw surface, you can see a blue surface, but any rendering TO the surface before plotting it to the DXDraw surface does not work.

Thus, in software, you can see the surface changing colour because drawing to the surface is working. In hardware, the surface stays one colour because drawing to the surface is failing.

**Speeeder** · 02-09-2006, 11:50 PM

I see... My bad, sorry. I'm too sleepy to think now, but a quick and dirty solution could maybe be that you draw a fully blue surface on a second, black surface with alpha. Haven't tested that. But really, I don't think any drawing is needed for a per-pixel hit check...

**ijcro** · 14-09-2006, 08:02 PM

Ahoy All!

Problem there overwritten in not problem.

How imagine works?

You use code:

Code:

    Inc&#40;Temp,10&#41;; 
    Surface.Fill&#40;Temp&#41;; 
    DXDraw.Surface.Draw&#40;0,100,Rect&#40;0,0,Surface.Width,Surface.Height&#41;,Surface&#41;;

But instance of surface is constant, and it is passed into texture stack. And there is check ‚Äì is image changed by instance? No and your changes no accepted! This can works in software mode as well, all images recently rebuild there, but in hardware no for save of time. You have to use other strategy for drawing like

Code:

    Inc&#40;Temp,10&#41;;
    Surface.Fill&#40;Temp&#41;;
    DXDraw.ClearStack; &#123;there is force clear texture stack, but speed rapidly fall down&#125;
    DXDraw.Surface.Draw&#40;0,100,Rect&#40;0,0,Surface.Width,Surface.Height&#41;,Surface&#41;;

And small hook is there. Function is supported in prepared version‚Ä¶coming soon 1.08‚Ä¶

I can release patch like 1.07b in short time.

**ijcro** · 21-09-2006, 07:42 PM

Patch as 1.07b was release.
Regards

Moderation Process Reminder

Thread: TDirectDrawSurfaces not working in hardware mode?

Thread Tools

Display