Standardised extended libs???

[Unseen Machine]

Hello everyone, 

Is there a community created/agreed upon function extension/definition library anywhere? By this I mean libs for things like input, graphics, math functions, etc.....?

If not, could we make some?

I only ask as if everyone used a standardised base when making new features, debugging, support and the rate at which support for things can be added would increase.

I personally would be more than happy to make future GDK dev on it...heck i have got the loader for quake 3 .bsp maps done but the rendering and the shaders! I got baffled and moved on to other things! If you guys understood the base on which it was built, helping would be easier! 

Extending on that, if its an agreeable idea, a program initialisation, udpdate and input automation would also be something i'd vote for.

Thoughts?

Unseen

[SpriggsySpriggs]

Interesting idea, for sure. Standardization is key.

[Petr]

@Unseen Machine Please, write here what exactly you suggest. I would be very happy to hear it.

[Unseen Machine]

Hey Gang!

Well, I may not post much but I sure do code! I have MY own set of tools as I am sure most of you do but even though I am a HUGE advocate for learning how something works, one should not always need to learn/interpret every last detail to use it.

The most basic would be things like input handlers, generic definitions and the like...i.e Vectors....in making GDK2 compatible with fzxNGN (Still working on it!) I had to re build from the ground up as GDK's vectors were different, but this has had GREAT results....so im okay with it but IF we BOTH had used a pre built, community agreed upon framework then they would simply be compatible with each other from the get go, or in an idea world, just parts of the same library, rather than the required wrappers, conversions, etc...also this would allow for EASY documentation, tutorials and provide a WHOLE series of other benefits.

I'll be posting something Ive been working on which use MY default stuff...then you may get a better idea.

Unseen

[SMcNeill]

We've talked about this many times over the years.  I'll have to do some digging and see if I can come up with the actual links to those conversations we had about things, and the stuff we decided upon.

Basically, the theme is just be as obvious, non-intrusive, and simple as possible.

1) Code everything with the idea that other people will use the library.  All variables, arrays, and such must be defined so they don't toss errors if someone plugs them into code using Option _Explict, in other words.

---

2) Code everything assuming that the other people will have different defaults than you.   

Example:  DIM Foo(100) AS INTEGER

^ Seems almost impossible that something could go wrong with that statement alone.  Right?

My first line of code is:   OPTION BASE 1  <--- I just broke your library because you weren't expecting that!  Your array Foo should go from 0 to 100, but my program only goes from 1 to 100... I get errors and can't run your library!

Solution:  DIM Foo(0 TO 100) AS INTEGER

Spell it out, there's no problem.  You avoid conflicts with option base.

Same with usage of $DYNAMIC or $STATIC or any other such things.  *Don't* assume the other person has the same defaults on your system.

---

3) Don't SHARE common variables, for god's sake!!   

DIM SHARED I, J, K     <---  ARRRGGHHHHH!!!

The above is going to die in 99.9% of programs.  Folks use those common names for temp loops and junk variables and everything else.  If those are your shared variables, you're doing something wrong!

---

4) Restore settings after a call to/from a sub.

Example:

SUB foo
   COLOR _RGB32(255, 255, 255), _RGB32(0, 0, 0)
   'do stuff
END SUB

AAAAHHHHHHH!!!  Your library just changed someone's settings and now they're no longer printing Red on Blue; they're now pooping White on Black text onto the screen!  You corrupted their code!

Solution:

