Messages

1

General discussions / Re: SFML 3 - What is your vision?

« on: September 06, 2017, 08:23:27 pm »

One thing I'd really like to have is the ability to independently set the translation, scale and rotation origin for sf::Transformable. I know I can use sf::Transform directly, but I think a middle-ground solution would be convenient, as the complication of using sf::Transform is barely justified for such a common¹ need IMHO.

¹ "common" in my experience, of course. Maybe there are far fewer people than I think who ever need this capability.

2

SFML projects / Re: Remnants of Naezith is now on Greenlight!

« on: February 19, 2017, 04:19:00 pm »

That looks amazing. Even more so considering it's all done in SFML (so I assume 100% C++ coded from scratch?)
Neat job!

3

SFML projects / Re: Temporarily Named MMORPG: The Adventure Game

« on: January 22, 2016, 09:36:39 am »

Just for curiosity: since you're using SFML, is there some reason why you're only targeting windows?

4

SFML projects / Re: Screenshot Thread

« on: November 22, 2015, 10:23:52 am »

Have a glimpse into the project "Cendric", currently under development. Its genre lies somewhere between RPG, platformer and puzzle and the code is completely open source.

Wow, looks really cool! I'm gonna try it, provided I can compile it on Linux 

5

Feature requests / Re: Pausable clock...?

« on: September 24, 2015, 09:34:49 am »

You can also use thor::StopWatch. There's some other stuff in Thor that you might find interesting, too

I'm going to have a look and probably use it for my next project - since I'm almost done with the game logic for the game I'm currently doing, and since it's my first SFML project at all, I prefer not adding more libraries to it right now

@Hapax: thanks for pointing that out; for now I'm using sftools::Chronometer with a couple of changes to adapt to the sf::Clock interface, but I'll take a look at your library too for the future.

6

Feature requests / Pausable clock...?

« on: September 23, 2015, 07:32:54 pm »

There have been already a couple of discussions on this, but none has a definitive answer, so I'm proposing this again.

I think the sf::Clock class would greatly benefit from a pause() and resume() method, since more often than not games can be paused and resumed as well, and this usually needs some internal timers to be paused when the game pauses and resumed later.
Of course, one can use a third party implementation - and it's pretty trivial to implement this by oneself - but having a standard API would be a better option.

Adding these two method would not break compatibility, but if sf::Clock is not to be changed, a new class could be added with the same interface as sf::Clock plus these methods.

(If API change is problematic, this may be considered for SFML 3)

7

Feature requests / Re: Facility to get standard paths

« on: September 16, 2015, 11:23:15 am »

Since we don't want to turn SFML into another filesystem library, I'd say just provide the paths.

Yeah, seems the best choice to me too.

8

SFML projects / Re: Screenshot Thread

« on: September 16, 2015, 09:43:57 am »

Slowly adding original assets to my game...the sidebar still uses assets taken from another game, but almost all the other ones are mine (they're far from excellent, I'm a pixel art uber-beginner  )
Still, I'm quite liking how's turning out

9

Feature requests / Re: Facility to get standard paths

« on: September 16, 2015, 09:36:29 am »

Variables are a bad idea, they limit the initialization to static functions run at program startup. Use functions and you have the full flexibility: either compute paths on-demand, or at program startup, or on first use.

That's true, but since the idea is to get "standard" paths, how complicated should it get to initialize those paths?

I think the question which needs to be sorted out first is: should we just provide those paths (either as objects, variables or getter functions), without bothering to check if they actually exist on the machine SFML is installed on, or should we also ensure the paths we retreive from the API are always valid?

Of course from the user's viewpoint the second choice is the obvious one but, as you said before, it can get pretty complicated to implement, while the first option would be slightly less than trivial if I'm not mistaken.

10

Feature requests / Re: Facility to get standard paths

« on: September 15, 2015, 12:31:31 pm »

Is there already any idea how would this be implemented in the API? Global namespaced variables like sf::Path::Home? Also, would we also need some basic functions to check if a path exists/create a directory/etc in a portable way?

11

SFML projects / Re: Witch Blast (dungeon crawl shooter)

« on: September 06, 2015, 02:12:57 pm »

I just tried it and it's really nice! I died quite early, though, so gotta try harder

Good job!

12

SFML projects / Re: MapMaker - Startproject for SFML

« on: September 03, 2015, 11:59:50 am »

Argh sorry silverweed, I somehow overlooked the "and" in your sentence and thought you meant that the '/' '\' thing is supposed to lead to the unclosed string error, my bad.

No problem, I could've expressed myself more clearly

13

SFML projects / Re: MapMaker - Startproject for SFML

« on: September 02, 2015, 07:20:49 pm »

which in short means that using '\' instead of '/' leads to not much more than undefined behaviour ("implementation-defined" is pretty explicit on this).

Don't confuse implementation-defined and undefined behavior, they mean different things. See here for an explanation of the terminology.

That is, using backslashes in include paths is permitted on certain implementations, but not advised for portable coding. There's no reason not to use forward slashes which work everywhere.

I'm aware of the difference in terminology, that's why I said:

to not much more than undefined behaviour

I meant to stress the fact that it's not a portable feature: what works on some platform/with some compiler may not work on others, and since it's so trivial to avoid this unreliability it's something worth fixing.

14

SFML projects / Re: MapMaker - Startproject for SFML

« on: September 02, 2015, 04:23:00 pm »

Like fallahn said already, the private draw function is perfectly fine and the includes you mention are fine too.

The backslashes aren't really "fine" actually: from the C++11 specs you read (paragraph 2.9/2):

The appearance of either of the characters ’ or \ or of either of the character sequences /* or // in a q-char-sequence or an h-char-sequence is conditionally supported with implementation-defined semantics, as is the appearance of the character " in an h-char-sequence.

which in short means that using '\' instead of '/' leads to not much more than undefined behaviour ("implementation-defined" is pretty explicit on this).

As for the private draw(), you're right: I didn't know it was friend with RenderTarget, so mea culpa.

The include you don't mention however is exactly the reason for the unclosed string error, because there is one additional quote #include "Tileset.hpp"" <-----------

That's what I mentioned here:

There's a typo (unclosed string) in this file

15

SFML projects / Re: MapMaker - Startproject for SFML

« on: September 02, 2015, 11:58:35 am »

Is the code on Github supposed to work? There's a typo (unclosed string) in this file, and you're using

#include <SFML\Graphics.hpp>

instead of

#include <SFML/Graphics.hpp>

. Also, Map has its draw() method defined private, which makes little sense, and the naming convention you're using is incoherent: I suggest you choose either camelCase, PascalCase or c_like_naming and stick with that (when working with SFML the camelCase is the most natural choice).