QB64-SDL 2020

[SMcNeill]

I know there's several folks out there who still like (and need) to code certain projects in the old QB64-SDL version for various reasons, so I thought I'd spend a little time and effort in 2020 and see about updating the old version so that it'd match the v1.3 capabilities as much as possible.

So far, this is my start on that journey: https://github.com/SteveMcNeill/QB64-SDL.git

Changes/enhancements so far:

Minor coloring in the IDE, mainly to help highlight quotes, remarks, and metacommands.

Addition of all the various math commands which SDL was missing.  _PI, all the extended trig functions, the degree to radian to gradian conversion functions (, and a few others.

A few bug fixes for various things already.

A whole new math evaluator to be used with CONST -- this one even surpasses the current capabilities of what's now in QB64-GL v1.3!  (At least, until I test it several times, make certain it's not going to break anything, and swap it in as a replacement.)  You can try it out and view it independently here: https://www.qb64.org/forum/index.php?topic=1555.msg112989#msg112989

The code has been cleaned up and formatted to be a lot more readable (especially the c code).

_LOADFONT has been modified so that it now behaves like the GL version for Windows.  Instead of immediately tossing an error message if a path is left off the fontname, it now will take a moment to look in "C:\WINDOWS\FONTS\" to see if the font in question is located there for use.

OPEN file$ FOR BINARY now works with LINE INPUT, rather than tossing an error as it did.  This has been brought up to QB64-GL standards.

The config file has now been made externally available and changeable, with more options available for IDE customization.

The antiqued help system has been removed, and all references to [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] should now be gone from QB64-SDL.  Instead, we now correctly download and get updates from the official qb64.org wiki. 

Swapped default behavior for the Run and Run (Detached) commands -- they're now Run and Run (Locked).  Run will compile and run your program independent of the IDE.  Run (Locked) will lock the IDE until it compiles and you finish running the program.


List of commands currently added are:

Code: [Select]

_D2R
_R2D
_D2G
_G2R
_R2D
_R2G
_PI
_ATAN2
_ASIN
_ACOS
_SINH
_COSH
_TANH
_ASINH
_ACOSH
_ATANH
_CEIL
_HYPOT
_ARCSEC
_ARCCSC
_ARCCOT
_SECH
_CSCH
_COTH
_SEC
_CSC
_COT
_INSTRREV
_STRCMP
_STRICMP
_AUTODISPLAY (function)
_WINDOWHANDLE
_WINDOWHASFOCUS
SELECT EVERYCASE
_CWD$
_STARTDIR$
_KEYCLEAR
_CAPSLOCK
_NUMLOCK
_SCROLLLOCK
_CAPSLOCK (function)
_NUMLOCK (function)
_SCROLLLOCK (function)
_SHL
_SHR
_SETBIT
_READBIT
_TOGGLEBIT
_RESETBIT
_TRIM$
_DESKTOPWIDTH
_DESKTOPHEIGHT

Other changes, commands, and enhancements to come as time and motivation allow.  If there's a feature/command which you really would like to see, or need, in the SDL version, mention it to me and I'll try to add those requested capabilities first.

It's a start, but it still has a long ways to go...   ;)

