- Forum
- Lounge
- What windows/gui library?
- Page 2
What windows/gui library?
| At the onset it is probably better I look at a cross-platform library (hence ImGui) |
I'm gonna be blunt.....
You have the situation reversed. You are buying a vehicle based on some cool feature you've only read about. No test drive or full feature comparison done.
You should learn how your development OS does GUI first. Yes, that means getting a good grasp of the WinAPI. You don't need to go spelunking around into every nook and cranny, that would be more effort than its worth.
Cooperative operating systems Windows or MacOS do things differently than earlier OSes like MS-DOS.
MS-DOS is a single use/task OS. When you run a program the app has total control over the computer's resources until the program terminates.
Windows is a multi-tasking cooperative OS, it can run multiple apps at once, sharing the CPU. Windows gives each running app a slice of time to execute. Windows also controls access to system resources, apps have to request memory or to use the printer, etc.
Most WinAPI apps are idle until they are informed of any possible events they might need to process. Such as a mouse click within the app's window or a button clicked, etc. That arcane flummery known as Windows Messages.
In the Before Time, before Windows, when an app wanted to print something the app had to have code to directly access the printer written into the code. That approach limited the hardware that could be used with apps. Either the programmer had to know the details of interacting with a wide variety of printers which meant a whole lot of bloat in apps, or restrict the hardware to a select few. The same goes for display devices.
Windows overturned that by introducing device drivers. The hard manufacturer wrote the code that drove the device and that device driver needed to be installed on the PC. The interface between Windows (and running apps) and the hardware was standardized so when a user wanted to print something the app told Windows what to print. Windows passed the info to the device driver to do the grunt work of running the printer. Now an app didn't need to know or care what hardware was installed. As long as a device driver was present the hardware was usable.
With the device driver model consumers could purchase a wide variety of hardware. You can have a simple dot-matrix line printer or an ink-jet or laser printer.
Hardware like monitors don't need a manufacturer created device driver, most follow a generic method for displaying info, so Windows already knows how to "talk" to most monitors.
Something else to consider when choosing a 3rd party GUI library....what are you going to use it for. Creating games mostly or the newest version of SuperCalc?
Form (ie, libraries) follows function.
When you have an idea of what you are going to create most times, and you have a basic understanding of the native GUI of your OS, choosing a GUI library becomes easier. You can compare features. And see if going cross-platform is something you want to support.
There are more than a few times when games and productivity apps that go cross platform the code is written and rewritten to specifically target the OS. Games especially are written for the OS because speed and the look are paramount.
I am NOT trying to say you shouldn't learn to use 3rd party libraries, cross-platform GUI libraries specifically, that should be on your to-do list. Somewhere in the future.
After you get comfortable of what GUI means natively. GUI apps by their very nature are a lot more code intensive than C/C++ console/command-line mode apps.
How Linux or MacOS does their GUI stuff I have not much more than a very brief understanding. What It do know is each system does the work different.
And knowing more than one GUI library would be considered a bonus if/when looking for employment.
The more you know the more a company would consider you someone they'd be foolish not to hire.
Last edited on
Thanks.
I am aware the device drivers are the intermediates between hardware and operating system.
I understand your philosophy of understanding the local Win32 workings first and foremost and then adding 3rd parties.
I am aware the device drivers are the intermediates between hardware and operating system.
I understand your philosophy of understanding the local Win32 workings first and foremost and then adding 3rd parties.
I think it's worth mentioning that you've listed SDL and SFML as GUI libraries. But to me a GUI library implements buttons and scrollbars and text-boxes and tabs -- widgets.
I can tell you for sure that SDL isn't about that. Instead, it merely lets you open up a window and make pixels show up. To contrast, Dear ImGUI only implements widgets: it does not open up windows for you, or let you draw into them - you have to facilitate that for the library on your own.
You've also listed Qt, which does window creation but also implements widgets.
Then you listed Win32, which is basically the entire Windows operating system.
There's such a huge variance in the stuff you've listed, it's not easy to make a comparison.
I think you should pick a project, and allow that project to guide your study.
I don't know of any GUI library which offers enough control to implement Minecraft's in-game UI. It's not even close. I'd be really surprised if the in-game UI wasn't completely custom.
I can tell you for sure that SDL isn't about that. Instead, it merely lets you open up a window and make pixels show up. To contrast, Dear ImGUI only implements widgets: it does not open up windows for you, or let you draw into them - you have to facilitate that for the library on your own.
You've also listed Qt, which does window creation but also implements widgets.
Then you listed Win32, which is basically the entire Windows operating system.
There's such a huge variance in the stuff you've listed, it's not easy to make a comparison.
I think you should pick a project, and allow that project to guide your study.
| Will it show up a lot heavier on a game like Minecraft? |
I don't know of any GUI library which offers enough control to implement Minecraft's in-game UI. It's not even close. I'd be really surprised if the in-game UI wasn't completely custom.
Last edited on
Once again SubZero, you completely ignore most of what I said and focus on something you can sneer at.
I wasn't blunt enough then, I am now.
I'm done with bothering to answer your questions since you whine the advice isn't want you want to see.
I wasn't blunt enough then, I am now.
I'm done with bothering to answer your questions since you whine the advice isn't want you want to see.
George
Your a walking encyclopedia of info and I appreciate your advice and quite the contrary, since I have already taken your advice. I am already buying that "Programming Windows Fifth Edition" book, but that is 1100 pages. I wish I could just read and memorize the book in a month, but that is very unlikely. And you have already convinced me to prioritize Win32 knowledge, but I will have to do it gradually.
There is nothing more that I would love than to start from the beginning and know all of it. But I will start by casting the widest net, in case I want to do something immediately and I can allow the huge Win32 lib to simmer over time. I don't see where I was sneering or whining or not taking advice. Actually, once I get into Win32 I was hoping you could be my go to guy. And I will also probably want to waste some time and create some mini-games with it for practice too and of course I would show it to ya.
I know things such as how device drivers work in general and that there was a time before (early computer days, early 80's & earlier) when the program had to write the code to talk to each hardware. I didn't know that ImGui creates the widgets but NOT the window, so there I am needing Win32 or I can use my SFML (of course former is lighter in weight).
SFML gives you the tools to create custom buttons, but yes they are not widgets. You can create text boxes and even scroll bars using their "View" class. You can create your own widgets, yes they won't be "Windows" or "Apple" widgets exactly, although you can simulate them with effort. Sometimes the creation of these widgets might be easier/faster using Win32 or the openGL lib directly.
SFML has widget lib's too:
https://tgui.eu/
https://en.sfml-dev.org/forums/index.php?topic=6112.0
Qt and WxWidgets are popular in the industry, but some programmers come out and say they dislike the learning curve and even profess to HATE them. So from the beginning I wanted something quick and easy with a larger net, so that I can quickly do something if I need to immediately and I can gradually play with something like Win32 over time. ImGui has code embedded for the various GUI's, so all you have to do is search, copy and paste and modify accordingly.
I believe that ImGui will allow me to QUICKER cast the largest "depending on what your doing" net.
Your a walking encyclopedia of info and I appreciate your advice and quite the contrary, since I have already taken your advice. I am already buying that "Programming Windows Fifth Edition" book, but that is 1100 pages. I wish I could just read and memorize the book in a month, but that is very unlikely. And you have already convinced me to prioritize Win32 knowledge, but I will have to do it gradually.
There is nothing more that I would love than to start from the beginning and know all of it. But I will start by casting the widest net, in case I want to do something immediately and I can allow the huge Win32 lib to simmer over time. I don't see where I was sneering or whining or not taking advice. Actually, once I get into Win32 I was hoping you could be my go to guy. And I will also probably want to waste some time and create some mini-games with it for practice too and of course I would show it to ya.
I know things such as how device drivers work in general and that there was a time before (early computer days, early 80's & earlier) when the program had to write the code to talk to each hardware. I didn't know that ImGui creates the widgets but NOT the window, so there I am needing Win32 or I can use my SFML (of course former is lighter in weight).
SFML gives you the tools to create custom buttons, but yes they are not widgets. You can create text boxes and even scroll bars using their "View" class. You can create your own widgets, yes they won't be "Windows" or "Apple" widgets exactly, although you can simulate them with effort. Sometimes the creation of these widgets might be easier/faster using Win32 or the openGL lib directly.
SFML has widget lib's too:
https://tgui.eu/
https://en.sfml-dev.org/forums/index.php?topic=6112.0
Qt and WxWidgets are popular in the industry, but some programmers come out and say they dislike the learning curve and even profess to HATE them. So from the beginning I wanted something quick and easy with a larger net, so that I can quickly do something if I need to immediately and I can gradually play with something like Win32 over time. ImGui has code embedded for the various GUI's, so all you have to do is search, copy and paste and modify accordingly.
I believe that ImGui will allow me to QUICKER cast the largest "depending on what your doing" net.
If you're going with WIN32 then be prepared to do a lot of internet research - particularly within learn.microsoft.com. Although Petzold's book will give you a good grounding, there's quite a bit which isn't covered (eg createwindowex, treeview control etc etc etc which came out after the book was written).
As an alternative book, there's also:
Win32 Programming by Rector & Newcomer
https://www.amazon.co.uk/Win32-Programming-Advanced-Windows-Rector/dp/0201634929/ref=sr_1_1
As an alternative book, there's also:
Win32 Programming by Rector & Newcomer
https://www.amazon.co.uk/Win32-Programming-Advanced-Windows-Rector/dp/0201634929/ref=sr_1_1
Also regarding WIN32 here's a few notes that may be of interest/help.
WIN32 introduces a whole new set of types (eg DWORD, WPARAM, LPARAM, LPSTR etc) which you need to become familiar. These are documented at:
https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
Note that some of these (eg DWORDLONG) have been introduced since the books were written. The books assume 32bit compile. If you compile as 64bit some of the example code may need changes (eg see George's comments).
Windows.h heavily uses #defines/#ifdef. Important ones are (include before #include <windows.h>:
#define WIN32_LEAN_AND_MEAN
Excludes some of the windows.h stuff from being compiled to help compile times. This excludes APIs such as Cryptography, DDE, RPC, Shell, and Windows Sockets.
#define NOMINMAX
This will prevent the definition of the min and max Windows-specific preprocessor macros which can cause conflict with std::min(), std::max()
Over the years Windows has acquired new functions and additions to existing structs etc. In order for programs to be compiled on one version of windows that can be used on other versions you need to specify the target version of windows to be used using #define _WIN32_WINNT and #define WINVER. See below for what values to be used for which versions of Windows:
https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers
WIN32 code essentially consists of a message loop that calls various functions when events happen. These functions have specified arguments so you can't pass user data between these functions by passing them as params. In books you'll often find many global variables to get around this limitation. This isn't a particularly good way of doing it. When you register a class (nothing to do with C++ classes) you can specify 'extra' bytes that can be used to hold data (eg a pointer to a struct). In this way you can pass data between message functions without using global/static variables. See GetWindowsLong()/SetWindowsLong() for info on usage:
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getwindowlonga
https://stackoverflow.com/questions/14883556/example-to-store-pointer-in-extra-window-memory-of-window-class
Most info is passed using two function parameters WPARAM and LPARAM. Often these contain 'packed' data eg the low 16 bits represent x and the high 16 bits represent y. There are various macros available to 'unpack' these:
LOWORD, HIWORD, LOBYTE, HIBYTE, MAKELPARAM, MAKEWPARAM etc etc
In the same vane, instead of using a large switch statement to handle the messages for a particular window and then decrypting the params, you can use 'message crackers' (#include <windowsx.h> ). These enable a function to be specified for each window message. Makes for much more readable code! Se:
https://www.codeproject.com/Articles/4948/Message-Cracker-Wizard-for-Win-SDK-Developers
Most WIN32 functions come in 2 versions - ending in A for ASCII and ending in W for wide versions. Eg CreateWindowA() and CreateWindowW(). There is also just CreateWindow() which is a macro which uses the UNICODE define to decide which of the W or A versions to use. Also there are the ASCII and wide versions of types eg LPSTR and LPWSTR. There is LPTSTR macro which again uses UNICODE to determine whether LPSTR or LPWSTR should be used.
Have fun!
WIN32 introduces a whole new set of types (eg DWORD, WPARAM, LPARAM, LPSTR etc) which you need to become familiar. These are documented at:
https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
Note that some of these (eg DWORDLONG) have been introduced since the books were written. The books assume 32bit compile. If you compile as 64bit some of the example code may need changes (eg see George's comments).
Windows.h heavily uses #defines/#ifdef. Important ones are (include before #include <windows.h>:
#define WIN32_LEAN_AND_MEAN
Excludes some of the windows.h stuff from being compiled to help compile times. This excludes APIs such as Cryptography, DDE, RPC, Shell, and Windows Sockets.
#define NOMINMAX
This will prevent the definition of the min and max Windows-specific preprocessor macros which can cause conflict with std::min(), std::max()
Over the years Windows has acquired new functions and additions to existing structs etc. In order for programs to be compiled on one version of windows that can be used on other versions you need to specify the target version of windows to be used using #define _WIN32_WINNT and #define WINVER. See below for what values to be used for which versions of Windows:
https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers
WIN32 code essentially consists of a message loop that calls various functions when events happen. These functions have specified arguments so you can't pass user data between these functions by passing them as params. In books you'll often find many global variables to get around this limitation. This isn't a particularly good way of doing it. When you register a class (nothing to do with C++ classes) you can specify 'extra' bytes that can be used to hold data (eg a pointer to a struct). In this way you can pass data between message functions without using global/static variables. See GetWindowsLong()/SetWindowsLong() for info on usage:
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getwindowlonga
https://stackoverflow.com/questions/14883556/example-to-store-pointer-in-extra-window-memory-of-window-class
Most info is passed using two function parameters WPARAM and LPARAM. Often these contain 'packed' data eg the low 16 bits represent x and the high 16 bits represent y. There are various macros available to 'unpack' these:
LOWORD, HIWORD, LOBYTE, HIBYTE, MAKELPARAM, MAKEWPARAM etc etc
In the same vane, instead of using a large switch statement to handle the messages for a particular window and then decrypting the params, you can use 'message crackers' (#include <windowsx.h> ). These enable a function to be specified for each window message. Makes for much more readable code! Se:
https://www.codeproject.com/Articles/4948/Message-Cracker-Wizard-for-Win-SDK-Developers
Most WIN32 functions come in 2 versions - ending in A for ASCII and ending in W for wide versions. Eg CreateWindowA() and CreateWindowW(). There is also just CreateWindow() which is a macro which uses the UNICODE define to decide which of the W or A versions to use. Also there are the ASCII and wide versions of types eg LPSTR and LPWSTR. There is LPTSTR macro which again uses UNICODE to determine whether LPSTR or LPWSTR should be used.
Have fun!
Last edited on
I have ordered both the Petzold & Rector books, as they were both cheap enough and I want them in my library as I am getting more into C++. This will be a huge sandbox!
Thanks seeplus, another very valuable thread from you fellas and this seems like very important info, along with George's info (to use things like LoadImageW/LoadIconW...etc). I save copies of my threads and go back to re-read them at times, and this one has loads of new info for me.
How do you treat these books and how much have you memorized vs referencing? Would you fellas say you know 25% of the book and can code without looking and have to reference 75%, or 50/50? For things like gui, one can review the book and code the windows/gui and then work on the same project for 2-5 years...not seeing the gui coding for many months on end.
And of course if Bjarne uses FLTK in his class and book and its relatively easier to pickup, that it is on my mind too. I cannot do it all at the same time though, but I am going to want to peek.
Thanks seeplus, another very valuable thread from you fellas and this seems like very important info, along with George's info (to use things like LoadImageW/LoadIconW...etc). I save copies of my threads and go back to re-read them at times, and this one has loads of new info for me.
How do you treat these books and how much have you memorized vs referencing? Would you fellas say you know 25% of the book and can code without looking and have to reference 75%, or 50/50? For things like gui, one can review the book and code the windows/gui and then work on the same project for 2-5 years...not seeing the gui coding for many months on end.
And of course if Bjarne uses FLTK in his class and book and its relatively easier to pickup, that it is on my mind too. I cannot do it all at the same time though, but I am going to want to peek.
| Would you fellas say you know 25% of the book and can code without looking and have to reference 75%, or 50/50? |
When I do Windows coding I keep learn.microsoft.com open on one display with VS on another. I sort of know what I want to do (I've programmed windows since 16 bit v3.0) but need learn for how to actually call the functions. what they return, what messages are posted by controls etc etc. I don't even try to remember all that sort of stuff. There used to be huge books that detailed these API's but of course with the internet you don't need them any more. See:
https://www.amazon.co.uk/Windows-Programming-API-Bible-Programmers/dp/1571690093/ref=sr_1_3 (1416 pages!)
| How do you treat these books and how much have you memorized vs referencing? |
If you use it enough, you remember it. If you don't use it enough, you look it up when you need to.
The most important part is understanding it such that looking it up is not about learning it, but just to recall it.
There's no point in learning every nook and cranny of creating a GUI unless that's what you want to be doing all the time. Otherwise, you learn enough to create what you need to create.
| listed SDL and SFML as GUI libraries |
They aren't GUI -- Graphical User Interface -- libraries. They are multimedia libraries designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware with a simplified interface. Bindings are available in several programming languages.
SDL is Simple DirectMedia Layer.
SFML is Simple and Fast Multimedia Library.
Multimedia might be "graphical", it doesn't have to be depending on the uses, but it certainly is not a graphical user interface of windows, buttons and menus.
Windows already has multimedia libraries built-in. The GDI and the multi-media library that work best in a windowed app and DirectX designed for doing full screen games.
Going with a mm library like SDL and SFML is used for writing code that is cross platform. Though it doesn't create well-optimized mm apps as can be achieved using the OS built-in capabilities. Most professional games that are ported from one OS to the other are usually rewritten to use the system's core mm routines.
That is reassuring, knowing that experienced programmers need their references. As I am getting more into it, I am finding it top heavy and realizing that I cannot memorize everything immediately. There will be times that I won't touch upon a subject for months.
I started reading a few months ago just to dabble, but the more I looked leisurely the more obsessed I find myself becoming...I partly blame you guys for inspiring me :)
George, yea I understand that they are not Windows GUI's per se, but essentially you can GUI'fy anything using the library. Both SDL & SFML are openGL under the hood. I don't know how much of Win32/WinAPI is upgraded for DirectX or Vulkan (if any) and I don't know anything about GDI(gotta look it up & I gotta run out now to help fam). I could understand if GDI is using either of the two graphics card technologies that they would be faster than SDL & SFML. I also understand/believe when seeplus says that the usage will be dependent on the case and might not be befitting for SDL/SFML.
What I don't understand is this, if Win32/API are not upgraded and parts might not be using direct to graphics card advantage, then shouldn't SDL/SFML be a better usage case?...of course GDI tops the aforementioned from the sound of things. If Win32/API are upgraded, then I understand.
George, what is the MOST visually impressive game that you have seen with Win32/API? Does not have to be 3D, at least something like a modern DKC. Does Win32/API do 3D graphics (I know DirectX for Windows/XBox does) as well, or only 2D?
Actually the whole point of this thread was for me to play catch up on these technologies, which was on the to do list for a while now. I know more than I did 2 days ago where I thought C++/CLI (Common Language Infrastructure) was just C++ with a library, but come to find out it is a language on its own. I am discovering and putting the pieces together.
I started reading a few months ago just to dabble, but the more I looked leisurely the more obsessed I find myself becoming...I partly blame you guys for inspiring me :)
George, yea I understand that they are not Windows GUI's per se, but essentially you can GUI'fy anything using the library. Both SDL & SFML are openGL under the hood. I don't know how much of Win32/WinAPI is upgraded for DirectX or Vulkan (if any) and I don't know anything about GDI(gotta look it up & I gotta run out now to help fam). I could understand if GDI is using either of the two graphics card technologies that they would be faster than SDL & SFML. I also understand/believe when seeplus says that the usage will be dependent on the case and might not be befitting for SDL/SFML.
What I don't understand is this, if Win32/API are not upgraded and parts might not be using direct to graphics card advantage, then shouldn't SDL/SFML be a better usage case?...of course GDI tops the aforementioned from the sound of things. If Win32/API are upgraded, then I understand.
George, what is the MOST visually impressive game that you have seen with Win32/API? Does not have to be 3D, at least something like a modern DKC. Does Win32/API do 3D graphics (I know DirectX for Windows/XBox does) as well, or only 2D?
Actually the whole point of this thread was for me to play catch up on these technologies, which was on the to do list for a while now. I know more than I did 2 days ago where I thought C++/CLI (Common Language Infrastructure) was just C++ with a library, but come to find out it is a language on its own. I am discovering and putting the pieces together.
Last edited on
I did some reading about GDI (Graphics Device Interface), which is legacy and dates back to MSDOS. It has the advantage of writing to the monitor and printer in WYSIWYG. It had its issues that would slow it down when more buttons and windows were added to the system, but that improved with each successive Win upgrade (95/98/Vista/XP...). It works with Win32/API. It was replaced by DirectDraw & Direct2D API.
They say it is slower than VulKan, DirectX, AND openGL, which I suspected, but fast enough to just draw windows & gui. I also understand that Win32 and GDI are local to the Windows platform and require less resources than something like SDL/SFML and less coding.
When I first read about openGL and DirectX the article said that they were fast because they directly accessed the supported video cards. Recently I read that they actually work indirectly, the openGL commands get sent to the device drivers, which each manufacturer writes and interprets the openGL command in order to utilize the cards directly. And all this as (GPU/GPU memory usage) opposed to the older sluggish ways of utilizing the CPU/PC memory.
Anyway, it is good to read more on all of this and I will continue with my readings.
They say it is slower than VulKan, DirectX, AND openGL, which I suspected, but fast enough to just draw windows & gui. I also understand that Win32 and GDI are local to the Windows platform and require less resources than something like SDL/SFML and less coding.
When I first read about openGL and DirectX the article said that they were fast because they directly accessed the supported video cards. Recently I read that they actually work indirectly, the openGL commands get sent to the device drivers, which each manufacturer writes and interprets the openGL command in order to utilize the cards directly. And all this as (GPU/GPU memory usage) opposed to the older sluggish ways of utilizing the CPU/PC memory.
Anyway, it is good to read more on all of this and I will continue with my readings.
| Both SDL & SFML are openGL under the hood. |
| I don't know how much of Win32/WinAPI is upgraded for DirectX or Vulkan (if any) |
| I could understand if GDI is using either of the two graphics card technologies that they would be faster than SDL & SFML. |
| George, what is the MOST visually impressive game that you have seen with Win32/API? Does not have to be 3D, at least something like a modern DKC. Does Win32/API do 3D graphics (I know DirectX for Windows/XBox does) as well, or only 2D? |
Much thanks!
I was first reading about openGL online a few months ago and came across references to SFML/SDL and my eyes lit up, as it was said they extract the complexities of openGL away and allow you to create the game quicker. It was also said not to worry since WE WILL BE using openGL indirectly, since both utilized openGL and you can even incorporate openGL. Since then I thought they used OpenGL (only).
From my starting post I meant to say that I started using SFML, not SDL (will change that).
Looks like SDL uses both and is depending on which OS. I know it is said that some aspects of rendering are definitely quicker/more efficient on DirectX, since it was written for Windows/XB/MS portable devices. So I am not too shocked to learn this now. But I also read months ago that openGL can render frames faster than DirectX, so conflicting info there. This is probably dependent on who is saying it and how they are optimizing and doing things as well. So I am learning to read, read, read and eventually I will come to a clearer picture and not always believe the first few things that I come across...which I have clearly done. Problem is that at some point you have to move on and start doing things and then eventually go back to read more.
SDL website:
Looks like SFML avoids DirectX.
"Beginning C++ Game Programming", John Horton (p6)
Thanks for clarifying that. I see constantly that this or that is upgraded to Vulkan, so I thought maybe parts of Win32/API and GDI might get upgrades with DirectX and/or Vulkan. I will check the Win pinball game.
I was first reading about openGL online a few months ago and came across references to SFML/SDL and my eyes lit up, as it was said they extract the complexities of openGL away and allow you to create the game quicker. It was also said not to worry since WE WILL BE using openGL indirectly, since both utilized openGL and you can even incorporate openGL. Since then I thought they used OpenGL (only).
From my starting post I meant to say that I started using SFML, not SDL (will change that).
Looks like SDL uses both and is depending on which OS. I know it is said that some aspects of rendering are definitely quicker/more efficient on DirectX, since it was written for Windows/XB/MS portable devices. So I am not too shocked to learn this now. But I also read months ago that openGL can render frames faster than DirectX, so conflicting info there. This is probably dependent on who is saying it and how they are optimizing and doing things as well. So I am learning to read, read, read and eventually I will come to a clearer picture and not always believe the first few things that I come across...which I have clearly done. Problem is that at some point you have to move on and start doing things and then eventually go back to read more.
SDL website:
| Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. |
Looks like SFML avoids DirectX.
"Beginning C++ Game Programming", John Horton (p6)
| SFML has a module (code) for just about anything you would ever want to do in a 2D game. SFML works using OpenGL, which can also make 3D games. OpenGL is the de facto free-to-use graphics library for games when you want it to run on more than one platform. When you use SFML, you are automatically using OpenGL. |
Thanks for clarifying that. I see constantly that this or that is upgraded to Vulkan, so I thought maybe parts of Win32/API and GDI might get upgrades with DirectX and/or Vulkan. I will check the Win pinball game.
Last edited on
| what is the MOST visually impressive game that you have seen with Win32/API? |
I know using the GDI and the built-in Windows multi-media system doesn't make the most impressive games, nor are the technologies all that good for creating speed and look. That is why MS bought and introduced DirectX.
Different technologies, different levels of sophistication.
Retro 2D games are making a comeback, though. Games that don't require the heft of a desktop PC to run. Games for phones and tablets.
| Does Win32/API do 3D graphics |
Not natively, that requires Direct3D. The same for full-screen. That requires Direct3D. Though 2D graphics are available via Direct2D, a replacement for earlier versions of DirectX that used DirectDraw. It is still possible to use DirectDraw, all the fancy work of 3D is built on top of 2D with a lot of nerdy physics equations and math doing the rendering behind the scenes.
A solitary developer ain't gonna be able to create big name Uber popular games any more, they require lots and lots of money, time and teams of people working on different parts of the game.
The WinAPI ain't designed to do natively modern games. But it can create simple games. They are decidedly lacking in immersive look, speed and sound/music. But one person can spend a couple of weeks/months mashing the code together.
Crafting GDI games does show why DirectX, OpenGL or other multi-media libraries were created for games. No doubt about it.
GDI games were a step-up from what MS-DOS could do. The modern multi-media frameworks are another step up from that. Look at how the look and gameplay changed for each entry in the Ultima series.
Frameworks have their place, whether they are GUI or MM. If I were to create from scratch a game I wouldn't use the GDI or WinAPI MM systems even for a simple 2D side scroller. Knowing what is required to use the GDI and WinAPI MM systems and their limitations gives one an appreciation for the frameworks and what they can achieve.
All those early clunky GDI/WinAPI MM games made people want better looking games, and the technology to do that was created.
| Both SDL & SFML are openGL under the hood. |
Nope, they aren't. Both frameworks can USE OpenGL. A separate graphics technology framework.
For SFML on Windows/MacOS the necessary MM guts are included. Linux distros don't have it, to use SFML on Linux requires additional libraries to be installed.
SDL can use either OpenGL or DirectX. Obviously on MacOS or Linux DirectX is not a pre-installed component.
| what is the MOST visually impressive game that you have seen |
Form follows function, not vice versa. A game should be fun to play regardless of "oooooh, look! Shiny object!" bells and whistles.
I don't consider a visually spectacular game all that impressive if the game play sucks. Or is just plain boring. There are a number of games I've purchased and tried for a couple of hours. And never played again.
Now with the spiraling every upward cost of modern games, coupled with requiring very expensive hardware as minimum requirements to run the beast I don't even bother doing more than looking despite the games are supposed to be really great. I have other luxuries I can spend my income on. Like bills and food, etc.
I still play several older games that have simple graphics/sound/music because they are fun to play and replay.
Just as a GUI app is less about how impressive the interface looks, even a clunky appearing app that does what I want/need is the key.