Messages

91

General / Re: A question about the dreaded singleton

« on: August 12, 2013, 10:40:07 pm »

The difficulty in testing comes from how in order to test you have to initialise all the dependencies of a class/function, either to fakes, mocks or real implementations.

And since when using the Singleton design pattern some of those dependencies are global, that means that class/function hasn't declared it needs to go off to that singleton explicitly, so knowing to do that requires either overly specific documentation or going through the source code under test line by line. Neither are desirable and mean the code is not inherently self-documenting.

This is related to a general problem with the Singleton design pattern: Any usage of them is implicit. The usage of the global singleton is a non-obvious side-effect, and that's the kind of place that at best just wastes some of the programmers time and at worst is where the crashes, bugs, glitches and mistakes love to hide.

A few good blog posts on this can be found here:
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/
http://misko.hevery.com/2008/08/25/root-cause-of-singletons/

There is little wrong with your code having only one instance of a class (singleton), that's an often unavoidable state, but if you were to go and take that instance and shove it into a global (Singleton design pattern) is a bad idea for all the reasons global variables are bad ideas.

It's almost always better to have one instance of something you explicitly pass around to what needs it, and have the lifespan of that instance be only as long as it's needed.

92

General discussions / Re: SFML 2.1

« on: July 28, 2013, 06:46:52 pm »

I'm starting to wonder if perhaps SFML would benefit from a suite of integration/acceptance tests to run. I know graphics and such are notoriously difficult to test, but still...

I may give it a shot just to see how feasible this would be. I've already integrated SFML into my automated continuous integration set-up, so may just give writing a "SFML.test" project a shot to drop it between my SFML.build and SFML.package jenkins jobs xD

Obviously not low-level unit tests, but maybe just something that fires up a bunch of sample programs and does a mix of automated and maybe some manual checks from the runner to verify the expected things to happen...well, happened.

It'd not be too difficult for me to do this for Windows at least, it's pretty easy to hijack the keyboard and mouse and just force some inputs using the Windows API, but I've not enough experience with this kind of thing on other OSes. With any luck a framework already exists.

It's also something I think would be required if ever SFML were to have more "community-driven development" for whatever reason, since I can't be the only one who likes to be able to code fearlessly, and the lack of tests giving me some assurance I haven't somehow broken everything and missed it, my biggest fear, would be the main deterrent for me taking part in that community-driven development.

93

General discussions / Re: SFML Game Jam

« on: July 18, 2013, 11:49:39 pm »

Personally I'm not a biiig fan of using 'real programming languages' in game jams. Much prefer to use RAD tools.

I'm a big fan of taking the time to constantly refactor and driving the code from tests, and the time limits on jams combined with the sleep deprivation just beat down on that too much for me. And just doing anything else feels like 'just hacking it out', which makes me feel dirty.

But if people want to do it, well...why not? I may even try to suck it up and join in

94

General / Re: Crash when attempting to initialize anything SFML Mingw

« on: June 17, 2013, 08:43:42 pm »

Mingw is GCC for Windows. If you can't get the GCC 4.7 Mingw version you'll have to recompile SFML using your Mingw version instead. It should still compile, so that won't be a problem.

95

General / Re: Am I setting up my game in the ideal way? (ie: pointers/.cpp/.header files)

« on: June 15, 2013, 04:28:02 pm »

My first concern is the overuse of comments, and the size of the functions. Comments mean the code doesn't explain itself adequately, so really should only be used in situations where you've had to make a weird decision, to explain that weird decision.

The current placement of the comments also serves as a good indicator where the main could be broken down into smaller and easier to understand functions. Remember, whilst a good coder can keep the entire system they've written in their head, a great coder writes the system in such a way that they don't need to.

