Getting the QB64 Message Out There

[Magdha]

FACTS:
QB64PE is marvellous
QB64PE is available to all
QB64PE is easy to learn
QB64PE can be enjoyed at all levels
QB64 since inception and this forum website are the result of a huge number of person-hours effort by much-talented people.

Yet it is being used by a miserable number of people.  I've been playing about with ("analysing") the Members List.

The first graph shows the time since the last forum visit vs date of enrolment for all members.  Don't worry too much about what the axes are.  If every member had visited the website recently, all the points would be on the x-axis.  The bounding top line is where members haven't visited since joining.  So, a great number of members just sign up and do nothing.  The greatest concentration of point near zero are at the origin - early joiners (from .org) and a core of active members.
   

The second graph shows the number of threads posted per member vs enrolment date.  Again lots of threads by a few early-sign-up members.  Then mostly zero by everyone else.  One outlier near the end is some Magdha fellow!
   

The third & fourth graphs show Cusums of Gaps in Successive Enrolment Dates vs Enrolment Date.  If you haven't come across Cusums, they're a handy tool to detect changes in a parameter over time.  You look at the slopes of the graph.  A change in slope indicates a change in the parameter average as time goes along.  In these graphs, more negative-going slopes indicate more members enrolling.  The first shows a huge negative slope at the start of PE - where lots of previous members re-joined.  The fourth graph is an expanded section of Graph 3 at recent time.
   
   

I was fascinated by Dave Mackay's presentation at the '25 Carolina Coding Conference which @Dav highlighted at this forum.  That was a chance to "get the QB64 message out there".  Did this exposure lead to more enrolments?  Remarkably, the graph shows a positive slope before change to a near-zero slope (noticeably more negative-going) after the Conference.  More members enrolling!  Fascinating, but that could have happened (it was only a slight change in membership enrolments) for any number of reasons.

Me engineer, gotta look at the data.  But that only shows the obvious:  we're a group of far-too-small members enjoying the benefits of QB64PE.

How do we get the message out?  @blpus 's YouTube website seems promising to me.  What do we need to do to attract a whole host of youngsters?

[Delsus]

Sad but true

[Heimdall]

Interesting graphs. But it's not just a QB64 thing. The popularity of Basic variants has unfortunately in general been in decline for many years, although the decline was probably steepest from about 2004 to 2010. You can have a look at https://trends.google.com/trends/ to see that trend. 

