This AI stuff is SCARY!!!

[Unseen Machine]

Use the power for good and no one needs needs to be scared - be excellent to one another... and party on dudes!

+1 for the bill and ted quote!

[Unseen Machine]

Hmmmm....seems Ai doesnt always agree with itself and has rekindled some hope!

qb64 can only uses the 1,1 stuff so shaders is never gonna happen

Your statement, "QB64 can only use the 1.1 stuff, so shaders are never going to happen," contains a common misconception. While it is true that many of QB64's built-in _GL commands correspond to the older OpenGL 1.1 fixed-function pipeline, it is still possible to use modern OpenGL features like shaders in QB64. The key is to access the graphics library directly, bypassing the built-in 1.1-style commands.
Here's a breakdown of why this is the case and how it changes the approach to the book's chapters.
Why shaders are possible
A C++ compiler backend: QB64 is not an interpreter; it's a transpiler that converts your BASIC code into C++, which it then compiles. This is how it can create native binaries and link with external libraries.
External libraries: You can use the DECLARE LIBRARY statement to access functions from external DLLs on Windows or shared objects on Linux and macOS. This means you can call any modern OpenGL function, including those for shaders, as long as you properly declare them.
Compatibility contexts: Modern graphics drivers still support older OpenGL 1.1 code through "compatibility contexts". This is what allows the QB64 built-in _GL commands to work. But because you can access the underlying library directly, you can also set up a modern "core profile" context to use all the new features.

Thoughts???

unseen

[madscijr]

As long as it isn't hallucinating - I have found Gemini sometimes like to invent commands! 
Like today it wrote some number formatting code using a _FORMAT command it was sure was an out-of-the-box QB64PE command!

[SpriggsySpriggs]

With something like QB64, unless you are using an AI trained specifically for QB64, you will almost always have hallucinations. The standard Gemini doesn't know enough about QB64 code or syntax to provide anything useful. It knows that QB64 can use more modern stuff, it knows you can use external libraries, and it knows that more modern keywords are given an underscore. So, it decides to make up stuff. That's why I like using NotebookLM for this kind of thing. Its scope is way smaller than Gemini. It only really knows about what you give it and will flat out give up trying to respond if it can't find anything in the sources to help. Gemini is best used for things that are common or popular, so it has a higher chance of knowing how to respond. NotebookLM is best used for things that are more niche. I once tried making a Gemini Gem (similar to a custom GPT) but it only allows 10 sources and it does not strictly adhere to any rules, just like ChatGPT's custom GPTs.

[madscijr]

I've had pretty good luck with Gemini and QB64PE, when it's more generic stuff like arrays and logic. If I know we'll need any special QB64PE commands, I'll try and include the wiki page URLs. It often gets them right but sometimes forgets the initial underscore, so you just have to paste the  code into the IDE and fix the errors that pop up.

I'll look up that NotebookLM.

[Unseen Machine]

For anyone who's a DEV or interested apparently tweaking QB64 to allow modern GL rendering natively(at least in windows) might not be quite so far fetched an idea

That is an entirely viable and very common "out the box" idea when interfacing different libraries! You are correct: if you can get the HWND (Window Handle) that QB64-PE creates, you can use that handle to initialize your own OpenGL rendering context (or even a DirectX context) and perform modern graphics operations within that existing window.
This approach is how many extension libraries integrate with established host environments.
The Plan: Get the HWND from QB64
To make this work, you need a way for your C++ library to access the HWND that the QB64-PE runtime generates.
1. The "Exported Function" Approach (Recommended for your current setup):
The simplest way within your current architecture is to have QB64 pass its HWND to your C++ DLL after the QB64 window has been created.
Step A (C++): Add an exported function to receive the HWND.Add a function to your C++ library that accepts the HWND as a parameter and stores it in your global hwnd variable:
cpp
// In your C++ code (.h or .cpp file)
extern HWND hwnd; // Make sure this global variable exists

__declspec(dllexport) void GL_SetExternalHwnd(long long external_hwnd) {
    // Cast the long long back to an HWND type
    hwnd = (HWND)external_hwnd;
}
Use code with caution.

Step B (QB64): Call the C++ function.Add this declaration to your QB64 DECLARE LIBRARY block:
vb
' In QB64 DECLARE LIBRARY block
SUB GL_SetExternalHwnd (windowHandle AS _OFFSET)
' or use LONG if _OFFSET isn't available in your version:
' SUB GL_SetExternalHwnd (windowHandle AS LONG)
Use code with caution.

Then, in your QB64 main loop, you would call this after the screen mode is set:
vb
SCREEN _NEWIMAGE(800, 600, 32) ' Create the window

DIM sharedHWND AS _OFFSET ' Use _OFFSET for 64-bit safe pointers/handles
sharedHWND = _WINDOWHANDLE ' Get the handle from QB64

GL_SetExternalHwnd sharedHWND ' Pass the handle to your C++ DLL

' Now your C++ functions can use that 'hwnd' variable
Use code with caution.

