Messages

1

General discussions / SFML Bindings creation mode for Emacs

« on: January 15, 2015, 09:47:55 pm »

Some of you will possibly remember that I was working on a Common Lisp Binding. No, I haven't given up, I just switched my focus to the Clasp compiler for Common Lisp, which allows direct integration of C++ libraries (no detour via C Bindings).
Anyway, as Clasp is still in early alpha, I don't think my bindings are of interest yet (SFML is practically the first library to run on it).

But I realized that something I created on the side may be of interest to other people who write or maintain bindings. My bindings creator mode for Emacs.
It does not automatically create the complete bindings, but it very much simplifies the process. I have two side-by-side windows and just put the cursor somewhere over a function or its comment, hit a key combination, and the binding for the function is automatically created in the file displayed in the other window. The same goes for classes, enums, etc., and includes differentiation between overloaded functions, a transposal of the documentation, etc..
Thus, the writer still has to go over every file, look at every function and think about it a little (which I think is good), but the repetitive task of copy&pasting and rewriting things is done away with.

My mode was written for the clbind syntax, but it can easily be adapted for any other bindings - all the necessary parsing is in there, so you just have to replace the clbind output with whatever format you need. It doesn't rely on any external parser, it simply uses regular expressions and relies on the strict adherence of the SFML files to the styleguide, which made my work much easier.

Anyway, here is the link:
https://github.com/HeyFlash/clasp-stuff/blob/master/cpp-to-clbind.el

