Messages

76

General discussions / Re: Exceptions in SFML 3 ?

« on: October 14, 2013, 12:26:01 am »

FYI I never proposed a TextureLoader, I was going more the ImageLoader/Load file and Decode way at the Image level.

I really should of thought of that splitting down to File -> Buffer -> Image, kicking myself for not when it's exactly where my thinking was heading and then I just couldn't finish it in a way I liked. But that way you presented, I like. It looks very nice and, I think, would read very well and be conceptually easy to understand.

For "simplicity" one could perhaps create a facade onto that system that unifies it for beginners, and when they need more complex solutions "Well, this actually uses these under the hood so all you need to do..." is always a nice thing to be able to say.

A benefit I kept thinking of and never bloody mentioned for some reason (sorry, it's been a long day xD) with an extensible design would be the ability to easily plug-in ones own loaders alongside the built-in ones for loading custom file types. An exposed loading system would be much easier for a user to extend.

Loading for images is, I believe, determined in the underlying libraries used in SFML by the "header bytes" of the files that image types have to identify them. A unified decoder you can add your own logic to would be very useful for people who want support for whatever types SFML does not provide support for.

However, I'm well aware all of these proposals would call for big changes in the underlying code for SFML. It's possible to instead write your own loader and call loadFromMemory/loadFromStream means it has solutions in the current way of doing thing.

Since the current way still works and can be made to work with others fine, it's arguable that it's not enough of a benefit to justify what could be a dramatic rewrite of the system.

But on the other other hand, writing a PhysFS File loader makes more sense to me than writing a PhysFS Stream as something to just drop into your code as a replacement for sf::LoadFile and have it just work...feels much simpler than having to go in, replace loadFromFile with loadFromStream and give loadFromStream the new stream you have to create.

77

General discussions / Re: Exceptions in SFML 3 ?

« on: October 13, 2013, 03:16:19 pm »

I'm cool with this going into a new thread if people want. I mostly just said the whole "image loading" thing as a way of highlighting my attitude towards design and programming, namely I prefer very discrete responsibilities in code. I'm also big on testability, for me simpler code is code that's easier write unit tests with and for. Code, frankly, cannot be simple without being testable for me.

Essentially, it appears things like create and loadFromFile were made because, due to the fact they could fail, they're reasonably complex and SFML atm doesn't use exceptions, people didn't want them in the constructors. But that, to me, doesn't mean move them to a member function. It means move them out the class.

If you look at the implementation of Texture.loadFromFile, it just calls through to sf::Image. At present every usage of it could be inlined and since it's pretty much just a helper done to hide the need of sf::Image it literally would inline to:

Code: [Select]

sf::Image image;
auto success = image.loadFromFile("filename") && texture.loadFromImage(image);

It's a helper function, nothing more. My preferred usage would be more like:

Code: [Select]

sf::ImageLoader imageLoader;
sf::Image image = imageLoader.loadFile("mario.png");
sf::Texture texture(image);

And loadFile throws on failure. Or does whatever the above debate will yield, Exceptions with an overload that takes sf::Error seems to be the preference. And I'll admit I do not mind that approach.

Really this is more about the whole self-mutating nature of image/texture, I find it preferable for images be created in their desired state and changing the image requires reconstructing the object.

But I always just create my own factories that look a lot like the above for me anyway, so it's a minor design nibble in the end that doesn't get in the way and I didn't intend for my aside comment to distract from the main topic. For that I apologise.

78

General discussions / Re: Exceptions in SFML 3 ?

« on: October 13, 2013, 02:49:53 pm »

Well in code they don't actually know it, but they appear to do so from the API point of view. That, to me, is a big hint that the responsibility is in the wrong place: SFML Image has feature envy of the ImageLoader. I'd rather an ImageLoader be an explicit class I have to initialise and use. To me, that is simpler. I definitely think it's easier to use and test code that separates use from construction like that.

I can't think of anything else in SFML that has two different expectations like loading does. Creating a texture, maybe? It's the things that do something and return true or false as a way of reporting success or failure, which are rare in SFML anyway. With an exception of pollEvent., of course.

79

General discussions / Re: Exceptions in SFML 3 ?

« on: October 13, 2013, 12:42:47 am »

Except here my argument is these are not the same function, that they have different responsibilities and as such deserve different names. Overloads exist to present a common responsibility with multiple interfaces, not to present multiple responsibilities with a common interface.

tryLoad says failure can be expected so failure is not exceptional, which is discrete from load which says success should be guaranteed and thus failure is exceptional.

I will grant the error pattern you present may be established in C++ for handling error conditions in situations where errors are exceptional but users do not want to use exceptions for various reasons. But here I present an alternative which is to create a tryLoad that acknowledges failure as not exceptional, and put forth that as a cleaner solution that more closely matches the needs of the user.

That is my argument, although I'll grant it hinges on whether or not you think there should be a version of loading that doesn't regard failure as exceptional.

As an aside, can I say I do love that these intellectual design discussions crop up in the SFML community with some regularity. It's nice when sometimes it can seem there are so few programmers out there who value thinking about this kind of thing. The debate is always fascinating.

And to be honest I have other issues with the current Texture/Image/Shader loading, namely I disagree that any of those should know how to load themselves from the file system, that it should not be their responsibility.

80

General discussions / Re: Exceptions in SFML 3 ?

« on: October 12, 2013, 12:47:42 pm »

To use C# as an example, Parse vs TryParse. Parse throws on failure to Parse, TryParse returns true/false. Is this problem not solved by creating tryX functions to create functions for whom failure is not exceptional.

For loadFile vs tryLoadFile,  that actually feels significantly better to me.  loadFile says "I want to load this file" and failure is an exceptional scenario, and with tryLoadFile it's saying "I want to load this file but not guarantee it will work".

Exceptions are for exceptional situations that deviate from the expected control flow, tryLoadFile is explicitly including both success and failure in it's expected control flow, whilst loadFile failing to load the file is an exceptional situation.

81

SFML projects / Re: What are you working on?

« on: October 07, 2013, 01:30:45 am »

What is this "Given()/When()/Then()" stuff?

The way my unit testing library, UnitTest11, handles tests. Instead of using the SetUp/Test/TearDown of the xUnit family of libraries it uses Given/When/Then/Finally. It more closely matches the way people often write unit tests: Arrange/Act/Assert/TearDown. The functions take a describing string and lambdas, which are the actual test logic.

When a fixture is ran, it builds up from the given/when/thens such that if you do
Given X
When U
Then A
Then B
When T
Then C
Finally O

Then the fixture will actually run as:
Given X When U Then A Finally O
Given X When U Then B Finally O
Given X When T Then C Finally O

82

SFML projects / Re: What are you working on?

« on: October 06, 2013, 03:07:57 pm »

Something I'm just experimenting with today before I start work proper on my university project tomorrow.



Just experimenting with taking control of the mouse and keyboard to trigger SFML events for the purpose of end-to-end testing.

83

General / Re: AW: SFML source and Visual Studio 2013

« on: September 30, 2013, 08:03:31 pm »

Huh, I'm sure when I looked at the list of generators for 2.8.11 it still didn't list Visual Studio 12...my mistake. I've amended my original post, and modified the scripts I posted to reflect.

CMake gui gives me more issues than command line ever does over the little things like "MinGW Makefiles" needing CMAKE_MAKE_PROGRAM defined.

I still stand by it's better to use the cmake command line, but I can be a bit obsessed with automation at times. Why do yourself what the computer can be scripted to do for you in two lines? I always script my 3rd party installs nowadays, much easier than faffing around with manual copying and manual building.

84

General / Re: SFML source and Visual Studio 2013

« on: September 30, 2013, 03:41:47 pm »

To be honest, the CMake GUI sucks. Always has. It's much easier to just use the command line.

Also to build SFML for Visual Studio 2013 RC at the moment, I have found I have to explicitly tell msbuild to change a flag to the correct visual studio version. The following works for me when ran by the command line: EDIT: Nevermind, last cmake update added Visual Studio 12 support. I've modified the scripts to reflect.

Code: [Select]

cmake <PATH TO SFML> -G"Visual Studio 11"
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" /p:Configuration=Release SFML.sln

Obviously replacing <PATH TO SFML> with the path to the root of the SFML directory. Also the location of the VS12 (Visual Studio 2013) msbuild on your system may be different.

EDIT: Here's a batch script (save it as a .bat and run from the command line) to completely download and rebuild SFML, and extract the headers, libs and bin into appropriate folders for both debug and release.

Code: [Select]

mkdir sfml2
pushd sfml2
mkdir include
mkdir lib
mkdir bin

git clone https://github.com/SFML/SFML.git
pushd SFML
mkdir build
pushd build
cmake .. -G"Visual Studio 12"
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" /m:10 /p:Configuration=Debug SFML.sln
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" /m:10 /p:Configuration=Release SFML.sln

xcopy lib\Debug\*.lib ..\..\lib /Y /S /I
xcopy lib\Debug\*.dll ..\..\bin /Y /S /I

xcopy lib\Release\*.lib ..\..\lib /Y /S /I
xcopy lib\Release\*.dll ..\..\bin /Y /S /I
popd
xcopy include ..\include /Y /S /I
popd
rd SFML /S /Q
popd


85

General / Re: Choosing a File

« on: September 25, 2013, 09:38:06 pm »

It's outside of the scope of SFML but there are other 3rd party libraries you can integrate to create this functionality. For the GUI side you may want to look into SFGUI. For file system exploration and the like, boost::filesystem is a good bet.

86

General / Re: Sfml 2.0/2.1 game engine

« on: September 15, 2013, 05:30:34 pm »

Time to hand out the link to hand out whenever this question comes up: Write Games, Not Engines.

Heck, a couple of years ago even I wrote a blog post on it...

87

SFML game jam / Re: Open GL - Yes/No

« on: September 06, 2013, 04:42:46 pm »

Honestly, I think people are making this into a bigger deal than it is. It's a Game Jam for making games and having fun, and it's the SFML Game Jam. People who join are, on whole, gonna be using SFML. To make games. In a jam.

Really, if you have to do something maintain a "spirit of the jam" clause and reserve the right to penalise games that are felt to have broken that spirit.

88

General / Re: Smooth Movement

« on: August 14, 2013, 03:48:32 pm »

You know, handling input in events vs polling is a valid way of doing this. That quote is misleading as I've said in another thread on the topic. Evens are a clean way to separate input checking from logic, turning them into something detached from SFML to keep input and outputs on the edges of the program instead of mixed throughout.

So he would just need to handle sf::Event::KeyReleased and turn off the movement flag.

89

General / Re: Global input vs event?

« on: August 13, 2013, 11:19:51 pm »

I'd say it's explaining the difference in functionality. It's saying how real-time says how things are, and events says when things change. Those tutorials are very good at explaining the difference in functionality, and that's a good thing.

What they aren't is game code design tutorials or discussions on approaches to structuring game code and I believe this is more that freesoul here is asking about: To know the high level design reasons one would choose one over the other. And that's a more complex discussion with a lot more nuance than those tutorials allow/need.

90

General / Re: Global input vs event?

« on: August 13, 2013, 10:57:53 pm »

Although those documentations does not explicitly explain why one would choose one over the other. It doesn't explain why you'd want to query the state of a keyboard as opposed to using events or vice-versa. Admittedly that's a wider discussion in "game coding" but none-the-less, I can see why it'd be a legitimate question what situations one is better than the over.
 
Heck, I'd say

Sometimes, people try to use the KeyPressed event to implement smooth movement. Doing so will not produce smooth movements, because when you hold a key you only get a few events (remember, the repeat delay). Smooth movements can only be achieved by using real-time keyboard input with sf::Keyboard (see the dedicated tutorial).

is downright misleading. Smooth movement is perfectly possible with events, it's just the way you go about it is different. Not "Can I move? If so, move" but "Apply velocity on press, Remove velocity on release".