2. The "Global Variable" Approach (Less robust):
If both your C++ DLL and the QB64 executable can access the same memory space for a specific global variable (which can be complicated to set up correctly across DLL boundaries), you might share the handle directly. The exported function approach above is much more reliable.
Doing Modern GL with the Shared HWND
Once your C++ library has the correct HWND, you can use standard Windows API calls within your C++ functions to set up a modern OpenGL context using WGL (Windows GL) functions.
You've already started this in your GL_Screen_New function:
cpp
    // ... Inside a C++ function where 'hwnd' is now the shared handle ...
    hdc_global = GetDC(hwnd);
    // ... setup PFD (Pixel Format Descriptor) ...
    hglrc_global = wglCreateContext(hdc_global); // Create the GL context
    wglMakeCurrent(hdc_global, hglrc_global);  // Make it current

    glewExperimental = GL_TRUE;
    glewInit(); // Use GLEW/GLAD to load modern GL functions (e.g., glGenVertexArrays)
Use code with caution.

Conclusion: This "out the box" idea is a solid engineering approach. You use QB64 as the host application framework while offloading the heavy lifting of modern graphics rendering to your C++ DLL.
AI responses may include mistakes. Learn more



and that way we could still use the built in qb64 keyabord.mouse etc...
That is correct and is one of the primary advantages of this approach. By obtaining the HWND from QB64 and using it to initialize your OpenGL context in C++, you successfully share the window management responsibilities.
Benefits of this Hybrid Approach
Shared Input System:
QB64 handles the Windows message loop internally. When a user presses a key or moves the mouse, the QB64 environment processes those WM_KEYDOWN, WM_MOUSEMOVE, etc., messages and updates its internal variables (like MOUSEX, MOUSEY, _KEYHIT, etc.).Since your game logic can query these built-in QB64 variables, you don't need to write a secondary input handling system in C++ (though you have one partially implemented in your WindowProc, which is also fine).
Shared Window Management:
QB64 manages the window creation, basic resizing, and interaction with the operating system taskbar/desktop environment. Your C++ code simply attaches to that existing window to perform specialized rendering tasks.
Modern Rendering with Legacy Host:
You get the ease of use and familiarity of QB64 for game logic, UI, and input, combined with the power of modern OpenGL for advanced 3D graphics, shaders, and performance-critical operations done in C++.
This setup provides a highly functional and robust bridge between the two environments, allowing you to use all the built-in features of QB64 while incrementally building a modern graphics library.

So in short, it may be possible...and weed not loose any normal functions either!

John

[SpriggsySpriggs]

Gemini 3 just released yesterday and it's already been a huge help for several things that would eat up my time. It generated a script that fixed my keyboard mapping permanently with a very minimal prompt.

Code: (Select All)

#!/bin/bash
# Script to fix Azio Keyboard Function Keys on Linux
# Author: Zachary Spriggs (Generated Assistant)
# Description: Forces hid_apple driver to use F-keys as default instead of media keys.

if [[ $EUID -ne 0 ]]; then
   echo "Error: This script must be run as root."
   echo "Usage: sudo ./fix_azio_keys.sh"
   exit 1
fi

echo "[-] Detected Azio/Mac-layout keyboard issue..."

# 1. Apply Immediate Runtime Fix
# Many Azio keyboards use the Apple HID driver. We force 'fnmode=2' (F-keys first).
if [ -d "/sys/module/hid_apple/parameters" ]; then
    echo "[-] Setting runtime parameter fnmode=2..."
    echo 2 > /sys/module/hid_apple/parameters/fnmode
    echo "[+] Runtime fix applied. Test your F-keys now."
else
    echo "[!] hid_apple module not currently loaded. It may load on reboot."
fi

# 2. Make Fix Permanent (Modprobe Config)
CONFIG_FILE="/etc/modprobe.d/hid_apple.conf"
echo "[-] Creating permanent configuration in $CONFIG_FILE..."

# 'iso_layout=0' fixes swapped key issues (like < and >) on some models
# 'fnmode=2' defaults to F1-F12 function keys
echo "options hid_apple fnmode=2 iso_layout=0" > "$CONFIG_FILE"

echo "[+] Configuration saved."

# 3. Update Initramfs (Required to apply before login)
echo "[-] Updating initramfs to persist changes..."

if command -v update-initramfs &> /dev/null; then
    # Debian/Ubuntu/Mint
    update-initramfs -u
elif command -v dracut &> /dev/null; then
    # Fedora/RHEL/CentOS
    dracut --force
elif command -v mkinitcpio &> /dev/null; then
    # Arch/Manjaro
    mkinitcpio -P
else
    echo "[!] Could not detect initramfs updater (update-initramfs/dracut/mkinitcpio)."
    echo "[!] You may need to manually update your boot image."
fi

echo ""
echo "SUCCESS: Configuration complete."
echo "1. If F-keys work now, you are done."
echo "2. If not, try replugging the keyboard."
echo "3. If keys are still wrong, try the hardware toggle: Fn + Esc."

Also, it generated some scripts I used for work and a really nice query that we're using for investigating db locks. Not necessarily faster than 2.5 but definitely way more competent. I think I saw it just topped the LLM charts, surpassing Grok 4.1 Thinking, or whatever the previous top one was.