Messages

At compilation - yes, that sounds good.

For strict, it would be easier to do (from a users point of view) if it was a project setting that is applied to all files in that project.  If you leave it OFF by default when creating a project compile and warn as normal.  If the project setting is changed to ON convert those warnings into errors.

Hi Gernot

Could I request two teeny additional features for GLB in the editor and compiler to be added to the wish list?

First one is could you add a strict option in GLB to fail compilation with an error instead of a warning when a variable has not been declared.  Make this an option that is off by default so not to cause any compatibility problems with older code and those that don't want it.  See reasons why below.

Second one is could you add an option to the editor to not change the case of what you type when it detects a reserved word.  And add a button to reformat the current code window (force case, spacing, indenting etc) so you can tidy up your code when you need to.  I know some people will like it, so again as an option, but for me it tends to get in the way.  The colour coding is not a problem (and is helpful) but the change to UPPERCASE changes your program.



The reason for the two above requests are that often, while in a procedure for example, I declare a local variable that starts with a reserved word, such as MAX for example, often GLB will jump in and change that part to upper case.  For example if I have a variable called "maxt" it I press del key to remove the 't' then max becomes MAX.  If I leave it as-is, and now have a new variable called MAXt, a different variable to maxt.  See code below.

Example:
FUNCTION test1:
   LOCAL maxt
   maxt=0
   MAXt=1
   
   PRINT maxt + " " + MAXt,0,0
   SHOWSCREEN
   KEYWAIT
ENDFUNCTION

in the compilation log (but only when in debug mode):
"test.gbas"(4) warning : implicitly created GLOBAL  : MAXt


The output from the above is "0 1" because we've now got two different variables.  If you have debug mode off you don't even see the warnings.

Would it be possible to add these features?  The strict option would stop any errors being introduced and if we could turn off auto formatting we could avoid the annoying renaming (by change to uppercase) of variables when we don't want them to.  It's a pain to avoid every reserved word as part of a variable name or to retyping in lowercase.

That's one way of looking at it, but not one that you tend to see in implementations of split in other languages.  Same in Excel when you import a CSV with empty values, the commas define the column the data goes in.

EG:

NAME, TITLE, PHONE NUMBER
Andy,,01215559999
Stu,Ovine,
Gernot,GL Basic,0123232323

In GLBasic Andy, Stu and Gernot would be in the first array element but then in the second array element it would all go wrong... Andy's Title would incorrectly have the telephone number in, Stu would have Ovine and Gernot GL Basic.  Then the third array element would not exist for Andy or Stu but would have the telephone number for Gernot.

I guess the replace will work, but seems a bit unnecessary and perhaps not desirable if handling lots of splits.  Perhaps you should write a SuperSplit function instead Stu to handle it as required?

OK, how would you pass a pointer to that function?
Or make it fix like:

TYPE Tfoo
   x;y;number
ENDTYPE

// Hardcoded name: <Typename>Compare
FUNCTION TfooCompare: a AS Tfoo, b AS Tfoo
   IF a.x < b.x THEN RETURN -1
   IF a.x > b.x THEN RETURN 1
   // y is equal
   IF a.y < b.y THEN RETURN -1
   IF a.y > b.y THEN RETURN 1
   RETURN 0
ENDFUNCTION

That's looks good to me.  Alternatively couldn't you pass the function name as a parameter in the new sort command you'd implement?

I'm afraid for types to be sorted in arrays you might as not bother unless it can be completely defined by the user.  Too many assumptions and limitations with the others to be practical.

So the last option would be the only useful method from my point of view - eg: a function that takes two parameters of the types being sorted, the code in the function would determine if something is bigger or smaller, so I can use what ever simple or complex comparison of data in the type, and return True or false as the result.

Hi Moru - yes I have come up against this also.  Would be nice to have a good solution to it in a future GLB build.

Looks good Schranz0r!

Ah - I need to keep the jaggies away most of the time    For some reason I had always assumed it was something to do with the sample buffers on playing sound (a similar term is used in MMF you see).  Cool, well that explains why my rectangles were sometimes coming out anti-aliased on the PC version of my game then!

What does the multisampling option do? 

There's a link to the Shoebox application under Tools.  Just point it at the directory you want to shoebox up (just like zipping) and that's it.  Is recursive so will pack up all the subdirectories in there too.

Then just add a command at the top of you program ...

SETSHOEBOX "ShoeBox.sbx", ""

Where ShoeBox.sbx is the name of your file.  Take a look at the help file for details, but basically just load your sprites etc as normal and if they are found in the shoebox file (using the same path) then it will load it from there.

That looks good Gernot - the kind of thing I'm used to in C#.

Moru - looks like an interesting function - thanks for posting that.

[DIMSORT]

A sprite system in GLB would be a nice game saving device to have, but I guess there's many things you might want to be able to do with it and perhaps writing your own gives more flexibility.

Talking of ordering, if a sprite system is too much, it would be nice to have some built in methods to make writing your own even easeir.  For example, I think most people use a TYPE array to store a list of sprites with DIMPUSH and DIMDEL for adding/removing items in the array and FOREACH to step through each element in the array.  What we're missing is a nice easy way to sort the array in to a preferred order.

I wonder if something like the following could be added to GLB?

TYPE sprite
sprnum ; x ; y
ENDTYPE

local mySprite1 AS sprite
local mySprite2 AS sprite
local mySprite3 AS sprite

mySprite1.y = 100
mySprite2.y = 50
mySprite3.y = 200

DIMPUSH Sprites[], mySprite1
DIMPUSH Sprites[], mySprite2
DIMPUSH Sprites[], mySprite3

DIMSORT( Sprites[],  Sprites[].y )  // sort Sprites[] array using Sprites[].y

The main thing is that there is a sensible work around, ie: get the latest MinGW.  I don't suppose that will be a problem for most who are still using MinGW 5.1.3 and GLBasic.

Ver 5.1.3.

It looks like 5.1.4 is the latest.  Installing ...

Yay... success.  No more ld errors.

Any luck with this one?  Still occurs if MINGW folder is not disabled (renamed).  I'm on Vista BTW.