QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: Richard on February 27, 2020, 11:52:01 pm
-
In my opinion it would be useful that the next version of QB64 (windows) has the option of being SDL (with GL as present being default).
I could image that there would have to be many (possibly thousands of) "intercepts" (using DEF IF etc) to allow switching between the two modes.
As Steve has already done much work for his QB64 SDL-2020 version (and so much more possibly needs to be done) - he may not be able to find the time to incorporate his work into QB64 v1.4 directly. Hopefully the other developers, with their vast knowledge and experience of the source code, could (slowly) systematically integrate the changes necessary (possibly at first without the actual SDL code itself part) - so that by the time QB64 v1.5 is released, at which time Steve may be essentially finished with his work on SDL-QB64-2020, Steve may only have to transfer the code (possibly with a special QB64 transfer/insert program).
In my opinion, it is better to have GL and SDL in the one program, as this would expose the SDL to a much wider users group than having a separate SDL version. It may even turn out that slowly there would be trend away from GL and back to SDL.
If adopted, maybe by the time of QB64 v1.6 the SDL option may be a better mode than the current GL mode for many or most users.
Of course, there are those who will say this will "bloat" the code - but then again, QB64 is "bloated" compared to earlier Basics - and Windows 10 is super bloated (a 4.7GB DVD of windows install taking up about 24 GB drive space) - DOES THIS "BLOAT" for QB64 v1.5 really matter then?
Just a thought ...
-
But, Why you need SDL in QB64?
...
It may even turn out that slowly there would be trend away from GL and back to SDL.
...
That's like a nightmare for me. Why we should go GL to SDL? We will lost all OpenGL features... :'(
-
Thanks Ashish for your response.
My suggestion was to have BOTH OPEN_GL AND SDL.
Historically, "competition" often is best for the enhancement of all competing products.
I did like your introductory tutorials on OPEN_GL (I was lost getting started).
By all means QB64 should retain OPEN_GL (as the default mode).
-
Yes sounds bloaty and redundant to have both. What does SDL have that is missing in GL?
-
Yes sounds bloaty and redundant to have both. What does SDL have that is missing in GL?
Copied from my SDL-2020 posts:
What does SDL have that GL doesn’t? Working fonts, correct keyhit codes, working _DEVICES support, the ability to PRINT to TCP/IP, 256 color image support, more image formats and better sound. (Current is: WAV, OGG or MP3 file types. SDL supports those plus AIFF, RIFF, VOC, MOD and MIDI.)
What does GL have that SDL doesn’t? Several years of development, adding multiple new commands and functions. 32 and 64-bit versions. Open GL support (though I’ve never actually seen it used for anything more than a few minor demos). Hardware images and an enhanced IDE with more customization capabilities. Stand-alone EXE support, and a majority user base which can help with any questions or problems which might arise while using it.
My biggest issue with GL is that we don’t have a single reliable input routine. *ALL* methods of input are screwed up in some manner, or another, in the GL version. Key codes are missing, mapped incorrectly, or just plain wrong — especially when getting to combination key codes like CTRL-TAB, or ALT-ENTER.
The only way I’ve found around these serious flaws is just to write my own independent keyboard routines using DECLARE LIBRARY and the windows API functions, and they won’t work for Linux/Mac users...
Galleon left us trying to patch up a badly flawed version of QB64-GL, and the only reason most folks never notice is because they never try to see what actually works and doesn’t work. With all its glaring flaws, QB64-GL is a hobbyist’s language, at best. QB64-SDL, even with it’s lack of Open-GL support, still happens to be a more reliable version for the things which it does do.
-
You can do everything OpenGL within SDL: https://www.libsdl.org/release/SDL-1.2.15/docs/html/guidevideoopengl.html (https://www.libsdl.org/release/SDL-1.2.15/docs/html/guidevideoopengl.html). You could keep all the OpenGL features and the rest of SDL would just be replacing freeglut
OpenGL is the part that does all the graphics and supports the fancy _gl* statements but it does not handle things like creating a window, handling user input, loading PNG files, playing sounds etc etc. Those things are platform dependent and you need a toolkit library like freeglut to do the gl context creating and handling of user input but on top of that you also need a bunch of external libraries to do the rest, ie opening PNG files, fonts, etc. SDL is an all in one that can do everything from user input to image files/sounds/fonts all the way to networking, but it can also create a gl context and support all the _gl* stuff. You could port the entirety of QB64 to the well supported SDL2 with zero compromises. Would it be more bloated? IDK
-
So is it practical to have both?
-
Keep the latest QB64 in a folder and keep Steve’s SDL version in another. Use each when you feel like changing.
-
Yeah seems like a fork in the road.
-
It seems to me that the GL version is already huge enough, no? Combining the two would make it far bigger, and more importantly, would create more opportunity for bugs, and bugs which are harder to correct.
Do those who prefer to use SDL want to switch back and forth all the time? Me, I have been using GL mainly because I need those stand-alone .exe files that I can send to others, so I'd never go back to SDL. The extra bloat and bug risks would not do me much good. Maybe others feel differently.
-
It seems to me that the GL version is already huge enough, no? Combining the two would make it far bigger, and more importantly, would create more opportunity for bugs, and bugs which are harder to correct.
Do those who prefer to use SDL want to switch back and forth all the time? Me, I have been using GL mainly because I need those stand-alone .exe files that I can send to others, so I'd never go back to SDL. The extra bloat and bug risks would not do me much good. Maybe others feel differently.
That’s why I support keeping the two versions separate. For folks who need what GL offers, they don’t need the SDL files bloating their work. For those who need the SDL capabilities, they usually don’t need the Open-GL stuff. (And the rare intersect who do need both, can always try a work around like _vince mentioned above.)
Separate versions, each developed to remain as compatible as possible to each other, seems to be the best way to go, to me.
Once life settles down here a bit, I’ll work on trying to add a few more features to SDL-2020 for us, to bring it a little more up to compatibility with the GL version. My next goal is the precompiler options for us, since I personally use those a lot myself. ;)
-
I personally think that Fillippe has the right idea.
Maintain a GL version AND an SDL version. Let the users download their choice.
Combining them may cause 'purists' to 'tolerate' the blend or completely reject it altogether.
In regards to 'bloat'... hasn't Micro$oft always had an answer for that? Throw more RAM at it or use a faster CPU or larger hard drive... lol
That's my 2 cents for what it is worth... lol