Follow the development of QB64 v1.3

[SMcNeill]

Push to fix the $IF/$LET issue as I reported here: https://www.qb64.org/forum/index.php?topic=720.0

This also adds a new capability so we can check to see if a precompiler variable has been previously defined or not, which allows for useful "smart definitions" of common variables/CONSTs in library files, such as:

Code: QB64: [Select]

1. $IF TRUEFALSE = UNDEFINED THEN
2.     CONST True = -1, False = 0
3.     $LET TRUEFALSE = TRUE
4. $END IF

With the above, we can now use True and False as constants in multiple libraries and not have to worry about whether they'll create duplicate definitions or not.  Only the first one executes (while the TRUEFALSE precompiler variable is unset), and the rest of the occurrences are ignored completely by our program. 

*********************

Pushed fix to memory leak issue with PRINT USING following a different print in the same statement, as described here: https://www.qb64.org/forum/index.php?topic=721.msg6075#new

[Cobalt]

A little on the new bit shifting functions _SHR(shift right) and _SHL(shift left)
as functions _SHR(VALUE,AMOUNT ) [same applies to _SHL]
where VALUE is up to a INTEGER64 variable that you want shifted
and     AMOUNT is the number of bits to move

null=_SHR(MyVariable,3) will shift the bits in MyVariable to the right by 3 and put the result in null

_SHL will have the effect of increasing the value, so in essence bit 0 is the right most bit. so a value of 1 would have bit 0 turned on( as _byte: 0000 0001) example

Code: QB64: [Select]

1. a~%%=1 'as bits (0000 0001)
2. b~%%=_SHL(a~%%, 1) 'shift it by 1 and it is now (0000 0010)
3. PRINT b~%%
4.  

the output would be 2 (0000 0010)

_SHR will have the effect of decreasing the value, and bits are simply dropped off the end of the value.
taking b~%% from the above code

Code: QB64: [Select]

1. c~%%=_SHR(b~%%, 2)
2. PRINT c~%%
3.  

now c~%% will be 0 cause we moved the bit from (0000 0010) over 2 which made it drop off leaving (0000 0000)

Trying to shift a value of 0 will have no result because there are no 'set' bits too move. [(0000 0000) no '1's to move!]
it is possible to move the bits too far left and get the same result, going with (0000 0010) we
c~%%=_SHL(b~%%,7)
and wind up with 0 because we move the bit clear off the left side requiring at least an INTEGER to hold the new value.

Values up to INTEGER64,  you can have signed or unsigned depending on what variable use use to hold the returned value a%%_SHL(1,7) will be -128 while a~%%=_SHL(1,7) will be 128

[SMcNeill]

Good news for all the nice folks who want to _SCREENMOVE _MIDDLE -- you now can!!

I pushed a fix into the development build (511aee9) a while ago which was basically a change of the original:

Code: QB64: [Select]

1.                     int32 SW, SH, WW, WH;
2.                     SW = glutGet(GLUT_SCREEN_WIDTH);
3.                     SH = glutGet(GLUT_SCREEN_HEIGHT);
4.                     WW = glutGet(GLUT_WINDOW_WIDTH);
5.                     WH = glutGet(GLUT_WINDOW_HEIGHT);
6.                     x = (SW - WW)/2;
7.                     y = (SH - WH)/2;
8.                     glutPositionWindow (x,y);
9.                 }

To the new:

Code: QB64: [Select]

1.                     int32 SW=-1, SH, WW, WH;
2.                     while (SW==-1){SW = glutGet(GLUT_SCREEN_WIDTH);}
3.                     SH = glutGet(GLUT_SCREEN_HEIGHT);
4.                     WW = glutGet(GLUT_WINDOW_WIDTH);
5.                     WH = glutGet(GLUT_WINDOW_HEIGHT);
6.                     x = (SW - WW)/2;
7.                     y = (SH - WH)/2;
8.                     glutPositionWindow (x,y);
9.                 }

So how's this fix work?

Glut returns a value of -1 if we try to use glutGet on an invalid window.

What the issue before was, was QB64 trying to move the window, before glut had finished registering itself properly with the OS and getting a valid handle...