Also you can scope using namespace statements to a function call, which personally I recommend if you insist on not just writing std:: and similar (which is what I'd recommend first), to limit the declaring "using namespace xxx" problem.

A few more things, I'd say the player knows too much. Namely: It knows when the keyboard is telling it to move itself.  I'd recommend breaking that logic out of the player, and having something else tell the when player to move.

96

SFML projects / Re: MineSweeper

« on: June 12, 2013, 07:39:03 pm »

Don't be afraid of "placeholder" graphics and sounds tastefully acquired from whatever corner of the internet allows it. 99% of programmer art sucks

97

Feature requests / Re: Bézier curves

« on: June 10, 2013, 04:23:56 pm »

Just personal preference. Use whatever you want to implement it (should be easy to replace/update) and what you think fits your specific use case.

Unfortunately it's incorrect. The way to view according to  Bjarne Stroustrup himself is that vector is the default list storage, whilst list is an optimisation and should not be used prematurely.

Source: The Bjarne C++11 Keynote

98

Feature requests / Re: Bézier curves

« on: June 10, 2013, 03:56:45 pm »

The way to test would be to compile std::pow and x*x*x with maximum levels of optimisation and compare the assembly.

I do know that g++ with -O3 can optimise std::pow(x, 2) down to the same assembly. I'd assume it can do the same for power of 3.

Now whether this is actually more readable than x*x*x is a whole other issue, and much more down to personal preference...

99

Feature requests / Re: Virtual Destructors?

« on: June 03, 2013, 02:49:56 pm »

This Is-A/Has-A model is a broken way to look at inheritance. It results in overcomplicated designs. A good way to view it is when you inherit you duplicate the responsibilities. Inheritance is a means through which one class can duplicate and extend the responsibilities of another class.

Sometimes this is good, sometimes you want to duplicate and extend responsibilities. But most of the time you do not want to do this. Code is always at it's simplest and cleanest when it has the fewest responsibilities, so inheritance will almost always make your design more complicated.

This is a situation where the code is made so much simpler by encapsulation, by keeping the myriad of responsibilities of the sf::Texture from polluting your class.

100

General / Re: Web Application

« on: June 02, 2013, 09:42:57 pm »

I've not done so, but someone may want to look into emscripten. It's an LLVM to Javascript compiler. Since you can compile C++ to LLVM, and then that to Javascript, it may be possible to port parts of SFML to Javascript.

However,  this may need to wait until SFML supports OpenGL 2.0 ES, since it turns the OpenGL calls to WebGL.

101

SFML wiki / Re: Simple Collision Detection for SFML 2

« on: May 27, 2013, 09:04:36 pm »

To highlight this, I quickly refactored the Circle test.

#include <Collision.hpp>

struct BoundingCircle
{
        sf::Vector2f centre;
        float radius;
};

sf::Vector2f GetSpriteCenter(const sf::Sprite& object)
{
        auto dimensions = object.getGlobalBounds();

        return sf::Vector2f (dimensions.left + dimensions.width / 2.0f,
                                                 dimensions.top + dimensions.height / 2.0f);
}

sf::Vector2f GetSpriteSize(const sf::Sprite& object)
{
        auto originalSize = object.getTextureRect();
        auto scale = object.getScale();

        return sf::Vector2f (originalSize.width * scale.x, originalSize.height * scale.y);
}

float GetRadiusOfRectangleWithSize(sf::Vector2f size)
{
        return (size.x + size.y) / 4;
}

BoundingCircle GetBoundingCircle(const sf::Sprite& object)
{
        auto objSize = GetSpriteSize(object);
        auto radius = GetRadiusOfRectangleWithSize(objSize);

        return BoundingCircle({ GetSpriteCenter(object), radius });
}

bool AreBoundingCirclesIntersecting(BoundingCircle boundingCircleOne, BoundingCircle boundingCircleTwo)
{
        auto distance = boundingCircleOne.centre - boundingCircleTwo.centre;
        auto magnitudeOfDistanceSquared = distance.x * distance.x + distance.y * distance.y;
        auto maximumCollidingDistanceBetweenBoundings = (boundingCircleOne.radius       + boundingCircleTwo.radius)     * (boundingCircleOne.radius + boundingCircleTwo.radius);

        return (magnitudeOfDistanceSquared <= maximumCollidingDistanceBetweenBoundings);
}

bool CircleTest(const sf::Sprite& object1, const sf::Sprite& object2)
{
        auto boundingCircleOne = GetBoundingCircle(object1);
        auto boundingCircleTwo = GetBoundingCircle(object2);

        return AreBoundingCirclesIntersecting(boundingCircleOne, boundingCircleTwo);
}
 

Note the code is longer, but functionality should be unchanged. I cannot, admittedly, guarantee this as I neglected to take the time to properly surround the code in tests before refactoring. The really interesting part is it reveals the nature of this function: It's actually two,
1. Get the bounding circle of the sprites
2. Check if the bounding circles intersect

102

SFML wiki / Re: Simple Collision Detection for SFML 2

« on: May 27, 2013, 07:39:02 pm »

Naked news-delete combos are the lowest level of abstraction possible in a system, so in general should only exist at the lowest level of abstraction, like when describing basic data structures.

The names of variables is not very descriptive. A, B, C and D for example. And t. What does the letter 't' tell me about the purpose of this variable?

The implementation is littered with comments, and as a general rule if code needs comments to explain what it is doing, it's better to make the code more readable than to add the comment. Those comments are good indicators of where you could probably break down the giant functions into a series of function calls to improve the readability and let the function names describe their functionality.

103

General / Re: Code is structured to use a global sf::RenderWindow, how can I fix this?

« on: May 27, 2013, 04:34:46 pm »

It may require a lot of re-factoring, but it strikes me as the best solution to have a renderer that knows how to draw the world, and not a world that knows how to draw itself. Or to be more specific, you shouldn't *need* to be sharing sf::RenderWindow around like crazy.

I'm of the opinion entities in the world shouldn't know how to draw themselves, it's not a responsibility they should have. This way the renderer can encapsulate the SFML graphical knowledge, such as RenderWindow, inside itself and not need to share such knowledge with the rest of the system.

104

General discussions / Re: Clean C++ Design

« on: May 25, 2013, 01:45:05 pm »

Day 1 Keynote - Bjarne Stroustrup: C++11 Style, this lecture may be relevant to these interests

And to get away from just C++, any of Robert Martin's other works are obviously also good recommendations. Test driven design by example is an often recommended classic by Kent Beck, and I'd agree. Refactoring by Martin Fowler is also very recommendable.

Admittedly I'm not happy with most of the unit testing libraries for c++, which is why I am writting my own.

105

General / Re: Classes and SFML

« on: May 21, 2013, 02:43:40 pm »

I personally pass by pointer because references hide that you are changing data stored someplace else, where as pointers make it very obvious (->)..

The counter-argument most commonly presented to this is that having a pointer parameter in C++ carries the implication that you can pass null to the function, which may be incorrect But even then, in general I recommend avoiding using such out parameters anyway where you can, for they are ugly and in C++ can be confusing. Mutating input arguments is a strong code smell (code smell means something in code that indicates a weakness in design).

What having to do that here suggests, to me, is that a bullet should not possess knowledge of how to draw itself. This is a responsibility which the bullet should not have, but should be the job of something else.