View Full Version : DXDRAW options

20-07-2006, 03:30 AM
Well, I looked on the net but didn't see a great deal that helped. A few questions:

1. I am running a 2d game, windowed. Which of the options should I enable in dxdraw? There are a few I am not sure about. a. doallowpallete b. do3d, c. dodirectx7mode (why would I want to go backwards?) d. doretainedmode e. doselectdriver. Also, should I enable to Use zbuffer?


2. Other thing I had trouble with, I took my game to a mates house, he uses a widescreen tft monitor on some awful resolution. My game was no longer correct looking because the dxdraw had been stetched according to his resolution, like his normal windows. So, how can I stop this from happening so that it appears to be a 600*500 Dxdraw surface on any computer?


20-07-2006, 04:39 AM
Just becareful with Do3d and XP.

Floating point operations become single rather than double which can cause hassles it you add two Doubles together. We had problems where 2 + 2 = 3.999999 or whatever.

This only happens with Windows XP.

If you aree doing 2d stuff then zbuffer is false.

As for wide screen - you will haveto take that intop account during design.

Either stick to your aspect ration and wide screen users have black bars on left and right. Or increase the width of the game area.

20-07-2006, 04:58 AM
yes, i have been having that problem...thanks:)

20-07-2006, 05:39 AM
You can set the maths precision back to 32 bit and it solves the problem

20-07-2006, 05:41 AM
don't need it anyway:) What about usedirectx7mode and selectdriver though? what are they about?

20-07-2006, 07:11 AM
I am not sure. I have never noticed any benefit to setting them.

20-07-2006, 09:18 PM
If you are using undelphix with DX9 backend - you could modify CreateDevice call and set D3DCREATE_FPU_PRESERVE behaviour flag. This will disallow Direct3D to hange FP precision to 32bit (single). If your application is not CPU limited this is the best solution.

20-07-2006, 09:23 PM
In my case I just used

Unit Maths

if GetPrecisionMode = pmsingle then SetPrecisionMode(pmDouble);

20-07-2006, 11:37 PM
hmm another few questions:)

On a computer with 4MB graphics card, obviously old, the game runs awfully slow no matter what. I take it that there is nothing I can do on sucha machine.

On a 16MB machine, again must be old, 60 FPS mode runs fine, but vsync mode runs sluggish. This is again a symptom of bad graphics card?

22-07-2006, 11:04 AM
In my case I just used

Unit Maths

if GetPrecisionMode = pmsingle then SetPrecisionMode(pmDouble);Well, this is not good as it can break Direct3D. You better save current FP control word, do SetPrecisionMode(pmDouble); before your code and restore control word before starting to call DirectX functions. This way you will be sure what everything will work correct and performance will be at top.

22-07-2006, 07:24 PM
Thanks for that Clootie.

In the situation where we needed it there was no direct3d used so it never affected anything in our case.

23-07-2006, 05:48 AM
I have 2 further problems in delphix where this is concerned.

Firstly if I use jpeg or PNG images, the collision detection does not work, and more over, the sprites don't seem to even draw on the screen.

Secondly, If I use bitmaps for the animations and set transparency, there is still evident the colour that should be discarded. I set a picture animating 4 frames with colour, and black is the transparent, but still there is black outlining and even the box is sometimes visible

23-07-2006, 08:39 AM
For jpeg's don't forget to add jpeg to your uses section.

As for transparent colour always use a "pure" colour, on ethat doesn't alter when set to 16 bit mode.

I stick to fuschia for the transparent colour, $FF00FF.

In photoshop I use a "background" colour that is close to the colour of the sprite. For example gray.. Then change the bitmap from RGB to index colours including the "primary colours" this includes fuschia in the pallete. I then select the background colour and replace with Fuschia. That way I don't get fringes of colour surroundingthe sprite.

I find black to be a terrible colour as the transparent colour as you tend to have black in the sprite itself.

Hope it helps.

23-07-2006, 10:48 AM
Well, the picture has blur to it needed for the effect of a shield. I chnaged to primary, and not rgb (it seems to go back to rgb actually when using primaries), used FF00FF as suggested and this is what I then got hehe:

