PureBasic Forums - English

Hi all,

As part of another project which I'm engaged in, I've started wrapping SFML to provide a slightly more modern 2D graphics system into PureBasic (as well as introducing Squirrel scripting, but that is still partially done so not yet ready to be offered).

After a couple of long weekends of crunching, I'd like to offer an interface to SFML including the following features;

• Open an SFML rendering screen on a PureBasic window or gadget.
• Ability to open multiple screens (though must all be on the main thread because OpenGL)
• Screen control functions
• Loading fonts from memory or file (Supports: TrueType, Type 1, CFF, OpenType, SFNT, X11 PCF, Windows FNT, BDF, PFR and Type 42.)
• Creating text drawables with transformation (scale, rotate, etc), outline and fill and rendering to the screen.
• Loading textures from memory or file (Supports: bmp, png, tga, jpg, gif, psd, hdr and pic -- Avoid jpeg as not all jpeg encoding like progressive is supported)
• Creating sprites from textures, sprite transformation and tinted colouring.
• Partially implemented event handling (Keyboard and Mouse support)
• Ability to resize the SFML screen parent and have the screen view resize (not stretch) with it.
• Colour functions (mfwRGBA, mfwRed, mfwGreen, mfwBlue, mfwAlpha) -- Use these as PureBasic's colour functions aren't compatible due to how colours are stored in 32bit integers.

Alongside the graphics library, I've included a few other components of the framework it's being developed into;

