New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion for new "standard" modules #45

Open
GWRon opened this Issue Dec 20, 2018 · 16 comments

Comments

Projects
None yet
3 participants
@GWRon
Copy link

GWRon commented Dec 20, 2018

After a short hint of Brucey I will start this issue here.

New standard modules

Brucey wrote a big bunch of modules which fill a gap almost any Blitzmax developer will reach once in a (bigger) projects lifetime.
Default brl-modules (brl.mod and the 3rd party modules pub.mod) for example lack convenience functions to retrieve user directories - which was not required on ancient Windows OS but nowerdays is needed for proper functionality (write access to certain directories is limited now).

For now Brucey already adds "sdl.mod" as new default module collection - and I am pretty sure there are some other "small" modules which could get added to the list of default modules (maybe also call it "must have").

Pay attention to something: a default module should be not as big as eg. "libxml.mod" as it should get auto-imported if you do not use the framework command. They should provide some barebone functionality. So back to the "xml" example I would prefer some lightweight XML-lib (tinyxml or so) which does a good but not perfect job with adding 4-5KB to the executable, instead of 1MB.

Naming scheme

while "brl.mod" initially stood for Blitz Research Labs it was suggested to interpret them as "Blitz Runtime Libraries" - which could allow to use brl.mod as "namespace" of the new default modules too.
I would not be against a "default.mod" or "base.mod" ... namespace. Something which each blitzmax-user can recognize as something which is a "provided by default" thingy.

Structure

pub.mod is there to house the "wrappers" for 3rd party libraries. Maybe this one can get reused too? Brl.mod then contains types helping to use the pub.mod-modules (so in essence they provide containers and helper functions to work with the 3rd party libraries).
Talking again about the XML stuff this means "libxml.mod" would belong to "pub.mod" as it wraps the libxml code. Within brl.mod (or something similar) you would then package serialization stuff utilizing the libXML module. Most "game" blitzmax-developers should prefer writing SerializeObject(obj, filename). Similar to calling LoadImage() instead to directly communicating with FreeImage-code.

If you are interested to help - feel free to add your suggestions here (I might edit them to this message). Also discussion about structure, naming scheme etc are nice to have.

@GWRon

This comment has been minimized.

Copy link

GWRon commented Dec 20, 2018

I would for example suggest:

default:

required by certain platforms:

non default ("without framework") but provided:

nice to have but not yet finished or "incorporated":

  • Col's / @davecamp's render2texture at https://github.com/davecamp/Render2Texture is something I would see provided as "basic functionality". It should be as simple as a "DrawImage()" to render to a texture. For now it needs some stuff to work properly with SDL (and so other platforms). Maybe col is interested in bringing the module in the perfect shape to get included as default module?