SUB foo
    dc = _DEFAULTCOLOR: bg = _BACKGROUNDCOLOR
    COLOR White, Black (I'm lazy.)
    'do stuff
    COLOR dc, bg   (clean up and restore settings before exiting the sub for good)
END SUB

.
.
.
.

These were the basic style guidelines that we came up with.  (There should be more of them, if I can ever find those old topics wherever they're hiding.)  But, at the end of the day, the general concept is:

Make your code where it works as flexibly as possible, where it doesn't corrupt existing code, and where it doesn't rely on global settings matching your system's set up.

[Unseen Machine]

Yeah, sounds like a framework to me....Im so out the loop nowadays that im useless but into the rabbit hole I go!

John

[mdijkens]

Over time I have built a huge library of reusable functions.
Unfortunately I have to use .BI and .BM files for most.
I would love to be allowed to have Type, Const, Dim and $meta commands between functions
$IncludeOnce is a very valuable new metacommand
Would be nice if already defined Const, Type, variable can also be detected or done once...

For me those 2 additions in QB64pe would make the world for Library functions

[Unseen Machine]

I'm bringing this topic back up as again, it's something that I really think we all as a community need to work on/add too and agree on...that way we can all show our ideas, explain our reasonings and together make a standardised, uniform and collaborative set of extended libs for QB64 PE - All well documented, governed and agreed on...this will help in collaboration, teaching, enticing new users, expansion and allow us ALL to have our work accessible to everyone with ease..

i'd love to have a foundational lib that i'd built gdk on so it would just harmoniously fit with fzxngn (it's a new headache for me!), heck a vertex is vertex a triangle a triangle, a color a color etc...from input to databases, from sounds to visual effects and guis, game tools, and SO MUCH MORE (you've all made some really cool stuff!) so as they'll all work on very similar principles, lets just start FFS! 

2) Code everything assuming that the other people will have different defaults than you.   

 
Sorry Steve, i agree with the rest of your comments but this is not possible...in creating a library you ENFORCE reserved names, functions etc....it's the concession i guess, to use it, you cant abuse it! As long as functions and type use a (group certified) prefix like i do with GDK and any other library i make, it's easily managed and any local variables in subs/functions can be __ or something...though whilst in dev everyone should be free to code as they want...with the idea that once an agreed level of function, naming and the code for a function is "agreed on", it''ll then be converted to fit the again agreed on rules for submision to the library.

Please jump in guys! There's something here for everyone to do! Testing, documenting, suggesting, creating, etc...

Unseen

[SMcNeill]

I think you misunderstand what I'm saying with point 2. 

What I'm saying is this:   You can't write your library knowing every default that a user has.  You have to code so that your library works with *any* default setting.

And what am I talking about with a default setting?

OPTION BASE 0
OPTION BASE 1

You wouldn't know which of those two statements an user of your library might have as their default.  If you just DIM foo(100), you could end up with issues if you assume foo() holds elements from (0 to 100) and the user has set OPTION BASE 1.

Instead of: DIM foo(100)
Explicitly define:  DIM foo(0 to 100)

No matter what option base they have or use, your code is now going to work with either of them without any issues.

---

Second example:

_DEFINE A-Z AS _FLOAT
DEFLNG A-Z
DEFDBL A-Z

You can't just assume that everyone is going to have a default variable type of SINGLE in their code.  

Don't:  DIM SHARED X, Y, Z
Instead:  DIM SHARED AS SINGLE X, Y, Z

Now, regardless of what DEF or _DEFINE an user has in their program, your library isn't going to have any issues meshing with it.

If you just DIM SHARED X, and *expect* X to be a default SINGLE, and the user has a line of DEFLNG A-Z at the top of their code, what's going to happen with your library?  It's probably going to explode and do stuff it's not supposed to do as X might be 0, or X might be 1, but it can never be 0.234567 like it's supposed to be for the library usage.

---

Same with arrays.  You can't *assume* that they're under $DYNAMIC or $STATIC.

Don't write your library with:
$DYNAMIC
DIM foo(10)

Instead, if foo is supposed to be a dynamic array and resizable for your usage:
REDIM foo(0 to 10) AS SINGLE

The first code had multiple possible conflicts with an user's program.  The use of Dynamic might have corrupted a global setting they were relaying on ($STATIC), for whatever reason.  foo() has an undefined lower base, so it *might* be 0; it *might* be 1.  How would you know?  foo() *might* be a SINGLE.  It might just happen to be a string.  Again, how would you know??  You don't know what DEF, _DEFINE, Option Base, $Dynamic/$Static the other guy is going to use in his library.

You have to assume that their default isn't going to match yours, and thus explicitly define your own stuff for a library.

REDIM foo(0 TO 100) AS SINGLE

With the above, it doesn't matter if they use $DYNAMIC or $STATIC.  You've declared that to be a redimmable array from the start.
It also doesn't matter if they have Option Base 0, or Option Base 1.  Your array foo() starts at base 0; you specified that explicitly.
It doesn't matter if they DEFINT A-Z or DEFSTR F or _DEFINE whatever type they want as their default variable tyle.  You've explictly declared foo() to be SINGLE.

---

*THAT'S* the type of thing I was speaking about with point 2 above.  You have to assume that everyone has their own style and that yours isn't going to match.  You can't take things for granted.  Explicitly define what you can and you'll make your library as user friendly as possible.  

And if it's NOT user friendly, you won't have a lot of friends using your library. 

[Unseen Machine]

Yeah, me didnt quite grasp it then...my bad. And as my idea is to have it as OUR library, i think itll be widely used if implemented correctly...im way to haphazard a coder to manage it but i know theres people who love to curate, a whole library of peoples stuff to work from and incorporate...yes we all got different styles but if we all use the same underlying types and functions in our code, we will see a huge leap forward in creativity and reduce limitations...I get a lot of people like to roll their own though...heck i rolled a whole lot in my time!

As always, happy coding!

John