![]() |
|
Renderer Support Info - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Expanding Horizons (Libraries) (https://qb64phoenix.com/forum/forumdisplay.php?fid=21) +---- Forum: Unseen Machine (https://qb64phoenix.com/forum/forumdisplay.php?fid=64) +---- Thread: Renderer Support Info (/showthread.php?tid=4249) |
Renderer Support Info - Unseen Machine - 12-22-2025 Save this as "GDK_PC_Info.h" in youre Qb64 folder Code: (Select All)
and then run this to see what (and to what degree) your system supports GL/Dx/Vulkan Code: (Select All)
This is a "Dumbed down" rendition of how GDK gets the info to set it rendering mode. Unseen RE: Renderer Support Info - TempodiBasic - 01-03-2026 Ok I try to follow you... I copy and save the GDK_PC_Info.h in QB64pe43 folder and then I make a subfolder Unseen and in this I save the second codebox with the name Test_Graphic_demo.bas. And i got this error C++ compilation failed (check ./internal/temp/compilelog.txt) and TADA here it is! but I am not able to understand why an internal header file can cause this error? Code: (Select All) g++ -no-pie -std=gnu++20 -fno-strict-aliasing -Wno-conversion-null -DFREEGLUT_STATIC -I./internal/c/libqb/include -I./internal/c/parts/core/freeglut/include -I./internal/c/parts/core/glew/include -DDEPENDENCY_NO_SOCKETS -DDEPENDENCY_NO_PRINTER -DDEPENDENCY_NO_ICON -DDEPENDENCY_NO_SCREENIMAGE internal/c/qbx.cpp -c -o internal/c/qbx.oRE: Renderer Support Info - Petr - 01-03-2026 Because you are Linux user? Or not? RE: Renderer Support Info - Unseen Machine - 01-03-2026 Doesnt need the subfolder, just put the .h straight in to your qb64 folder. But as Petr says...if your on linux, this aint gonna work as it uses the windows API to get the information. Thanks John RE: Renderer Support Info - TempodiBasic - 01-05-2026 OK I have tried also without a folder... the same result. Yeah thanks for replying on my procedure mistake! I have assumed that the code was for all the OSes and not esclusive of Windows of Microsoft. In my mind I have thought that windows.h was the header for a library of a windowing system, and not for Windows of Microsoft. LOL now I can say that C++ compiling error is a good result, here we are in DebianLinux. .... only two things to add to this my post: 1. Thanks for replying @Petr, @Unseen 2. putting in the point of view of a BASIC coder, is there anywhere a library not relying on OS and getting the same results? OpenGl and Vulkan are OS indipendent... RE: Renderer Support Info - Petr - 01-05-2026 @TempodiBasic The main issue is whether the library was designed from the start with multi-platform support in mind. On Windows, libraries (DLLs) typically depend on Windows internals and the Windows API, and they link against Windows system DLLs. On Linux, shared objects (.so) usually depend on other packages and system components that must be installed on the target system (often via the package manager). Each OS has its own runtime environment and binary formats, and they are not mutually compatible. On top of that, there are 32-bit and 64-bit builds. That can affect things like structure layout/alignment, pointer sizes, and calling conventions / ABI details. So if the C/C++ code was written with these differences in mind (using proper abstraction layers, conditional compilation, and a stable API/ABI boundary), then yes: you can have one C/C++ codebase and build different binaries from it — e.g. a 32-bit DLL and a 64-bit DLL on Windows, and a 64-bit .so on Linux (32-bit Linux is largely being phased out today, so many projects no longer target it). That said, for clarity and maintainability, platform-specific parts usually end up separated (at least in different source files), even if the project is “one library”. Example why a single binary can’t just be “OS independent”: you want a graphics program. If it creates and manages a window on Windows, you call the Windows API. If it creates a window under Linux/X11, there is no Windows API — you use X11 (or Wayland, SDL, GLFW, etc.). Same OpenGL rendering on top, but the window/context creation layer is OS-specific. RE: Renderer Support Info - TempodiBasic - 01-05-2026 Hi thanks Petr for the time and the patience for showing me where OS and Graphic card system (OpenGL or Vulkan ) meet to work together. In the used way the QB64pe works via C/C++ fundaments and so it goes down towards the hardware and the way of managing it (specific OS features ). I make a mistake to think of QB64pe like a ship over the sea (as other languages first Java), instead it must be thought as a submarine that must take front of all those things that are under the hood. |