As I mentioned above (but I'll repeat the link here to save someone some scrolling), these changes can all be found and tracked here:  https://github.com/SteveMcNeill/QB64-SDL.git


And a list of commands which hasn't been implemented yet in the SDL version, for quick reference:

Code: [Select]

_ACCEPTFILEDROP
_ALLOWFULLSCREEN
_ASSERT
$ASSERTS
_BLINK
_BLINK (function)
_CLIPBOARDIMAGE (function) pastes an image from the clipboard into a new QB64 image in memory.
_CLIPBOARDIMAGE (statement) copies a valid QB64 image to the clipboard.
$COLOR
_COMMANDCOUNT
_CONNECTED
_CONSOLETITLE
_CONTINUE
_DEFLATE$
_DEPTHBUFFER
_DIR$
_DISPLAYORDER
_DROPPEDFILE
$ELSE
$ELSEIF
$END IF
$EXEICON
_FINISHDROP
$IF
_INCLERRORFILE$
_INCLERRORLINE
_INFLATE$
$LET
$NOPREFIX
OPTION _EXPLICIT
_PRINTSTRING (doesn't work in SCREEN 0)
$RESIZE
_RESIZE
_RESIZE (function)
_RESIZEHEIGHT
_RESIZEWIDTH
_SCREENEXISTS
_SCREENICON (function)
_SCREENICON (statement)
_TITLE$ (function)
_TOTALDROPPEDFILES (function)
$VERSIONINFO
$VIRTUALKEYBOARD

NOTE: This may not be the complete list of every command which is missing, or every syntax which isn't 100% compatible.  This is a list of things which I'm certain won't work currently, and it's up for modification at any time as I implement these missing segments, or find other things which should work but don't, for us. 

[Pete]

I wished Rob would have renamed the SDL version QuickBASIC64. It was the closet thing we had to QuickBASIC. I still recall TheBOB had to change a small amount of code in his cake routine, to stop some color bleed issue when he ran it on GL. I experienced the same problem with my graphics GUI routine, but I never did debug it to find out why GL handled the display slightly differently.

I think SDL compiled into smaller executable programs, but the downside was you could only run thiem in the same folder as the dependency libraries. GL comiles those libraries in the project, making the finished product a stand alone exe. That's the way I recall it, but it's been awhile, and maybe I'm mistaken. I also recall SDL compiled faster, but Rob got the GL compilation down after a few revisions. Since you're working with it, do you have a quick list of advantages / disadvantages between the two? Obviously GL offers 64-bit compiling (I believe you produced that GL version), more keywords, the addition of adding libraries, etc. I also wonder what the new SDL interface would have added, if Rob had waited for it to be released? The licensing, I recall, was also different. I thought SDL was a bit less restrictive.

Anyway, thanks for your efforts to keep the good ship SDL afloat, and good luck with the additions to the upcoming new and improved version. When it's ready to sail, I'll download a copy. Hopefully, I'll be among the many here who can say... "Hey that guy Steve finally got his ship together!"

Pete

[Qwerkey]

It was the closet thing we had to QuickBASIC.

Pete 

You need to come out of the closet, Pete!

[Qwerkey]

I know there's several folks out there who still like (and need) to code certain projects in the old QB64-SDL version for various reasons

Really?  I know that I was very resistant to giving up SDL at first, but once you move up everything is backward-compatible with a few tweaks if necessary?  But if Pete has tried with problems there must be some things that don't convert (seems odd but then I'm very limited in what statements I know and use).

[SMcNeill]

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.

[SMcNeill]

Really?  I know that I was very resistant to giving up SDL at first, but once you move up everything is backward-compatible with a few tweaks if necessary?  But if Pete has tried with problems there must be some things that don't convert (seems odd but then I'm very limited in what statements I know and use).

Several things I can think of immediately that would make converting hard up hard to do:

Use of 256 color images, or SCREEN 13.
Use of _DEVICES to handle input needs.
Use of _MEM.  (As SDL had a depreciated MEM.TYPE structure, different from the GL version.)
Use of various image/sound formats.
Use of PRINT/INPUT with TCP/IP stuff.
Fonts may need converting if BOLD, ITALIC, UNDERLINE was used.

[Pete]

You need to come out of the closet, Pete!

Closet, Closest... Huh, my "s" is missing!Well, that was embarras-s-ing. Why didn't someone hand my s?

Pete :D

[luke]

It's worth noting that QB64 used SDL 1.2, the licensing of which made it unsuitable for static linking.

The most recent version is SDL 2, which is more freely licensed.

[RhoSigma]

It's worth noting that QB64 used SDL 1.2, the licensing of which made it unsuitable for static linking.

The most recent version is SDL 2, which is more freely licensed.

Which doesn't matter at all IMHO. I remember the licensing was one of the big points back then, when QB64 was moved from SDL to GL. But for real, be honest, how many projects have you seen since 2012, which really required the static linking (ie. distributed in one binary file form only), not even one. Every coding happening here in the forum provides source code, and everybody who likes to use it has his own installation of QB64 and can compile the sources by himself.

[Petr]

hat 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.)

