01-17-2026, 10:27 PM
After all my recent dev, with proven implementations and talking with AI on how to do it...here is my opinion
The Vision: Why QB64 Must Evolve
To remain a viable language in 2026, QB64 must move beyond its role as a "nostalgia engine." By combining the Universal Variable system with an OpenGL 4.6 graphics core, we can transform the language into a modern powerhouse while keeping the "QBasic" simplicity we love. This isn't just about new features; it is about ensuring the language doesn't "go up in flames" as modern OS environments move further away from 1990s architecture.
Step 1: The "Brain" (Dynamic Data Management)
We have already proven that we can bypass the rigid limitations of TYPE structures using a C++ vector-based backend.
The Goal: Hardcode this "Universal Variable" logic directly into the QB64 transpiler.
The Benefit: Users could finally define dynamic, nested arrays inside UDTs (e.g., DIM User.Inventory(100) AS DYNAMIC). The parser would automatically handle the memory allocation and recursive cleanup behind the scenes.
The Result: A Tier-1 language feature that rivals the data flexibility of Python or JavaScript.
Step 2: The "Skin" (OpenGL 4.6 & GLEW Integration)
The legacy GL 1.1 pipeline is an artifact. We need to implement full OpenGL 4.6 support to unlock modern shaders, post-processing, and GPU performance.
The Goal: Integrate GLEW in "experimental mode" (glewExperimental = GL_TRUE) and set the window's Bits Per Pixel (BPP) to modern standards.
The Compatibility: By using a "Compatibility Profile," we keep the legacy 1.1 commands (like LINE and CIRCLE) working perfectly while allowing advanced users to write modern 4.6 shader code.
The Input Fix: To prevent losing built-in commands like _MOUSEBUTTON, the core devs must bridge the modern window event callbacks (from GLFW/SDL) back into the internal QB64 input buffers.
Step 3: How We Achieve This (The Rebirth Path)
Standardize the Backend: Move the qb_universal C++ logic into the core libqb library.
Modernize Context Creation: Update the internal engine to request a 4.6 Compatibility Profile upon window creation.
Parser Update: Add a new keyword (like _VAR or _DYNAMIC) that tells the compiler to use our flexible memory system instead of static blocks.
Community Access: Release these as experimental "Phoenix" builds, allowing the community to test the performance of 4.6 shaders alongside their legacy code.
By following this path, the Phoenix isn't just a bird that survives—it becomes a high-performance engine capable of building professional spreadsheets, modern 3D games, and complex data applications for the next decade.
It's all above my paygrade and skill level to actually build this into QB64 but with these 2 major additions i reckon you'd see a huge uptake in users.
John
The Vision: Why QB64 Must Evolve
To remain a viable language in 2026, QB64 must move beyond its role as a "nostalgia engine." By combining the Universal Variable system with an OpenGL 4.6 graphics core, we can transform the language into a modern powerhouse while keeping the "QBasic" simplicity we love. This isn't just about new features; it is about ensuring the language doesn't "go up in flames" as modern OS environments move further away from 1990s architecture.
Step 1: The "Brain" (Dynamic Data Management)
We have already proven that we can bypass the rigid limitations of TYPE structures using a C++ vector-based backend.
The Goal: Hardcode this "Universal Variable" logic directly into the QB64 transpiler.
The Benefit: Users could finally define dynamic, nested arrays inside UDTs (e.g., DIM User.Inventory(100) AS DYNAMIC). The parser would automatically handle the memory allocation and recursive cleanup behind the scenes.
The Result: A Tier-1 language feature that rivals the data flexibility of Python or JavaScript.
Step 2: The "Skin" (OpenGL 4.6 & GLEW Integration)
The legacy GL 1.1 pipeline is an artifact. We need to implement full OpenGL 4.6 support to unlock modern shaders, post-processing, and GPU performance.
The Goal: Integrate GLEW in "experimental mode" (glewExperimental = GL_TRUE) and set the window's Bits Per Pixel (BPP) to modern standards.
The Compatibility: By using a "Compatibility Profile," we keep the legacy 1.1 commands (like LINE and CIRCLE) working perfectly while allowing advanced users to write modern 4.6 shader code.
The Input Fix: To prevent losing built-in commands like _MOUSEBUTTON, the core devs must bridge the modern window event callbacks (from GLFW/SDL) back into the internal QB64 input buffers.
Step 3: How We Achieve This (The Rebirth Path)
Standardize the Backend: Move the qb_universal C++ logic into the core libqb library.
Modernize Context Creation: Update the internal engine to request a 4.6 Compatibility Profile upon window creation.
Parser Update: Add a new keyword (like _VAR or _DYNAMIC) that tells the compiler to use our flexible memory system instead of static blocks.
Community Access: Release these as experimental "Phoenix" builds, allowing the community to test the performance of 4.6 shaders alongside their legacy code.
By following this path, the Phoenix isn't just a bird that survives—it becomes a high-performance engine capable of building professional spreadsheets, modern 3D games, and complex data applications for the next decade.
It's all above my paygrade and skill level to actually build this into QB64 but with these 2 major additions i reckon you'd see a huge uptake in users.
John