Since Basic is rarely mentioned in programming discussions and communities (they tend to focus on C, C++, C#, Python, Rust etc.), Basic variants don't get a lot of newcomers. As an example, have a look at the programming subreddits and see how often Basic is mentioned.  I get the sense that many current Basic users are the ones who used Basic, when it was more popular (i.e. people born some time between 1945 and 1990), and that group of people is of course not getting any bigger. 

It's a shame, because there are some really cool, useful, compiled, multi-platform and very capable Basic variants out there - QB64-PE, FreeBasic, PureBasic, to name a few of my favorites (the latter two being very capable of creating modern GUIs).

What I think could give QB64-PE at least a little boost is:

• Mentioning QB64-PE outside of this forum, when there is a natural opportunity to do so (for example in other programming forums) 
  
• Highlighting the strengths of QB64-PE (very intuitive language, multi-platform, actively developed, compiled, (simple) GUIs possible)
  
• Further developing InForm-PE to support just a few more of the most useful GUI form elements (especially multi-line text editor and maybe a grid view / listicon), maybe even multiple forms/windows, if that is feasible. This would in my view make it a strong option for making various utilities, and a good alternative to AutoIt
  
• Highlighting (on the main website) the GUI capabilities provided by InForm, since I think that focusing mostly on retro/console scares away many, who want to be able to do at least basic GUIs. The retro appeal probably mainly attracts those, who grew up with console, command-line and QB.
  
• Maybe (further) developing some "plug and play", multi-platform GUI (or "TUI") libraries so anyone can put something together that is visually appealing with minimal effort
  
• Clearly communicating that QB64-PE is the only active fork of QB-64. When I was considering QB64, I spent quite a long time trying to figure out what the different QB64 versions and websites were, which sites could be "trusted" and what this whole "RC Cola" thing was about. Most people probably wouldn't bother.
  

I definitely have a soft spot for QB64. I think the developers and community are doing a great job and I hope QB64-PE thrives. But since I do most of my stuff in GUIs, I unfortunately don't use QB64-PE as much as I'd like to.

[Sprezzo]

The site design choices have everything to do with this.

The forums are dismal compared to what we had twice already; this is the worst iteration since 2007. Every forum and subforum is specifically designed to counterculture what we had before. You old timers know exactly what I'm talking about.

Even if people are too scared to agree with me and risk feeling alienated, in the back of their minds they know the site is a joke. How did the Christmas code go this year? Did we ever do another banner contest after Steve clowned the whole thing with AI? Did you all know that game jams and all kinds of BASIC community-related things are happening all the time? You don't learn that here, hell no.

Anyway, nice data Mag.

[grymmjack]

The community is somewhat toxic, archaic, and stubborn, which doesn't help matters.

I have created a few new things to help me personally that might help QB64PE in general, one of which is a qb64pe-docker github action, which will build releases.

If you don't know what a github action is, it automates the creation and running of things using CI (continuous integration).

Basically you push and tag a release using the git cli, and it automatically builds windows, linux, and mac packages for people to download and use.

https://github.com/grymmjack/qb64pe-docker

This is a gap that was present for QB64PE in the eco-system vs. "modern languages" and that gap has been closed at least a bit.

For getting more newer users, you need to have a path of least resistance, and you need to meet them where they are. In this case, almost every developer is using git (except obviously the old grognards here in this community who for some reason prefer to keep their heads buried in the sand).

You want more exposure for something, make it accessible and easy, and make it so that the modern developer can use QB64PE just like any other lang like python, node, etc.

Which I'm trying to accomplish with the docker github action and the mcp-server (WIP! WARNING!): https://github.com/grymmjack/qb64pe-mcp-server

This lets young bucks easily slip into the ecosystem of development because it's where they live. AI + GitHub.

You have to adapt if you want to grow, and this forum, as fun as it is, is not enough for what you're asking for @maghda.

Anyway.. 2c.

Also, start participating in game jams like @dbox does using QB stuff. You want to expose the language then do it that way, where the kids live.

Last, here is an example of how the github action builds releases (i used my DRAW project - not done, not close, but just for testing my docker action in github): https://github.com/grymmjack/DRAW/releases

This was automatically built. I didn't have to cross compile or do anything. 1 source, 3 platforms. Small exe's. That's HUGE competitive advantage of QB64PE vs. other platforms too, so we gotta hit them where they live.

Start evangelizing, and stop complaining and diffusing on the old grognards here - start streaming, making videos, etc.

Peace and love

[grymmjack]

The site design choices have everything to do with this.

The forums are dismal compared to what we had twice already; this is the worst iteration since 2007. Every forum and subforum is specifically designed to counterculture what we had before. You old timers know exactly what I'm talking about.

Even if people are too scared to agree with me and risk feeling alienated, in the back of their minds they know the site is a joke. How did the Christmas code go this year? Did we ever do another banner contest after Steve clowned the whole thing with AI? Did you all know that game jams and all kinds of BASIC community-related things are happening all the time? You don't learn that here, hell no.

Anyway, nice data Mag.

I wasn't around for the previous gen, but I agree, I hate how hard it is to:

1. Share code
2. Share screenshots (of any kind)
3. Share examples

I wish we used a more modern software for the forums, and i've approached that topic before but got nowhere.

Imagine being able to *gasp* use 3 backticks for a code block, markdown support for posts, and pasting images, *gasp*

Not being a dick, but I agree on the usability aspect. I hate the "Add image to post" and wish I could just copy/paste my clipboard. BTW, I HAVE looked into this, and even created some demos in a staging environment here, but this forum software is very old-school in it's design, and I could not get it to play nicely with all the other crap we have here.

Anyway, I get you and agree. Wasn't around for the previous, but I know the current is painful.

I think people would share more if it was easier to do so. Maybe an IDE function like "Post my program to the forum" lol, that zipped the source, created a screenshot, added it to the images in the post with that image thingy, and made it 1 step?

Just trying to get people to share their stuff with a screenshot is a battle.

[Unseen Machine]

If you weigh Qb64 against the other Basic languages you'll see we lack a lot.  No arrays inside UDTS, only being able to use GL through the _GL sub and it only supporting gl 1.1, peoples libs not working together (due to a lack of universal UDTS/naming conventions) etc...

Even though recently we have made major steps forward via binding external libs through C++ (petr's VLC as an example) we still have ways to go before we can really compete with the other Basic variants out there. A proper IDE would be a good start as even though I love the nostalgia of the current one it probably instantly turns of younger coders as it looks outdated. 

Unseen

[ahenry3068]

If you weigh Qb64 against the other Basic languages you'll see we lack a lot.  No arrays inside UDTS, only being able to use GL through the _GL sub and it only supporting gl 1.1, peoples libs not working together (due to a lack of universal UDTS/naming conventions) etc...

Even though recently we have made major steps forward via binding external libs through C++ (petr's VLC as an example) we still have ways to go before we can really compete with the other Basic variants out there. A proper IDE would be a good start as even though I love the nostalgia of the current one it probably instantly turns of younger coders as it looks outdated. 

Unseen

     The familiarity of the IDE is actually one of the things that grabbed me and I like.   But then again I'm not one of those younger coders

[Unseen Machine]

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

[TempodiBasic]

here 3 simple ideas:

1.
If I was a beginner for the coding I could be interested to something like this 


there are different versions for different programming languages...Why not QB64pe too?
A PDF document on topics:  beginning programming can be a start, but also modular and event driven programming, interfacing with other languages or with specific not-BASIC libraries.

2.
A collection of opensource programs made in QB64pe.

3.
About Inform_pe:
it seems to be in the state of VB2.0-3.0 when you had a set of objects (items) with their features. And you were not able to modify them, except than making your own .OCX. 
The next step, if it is possible, is to let user to add its own objects (items) opening the Informpe engine to the add-ons.
I dunno if it is possible, if it is easy to do, if it is compatible with the actual structure of this program. 
Moreover Informpe should be real OS indipendent for resource used to build it and for QB64pe keywords that are in its code... (some QB64pe keywords work only in Windows).