BlitzMax (NG) - New Standard Modules?

[Derron]

While I posted this on the bmx-ng github issue page already, here a short repetion:


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.


... more at the source: https://github.com/bmx-ng/bmx-ng/issues/45



There I already made a lot of suggestions - and others contributed too. The idea is to find out what the "average joe"-BlitzMax user assumes to get provided by a language toolkit like BlitzMax. So provided XML/JSON support, serialization, ... and so on.

Maybe some of you - who do not lurk around in the issues on the bmx-ng repo at github - are willed to post their ideas here too? It's your chance to help creating the language package you like to have had 10 years ago ;-)



bye
Ron

[Derron]

Stuff like "xml", "json", filetype support, ... are best done by reusing a wheel someone already (re-)invented - aka using 3rd party libraries and wrapping them. This allows to keep maintenance consuming less work hours (others update and fix stuff - you "just" need to update the wrapper).

This means - if you suggest something less trivial (so no one-file.bmx-solutions like TLinkedList, TMap ... stuff which is self-contained in its own file) then you might already have a look if there is a library existing - having a liberal licence (allowing for the static linking we want to do).

While some libraries are "feature complete" (like libXML) you might want to have a look if there is a lightweight solution available too (like tinyXML or smallXML or ...). You often do not need all features and packaging all those big libraries into your binary (without "framework command") ... you would get longer compilation/linking times and of course bigger files if you do. So sometimes "less is more". Still we want those features which make game creation a bit more convenient.

- png/jpg support (no need for tiff, tga, ... as default one)
- streamed ogg audio (albeit mp3 is free now too)
- maybe even video playback (ogv ... for cutscenes ;-))
- joypad/joystick support
and so on and so forth


Some stuff might be doable with existing modules - other stuff (dunno, Steam?) not. Still some of these things are essential for nearly every "today's game" (so not Steam ;-)). These "essentials" is what I was asking you for.


bye
Ron

[fielder]

for example.. all my applications are using these modules:

Code Select Expand

Framework brl.standardio
Import brl.retro
Import BRL.wavloader
Import BRL.FreeTypeFont
Import BRL.PNGLoader
Import bah.clipboard
Import bah.volumes

?MacOS
Import BRL.glmax2d
Import brl.freeaudioaudio
?win32x86
Import brl.d3d9max2d
Import brl.directsoundaudio
Import "application32.o"
?win32x64
Import brl.d3d9max2d
Import brl.directsoundaudio
Import "application64.o"
?Linux
Import BRL.glmax2d
Import brl.freeaudioaudio
Import "-ldl"
?

[Derron]

They are already standard modules ... without "Framework" at the top of your source code you would already import many many of these modules (all the brl.* stuff).

"clipboard" is what I suggested too - to be shipped with NG, same for "volumes". Both are mandatory these days. For a more complete list have a look at the linked issue in the first post.


bye
Ron

[Derron]

Brucey added some standard modules already:
Brl.json
Brl.xml (wrapping "mini xml" not the bigger "libxml")

Still there is surely something YOU as NG developer think would suit well as a default shipped module - or a lightweight module to some heavy module you use for now.


So - come up with your ideas!


bye
Ron

[Brucey]

brl.clipboard and brl.volumes are now part of the standard modules, along with brl.xml and brl.json as Derron alludes to.
I'm also looking at adding brl.geometry (for want of a better name) which adds basic vector and matrix stuff - in such a way that you can add vectors with a + b, for example.

[Henri]

Hi,

maybe little on the fringe for basic, but database functionality might be considered as a nice to have on a modern environment.

Also, Cairo is something that I use a lot, like for example making PDF files.

-Henri

[Derron]

Think cairo is something which could stay in bah.mod - it is useful for sure - but imho nothing you would consider "almost used everyday" in your little game/app projects.

Maybe if we had some kind of "serious app"-package ;-)


@ Database
SQLite is small and lightweight - yet I am not sure if people use DBs for everydays apps. Json/XML might be used for eg. asset loading (by 3rdparty code or your own) and so might the flatfile DB sqlite. But until all 3 are wrapped under the hood of a generic reader/writer thing (like a TStream) I think it keeps being a "special use case".

Standard modules should be stuff you need when creating a simple but advanced game/tool in BlitzMax NG (at least in my opinion).

So it should contain stuff to enable proper runs on modern OSs -> use the right filepaths (brl.volumes) or to let your tools interact with the clipboard (copy paste strings to your game - or so). Clipboard is not that important but pretty lightweight so no biggy.
Next to it you need modules to load assets/media, to play sounds/music, to store and read files/configurations.

Remember that BlitzMax was kind of game oriented - so the modules should be so too. I am with your that bah.dbsqlite are cool modules and could even be provided "by default" with BlitzMax NG releases - but it should be under another "module scope" (or how you call BRL and PUB) to avoid getting imported automatically.



Things of course would be way different if the use of "framework" was mandatory (against the principles of keeping the language "easy") - as then not all these "standard modules" would get auto-imported.



bye
Ron

[fielder]

maybe it's not necessary to add more modules ... volumes and clipboard are good... (maybe a printing module? ... an Cairo PDF seems the only alternative to a real printer)
but it's necessary to add small examples of module use...

[Derron]

Most of bruceys library wrappers/modules contain examples.

What do you mean with examples...something like the code pieces within the documentation / command-help?


Bye
Ron

[fielder]

.something like the code pieces within the documentation / command-help?

yes... but maybe the code is too "long" to be placed on this "help" section. or maybe the "help" section is not the right place for module's infos...