Messages

1

General / Interest in Lua binding (also embeddable in C++ application)?

« on: February 21, 2015, 06:50:22 pm »

Hello,

I have began to develop an SFML binding to the Lua scripting language. Since this was originally only intended as a test for my general Lua to C++ binding library apollo, it is in a very rough shape right now (e.g. the graphics module is incomplete, there are probably lots of bugs, …). Anyway, it's already enough to run a Lua version of SFML's Pong example.

An executable demo (Windows + MSVC12 + Lua 5.2 with pong example and all required DLLs) for you to play around with is available here: https://dl.dropboxusercontent.com/u/1802511/os/lsfml-demo-lua52-msvc12.zip.
Run lua.exe pong.lua from the command line in the demo directory to start the pong example.

The source code is here: https://github.com/Oberon00/lsfml/

While it might currently not work (demo/alpha stage), this binding could run on Lua 5.1 ‒ 5.3 and is generally cross-platform (for MSVC12 and any platform with a recent clang or gcc at least) with a little effort put into it.

Also, as I teased in the title, a special feature of this binding would be (lacks a triviality right now to be actually usable) that it is embeddable in a C++ host application that uses my apollo library. This means that using this binding, you could easily add scripting to your SFML-based game.

Since I do not actually have an use for this myself right now (beyond demonstrating the abilities of apollo), I'm asking here if there is interest in this binding. If so, I may continue development.

2

Feature requests / Re: Improved Iterator Support for sf::String

« on: June 24, 2013, 11:14:41 am »

One has to know the encodings anyway: If you initialize a string with

sf::Text text("hello");

then "hello" has to have the current global locale's encoding. It can't e.g. be encoded in UTF-8 when the locale's encoding is Latin 1  [of course "hello" can, but strings containing special characters probably can't].

But if implicit conversion is desired, sf::String could be used just for this: In function parameters and return values. The library and users are then free to store and use the data as either std::basic_string<Uint32>, std::string or any other type to which a conversion exists.  All that's missing is a convenience

typedef std::basic_string<sf::Uint32> sf::Utf32String

and

sf::String::operator  sf::Utf32String() const;

. Then no one has to bother performing string operations on sf::String but can use the full power of std::basic_string -- without API incompatibilities.

3

Feature requests / Re: Improved Iterator Support for sf::String

« on: June 24, 2013, 10:42:22 am »

Why was sf::String introduced in the first place instead of directly using the internal std::basic_string<Uint32> plus maybe a few additional sf::Utf helper functions for converting whole strings to/from ANSI? If I think of it, I don't see any real benefit in the class.

4

Feature requests / Re: Relative Mouse Movement (Mouse Capture)

« on: November 03, 2012, 04:34:34 pm »

If this is ever going to be implemented, Chrome might serve as a reference implementation: http://code.google.com/p/chromium/source/search?q=%3A%3ALockMouse%5C%28%5C%29.

5

Graphics / Re: SFML's example can't be build anymore with static std libs and VS10+11

« on: October 31, 2012, 09:47:37 am »

Omitting the default library name (/Zl) is not enough. Like you cannot link the object files of an SFML application compiled with SFML_STATIC defined to the sfml-s-* libraries, you cannot link an .lib file compiled with /MD to an application compiled with /MT (although the opposite works; see below): Look at  the crtdefs.h header: There you will find the following lines:

#ifndef _CRTIMP
#ifdef  _DLL
#define _CRTIMP __declspec(dllimport)
#else   /* ndef _DLL */
#define _CRTIMP
#endif  /* _DLL */
#endif  /* _CRTIMP */

This is basically the same, what SFML does with its SFML_API #define, and thats the problem: either you dllimport your functions, or you do not. Still, if you omit the dllimport, it should work both with and without the DLL, albeit a bit slower, according to http://blogs.msdn.com/b/russellk/archive/2005/03/20/399465.aspx. So compiling the libraries with /MT might work for all configurations. I don't think, however, that a loss of speed when calling default library functions like malloc is desireable, so I would still opt for an additional freetype-s.lib.

6

Graphics / Re: SFML's example can't be build anymore with static std libs and VS10+11

« on: October 27, 2012, 12:19:46 pm »

Maybe you fixed the "... conflicts with default library ..." warning by recompiling the external libraries using the non-static default libraries (DLL-Runtime, /MTd, MDd). But you would have to supply two versions of them, one for the static and one for the DLL runtime.

7

SFML website / Spam user?

« on: April 11, 2012, 05:19:54 pm »

Sorting members by post count shows an user called frankscott39 on top, who has a whopping 134217.720 posts per day (!) and a signature which looks like spam.
However, when clicking show posts no single post shows up. I suspect, that the posts are blocked by some spam filter but counted neverthless.

8

Graphics / Re: Too many sprites?

« on: March 30, 2012, 09:15:50 pm »

With vectors you can do std::vector<std::vector<sf::Sprite> >, although in this case a 2 dimensional array has higher performance.

9

Graphics / Re: Too many sprites?

« on: March 30, 2012, 03:39:48 pm »