http://img388.imageshack.us/img388/5024/untitledwa0.png (http://imageshack.us)

23-07-2006, 11:03 AM
That kind of FX effect (if I imagine it correctly) require alpha-blending, and tend to require real alpha in source image itself (not just alpha-mask).

23-07-2006, 11:05 AM
Is there anyway to implement this in delphix. My shield would look really crap without the gaussian blur I added in photoshop

23-07-2006, 06:08 PM
DelphiX is not suitable for what you want to do. I would suggest moving on from DelphiX and using different system. Have a look at DanJetX, it will do everyting you want and leaves room to get into proper 3d stuff later.

26-07-2006, 11:56 AM

You can see to DXDraws in code for new function on DirectDrawSurface like

procedure Noise(Oblast: TRect; Density: Byte);
procedure Blur;


01-08-2006, 10:03 PM
On some machines delphix certainly has better framerate or performance whilst in fullscreen mode.

Is this normal?

02-08-2006, 02:08 PM
Alot better way... Make the shield effect on a totally black background, as if it'd be drawn on some black space already. Then draw it additively. That way the black will be invisible, and brighter it gets, the more visible it'll be. (In fact, draw about everything additively that's gonna glow) Also note that this is a pretty slow thing. So if you will use additive drawing, be sure to have the latest UnDelphiX and Hardware Accel on...
You should use an alpha of 255, that way, the effect will look about like how you've drawn it.
(For an example, lookie at http://freespace2d.try.hu, screenshots section... Yeeaaa, that's coloured additive drawing, same thing :P)

Of course, everything runs faster in full screen than in windowed...

czar: now who's saying bad things about UnDelphiX? You or me? :)

06-08-2006, 05:20 PM
That brings me onto another question I have been meaning to ask;)

What do you guys do in your games? Force the player to use fullscreen or allow window mode?

The main problem is that on some computers the difference between correct speed and slow speed is huge and determined by whether player is in fullscreen/window (especially with vsync it seems).

So? Do you force em to use full screen? give them option knowing that they may have an advantage due to slow down?

06-08-2006, 06:29 PM
Hi ya speeder,

I am not saying anything bad about delphix - I have used DelphiX for almost 10 years. However, there are now better, cleaner and more suitable APIs for doing directx stuff. We (at my work) moved to Omega and now to DJX. With DanJetX it is so easy to combine 2d and 3d material that it just opens up so many possibilities for us and the type of programs we make.

I have never found fullscreen to be much faster than windowed mode.However, the FPS difference should never make a difference to you game. All movement and changes should always be based on time rather than frames. Once you adopt a tiem based system you solve a lotr of headaches.

I do movement in pixels per second. Other events you can also do as chance per second. That way you never have to worry about computers that drop below your desired FPS.

06-08-2006, 09:28 PM
I do use while do main loop with timegettime to prduce the intervals. The problem is that on real slow comps, it doesnt skip frames, it just slows down the drawing process because it isn't fast enough to draw at the right speed.

Should it be skipping frames when it cannot maintain steady flow? Better yet...upload a small example? An example of say a ball going back and forwards using your method. That way I can see if ui am doing it differently but I don't think I am.


06-08-2006, 10:35 PM
deltaTime := timegettime - lastTime ;
lastTime := timegettime;


Lets see, this SHOULD work should it not;)

If cpu cannot keep up theoretically the next time it executes the loop it will just have a greater deltatime and move character by that amount:)

I think I understand

and 0.1 part would be pixels moved...so 1/1000 would be 1 pixel a second?

06-08-2006, 11:19 PM
Looks right.

I use

A fraction - the (time since last frame / 1000) and then the pixels per second can be say 200 or 400 or whatever rather than 0.1


x :=x + dx;

draw at trunc(x)

Only thing you need to consider if DX gets too big. Either cap DX or make sure that you aren't skipping past other objects.

06-08-2006, 11:22 PM
ahh of course you have simply rearranged the equation to again work in pixels a second on the same basis. I see:)

I understand now, I understand why the hell it hasnt been woring proper on any machine.

I take it on a crap computer the game will now skip frames instead:)

07-08-2006, 12:42 AM
uuhhhmm... If you base the game on spent time, not frames then frames won't be skipped, they just follow each other... If you base it on frames, then you might talk about skipping frames :)