also needed for a proper "game programming" language:

  • shader support (bgfx.mod needs love - sdl.mod provides surely some way too, but I dunno)
  • streamed audio (possible via rtaudio.mod but it's not "inbuilt" and is not co-existing to the default audio setup of Blitzmax)
@HurryStarfish

This comment has been minimized.

Copy link

HurryStarfish commented Dec 21, 2018

Yeah, we are already "reusing" BRL.mod and Pub.mod and extending them with new modules (BRL.Collections, Pub.xmmintrin, ...), which I think is fine. (Renaming either of them is not an option, since it would break pretty much literally all existing BlitzMax code out there.)

A list like this is a good thing to have. 🙂 The standard libraries could indeed use some additions (as well as improvements in certain places).
The string builder module you're suggesting already exists as BRL.Stringbuilder, so I think you can remove that from the list.
As an addition to the list, I'd like to suggest some modules for non-trivial math datatypes like big integers, complex numbers and vectors. #19 is an issue though; I ran into that problem trying to write a complex number and vector module in the past.

@GWRon

This comment has been minimized.

Copy link

GWRon commented Dec 21, 2018

@HurryStarfish

This comment has been minimized.

Copy link

HurryStarfish commented Dec 21, 2018

Yeah, BaH.BigInt exists, but seems very barebones/unfinished. It could probably be extended though. (And eventually maybe moved into Pub.mod?)
There's also BaH.Rational, which seems related and could also use an upgrade for NG (replace methods with operator overloads, maybe turn it into a struct, ...). This one is dependent on Boost though, so it might not be Pub.mod suitable.

@woollybah

This comment has been minimized.

Copy link
Member

woollybah commented Dec 25, 2018

I've added bah.bsdnt, which is an NG-based big integer module. Bah.bigint was originally added as a dependency for another module. The library is not currently maintained, so there wasn't really much incentive to spend much time implementing it more fully.

@GWRon

This comment has been minimized.

Copy link

GWRon commented Jan 3, 2019

Any other input on what might be useful as standard module for a blitzmax user?
Dunno how much we are still targetting "game developers" instead of "tool and little game creators" ... depending on that we could add a bit of scientific stuff, console stuff (ncurse or so) ...
I would prefer to stay with "games", so concentrate on asset loading, ressource management, ...

@woollybah

This comment has been minimized.

Copy link
Member

woollybah commented Jan 3, 2019

I've been working on a bunch of vector/matrix additions to brl.math.
They are all Structs and utilise method overloading where useful. So far I have SVec2, SVec3, SMat2, SMat3, SMat4 and SQuat.

@woollybah

This comment has been minimized.

Copy link
Member

woollybah commented Jan 3, 2019

I'm also leaning towards having SDL as the primary backend for macOS now, given I don't really have the time to rewrite brl.glgraphics and friends.
I'd also like to insert bgfx into the mix as the low level processor between Max2D and SDL, which would allow us to target things like Metal and Vulkan indirectly - to that it basically wants something like sdl.gl2sdlmax2d to be ported to bgfx, rather than be GL specific. bgfx uses its own GLSL-type shaders, so in theory, it just wants the appropriate shaders implemented...

I've added the BlitzMax samples to bmx-ng, updated for NG, and using the SDL backend (because, why not).

@GWRon

This comment has been minimized.

Copy link

GWRon commented Jan 3, 2019

So Max2D should utilize bgfx.mod - and bgfx.mod uses sdl.mod/* ?

Think a bunch of "maxgui/wxmax"-things might break then (I vaguely remember to have had issues with sdl.mod and wxmax/my gui apps).

@woollybah

This comment has been minimized.

Copy link
Member

woollybah commented Jan 8, 2019

I've just added Pub.mxml and BRL.xml modules.
The mxml library is much smaller, and therefore does not implement as many features as libxml (like compression, namespaces, etc), but provides a reasonable base from which to do xml. Users wanting more, can "upgrade" to bah.libxml.
The API closely resembles the BaH.libxml API in order to make transitioning from one to the other fairly trivial.

@woollybah

This comment has been minimized.

Copy link
Member

woollybah commented Jan 8, 2019

A version of Max2D with a bgfx renderer would bring support for directly rendering to all the APIs that bgfx supports - which includes Metal and Vulkan.
It still requires a "backend" from which to get a context for renderering - like which SDL provides.
It's certainly easier for me to use SDL as a backend than to hand-craft the window/context code for all supported platforms.

@GWRon

This comment has been minimized.

Copy link

GWRon commented Jan 8, 2019

Good job with mxml (will try soon - so prepare for issue reports :-)).

Using SDL for the context creation ... hmm, doesn't it open a can of worms? IF we really used SDL there, the whole thing should be based on SDL (timers etc) - with it's advantages and disadvantages.

But isn't there some cross-platform thingy for the context / window stuff too? I only know of GLFW but it is not for DX ...

@GWRon

This comment has been minimized.

Copy link

GWRon commented Jan 8, 2019

I am asking above as "SDL" consists of so many things ... and having "beasts" within the modules will sooner or later lead to either "duplicated functionality" or naming confusing or even more trickier problems.
Having a simple module/library for a limited purpose is more like the initial "module" approach of BlitzMax.
In other words: you should always think twice if you need multiple "sub folders" for modules (sdlimage, sdl, sdlaudio, ...) - even with bgfx you already get a load of modules justifying the use of a custom "main module name" ([b]gfx.mod).

So if possible we should try to have some kind of "brl.mod/graphicswindow.mod" or so. It should be avoided to replace all the timer stuff (like sdl.mod does for now) - until of course this is all automatically handled and does not lead to issues putting of newcomers.

@GWRon

This comment has been minimized.

Copy link

GWRon commented Jan 14, 2019

"stringbuilder" could be added to a generic "brl.stringhelper" or "brl.string" module containing other functionality too.
Same as a "brl.math" might contain all the vector stuff and so on.

@woollybah

This comment has been minimized.

Copy link
Member

woollybah commented Jan 14, 2019

There's already brl.stringbuilder.

@GWRon

This comment has been minimized.

Copy link

GWRon commented Jan 15, 2019

Updated my list above with current state.

Anybody with other ideas for default modules?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment