Library recommendation?

[Wiering]

Hello, I used to work with Delphi a lot, but then moved on to Haxe and C#.
Anyway, I have an old game (Charlie II (http://www.wieringsoftware.nl/ch2)) written in Delphi that uses unDelphiX. Unfortunately, the game no longer works in full screen mode on Windows 8/10, which is probably due to Microsoft no longer supporting DirectDraw. So my question is, what would be a good game library nowadays to replace unDelphiX with?
Basically, all it needs to do is draw (scale up) a 320x200 pixel buffer to the screen every frame, but it should also support sound and keyboard/joystick input, be able to switch to full screen mode and also work in windowed mode so I can use windows menus and UI. And it needs to work in Delphi 5 (since I can't use later versions commercially).
Thanks!

[Rickmeister]

I'll stick out my neck and recommend SDL2

Multi platform support
Hardware accelerated (using GL and/or DirectX depending on platform)
Pretty much industry standard (supported by Steam)
Support for Joystick, Gamepads, force feedback and Touch/Multi Gestures
Support for image loading (Through SDL_image)
Support for music/soundfx (Already in the lib, but works much better when using the extension SDL_mixer)
Support for TrueType fonts (SDL_TTF)


Some links to wet your appetite:
SDL2 (https://www.libsdl.org/)
Free Pascal meets SDL (http://www.freepascal-meets-sdl.net/)
SDL2 Pascal Headers (https://github.com/ev1313/Pascal-SDL-2-Headers)

To scale a 320x240 image to fit the current window I usually render to an offscreen texture and then stretch it to fit the screen, works other way too if you need to scale it down. Don't hesitate to ask me about SDL2, been using it since forever (it feels like it..). Also got a more OOP oriented set of wrapper classes around SDL2 that I can provide you with, still a work in progress and not very relialble and may cause serious damage to your mood...

And why use Delphi5 when FPC/Lazarus is free for commercial use? Even if I'm not the biggest fan of Lazarus I can really recommend FPC! Gives you the opportunity to deploy your work to Linux and OS/X aswell.

[EDIT]Delphi starter is free for limited commercial use (think it's $1000 before you have to upgrade it)

(Ñuño Martínez (http://www.pascalgamedevelopment.com/member.php?854-%D1u%F1o-Mart%EDnez) will probably say Allegro ;D).

[Wiering]

Thanks Rickmeister, that's probably a good idea, I'll try to see if I can get SDL2 to work.

Why still use Delphi 5? So far, every time I tried to convert a Delphi project to Lazarus or FPC, I was unsuccessful. Even if I can eventually get everything to compile, the executable will just crash or do nothing. And this game is huge and full of inline assembly.

I'll look at Delphi starter too, thanks!

[Rickmeister]

There are other options too. Pascal bindings exists for SFML (http://www.pascalgamedevelopment.com/showthread.php?32529-Announcement-New-SFML-CSFML-headers-binding-for-FPC), Allegro (http://www.pascalgamedevelopment.com/content.php?410-Allegro-pas-4-4-5-released) and TileEngine (http://www.pascalgamedevelopment.com/showthread.php?32525-Tilengine-2D-Pascal-Wrapper!) are a few examples. Of the mentioned ones I've tried out SFML, Allegro and SDL2 but as I have quite alot of experience with SDL I'm sticking to that.

[SilverWarior]

Hi Wiering!
I personally don't think it is really worth switching to another game library just because of this "full screen" difficulties you are facing. Why?
Switching to another game library will require you to rewrite most of your code do to the fact that each game library is using a different approach for its usage.
Another big obstacle might be the fact that you are using "ancient" version of Delphi, meaning that you will have hard time finding game library that still officially supports such old Delphi version. So you won't be able to rely on game library authors to help you with solving of potential bugs since they probably won't be able to reproduce them.

So in my opinion it would be better for you to simply solve the current "full screen" problems with using of unDelphiX. How?
Since your game already runs just fine in windowed mode I guess the best solution would be to simply implement "borderless full screen window" support. Note that this is becoming preferred full screen mode even in modern games as it does not block notification messages from other programs. Also there is basically no more performance loss or this performance los is really negligible on modern computers while in the past there was significant performance loss if you would be running your game in windowed mode.
Also it might not be a bad idea of contacting the author of unDelphiX library. While the original DelphiX library did heavily rely on DirectDraw I believe unDelphiX library is trying to use DirectX7 functionality instead. The author of unDelphiX library would probably be the best person for offering you more information on this matter. And if not that notifying the author about possible incompatibilities of unDelphiX with newer OS versions might lead him into fixing the unDelphiX library accordingly.

As for porting your code from Delphi 5 to Lazarus:
I guess the most common problem is the fact that in FPC/Lazarus you can't use same names for method parameters and object properties as it confuses the compiler about which is which.
http://stackoverflow.com/questions/42073767/why-does-a-valid-constructor-in-delphi-fail-in-lazarus/42076621#42076621

Another problem that you will probably face is the fact that newest versions of FCP/Lazarus and also Delphi already have Unicode string support enabled by default but Delphi 5 only had AnsiString support. And since there is a big difference between ANSI strings (one character = one byte) and Unicode strings (one character = two or more bytes) this will probably broke any routines that work on strings using pointers and probably most routines used to save strings to and load them from files.

[Wiering]

Thanks SilverWarior, the reason is that I want to try to get the game on Steam and the broken full screen mode is a complaint I get most, so it needs to be fixed.
Actually the DelphiX version is already kind of a port, since it started out as a DOS game, so it mainly just uses one DIB from DelphiX to draw the screen on, so moving to a different library shouldn't be that bad.
But your idea for borderless full screen window is probably a good temporary fix (eventhough I would prefer real fullscreen for the smoothness), it sure would be better than having an option in the game that doesn't work.
I recently contacted the author, maybe he will still reply. But I think it is something that Microsoft needs to fix (and from https://answers.microsoft.com/en-us/windows/forum/games_windows_10/directdraw-emulation-still-broken-in-windows-10/5a619148-cf1e-4813-b733-997b996b9567 I don't think it is very high on their priority list.

I don't remember running into that problem of the names, but it's a good thing to know. And yes, unicode could be a problem too, especially combined with assembly (I used to have lots of optimized string functions like UpCaseStr with assembly). I should probably rewrite all my assembly code to standard pascal.

[Wiering]

There are other options too. Pascal bindings exists for SFML (http://www.pascalgamedevelopment.com/showthread.php?32529-Announcement-New-SFML-CSFML-headers-binding-for-FPC), Allegro (http://www.pascalgamedevelopment.com/content.php?410-Allegro-pas-4-4-5-released) and TileEngine (http://www.pascalgamedevelopment.com/showthread.php?32525-Tilengine-2D-Pascal-Wrapper!) are a few examples. Of the mentioned ones I've tried out SFML, Allegro and SDL2 but as I have quite alot of experience with SDL I'm sticking to that.
I'll look at those, but I think SDL2 is probably the most commonly used (I've seen many games that use it).
I used to avoid SDL because of the license, I'm glad they changed it!

[SilverWarior]

Actually the DelphiX version is already kind of a port, since it started out as a DOS game, so it mainly just uses one DIB from DelphiX to draw the screen on, so moving to a different library shouldn't be that bad.

If you are drawing the contents of the game screen into a DIB (device independent bitmap) and then rendering that DIB onto the screen you don't even need specific library. That could all be done with a Windows API.
But in your original post you were also talking about sound and input handling. Here is where I believe you might encounter even greater difficulties.


But your idea for borderless full screen window is probably a good temporary fix (eventhough I would prefer real fullscreen for the smoothness)

As I sad before on modern computers there is virtually no performance impact of running a game in borderless full screen window.
If you don't believe me just check any modern game that has support for full screen borderless window and make a comparison. You might even find out that some of the modern games no longer even support the true full screen mode.

[Wiering]

If you are drawing the contents of the game screen into a DIB (device independent bitmap) and then rendering that DIB onto the screen you don't even need specific library. That could all be done with a Windows API.
But in your original post you were also talking about sound and input handling. Here is where I believe you might encounter even greater difficulties.

It's actually not DIB but DXDIB, and yes I also use a DXDraw, DXTimer, DXInput, DXSound and DXWaveList. What I meant is that game itself is not based on DelphiX, like when you use DelphiX's sprites and collision detection, instead I use it as a layer around the game.


As I sad before on modern computers there is virtually no performance impact of running a game in borderless full screen window.
If you don't believe me just check any modern game that has support for full screen borderless window and make a comparison. You might even find out that some of the modern games no longer even support the true full screen mode.

Could you name any examples of modern games that use full screen borderless window?

[SilverWarior]

It's actually not DIB but DXDIB

Actually DXDIB or to be more precise TDXDIB is a unDelphiX component intended to ease up working with DIB images.
Notice that all od unDelphiX components and many of its classes have DX prefix. This prefix is still from the time of the original DelphiX library. unDelphiX is actually an unofficial version of DelphiX which has been updated with more features and better compatibility with newer versions od DirectX.
And yes many people mistakenly think that DX prefix in unDelphiX library is actually referring to DirectX API which is not true. This has caused quite some confusion in the past and even whole lot of problems when people would have both DelphiX and DirectX wrappers in same project as it lead to scenarios of having duplicate names.


Could you name any examples of modern games that use full screen borderless window?

Hmm... Where should I start? Let's start by checking my steam library ;D

Age of Empires 2: HD Edition
In the options you have three choices for Dipslay Mode:
- Windowed: which is self explanatory
- Full Screen: which is true Full Screen mode
- Full Desktop: which is borderless full screen window mode. Note some people experience problem when switching between Full Screen and Full Desktop mode due to a bug in AOE2 HD

BeamNG Drive
It has ability to run in borderless full screen window but always switches back to standard windowed mode when it loses focus (user clicks on some other application on the second monitor - dual monitor setup)
Done quite some testing and haven't seen any performance difference

Empyrion - Galactic Survival
Also supports borderless full screen window. Also haven't noticed any performance difference.

Grand Theft Auto V
It does support borderless full screen mode.
Here I used in-game benchmark system to test out the performance difference between true full screen and borderless full screen window mode. The is a slight performance drop in borderless full screen window mode of about 3 FPS. But that is still negligible especially if you take into account that GTAV is graphically heavy demanding game and my computer (AMD FX-8350 Eight Core, 16 GB RAM, Radeon R9 270 2GB VRAM) isn't some very powerful gaming rig either.

Medieval Engineers, Space Engineers
Both support full screen window mode. There is slight performance drop when running in full screen window mode but nothing serious. Just a few FPS similar to GTAV

Scrap Mechanic
Haven't noticed any performance difference

X-COM: Enemy Unknown
Haven't noticed any performance difference but since it is turn based game I guess if there is any difference it would be much harder to spot.

These are just some of the more known games who have the borderless full screen window mode available in the options menu. But there are also others which might require starting game with additional command parameter or manually editing game settings files.

[Ñuño Martínez]

(Ñuño Martínez (http://www.pascalgamedevelopment.com/member.php?854-%D1u%F1o-Mart%EDnez) will probably say Allegro ;D).

Rickmeister knows me very well. ::)

Allegro (http://allegro-pas.sf.net/) is just an alternative to SDL. It does everything SDL does but in a different way. That's all. I like it more than SDL so that's why I use and recommend (and support) it.

Anyway, will you continue with Tile Studio (http://tilestudio.sf.net/)? It would be great to make it work on Linux. ;)

[Wiering]

I remember Allegro from a long time ago. Unfortunately, I'm having a lot of trouble getting my game to work in Lazarus due to the huge amount of inline assembly.

However, I did get Tile Studio to work, sort of. It's still far from usable, but it actually started.

http://www.pascalgamedevelopment.com/attachment.php?attachmentid=1449&stc=1

I'll add it to github once the worst bugs are fixed.

[Ñuño Martínez]

I remember Allegro from a long time ago. Unfortunately, I'm having a lot of trouble getting my game to work in Lazarus due to the huge amount of inline assembly. Allegro.pas fixes that. 8)

Glad to know you're working with TileStudio. Keep up the good work.

[Wiering]

Hi Everyone,

Sorry for resurrecting an old thread, but I started working on this again and want to finally get this game on to Steam.

I was eventually able to get the fake fullscreen working, so thanks SilverWarior for suggesting that!

I wasn't able to port the game to lazarus (too much assembly and other hacks that sadly don't work in lazarus), so I'm sticking with Delphi 5.

Now I need to change the MIDI sound into streamed audio (.ogg or .mp3), which is unfortunately not supported by UnDelphiX.

So does anyone have a suggestion on what library to use? It doesn't have to do much other than play background music (looping without gap), should sometimes suddenly change into a different song (my songs have 2 different endings). Should be free (but not GPL) and work in Delphi 5.

[SilverWarior]

Hi!
Have you checked BASS Sound Library from https://www.un4seen.com/
It can be used for free as long as you are not earning any profit from your project. But for commercial usage you need to purchase one of the valid licenses.

The thing that I love about BASS is that it has support for lots of sound formats even including support for playing Module music files.
Another great thing about BASS Sound Library is that it supports wide array of platforms. While this might not seem very important to you since using Delphi 5 you are basically limited only to Windows platform. But it can still be an advantage because if in the future you chose to use some moder version of Delphi to try and develop another game for some other platforms as well you will already have good knowledge of using sound library that supports that platform.

The only thing is that I'm not sure if BASS sound library still support so old Delphi versions as Delphi 5. But since it is free to use for non-commercial use I strongly suggest you give it a try.

EDIT: BASS Sound Library is compatible with FreePascal so if in the future you decide to switch from Delphi to FPC/Lazarus you can keep using the same library.
http://wiki.freepascal.org/Multimedia_Programming#BASS

[JC_]

Most used is probably OpenAL because it's freeware.

[Wiering]

Hi!
Have you checked BASS Sound Library from https://www.un4seen.com/
It can be used for free as long as you are not earning any profit from your project. But for commercial usage you need to purchase one of the valid licenses.
Thanks for the suggestion, however the reason I'm bringing the game to Steam is to sell it, so that would be commercial use.


Most used is probably OpenAL because it's freeware.
Thanks, that's probably the best option then. I found http://www.noeska.com/doal/ and already got sound playing on Delphi 5, now just to figure out how to get it to repeat a stream.

Anyway, do you guys have any games on Steam? If so, what parts did you implement?
I'm wondering whether to do global leaderboards or not. I used to have them in my Flash games and they got hacked all the time.
In my last game I only implemented achievements, spent quite a lot of time on them, but it looks like very few people are trying to unlock them, the easiest one (that anyone who gets half way through the first level should get) only has 60%! Makes me wonder if people who buy the game actually play it?

[laggyluk]

Anyway, do you guys have any games on Steam?

I was planning to get my current project on steam when finished but I'll probably just stick to itch.io.
For some time now you have to pay 100$ to publish on steam even if it's a free game..

[Wiering]

I was planning to get my current project on steam when finished but I'll probably just stick to itch.io.
For some time now you have to pay 100$ to publish on steam even if it's a free game..

Yes I know, I just payed it for my next game. But I think it is worth the exposure, last time I earned those 100$ back in the first month.

Good to see that itch.io can now handle EU VAT (with the Collect & Pay Later model).

[Ñuño Martínez]

Hi Everyone,

Sorry for resurrecting an old thread, but I started working on this again and want to finally get this game on to Steam.

I was eventually able to get the fake fullscreen working, so thanks SilverWarior for suggesting that!

I wasn't able to port the game to lazarus (too much assembly and other hacks that sadly don't work in lazarus), so I'm sticking with Delphi 5.

Now I need to change the MIDI sound into streamed audio (.ogg or .mp3), which is unfortunately not supported by UnDelphiX.

So does anyone have a suggestion on what library to use? It doesn't have to do much other than play background music (looping without gap), should sometimes suddenly change into a different song (my songs have 2 different endings). Should be free (but not GPL) and work in Delphi 5.Delphi 5 is pretty old. Did you tried Tokio? There is the free starter edition at Embarcadero's website. I installed it recently and has some differences with the old Delphi I know (I got stuck with Delphi 6) but it is not hard to upgrade my knowledge (but it is being a bit tricky to make my Allegro wrapper compatible with it though).

Glad to see you're still fighting!

[Akira13]

It's way, way harder to update an old Delphi app to a new version of Delphi than it is to update it to Lazarus, for what it's worth. I'm willing to bet there are most likely non-assembly alternatives to what Wiering is trying to do nowadays, though. Hard to say without seeing the code.

[Wiering]

Delphi 5 is pretty old. Did you tried Tokio? There is the free starter edition at Embarcadero's website. I installed it recently and has some differences with the old Delphi I know (I got stuck with Delphi 6) but it is not hard to upgrade my knowledge (but it is being a bit tricky to make my Allegro wrapper compatible with it though).

Glad to see you're still fighting!

I know, and I was able to get it to work in the starter edition. However, that "free" starter edition requires you to buy the full version if your company makes more than $1000 in a year (not from use of Delphi, but in total), which is ridiculous, so I'm staying with Delphi 5.

[Wiering]

It's way, way harder to update an old Delphi app to a new version of Delphi than it is to update it to Lazarus, for what it's worth. I'm willing to bet there are most likely non-assembly alternatives to what Wiering is trying to do nowadays, though. Hard to say without seeing the code.


Here is a little example: I stored most of my data as assembly (example: parameters for a level background):



procedure BackGrParP1b; assembler;
asm
db 1 { StaticBackGrObj }
db 52, 77, 24, 20; dd SUNB01

db 9 { BackDraw }
db 100, $C9; dw PKD; dd BIGPLANTpck; db $CD
db 30, $86 + $10; dw PKD; dd PALMBACKPK0; db 0
db 42, $86 + 32 + $10{, 16, 58;} dw PKD; dd PALMBACKPK1; db 0
db 100, $90 + $10; dw PKD; dd PALMBACKPK0; db 0
db 112, $90 + 32 + $10{, 16, 48;} dw PKD; dd PALMBACKPK1; db 0
db 40, $D0; dw PKD; dd BIGPLANTpck; db $CD
db 100, $D8; dw PKD; dd BIGPLANTpck; db $CC
db 200, $C0; dw PKD; dd BIGPLANTpck; db $CD
db 40, $D4; dw PKD; dd BIGPLANTpck; db $CD

db 0 { FromPalTo }

db 4 { RandomPixels }
dw 1; db 0, $0F, 0, 1, $F1
dw 2; db 0, $1F, 0, 1, $F0
dw 1; db 0, $2F, 0, 1, $F1
dw 2; db 0, $3F, 0, 1, $F0
...
end;

That was ideal, because that way you don't have to define any data structure for it and you can easily have variable sized sections and not waste any bytes.

Also all sprites were saved like that, but I could easily convert those into arrays of bytes.

When I try to use this in Lazarus, I get a SIGSEGV exception, probably because this is all compiled into the code segment and I'm trying to use it as data.
(I thought of using the Delphi version to save all of these things as data, but it wouldn't work for the Pointer values).

Also, I have many thousands of lines of assembly code, all drawing stuff that needed to be fast. And I haven't found any good documentation of how the Lazarus assembly works.

Actually I did get the game to work somewhat in Lazarus by commenting out everything that requires assembly or these data structures and by rewriting one sprite drawing function to Pascal code (you only see a black screen and a few sprites and it is already terribly slow).

[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]

If any of you would like to try out the beta version on Steam, you can use one of these codes:

1: KLBK0-EEBAZ-2NN9P
2: KEX06-G5NXN-N2RKI
3: FNCX0-Z9CRH-FI40F
4: FZ69E-4I3JV-E8PEQ
5: 5054H-8266W-53K6E
6: WCN5J-RDHVZ-G830K
7: GKM9A-G4FCW-PVP3R
8: Z5G8C-Z9A98-7P24F
9: C3IXL-0Z05Z-XT0BJ
10: TL4M6-P04HV-G30JA

If you claim one, please reply with the number, so other people know which ones are still available.

Please let me know if you run into any problems or if you have any remarks or suggestions about the game.

Trailer: https://www.youtube.com/watch?v=VXIFOcOHIHM

[SilverWarior]

Hi!
I have claimed 1. code

EDIT: I do have a problem. The game seems to be running on steroids. It is like when you take one of those old DOS based games and run it on a modern computer.

[Wiering]

EDIT: I do have a problem. The game seems to be running on steroids. It is like when you take one of those old DOS based games and run it on a modern computer.

Thanks, that is interesting, what kind of video card do you have?
Could you try Options, View, Graphics, DirectX?
Otherwise, if you go to windowed mode (Alt+Enter) there is menu at the top and you can choose Game, Slow Down.

[JC_]

Hello,

I have second code.

DirectX speed is ok, OpenGL not.

Game isn't bad, I like this decent style and graphics is ok.

some hints
- graphics/zoom level is maybe too big
- music is bit stereotypic
- scrolling, moving, jumping isn't 100% smooth, e.g. cloud effect on background - effect itself is nice but there is tearing
- game over effect is weird
- text can be badly readable for kids, pixelatization isn't great for it

If you have game speed limited by VSync it's not good approach, you can use some fixed limit for game update/logic or another solution.

[Wiering]

Thanks for trying it out!

I just updated the game with a new version that checks if enough time has passed since the last frame in OpenGL mode. Could you please try if that makes it playable?

@JC_, thanks for your hints, however this game was originally written in 1998-2001, first intended for DOS, later I added a kind of "emulation" layer for Windows, internally it is still using 320x200 mode with a 256 color palette. I would do many things differently if I wrote the game from scratch now (and I'm working on Charlie III). But here I'm just trying to get my old game onto Steam.

BTW: during the game you can Ctrl+Shift+R to show the framerate.

[JC_]

Still same and I'm not sure if new version was downloaded, put some version info there. OpenGL shows around 350 FPS, DirectX 60 FPS.

[SilverWarior]

I just updated the game with a new version that checks if enough time has passed since the last frame in OpenGL mode. Could you please try if that makes it playable?

When ran in OpenGL the gam is still way to fast. In OpenGL the game is actually running with 290 FPS while in DirectX the game is running nicely with 60 FPS.
So now either your waiting code doesn't work or there is an error somewhere in your math.

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

[Wiering]

Thanks, I can now test this at home by changing the video card settings and I finally got it to work.

I was using wglSwapInterval(1) and it never seemed to work, but I was just calling it once after OpenGL initialization. Now I call it every frame just before SwapBuffers() and it works great!

[Chebmaster]

Good game loop :
Yes, But:
If you do too much stuff it may not cost much immediately but get cached in the command buffer instead and lead to swap stretching over the frame limit and wait until the end of the next frame (BAD!).
So you have to monitor for such accidents and decrease the amount of "do stuff" accordingly if that stuff includes uploading hi-res LODs in the background.


I learned this the hard way and I (maybe, wrong) "do stuff" *before* issuing rendering commands and just let this homeostatic system of waiting swap and my auto-balancer system stabilize FPS for me. I even have an alternate mode when v-sync is disabled and the auto-balancer simply keeps increasing load until FPS drops to about 80. Leads to funny cases like rendering an empty scene in 6k FBO before downsampling to back buffer, cooling fans roaring like wild beasts and so on.

In short, it is up to you :p

[Chebmaster]

P.S. I am thinking of switching to a hybrid system where xxxSwapInterval(1) is called once per N frames (I think, 5 or 10) while the rest of the time the loop tries to adhere to the timing using micro-sleeps (hello, TimeBeginPeriod(1), you ugly freak) and can measure SwapBuffers()+glFinish() duration freely, thus getting real results not contaminated with v-sync wait times.

[phibermon]

It shouldn't be the case that you need to call xxxSwapInterval more than once for each context but clearly it works for you. The overhead is likely negligible but it might be worth timing how long that call takes just in case you need to manage it.

I totally agree and I believe you're quite right as far as what I personally know goes - handling v-sync in this way requires that you know how long your operations take, how long they could take etc

But dropping a frame isn't the end of the world - the nice thing is that if it looks like you're going to miss your window? you can skip over all of the rendering and then use all the time to catch up for the next window - or even better, start rendering the frame after the one you're about to drop - if the scene is very complex and you're only going to get 30 FPS anyway - then implementing it like this automatically gives you an optimal solution for when the refresh rate of the display can't be matched.

Don't think of a loop that runs 60 times a second - instead think of it like a WW1 bi-plane gun firing through the spinning propeller - its not in sync with the insane spinning - it just fires whenever both the gun is ready and the propeller is ready - it's firing as fast as possible regardless of how fast the propeller is spinning (refresh rate) or the rate of fire of the gun (frame rate)

You don't want this to happen a lot or you may get perceptibly visible stutters in the output - but by calculating a safe 'overhead' over the lifetime of your scene - while you miss out on time you could of used - you can basically turn such potential frame dropping into an initialization process.

Yeah - it's not simple and the more time you want to save, the more likely you are to drop a frame - 50 explosions and thousands of particles suddenly bursting into existence isn't the kind of thing you can predict or that you want to increase your overhead to manage - I guess no matter how hard you try - dropping frames is a possibility.

But given that the approach covers both the best case scenario (60fps, never miss a window, silky smooth graphics) and lesser cases (eg 30fps, miss every other window, minimal stutter) then I personally feel it's a good choice :)

It is important however that such an approach covers very poor performance - let's say we can only manage 10fps - assuming we will get 60fps and then skipping a window when it looks like we won't? may not lead to efficient management of the time available. I believe it is prudent to have some form of mechanism that says :

"ok, we're definitely going to miss the next 5 windows, so instead of trying to hit each one and then giving up, let's just use all the time to ensure we hit the 6th"

So I guess variables that keep track of 'desired frame rate', 'predicted frame rate', 'actual frame rate' and then logic that acts accordingly. We've not touched on LOD schemes but for anybody reading? it goes without saying that being able to manage the level of detail in each frame dynamically lends itself very well to such a design. You don't want everything to collapse to cubes when a hundred explosions go off just to keep your framerate - but you want something along those lines. Quality settings should be a thing of the past, instead we should have a desired frame rate and the quality is the best it can be while still meeting your demand. (In fact I distinctly remember an old DOS nascar style game where you did exactly this - can't remember what it was but clearly they were ahead of their time)

(EDIT : it was "NASCAR Racing" - so I didn't forget the title - it just basically didn't have a title ;) )