And to give you an idea of what a result might look like (practically everything in there is generated:
https://github.com/HeyFlash/SFML/blob/master/src/SFML/Window/ClaspBindingWindow.cpp

2

Feature requests / Re: Call and return by reference in CSFML

« on: June 03, 2014, 07:26:37 am »

In some cases, D is able to interface directly with C++, so I do that when I can and it makes sense. That means that some functions in DSFML-C expect C++ objects to be passed to them by address since those can be created in the D code.

OK, so I can't use it either.   

3

Feature requests / Re: Call and return by reference in CSFML

« on: June 02, 2014, 09:13:26 pm »

Please be aware that DSFML-C is written specifically to interface with the D binding so it might not fit right for lisp in all cases.

How does this specificity manifest itself?
I thought it was just a normal C binding without structs.

4

Feature requests / Re: Call and return by reference in CSFML

« on: June 02, 2014, 07:56:02 pm »

It would only add confusion

Having two versions of each function in CSFML would be confusing. Having a fork which is dedicated to this modification would be a lot clearer in my opinion.

unnecessary work of re-merging if SFML or CSFML is updated

Updating these functions every time CSFML is updated is not unnecessary work, it has to be done anyway. Of course it's easier for you if it's me who does it...

I'm sorry, I just realized that I made this request under false preconceptions.
For whatever reasons I thought that rogerlevy's list posted in this thread was accurate, and I still think that it would have been a good idea for ~10 functions (and little extra work to maintain).
However, knowing the CSFML source I should have known better, as this list contains none of the functions that return vectors, rects and similar stuff (I think I realized this a few weeks ago, but had forgotten, as I did not work on the binding in the meantime).
Thus I realize that having alternatives for that many functions might be confusing, and is additional work to maintain.

CSFML is being provided precompiled for many systems, and people would just need to download the binding + CSFML

You can provide your own releases. And since people interested in this fork would be bindings creators, I don't think they would be afraid to compile it if they can't find a precompiled version for their platform.

Well, I hope that the people interested in this fork would be Common Lisp Users. And it would have been nice to just download the appropriate dll, load the bindings via quicklisp and everything would work, regardless of system. Alas, that's not gonna be.

There's a reason SDL only passes pointers.

Did they say it is for this particular reason?

No, it was an assumption on my part, because I couldn't think of a better reason other than speed (but they do it even for all structs). It might be one of several reasons, or not play a role.

So I'll see what I'll do. Possibly DSFML-C is the best alternative, as I really want to avoid having yet another fork unless I really have to. As I plan to have high-level lispy abstractions modeled on SFML anyway, the deconstructed parameters would be hidden anyway.

5

Feature requests / Re: Call and return by reference in CSFML

« on: June 02, 2014, 07:25:11 am »

I don't know if this helps you out at all, but you could look at DSFML-C, which is a modified version of CSFML that removed all POD structs (sfVector2f, sfTime, etc) in lieu of using a set of scalars instead.

For example:

CSFML_GRAPHICS_API sfImage* sfImage_createFromColor(unsigned int width, unsigned int height, sfColor color);

Looks like

DSFML_GRAPHICS_API sfImage* sfImage_createFromColor(DUint width, DUint height, DUbyte r, DUbyte b, DUbyte g, DUbyte a);

(though now I realize this function passes the color in rbga order instead of rgba order )

Feel free to use it if you want, but some of it (the audio stuff) is a little experimental. Just a heads up.

Thanks, this one would actually work. 
Deconstructing all structs seems a little overkill for my purposes, though, as I only have problems with very few functions, and you lose some readability. Still, it'd be a better alternative than having to maintain yet another fork, IMO.

6

Feature requests / Re: Call and return by reference in CSFML

« on: June 01, 2014, 11:18:27 pm »

If it's an alternative implementation, why does it have to be in CSFML? Can't you fork it and do the modifications in your own modified CSFML?

Well, of course I can do that. But what would it be good for? It would only add confusion and unnecessary work of re-merging if SFML or CSFML is updated. CSFML is being provided precompiled for many systems, and people would just need to download the binding + CSFML.
It would also enable other people with similar problems to write a binding directly to CSFML. There's a reason SDL only passes pointers.

Again, as I don't want to cause any work, I'd fork it anyway, and only ask to submit if the binding gets finished. It possibly was a bit premature to ask, as that is still a way off. 

I guess it might be helpful to provide a bit more information on your idea, especially since the bumped thread is like four years old.

The basic idea is to just provide alternative functions that pass pointers, e.g.

CSFML_GRAPHICS_API sfRenderWindow *     sfRenderWindow_create (sfVideoMode mode, const char *title, sfUint32 style, const sfContextSettings *settings)
=>
CSFML_GRAPHICS_API sfRenderWindow *     sfRenderWindow_create (sfVideoMode *mode, const char *title, sfUint32 style, const sfContextSettings *settings)

and

CSFML_GRAPHICS_API sfContextSettings    sfRenderWindow_getSettings (const sfRenderWindow *renderWindow)
=>
CSFML_GRAPHICS_API void sfRenderWindow_getSettings (const sfRenderWindow *renderWindow, sfContextSettings *settings)

I'm not so sure about the second example, or if it's better to create a new sfContextSettings struct and return it, but I'd rather have a "who creates it, is responsible" approach.

If anyone is interested, I asked a question on the Common Lisp side of this on StackOverflow a while back, to make sure I'm not missing anything.

7

Feature requests / Re: Call and return by reference in CSFML

« on: June 01, 2014, 07:57:45 pm »

How would alternative implementations that do not change any of the functions that already exist break anything?

8

Feature requests / Re: Call and return by reference in CSFML

« on: May 31, 2014, 07:31:37 pm »

I know this is an old topic, but may I add my support to this request?
Forth is not the only language that is designed this way, it is true for Common Lisp (and other languages) as well.
The functions that get or return structs on stack would not need to be replaced, it would be OK to merely implement an alternative and make it clear in the documentation that they are only to be used for bindings.

I can do the additions myself, all I'd ask is that *if* I ever finish the Common Lisp binding, I'd be allowed to commit the changes back to CSFML, so that the binding would compatible with the main branch, without needing an additional wrapper dll.

9

General / Re: New install of Qt 5.2.1 and SFML 2.1

« on: May 15, 2014, 10:57:00 pm »

BTW..  I sort of figured you could use Qt and SFML in Express without the Qt plugin.  But you loose all of the visual capabilities of Creator. 

I don't know what other visual capabilities the Creator has, but if you are talking about GUI design, you can use Qt Designer (designer.exe in the bin folder). Just add a ui to the .pro, and qmake will set everything up so that it works in Visual Studio. Then in Visual Studio you can set designer.exe to be the default for .ui files, and it will open them on double click.

10

General / Re: New install of Qt 5.2.1 and SFML 2.1

« on: May 14, 2014, 11:35:00 pm »

Actually there is a version of Qt and Qt Creator that was built using MVSC 2010 available for download from the Qt webpage.  I needed that because a 3rd party API I am using was also built with MVSC 2010.  So in order to use Qt with my 3rd party product it has to be compatible.  I found out the hard way because I started off with the MinGW version first and nothing would link.

I am using Qt Creator because I don't have access to the full version of MVSC 2010 and the Qt plug-in does not work with express.  I don't have a choice.

Laurent was right, it really was a long time ago.
If you'd rather use visual studio, you don't need the plugin. I don't use it either. You can create a Visual Studio project from a .pro file with "qmake -tp vc".

11

General / Re: New install of Qt 5.2.1 and SFML 2.1

« on: May 13, 2014, 11:22:38 pm »

I do not quite understand your configuration. You say that you have installed the MVSC (MSVC?) version of Qt, but then you say you are using Qt Creator.

This is not a problem at all. QtCreator can use both gcc and VC++.

OK, this must have changed since the last time I used Qt Creator.

12

General / Re: New install of Qt 5.2.1 and SFML 2.1

« on: May 13, 2014, 10:47:21 pm »

I do not quite understand your configuration. You say that you have installed the MVSC (MSVC?) version of Qt, but then you say you are using Qt Creator.
If you are using the MSVC version of SFML, but the Qt Creator version of Qt (which compiles via mingw, IIRC), it will not work.
The SFML dlls, the Qt dlls, and your application need to be built with the same compiler.

I am running the audio module of SFML in a Qt application, and it works without a problem, but I am running Visual Studio versions only.

13

C / Re: CSFML Documentation vs. SFML Documentation

« on: May 10, 2014, 12:21:45 pm »

I see.
When I get to it, I can have a look at updating it. I don't want to promise anything, though, I should be working on other stuff anyway. 

14

C / CSFML Documentation vs. SFML Documentation

« on: May 10, 2014, 10:28:38 am »

Hi,
I am trying to write a Common Lisp binding. As the CSFML function definitions are very regular, I intend to automate as much as possible. I'd like to also automatically generate the documentation string, by parsing it together with the function definition.
However, I have noticed, that the CSFML documentation is very abbreviated compared to the SFML documentation. As an example, here is the sfRenderWindow_create documentation:

////////////////////////////////////////////////////////////
/// \brief Construct a new render window
///
/// \param mode     Video mode to use
/// \param title    Title of the window
/// \param style    Window style
/// \param settings Creation settings (pass NULL to use default values)
///
////////////////////////////////////////////////////////////

The documentation for the appropriate constructor in SFML is

////////////////////////////////////////////////////////////
/// \brief Construct a new window
///
/// This constructor creates the window with the size and pixel
/// depth defined in \a mode. An optional style can be passed to
/// customize the look and behaviour of the window (borders,
/// title bar, resizable, closable, ...).
///
/// The fourth parameter is an optional structure specifying
/// advanced OpenGL context settings such as antialiasing,
/// depth-buffer bits, etc. You shouldn't care about these
/// parameters for a regular usage of the graphics module.
///
/// \param mode     Video mode to use (defines the width, height and depth of the rendering area of the window)
/// \param title    Title of the window
/// \param style    Window style
/// \param settings Additional settings for the underlying OpenGL context
///
////////////////////////////////////////////////////////////
 

It is similar for other functions, often you have to consult the original documentation to fully understand the function.
I would assume that it'd be easier to just copy&paste the original documentation for the CSFML binding, instead of writing an abbreviated documentation. So is there a reason for this?

15

General discussions / Re: Better keyboard handling

« on: April 20, 2014, 07:39:24 pm »

Should we try to make some concrete proposals for how SFML should implement/expose this stuff?  My first thought is simply giving the key event "scancode", "location" and "vkey" properties.

I don't know, I had the impression that Laurent likes to think about those things by himself.
If he wants us to, we can try to make some proposals.