Exactly. Whoever says what he wants and thinks what he wants about me, but the absence of some music formats in version 1.3 really annoys me. I even think Galleon was going to make RAW audio data available with the _SNDRAWOPEN command. This command does not make sense as it is written, because the sample rate changes when you use two of these commands in succession for the same audio channel. I spoke to [banned user] about this two years ago, apparently there was a way to make RAW audio data available. Basically, I'm talking about the equivalent of MEM but for sound. I would be absolutely thrilled away if this were done.

And just a question. Why doesn't version 1.3 use LOADIMAGE (image, 256) internally as a 32-bit image and then convert it (dithering) and place the image on a 256-color screen?

[RhoSigma]

And just a question. Why doesn't version 1.3 use LOADIMAGE (image, 256) internally as a 32-bit image and then convert it (dithering) and place the image on a 256-color screen?

As far as I remember it was tried to do it that way, back in v1.1 (think Fellippe did), but it didn't turn out very well by testing with several different image formats, so it was removed/disabled again until a better workaround will be available, which obviously didn't happen 'til now.
That's why I built in my own Floyd-Steinberg dithering routine into GuiTools, which was also adapted for Steve's SaveImage library v2.1 last year.

[SMcNeill]

Next step forward has been taken with regards to QB64-SDL 2020:

The code has been cleaned up and formatted to be a lot more readable (especially the c code).

_LOADFONT has been modified so that it now behaves like the GL version for Windows.  Instead of immediately tossing an error message if a path is left off the fontname, it now will take a moment to look in "C:\WINDOWS\FONTS\" to see if the font in question is located there for use.

FUNCTION _AUTODISPLAY has been added.
FUNCTION _WINDOWHANDLE has been added.
FUNCTION _WINDOWHASFOCUS has been added.


Modifying things to bring SDL up to become more GL compatible is now starting to slow down, as several of the commands which need converting are wrote using openGL libraries.  I have to take time to hunt down the difference between SDL and GL, find the SDL replacement routine to GL, and then plug it in and test to make certain it's working as intended. 

[RhoSigma]

Hi Steve,

I could bring in my fix to _COPYIMAGE/_FREEIMAGE glitch and the &B binary string enhancement done lately. However as you have reformatted libqbx.cpp and qbx.cpp the WinMerge comparisation gives me diffs on almost every line and it's hard to spot my additions to the code anymore. Ie. I'd need to reformat my files too first to match your format, did you make the changes manually (guess not) or which program/online service did you use to do so?

I usually use this service http://format.krzaq.cc/ with the google style formatting, you paste code, click to format and then copy the formatted code back. Unfortunatly it can't reformat the whole file at once, so I usually only reformat the functions I work on.

[SMcNeill]

Hi Steve,

I could bring in my fix to _COPYIMAGE/_FREEIMAGE glitch and the &B binary string enhancement done lately. However as you have reformatted libqbx.cpp and qbx.cpp the WinMerge comparisation gives me diffs on almost every line and it's hard to spot my additions to the code anymore. Ie. I'd need to reformat my files too first to match your format, did you make the changes manually (guess not) or which program/online service did you use to do so?

I usually use this service http://format.krzaq.cc/ with the google style formatting, you paste code, click to format and then copy the formatted code back. Unfortunatly it can't reformat the whole file at once, so I usually only reformat the functions I work on.

I just used Visual Studio’s 2019 built in Format and let it do the spacing for me.  Feel free to do what you need to, to help highlight the changes for you.  You can copy the current code into krzag.cc and format it to match your current style for comparison, if you want.  Or, if it’s easier, make the changes with an older version (or even the original version of SDL 0.954), and I can use WinMerge, or a similar comparison tool, to highlight where to add the changes into the upgraded SDL version.    ;)

[SMcNeill]

Pushed fix to OPEN file FOR BINARY so that it now works with LINE INPUT as it currently does in QB64-GL.


Cleaned up some more of the code to remove further references to the old SDL update procedure.  Back in the day, SDL used to call up [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there], see if a newer version of itself existed, and then, if so, upgrade itself for us.  Now, however, [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] is a hacker's site -- Galleon no longer maintains it and nobody knows who the crap registered it and put it back up on the net -- so it's not a place that one wants to visit ever.  Going there isn't going to update crap -- it'll just lock up the update process as it freezes waiting for a non-existent response to come back to it -- and there's no reason to give that bogus site your IP address, or anything else.