DXDRAW options

[seiferalmasy]

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?

[czar]

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.

@seiferalmasy
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.

[seiferalmasy]

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.

[seiferalmasy]

deltaTime := timegettime - lastTime ;
lastTime := timegettime;

-----
x:=x+0.1*deltatime

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?

[czar]

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

dx := (FRAMETIME / 1000) * PIXELPERSECOND;

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.

[seiferalmasy]

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

[Speeeder]

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

[seiferalmasy]

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....

[czar]

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
begin
inc(animationCell);
AnimationCount := TimeGetTime + 250;
if animationcell MaxCells then Animation := 0;
end;

That way the animation should be smooth

[czar]

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.