St_W wrote:I think that the gfxlib should be extended to fulfill today's requirements. Examples are e.g. support for PNG and other modern graphics formats, resizeable text rendering (TTF/OTF support) and probably also basic sound support. Basic networking support would be nice too, but I don't know whether the gfxlib would be a suitable place to implement that.
I think that an improvement would be adding the option to use OpenGL for rendering (basically, rendering the graphic buffer on a texture, and then display a quad with such a texture). In this way, it would be possible to use shaders for post-processing, giving a complete new look to FreeBasic graphic.
So far so good. However, these extensions to the libraries have to be done very carefully. I wouldn't e.g. blow up the rtlib with additional features to keep it pretty small. On the other hand I think that the gfxlib can grow and that size is not that important there. This would allow to keep applications small for users not using the gfxlib.
About sound, my idea was to have another library, working just like the graphic library: it should be statically linked only when the sound commands are used, just as the graphic library is linked only when graphic commands are used. Otherwise, every time a sound command is used, all the graphic functions would be linked, and every time a graphic command is used, all the sound functions would be linked. Last but not least... my sound functions are written in FreeBasic, not in C, so they can't be included in a C library.
Code: Select all
A very important decision will be how to introduce those new features in the FB language. We currently already have a situation near to a "keyword hell" and I wouldn't make that even worse by adding a lot of keywords.
I see, but PLAY and SOUND were already used in other basic dialects that FreeBasic is replacing
Additionally to the language I'd be also very careful when introducing new dependencies. For example a dependency on winmm.dll for adding sound support probably wouldn't be problematic because that library is part of every Windows installation. However, whether to add a dependency on some non-standard libraries should be carefully considered.
In fact, with my subroutines, under Windows the only dependency needed is winmm, and under Linux, first it tries to dynamically load ALSA, and if it fails it uses OSS as fallback.