About slowdowns in DelphiX:
In case you're developing your game for a reasonable computer today... Say... 1GHz CPU with a GeForce 2 or Radeon 7000, then the latest version of UnDelphiX should give you a good enough performance. And that configuration is the minimum I could imagine a game would be wanted to run nowadays. If your game isn't running well enough on such a machine, then you probably should think it over, you prolly have some inefficiency in there.
Please check if you have acceleration on. Have do DirectX7Mode, do3D, doFlip (makes fullscreen drawing faster).
To check if you have acceleration on, just draw a coupld of bigger pictures additively... If your framerate drops like hell, you have it off, if the speed change is hardly seeable, you have it on :)
About my project, I give the users the choice to use it in window of fullscreen. They can just change any time with Alt+Enter, question solved on my part :)
Also, about the more time consuming things like the additive or alpha drawing, I've added switches that the user can set, so the game would have a low and high quality mode. And for the very "high quality" effects, like additively drawn smoke particles, the game would look at its FPS meter and adjust the smoke acordingly. Skip it totally in low quality.

VSync makes DirectX wait with each buffer flipping untill your monitor finnishes drawing the picture one. This means that if your monitor's running at 60Hz, then your framerate will not go over 60Hz. This also will do smaller timeouts when your game's running under 60FPS, cuz the proggy may finnish drawing the picture in say... The 2,01Hz of the monitor's refresh, then VSync would probably wait till the 2nd frame of the MONITOR would finnish, and only flip before the monitor would draw its 3rd frame. Generally, it's okay without VSync, at least I don't notice tearing without it. (When the draing buffer is flipped when the monitor's only half-done with its drawing, so for example, the upper half of the monitor would contain the game's frame x and the lower half would contain the game's frame y.)

Aaaand if you're developing for a computer so low end that it does't meet my upper configuration, then you should consider learning pure DirectX on C++, bcuz Delphi wasn't made to be the most optimized game engine as it's logical... Also, maybe Direct3D's features may not even really work on such an old computer (in an accelerated way of course... The CPU loves emulating :))

P.S. Sorry if I said something obvious or totally stupid :)

07-08-2006, 01:23 AM
and now using timebased gaming, most of it is fine. 2 problems do occur:

1. If I hold the window with my mouse the game skips everything (because timegettime is constant and external to the game) and sprites leave the screen. Anyway to disable that freeze that happenes when you hold the window?

2. Animation speed, havent quite figured out how to make it the same speed every no matter what, seems to speed up animation or slow down alot....

07-08-2006, 01:29 AM
When you say you hold the menu. Does that mean when you draw the frame the equation results in a huge jump in x? If so you will need to handle that.

If you sprite has a number of cells of animation then obviously you do not want to go to the next cell each frame instead you have a "animation counter" as part of your object

if TimeGetTime > AnimationCount then
AnimationCount := TimeGetTime + 250;
if animationcell MaxCells then Animation := 0;

That way the animation should be smooth

07-08-2006, 01:31 AM
Another thing you can do is have

GameTime := TimeGetTime; // oncreate

then in your game loop

you have to add the time between frames to GameTime.
GameTime := GameTime + TimeDifference;

When the game is paused for whatever reason you stop adding the time to your variable.

I use system like that usually when I need to have pause or menu functions in my games and application.

07-08-2006, 01:51 AM
yes x has a huge jump whenever the game is not drawn proper, or when i hold the menu....

You may have done this yourself, whilst a timer is running, hold menu and the counter stops, then when you let go, the counter jumps to where it should be. The game itself pauses but of course the Gamecounter hasn't.

I guess I will have to go along the lines of pausing the game as you say to stop this happening.

What about a computer that is really slow though?

if x>500
direction:='left'; {direction is a global variable for the row}

if direction:='left' then x:=x-1; {obv. i am using deltatime here.... not x:=x-1 but you get the point}

this is to make the sprite bounce of the wall, a space invaders game would be the closest idea. Unfortunately if too much time is skipped when the game gets control back, x may be 600 and will have ages to come back on itself If i say if x>500 then X:=500, the last sprite in a line will go out of sync with the rest in that line ;)

