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