Since it's easy to forget the delete[] Tile; part or because of some exceptions it will never get called it's best to use RAII and therefor std::auto_ptr.

Never ever use new for dynamic arrays in C++ (see the C++ FAQ entry on Why should I use container classes rather than simple arrays?). Instead use an std::vector. With it, the above snippet could be rewritten as

unsigned int WorldXS = 100;
unsigned int WorldYS = 105;
std::vector<sf::Sprite> Tile(WorldXS * WorldYS);
// no delete[] or delete necessary
 

std::auto_ptr would cause undefined behavior here, as it uses delete instead of delete[].

Unfortunatly it's only in C++11 so you need one of the newer compilers.

Quite the opposite is true: It is old C++ 03 and deprecated in C++11 in favor of unique_ptr.

These are all basic C++ problems, I would recommend working through a good book on the language, before trying and struggling with SFML (That's just my advice, I do not want to offense anyone.)

10

Feature requests / Request: Exceptionhandling?

« on: March 11, 2012, 05:23:27 pm »

Yep, I still don't know how to translate them to C.

Just catch them and return error codes? e.g

Code: [Select]


try
{
    texture->This->LoadFromFile(filename, rect);
}
catch (Exception& e)
{
    //cleanup
   
    SetLastError(e.what().c_str());
    return NULL;
}

The C binding itself is in C++, so it can handle exceptions.

11

Feature requests / Request: Exceptionhandling?

« on: March 11, 2012, 05:07:15 pm »

As a reminder: Reworking the error handling mechanism is better done before than after the release of SFML 2.

The problem with exceptions thrown across shared library boundaries, seems (according to the quick googling I just did )not to be a showstopper, as long as (a) SFML is not loaded with LoadLibrary or dlopen and (b) application and library are compiled/linked with the same compiler with the same version, which must be done anyway.
As Nexus mentioned it works well at least in Boost and other big libraries. The Boost Filesystem library, which is among the few boost libraries that need to be compiled (also as a shared library!) for example, makes extensive use of exceptions.

But if you absolutely do not want to use exceptions and keep the return codes, a GetLastError/SetLastError mechanism, like Disch proposed would still be a big improvement over the current stream-based system, which makes it very difficult to log the error messages to a file in a customized format (e.g. HTML), display them to the user (in a non-console application), translate them to exceptions yourself, or generally do anything useful with them.
Maybe you could also call a user defined callback, or raise a signal.

12

Feature requests / Make properties of Window readable

« on: February 26, 2012, 01:02:39 pm »

The Window class has (too) many write-only properties, i.e. setters without corresponding getters (I found 10, to be exact):

• SetPosition (pull request #168, issue #15)
  
• EnableVerticalSync (SetVerticalSyncEnabled)
• SetFrameRateLimit
• SetJoystickThreshold
• video mode (bits per pixel) and style (Create and constructor)
• SetTitle
• Show(bool): Could also be named SetVisible
• EnableKeyRepeat (SetKeyRepeatEnabled)
• SetIcon
• ShowMouseCursor
• (SetSize has GetWidth and GetHeight, but could be more consistent (would also affect RenderTarget, RenderWindow))

Many of them could be useful e.g. for displaying an options-dialog, without having to save e.g. the joystick threshold in another variable.
In addition, I suspect this to be the reason for the usage SetXx methods  instead of properties in SMFL.net, am I right?

Imho, this is all not high priority but should be considered for 2.x.

13

General discussions / New naming convention

« on: January 25, 2012, 01:52:39 pm »

SFML has to provide iterator and const_iterator, otherwise the containers will not be usable in BOOST_FOREACH or the C++11 range based for loops ("foreach loops").
I propose to follow the Qt way here and provide both, one of them as typedef.

14

General discussions / New naming convention

« on: January 17, 2012, 06:38:45 pm »

I think using native Windows API and SFML together is not that uncommon: For example, if I wanted to program a screensaver in SFML I had to use WinAPI, because for the preview I get a window handle which I have to use as the parent for my window.

To illustrate:
(random screenshot found with Google).
In this image, the program "ScreenOGL.scr" was started with eg. /p:12345, where 12345 is the handle of the parent window.

And after all, there is even the win32 example included in SFML.

15

General discussions / New naming convention

« on: January 17, 2012, 06:19:45 pm »

Hah! I finally found a very practical reason for camelCase!

Code: [Select]

#include <Windows.h>
Every WinAPI function is #defined so that namespaces, scope, etc. are rendered useless. For example the really existing code

Code: [Select]


#ifdef UNICODE
#define GetTextMetrics  GetTextMetricsW
#else
#define GetTextMetrics  GetTextMetricsA
#endif // !UNICODE

will change the hypothethically code myText.GetTextMetrics() to myText.GetTextMetricsW() (or myText.GetTextMetricsA()), causing compiler or linker errors or "function not found in DLL" errors.
There are also lots of other dangerous names like LoadImage, LoadIcon, PeekMessage, ...
So if SFML's names do not clash with them, user code which does not want to mix in yet another naming style might get problems when using native WinAPI.
Microsoft uses PascalCase everywhere (except for the infamous min/max macros) so with camelCase SFML users wouldn't face this problem.