I can send an example if you wish?

07-08-2006, 02:31 AM
We started making delphiX programs for Pentium I 300Mhz-400Mhzs etc. So I doubt that DelphiX cannot handle most computers available.

Obviously we never used rotating or blending functions. However, with some simple photoshop techniques you can prepare most graphics so that your games still look excellent without using fancy blending etc.

What you can do is switch off optional graphics/reduce number of particles that take much time on older computers.

I never used the hardware accelarated version of DelphiX. When that came onto teh scene we had already decided to move away from DelphiX.

07-08-2006, 01:01 PM
The computer in the office is 600 MGHz 2 MB gcard. It doesn't run very well there. I sorted out application freeze by setting to DKdock rather than drag.

I will test on slow computers and report back. Space invaders moving sprites back and forward has proven more difficult than it should be, but delphix still rocks for a novice;)

07-08-2006, 08:35 PM
OK here is a conundrum for you:) Think of space invaders, the ships in 1 row go back and forward in 1 motion. If the far left hits the left wall the whole row proceeds to go right and vice versa.

I have doen this by using a global variable ROW1Direction which is a string. If Row1Direction='LEFT', then x=x+1; if right X=x-1 as an example

The line of 10 sprites (row1sprite) that are part of Tenemy. On the Domove I have code which says:

If X<0 then Row1direction='RIGHT';
if X>GameareaX2-Image.width then Row1Direction='LEFT';

if (Row1Direction='LEFT')then
X=x-1; {obviously time based in real thing}

if (Row1Direction='RIGHT) then

Now here comes the fun.... the row stays with equal spacing after X<0 and row turns to go RIGHT. BUT when the far right sprite hits the far right wall and turns to go LEFT it goes out of step with the other 9.

Why is this?

07-08-2006, 08:41 PM
Not sure if I get your problem...

In SPace invaders all enemies move same speed and distance.


DeltaX := 200 * (FRAMETIME / 1000);

If Going Right and
If far right enemies + deltaX > RightSideOfScreen then ReverseDirection.

If Going Left and
LeftMost enemy is < LeftSideOfScreen the ReverseDirection.

In otherwords

all the enemies move same set amount. Apart from exceptions like mothership.

07-08-2006, 08:49 PM
I will have to send it to you, it is defying physics.

Download RPGNINVADERS.zip from FTP server


I don't normally release source but since this game is purely for fun with a few mates I guess I will allow it this time;)

It is very very early made this one...and whilsy you are there if there are any pointers you think are necessary, like hey dude thats totally not the way to do things, feel free to tell me;)


FTP updated.

07-08-2006, 09:05 PM
And someone just dl from Aukland, that you? :) yes it is I see your details;) Neotrace pretty accurate. I take down ftp now

07-08-2006, 10:03 PM
I had a look at your code.

I found it quite difficult to follow so instead of trying to work it through (I am at work :) ) I have made a simple delphix program that demonstates




So hopefully it will give you some ideas.

07-08-2006, 10:04 PM
thanks, but do check that program, you will find that rows will not stay in alignment and if you can suss it out that would be great but I think you too will find it a bit weird;)

08-08-2006, 11:11 AM

You know the time between two frames.
You count the distance the invaders can go from the speed and time.

You create a cycle to handle moving the ships, while distance is > 0.
You check the direction (left/right)
You move an Area of the ships the correct direction to a wall, and reduce distance accordingly. (Area of the ships - X1 = left side ship X, X2 = Right side ship X + Width). Change direction if the area has hit a wall.
The same for the other direction.
End of Cycle

You Align the left side ship to the Area you've moved.
You align all of the other ships to the left side ship.

This could for example make an algo that'd work with whatever lag your proggy can have...
If you wish to add hit detection to the gap, then I you probably need to move every object with a greater resolution, and checking everything... No drawing. But the same algo should be okay for moving the ships...

Also, your FTP isn't working :)

08-08-2006, 12:42 PM
I took it down, i will put it back for you to download later, try in 6 hours:)

08-08-2006, 08:54 PM

Ok, now remmeber, any help as to why the line is only going out of sync when sprite hits RIGHT wall;)