So now, we set the value to -1 to begin with (as if it's an invalid window), and we simply keep pestering glut to return a proper value to us once it's all finished doing its initialization junk with the OS.

Simple fix and _SCREENMOVE _MIDDLE now works as advertised. 

[SMcNeill]

It's been a few days since I pushed changes to CONST into the development build, but I forgot to mention it here.  I apologize.

As I described here -- https://www.qb64.org/forum/index.php?topic=742.0 -- CONST and the internal math routines have now been completely overhauled.

CONST names are now resolved and usable inside other CONST without glitching out, and this now includes our math functions as well.

Before, this would error out:

CONST X = 1.2
CONST Y = INT(X)

It now works perfectly fine.  (Or at least, it should.)

*************

Change #2: CONST has been changed to work with the standard QB64 syntax with the functions/keywords it supports.  Instead of CONST X = ARCCOS(0.5), which didn't follow standard syntax, it now accepts CONST X = _ACOS(0.5).  This should open up ease of use for folks and add increased flexibility to CONST.

[Robert Claypool]

Can you bring back midi file playing. A lot of qb45 programs used TSRs to play midi files and it used to be not that hard to swap in _SND* commands to play them instead.
These, for example: http://qbrpgs.blarg.ca/rpgs.php?view=ALL&page=1

[FellippeHeitor]

Can you bring back midi file playing. A lot of qb45 programs used TSRs to play midi files and it used to be not that hard to swap in _SND* commands to play them instead.
These, for example: http://qbrpgs.blarg.ca/rpgs.php?view=ALL&page=1

We need a free reliable cross-platform c++ midi library suggestion.

Now, if you're on Windows, just use the builtin system capabilities: https://www.qb64.org/forum/index.php?topic=811.msg100434#msg100434

[Petr]

Please repair function _MOUSEMOVEMENTX! Thank you!

not that I could not get around it, but the dysfunction does not really benefit my laziness.

:-D

Code: QB64: [Select]

1. 'mousemovementX, mousemovementY alternative
2.  
3.  
4. DIM SHARED OldMouseX AS INTEGER, OldMouseY AS INTEGER
5. WHILE _MOUSEINPUT: WEND
6. OldMouseX = _MOUSEX
7. OldMouseY = _MOUSEY
8. DO
9.     WHILE _MOUSEINPUT: WEND
10.     PRINT MOUSEMOVEMENTX, MOUSEMOVEMENTY
11.     _LIMIT 20
12. LOOP
13.  
14. FUNCTION MOUSEMOVEMENTX
15.     SELECT CASE OldMouseX
16.         CASE IS > _MOUSEX: MOUSEMOVEMENTX = -1: OldMouseX = _MOUSEX
17.         CASE IS < _MOUSEX: MOUSEMOVEMENTX = 1: OldMouseX = _MOUSEX
18.         CASE ELSE: MOUSEMOVEMENTX = 0
19.     END SELECT
20. END FUNCTION
21.  
22. FUNCTION MOUSEMOVEMENTY
23.     SELECT CASE OldMouseY
24.         CASE IS > _MOUSEY: MOUSEMOVEMENTY = -1: OldMouseY = _MOUSEY
25.         CASE IS < _MOUSEY: MOUSEMOVEMENTY = 1: OldMouseY = _MOUSEY
26.         CASE ELSE: MOUSEMOVEMENTY = 0
27.     END SELECT
28. END FUNCTION
29.  
30.  

[FellippeHeitor]

Development build available today (from git 358b725) contains a few more minor fixes and a new warning system has been implemented:

 [ You are not allowed to view this attachment ]  

So far there are two types of compiler warnings that will be presented to the user but will not prevent compilation:

• Variables you declared with DIM or equivalent and never used in your program (also SUB/FUNCTION parameters you created but never used in the body of the procedure) - of course these didn't prevent compilation before but now you have the chance to pinpoint these minor issues and cleanup your code.
• CONSTs you redefined with the same value (as when you already have CONST TRUE = -1, FALSE = 0 and then you proceed to add a library to your program that does the same; in previous versions that would prevent compilation and require you to edit your program or the library - now that's just a friendly warning and compilation can go on).

Also with this build the macOS Mojave issues have been fixed (one by Apple itself with version 10.14.4 of their OS and one by us), so we're compatible with macOS again.

Please help us test these new features of the latest dev version (as well as the ones outlined on this post) as we're **this** close to releasing version 1.3.

Fellippe.

[RhoSigma]

The Windows development download links on qb64.org are not available (x32 version, the former text link) and or not working (x64 version, the icon link), which returns "Forbidden", as it only points to autobuilds/development folder, not to an actual download file.

EDIT:
Ok, after deleting all cached browser content and then reloading qb64.org, both download links (x32/x64) appear, but still, both only point to autobuilds/development/ and error out "Forbidden".

BTW - I was wondering long time, that the windows dev download stuck on the built from 2019-02-01, while Linux and Mac dev builds were updated regulary. Maybe a build script problem?

EDIT2:
Forget about it, everything's working now. Probably i just tried to download it in the middle of the built process...
...delete this post, if you want.

[jack]

thank you FellippeHeitor :)

[Pete]

Will _INSTRREV work with a seed? Example x% = _INSTR(10, x$, ",") Where 10 is the seed and wuld mean go ten characters from the right of x$ and then start looking for the first comma?

Pete

[FellippeHeitor]

_INSTRREV takes an optional numeric first parameter but it doesn't go from right to left; it just specifies where to start looking, just like with INSTR. If you want ten characters from the right you'd still have to do x% = _INSTRREV(LEN(x$) - 10, x$, ",")

[Pete]

What? Don't you think that should be changed? I think it should be changed, and it should cost 5-cents.

Pete

[FellippeHeitor]

I'm borrowing the name and the behaviour from VB, and it did make sense to me to specify a start position from left to right instead of the contrary.

[RhoSigma]

I also do it the same way in my RInstr&() function (part of GuiTools). It's just the start position as usual from the beginning (left side) of a string and to be honest I found it the same way in almost every BASIC like language I've ever used, doesn't matter how the name of the actual function was. I've taken RInstr&() from MaxonBASIC (very popular on the Commodore Amiga in mid 1990's). Fellippe took _INSTRREV form VB, but it's all the same functionality.

I was about exchanging my RInstr&() with the new _INSTRREV, but didn't, as I still use the old SDL version a lot, which doesn't have the new commands. Unfortunately I still have to stick to SDL, as GL don't work correctly with intl. chars and some symbols on CP437. KEYHIT, INKEY$, INPUT$, (LINE) INPUT all give different results here, but non of it give the correct values/chars. I wish this would be the next great step in improving QB64 GL, bring that back to the SDL behavior, which handled this gracefully. It's a pitty to say that, but cause of this discrepancies, QB64 GL is almost useless for my projects at work, I can use it in private, coding everything in english, but can't expect my work fellows to use english software, as most only speak their native language german.