Library recommendation?

[Wiering]

I got the game to work now (using UndelphiX in Delphi 5), but the Steam overlay doesn't appear (probably because it uses DirectX 7), achievements are shown after ending the game.

Would a game be allowed on Steam if the overlay doesn't work? (Are there other games that don't have the steam overlay?)

I tried adding an OpenGL layer. That works, but it is always UNDER the game and is invisible (if I make the game window smaller, I see it on the sides). Anyone know a way to get something in front of a UndelphiX DXDraw?

[SilverWarior]

According to official documentation about Steam Overlay that you can find here https://partner.steamgames.com/doc/features/overlay DirectX 7 is supported. The documentation also states that you need to initialize Steam API before your game render surface is created in order for the API to successfully hook the rendering device creation.
Another cause for your problem might be the fact that UnDelphiX might be actually running in software mode with which Steam Overlay is not compatible.

[Wiering]

According to official documentation about Steam Overlay that you can find here https://partner.steamgames.com/doc/features/overlay DirectX 7 is supported. The documentation also states that you need to initialize Steam API before your game render surface is created in order for the API to successfully hook the rendering device creation.
Another cause for your problem might be the fact that UnDelphiX might be actually running in software mode with which Steam Overlay is not compatible.

Thanks, I am starting Steam first, but I'm unable to get it to work. I'm actually wondering if UnDelphiX really uses DirectX 7 for 2D, I don't think DirectDraw was ever changed after DirectX 5. I set doDirectX7 and do3D and from looking at the source it does seem to load a DX7 object at some point, but Steam never hooks to it, strange.

Anyway, I made a new rendering engine using OpenGL and set that as default and now the Steam overlay works fine.

[Roland Chastain]

Hello!

@Wiering
Glad to hear that you are still interested in Pascal programming. My children and me love your Mario for Turbo Pascal. I hope you will give us some open source Pascal/Delphi games.

[Wiering]

Sorry, I guess your computers must be so fast that they do the entire frame within 1 ms then. I had a little check of delta time > 0 (in case it would wrap around), but now changed it to >= 0.
It should now be a little over 60 fps. If I try to get it exactly at 60 fps, it will stutter on systems where OpenGL does wait for the retrace.
New build ID is: 2498995

[JC_]

Now is speed ok, OpenGL have 64 FPS, but there is bad tearing in fullscreen when is screen scrolling. In windowed + maximized mode (OpenGL) it's ok.

DirectX is in fullscreen ok, it is not completely smooth but playable without any problems.

[phibermon]

Use V-sync, the tearing is because you're not. 60hz is likely the refresh rate of your display hence the 60fps of DirectX. This whole 'disable v-sync' deal is a total myth. The only reason it ever improves 'performance' of a game is because developers rarely handle it correctly and waste vast amounts of time spinning in a swap call. When you disable v-sync, it's not the rendering that makes things 'smoother' - the screen can only display (in this case) 60fps - it's the fact that all the other game code in the main thread gets called a lot more which superficially improves 'performance' because you're no longer wasting time waiting for a v-sync when you could be processing input and everything else.

The correct way to get silky smooth performance with no screen tearing - is to use v-sync and make sure you spend the minimum amount of time blocked in a swap call.

So if the refresh rate of the display is 60hz, that gives you 16ms per frame to do everything before you call swap. You should time each frame and try to spend (for example) 15ms running your game loop - you only break out and call swap JUST BEFORE the 16ms swap window. Miss the window and you drop a frame. If you drop a frame then you increase your margin to say 2ms - you find the right amount of time to spend processing so you always hit that swap window.

Bad game loop :

Do stuff.
render stuff.
call swap.
swap waits.
swap waits.
swap waits.
swap waits.
swap waits.
etc etc

Good game loop :

Render stuff.
Do stuff.
do we have some time left this frame? yes > do stuff, repeat.
do we have some time left this frame? no > call the swap function.

Do this properly and you'll have silky smooth, v-synced graphics.

I render before I do any processing personally. This does mean I introduce a potential delay from input to displayed output - there's no reason you can't call render just before swap and decrease this potential delay - in fact it's probably best for most people - I only do this because the amount of time it takes to render a given frame is variable and can spike causing you to drop frames if you weren't expecting it - I have far more control over how much time I spend doing other things - so I leave them until last so I don't miss my swap window. A (at worst) 16ms delay between an input event and the potential response on the display is nothing to worry about - most guitar effect pedals introduce a greater delay from plucking the string to hearing the sound and believe me - no matter what gamers like to think, if it's good enough for a death metal guitarist? it's good enough for a head shot

Disabling V-sync to improve performance only works on flawed code and it introduces screen tearing.

[Wiering]

I've done something like that in the old days in DOS and it worked perfectly, but in Windows from my experience it only works if you don't have any other programs running and even then not 100% reliable (that was in Win7, haven't tried 10).

But the problem I have with OpenGL is that I don't seem to have control over V-sync. On the computers I've worked with personally, SwapBuffers() always uses V-sync and I can get a steady 60 fps, but as it turns out, for some people there is no V-sync and they get like 300 fps. I think it is even a setting that people can configure for their video card and even force. So I'm adding a little sleep function just in case V-sync doesn't work (and in that case people will get tearing).

I've added a note in the description that if people experience tearing they should try DirectX instead of OpenGL.

[SilverWarior]

But the problem I have with OpenGL is that I don't seem to have control over V-sync. On the computers I've worked with personally, SwapBuffers() always uses V-sync and I can get a steady 60 fps, but as it turns out, for some people there is no V-sync and they get like 300 fps. I think it is even a setting that people can configure for their video card and even force.

The thing about VSync is that most graphical drivers have it off by default. So if you want to use VSync in your application then your application must request to enable it. Now there are some graphical drivers out there which have VSync enabled by default (I have most often seen this on laptops) but they still allow for applications to request disabling of VSync. Rarely you encounter computer which is forcing either enabled or disabled VSync and even then this is because users chose so.
So you need to make sure that your application requests enabling of VSync feature in order for it to be used on most computers.