09-08-2006, 11:50 PM
Well... Firstly, when I ran the game it did quite close to nothing at all :) I'll look into what the heck is with it sometime other than 2am :)

Edit: I did take a quick look tho... What the bloody hell is a TQRImage?

I othervise don't know the Sprite Engine at all, so I think I won't be able to help you :) I'm used to handling the things myself and using TDirectDrawSurfaces

09-08-2006, 11:54 PM
That shouldnt be there anymore:) That was from a much much early experiment years ago when I knew 0 and was using images and normal timers to move pictures around the screen, simulating what dxdraw does with normal components hahaha they were the days:)

and yeah like I say this game is practicly a fgew hour old.

Press vsync buton to get game started. If you enter fullscreen mode it will seem to freeze this is because game pauses. Use for now click with left mouse on DXdraw area to unpause...

and you are from Budapest?

09-08-2006, 11:56 PM
Well, I let Delphi kill those, so whatever, but it'd be nice if you cleaned your code up some :)

09-08-2006, 11:57 PM
I am messy and I tend to always clean up at end....hehe this started as experiment;)

10-08-2006, 01:35 PM
okaaay, ummm...

I've looked a bit more deeply into it - unfortunately after learning C++, so my mind isn't at full juice, but I think I won't really understand how this thing goes...

First thing's first, you should REALLY look over classes and the basics of object oriented programing, cuz declaring tons of global variables just blows the mind out of anyone else than you :) (That's also very important if you want to work as a programmer)

If you would like a quickly done example application or something, I think I could trow togeather one, buuut, the way it is now... I think I'll pass going into it, sorry :)

(oh, yea, and I couldn't make it start however I tried...)

10-08-2006, 01:44 PM
True but the object is for me to understand it noone else....in this case I make an exception;)

Anyway you don't really need to understand the main stuff, its just weird that the line stays in sync when X<0 but goes out of sync on the other side when it is a mirror of the prgramming for <0.

I can get round this two ways avoiding normal invaders movement. 1. By making the sprites simply go through x>500 back to 0 or just let each sprite see the edge and have then go back and forward overlapping. I still want to do it thw classic way though;)

10-08-2006, 06:14 PM
HI seiferalmasy,

I agree with Speeder. There are many reasons for writing solid and clean code. One is so that it is easier to find and squish bugs. And also so that it is easier to maintain code in the future. This is true even for hobbyists, going back to a program 6 months later you might find you don't understand your own logic. I know I have found this to be the case with my own software :)

I help maintain over 1200 programs and I having to change or fix a program that was badly written it makes the job very difficult. Using meaningful variable names and good use of classes and records etc makes it much much easier to go back to programs later. I am not having a dig at you, you can write your programs however evr you like that is fine. But you program is hard to follow which is why no-one has been able to help with the out of line bug that you have got.

Good luck

10-08-2006, 09:39 PM
I agree with you;) But this is not the reson for my line goin out of sync, I can't explain that.

You are right but I am no pro and as such I will live and die by my sloppy code hehehe

11-08-2006, 01:01 AM
Well, seifer, as far as I see, it wouldn't really be THAT hard to restart your project... And if you took about like 10 minutes with overthinking a followable system for your program, like putting every whip into a class, then making a container class which will contain all the ships in a matrix of pointers (so it will know which ship is in which poistion without further alignment tinkering) and moving all the ships as one from the container class... You'd only need to make it know which row in its matrix has living ships, then it would know how much area the field of ships will take... So it could very simply move them all... Also, that way, we could as well help you correct something if you have a problem ;)

Edit: oh, yea, I'd also forget the sprite engine, and load the picture of the ships to eighter the container or the ships (depending if you wish to use diff for each or not) into a TDirectDrawSurface, and handle drawing and hit checking in the ship classes.

29-08-2006, 11:29 AM
well, I really didnt think the answer was so simple. It turns out, on some graphic cards (poor ones), if the desktop bitdepth is over 16 bit there is a massive performance loss, frames skipped ALOT . I thought it was window mode doing it, but it was just the bitdepth.

It could be just that 24/32bit takes up more graphic card performance, but this kinda performance degradation leads me to wonder whther this is a bug in delphix.