• Logging component which allows you to define custom logger outputs (console, file, etc). Console logger is included with the sample
• Interval functions module - Call a procedure every x milliseconds (Procedure must return true to repeat, or it'll only fire once)
• 143 named colour preset constants

Included:

• Windows x86, x64 DLL (mfwlib.dll) which houses all the components and handles the interfacing. SFML and subsequent components are compiled in Unicode for seamless integration with PureBasic
  (Linux will also be included in the distant future when the main project this is part of becomes more mature)

All in all so far there are 97 functions in the graphics library alone, and more will be added over time (such as additional event handling, views, shaders), and I will endeavour to share it with you.



Current backlog:

• Complete Events handling (Handling Joystick, unicode character input)
• Begin wrapping and binding handling of SFML views.
• Identify a suitable automated documentation tool to create a reference guide.
• Discussion about it's open sourcing, and consideration of related project to see if separation can be formed to isolate this library fully into open source domain.

Distant backlog:

• Investigate how much of the shader library can be implemented
• Introduce particle system
• Retrospective on Squirrel-Language requirement and introduce low-level module for wrapped methods, as well as higher-level module for usage.

Feel free to clone and check out the sample included. Sorry there's no documentation (yet) but automated documentation is on my backlog for it for the near future.

GitLab Project Group
https://gitlab.com/mfwlib

Samples Repo
https://gitlab.com/mfwlib/sample

Include Repo
https://gitlab.com/mfwlib/mfw

DLL Source Repo
https://gitlab.com/mfwlib/mfwlib-src


This is provided as-is under CoffeeWare so if you like it then please feel free to get me a coffee https://ko-fi.com/randodev - it'd be greatly appreciated.

How do I know what commands are there?

AMpos wrote:How do I know what commands are there?

For now you'll have to look at the file mfw/graphics.pbi in the Module declaration to get an overview of the commands available. They should be quite self-explanatory, but if you have any questions then please feel free to ask them, or better yet check out the SFML documentation which will provide a good insight.

Screen functions: https://www.sfml-dev.org/documentation/ ... Window.php
Text functions: https://www.sfml-dev.org/documentation/ ... _1Text.php
Texture functions: https://www.sfml-dev.org/documentation/ ... exture.php
Sprite functions: https://www.sfml-dev.org/documentation/ ... Sprite.php

Looks good.
But the DLL are close codes. And I never use codes from third parties that are not open.
Besides that, maybe you could use them for macOS and Linux.

mk-soft wrote:Looks good.
But the DLL are close codes. And I never use codes from third parties that are not open.
Besides that, maybe you could use them for macOS and Linux.

The code in the DLL is purely just a lot of wrapping, prototypes and some glue code with external libraries statically linked in (I can assure you nothing malicious);

If you want to check the source out then it's here: https://gitlab.com/mfwlib/mfwlib-src - though please understand I can offer zero support in setting up all the third party dependencies and compilation haha.

As for support for Linux, or Mac (though Mac would be less likely for now), when more updates are done on the main project this is associated with, I'll split the code repo into two (one for the project, one for public release) as some of the code going into the framework (including shared library) will be exclusive to the project I'm working on, and offer pre-compiled versions for windows and linux. For now I'm just offering SFML stuff since I imagine it'll be very useful to some

Great engine! but I agree with mk-soft, libraries without source would not be good choices, there were so many engines out there but soon be dead as the author disappeared. So make it open source would be great

IndigoFuzz wrote:

mk-soft wrote:Looks good.
But the DLL are close codes. And I never use codes from third parties that are not open.
Besides that, maybe you could use them for macOS and Linux.

The code in the DLL is purely just a lot of wrapping, prototypes and some glue code with external libraries statically linked in (I can assure you nothing malicious);

If you want to check the source out then it's here: https://www.indigofuzz.com/stuff/mfwlib_0.1_src.zip - though please understand I can offer zero support in setting up all the third party dependencies and compilation haha.

As for support for Linux, or Mac (though Mac would be less likely for now), when more updates are done on the main project this is associated with, I'll split the code repo into two (one for the project, one for public release) as some of the code going into the framework (including shared library) will be exclusive to the project I'm working on, and offer pre-compiled versions for windows and linux. For now I'm just offering SFML stuff since I imagine it'll be very useful to some

the source file seems not working for me, can you post another link, etc. Onedrive or Dropbox?

leonhardt wrote:

IndigoFuzz wrote:

mk-soft wrote:Looks good.
But the DLL are close codes. And I never use codes from third parties that are not open.
Besides that, maybe you could use them for macOS and Linux.

The code in the DLL is purely just a lot of wrapping, prototypes and some glue code with external libraries statically linked in (I can assure you nothing malicious);

If you want to check the source out then it's here: https://www.indigofuzz.com/stuff/mfwlib_0.1_src.zip - though please understand I can offer zero support in setting up all the third party dependencies and compilation haha.

As for support for Linux, or Mac (though Mac would be less likely for now), when more updates are done on the main project this is associated with, I'll split the code repo into two (one for the project, one for public release) as some of the code going into the framework (including shared library) will be exclusive to the project I'm working on, and offer pre-compiled versions for windows and linux. For now I'm just offering SFML stuff since I imagine it'll be very useful to some

the source file seems not working for me, can you post another link, etc. Onedrive or Dropbox?

My apologies - link updated

leonhardt wrote:Great engine! but I agree with mk-soft, libraries without source would not be good choices, there were so many engines out there but soon be dead as the author disappeared. So make it open source would be great

It's not going anywhere anytime soon, I can assure you of that - and like I said when things have matured a bit with the project this was initially designed for I'll break it up so that the wrapper becomes its own separate entity, hosted on gitlab for people to play with

Without disclosing the source code, they are riding a dead horse here.

I think, nobody wants to use it because it has no future.

Best Regards Saki

Saki wrote:Without disclosing the source code, they are riding a dead horse here.

I think, nobody wants to use it because it has no future.

Best Regards Saki

If you do look, the source code is provided above. Look, folks, if you want to use it then feel free. If not? That's absolutely fine too haha

Read through the thread and you'll see the intention to opensource once things are more mature with it rather than non-constructive response. And people wonder why this community doesn't attract more contributors and active members

Hi IndigoFuzz,

As I had have a lot of troubles with 2D graphics in PB.
I did some small stuff with SFML in C++ to see and test.

And I must say, I loved SFML ...
and I love also PB, and if I see that these two are combined ...
I just love it.

I'm not a good C++ programmer, so I returned to PB
and I will use your stuff, but then it must be bug free.

It is already fine to see the first things.

thanks,
marc

marc_256 wrote:Hi IndigoFuzz,

As I had have a lot of troubles with 2D graphics in PB.
I did some small stuff with SFML in C++ to see and test.

And I must say, I loved SFML ...
and I love also PB, and if I see that these two are combined ...
I just love it.

I'm not a good C++ programmer, so I returned to PB
and I will use your stuff, but then it must be bug free.

It is already fine to see the first things.

thanks,
marc

Hey Marc,

Good to hear There should be no bugs at all with this, at least on the bridge between PB and SFML, so long as pointers don't accidentally get modified, and correct structures are used when required then it should be quite robust.

Either this evening, or tomorrow I'll be completing the events bindings to just tick the box in those being complete and throughout the next week will work on managing views just to add a bit of enhancement. When that's done I'll update the links, and it will be the simple case of overwrite the existing mfw directory and the DLLs (which are included in the mfw/bin/msw/ directory)

Hopefully the next update will be by Friday, or Sunday at the latest.

I've added a backlog to the original post just to indicate progress to a next release, as well as a distant backlog to show planned features.

PB getting access to a capable gfx library is nice to see.
Good luck

IndigoFuzz wrote:the source code is provided above

They probably missed that. A lot of us are wary of using libs without source because we've been bitten before when the lib owners suddenly disappeared and left our apps in limbo. So don't get too hard on us; we're still licking our wounds from those experiences.