Anyway, I need to upgrade to undelphix soon.....

29-08-2006, 06:05 PM
Like I said, UnDelphiX 1.07 is pretty close to bugless... I hardly doubt that performance died only cuz of DelphiX. You need to note that older graphic cards will not support much of the hardware accelerated functions, and DirectX will draw them software emulated... If the CPU is crappy too, then that'll be some extra juice for it ^^ Anyway, as far as your game goes, if you plan to release it for crappier computers, then make it start in fullscreen mode by default, and do not use 24bit. Only 16 and 32. Have to add there, that older video cards also had quite a big performance reduction on 32bit in ANY game, just as you said. And finally, add at least command line options so the user may choose a mode (fullscreen/bit depth), so your game will run as wanted.

In short: A game will run fastest in fullscreen 16 bit mode. If that's not sufficient enough, add configurability. If the given performance isn't that needed, then you can push it up :)

29-08-2006, 07:34 PM
You bet ya. I am making 16 bit mode forced;) I myself have a 256 MB graphic card. and the performance increase on mine is noticible...so I am sticking with 16 bit, the quality increase just isnt worth the hit on performance imo . On crap comp 1 : 2 GHZ with 16MB gcard it won't run anywhere near smooth on vsync or above 60 fps. On crap comp 2 600 MGHz 4 MB gcard, the game does not run at all in 32 bit mode (well unless you count about 98% frame loss).

The performance loss is staggering:)

29-08-2006, 11:46 PM
Then that kinda performance loss is your error, not DelphiX's... Check my game: http://freespace2d.try.hu, it's running pretty nicely compared to what graphics it is pulling off, and the fact that most pictures aren't in the power of two width/height. You can use -lowquality on slow machines to turn the glow effects off. (And it's 32bit)

30-08-2006, 05:11 AM
I will run your game on those crap computers and I can guarantee it won't run right (unless undelphix is somehow different). (also I have made 3 games, 1 uses hardly any graphics)

Yours forces fullscreen mode and prob uses non32 bit mode so it might run correct. No way to use window mode?>

Btw, nice use of graphics

also: I figured out an earlier problem I had, I use the sprite engine, and in order to make sprite change I just override the dodraw method:):)

30-08-2006, 09:26 PM
This might be a shockingly suppriseing thing, buuut... Please do read the text at the bottom of the menu screen :) Hint: Alt-Enter :P

Yes, it does force 32bit mode, read the minimum system requirements for the game ^^ Also, it needs a fair enough video card - Gef3+ or Radeon 8500+. I think that's fairly reasonable. Of course there could be many places that could be optimized, buuuut... Imo if you make your game about that much optimized, then it'll be all good :)

31-08-2006, 12:33 AM
hahaha yeah i did just bris through it, should have checked alt-enter my bad

09-10-2006, 04:25 AM
Stretcthdraw my logo onto dxdraw.surface. Cpu usage never goes above 1%

DrawRotate, same procedure, 50% cpu at all times, even when logo has stopped moving.

Any reason for this? normal?

09-10-2006, 10:11 AM
It's been a while since I did any DelphiX, I do remember Draw Rotate being a heavy function though.

I'd wrap the draw rotate function in another function which has a buffer surface.. DrawRotate the sprite onto this surface when the angle changes and just blit the surface the rest of the time.
If you're rotating all the time, it'll be slower, but if you rarely change the angle, you'll see a massive performance gain to just using DrawRotate.

*Obviously, you'll have to supply the previous buffer and previous angle to the function and let it decide to either use the prevoius buffer or render a fresh image with DrawRotate.

13-10-2006, 08:31 PM
Also on subject of rotate. I am overriding draw and using dodraw to draw my sprite to screen.

procedure dodraw;override ;

However, the collision detection does not recognise the sprites position, rather..where it would be if it were still. See picture below:

http://img288.imageshack.us/img288/1046/1zk5.png (http://imageshack.us)

The red Square is rotating from the fixed point where it joins with the black square. The red square is the rotating sprite. However, the sprite engine collision detection treats it as if it is not moving, resulting in collisions only where the black square is (which obviously isn't visible).

Any chance this can be resolved?

18-10-2006, 08:52 PM