Messages

46

General discussions / sf::Texture crashes when used in a static object

« on: March 14, 2012, 01:19:42 am »

[...]but because I needed a singleton object there was no other way.[...]

There is always another way Use the service locator pattern instead.

47

General discussions / Do you use C++11?

« on: March 11, 2012, 12:09:14 pm »

Either way, my point that it's all made infinitely simpler and cleaner looking by variadic templates remains

It was never in question.

[EDIT]

I didn't see the last part of the following sentence, I'm guessing you added it later:

Maybe I'm thinking of Loki or something else but this is definitely a way it can be simulated...

Not really. The technique you showed has a fixed maximum arity and thus is not variadic, even if the TYPELIST macro is.

[/EDIT]

48

General discussions / Do you use C++11?

« on: March 11, 2012, 11:49:54 am »

I think the actual implementation uses variadic macros [...]

No, it recursively includes itself. Besides, variadic macros are in fact preprocessor macros, so I'm not sure why you felt the need to mention them.

[...]I thought it wrapped them inside a huge set of template specialisations (generated by script)[...]

That description is somewhat inside out. The macros are used to stamp out the overloads.

The nice macro-free headers you see are generated by the preprocessor (using the Boost.Wave preprocessor, I believe). They are then included to improve compile times (i.e. it has nothing to do with how ugly macros are). In fact, if you redefine the maximum overload arity to some value greater than what is provided by the preprocessed headers (or otherwise disable them), the overloads will be generated on-the-fly (no need for scripts at all).

49

General discussions / Do you use C++11?

« on: March 11, 2012, 11:02:43 am »

Variadic templates are amazingly powerful and the only way to emulate them pre-C++11 is via generating code with scripts (how boost::function was written....a lot of partial specialisations generated by scripts).

Not quite. They can be emulated with preprocessor macros (and they are, at least in Boost.Function).

50

Feature requests / Add CoordinateType member to RenderStates class

« on: March 09, 2012, 03:33:19 am »

Alrighty.

By the way, how did the renderer work before the new graphics API (and its vertex arrays)?

Raw OpenGL calls.

It still doesn't use vertex arrays directly, yet (it creates a RectangleShape and gives it a texture), but I'm working on a patch for that.

EDIT: I'm not the author of the original Gwen SFML renderer, btw.

51

Feature requests / Add CoordinateType member to RenderStates class

« on: March 09, 2012, 01:05:39 am »

I don't "need" to work with normalized coordinates any more than SFML needs to work with pixel coordinates

It came to mind while implementing Gwen GUI's renderer class. In Gwen, texture coords are normalized, so having to access the texture's width and height members, then scaling the coords before handing them off to SFML seemed somewhat pointless and wasteful, given the existence of sf::Texture::CoordinateType.

52

Feature requests / Add CoordinateType member to RenderStates class

« on: March 08, 2012, 11:56:08 pm »

Hi,

sf::RenderStates should have a 'CoordinateType' data member (of type sf::Texture::CoordinateType) to enable the use of normalized texture coordinates in vertex arrays rendered by sf::RenderTarget::Draw.

53

General discussions / New graphics API ready

« on: January 07, 2012, 05:44:16 pm »

If we're being pedantic, it's worth mentioning that ISO C++ doesn't define anonymous structs, thus the above construct relies on a compiler specific language extension.

C++11 does.

Oh that's nice. FDIS reference?

54

General / Re: Resolved ( I think )

« on: January 07, 2012, 04:49:06 am »

Code: [Select]


moveHero(dave.location,dave.location = dave.location -= X_TILES);


Don't do that. The C++ standards does not specify the order of evaluation for function arguments.

55

General discussions / New graphics API ready

« on: January 07, 2012, 04:36:12 am »

[...]Chained member access would be a nuisance, but I don't think that was the suggestion, and not what I would suggest either.

Code: [Select]

struct Colour
{
    union
    {
        struct
        {
            unsigned char r;
            unsigned char g;
            unsigned char b;
            unsigned char a;
        };
        sf::Uint32 rgba;
    };
};


In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.

Don't forget that if you set one and read the other, the behaviour is undefined according to the C++ standard. In practice it works as expected on most (if not all) platforms, but it can still break one day.[...]

If we're being pedantic, it's worth mentioning that ISO C++ doesn't define anonymous structs, thus the above construct relies on a compiler specific language extension.

56

General discussions / New graphics API ready

« on: January 02, 2012, 08:43:34 pm »

I'm not even sure if I'd call it an optimization at all. A few points off the top of my head:

The added reference members increase the Color class' size by 20 bytes assuming 32 bit references, 40 bytes assuming 64-bit references. That is a potential 10x size penalty without even mentioning padding.

Accessing a reference member may incur an indirection (depending on the optimizer).

Copy construction and copy assignment become non-trivial (in the standard sense).

The last "New code" example breaks strict aliasing rules, invoking undefined behaviour (I'm ignoring the issue of union type punning, due to widespread compiler support).

57

General / SFML Complete Game Tutorial

« on: January 02, 2012, 12:47:27 am »

Part 9 is now online

I haven't looked at your code in any detail, but a quick look revealed at least four memory leaks. You're new'ing up exceptions (why?) but attempt to catch them by reference.

58

General / Thinking about making a GUI library

« on: October 14, 2011, 06:27:45 pm »

So do what the error message tells you. Say &A::test.

59

General / Thinking about making a GUI library

« on: October 14, 2011, 06:11:40 pm »

It's just that I don't know how to write a function that takes an object and an object's function...

Code: [Select]

template<typename F>
void setOnClickCallback( F f )
{
    m_Callback = f;
}

template<typename T, typename F>
void setOnClickCallback( T* pInstance, F f )
{
    m_Callback = boost::bind( f, pInstance );
}

The single argument overload takes either function pointers or function objects. The two argument overload takes a class instance pointer as its first argument, and a member function pointer as its second.

60

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 14, 2011, 05:12:07 pm »

I think that would work, but it still doesn't allow anyone to have globals; which is almost equivalent to the current implementation (it would just provide a way for SFML to control the lifetime of its own globals).

What it does is turn undefined behaviour into diagnosable errors: resource objects can be default constructed before main(), but operations requiring a valid context will return an error value, rather than cause the application to crash/hang/who-knows-what.

The rules cannot be more relaxed than that, since it is fundamentally impossible to create a resource either before or after the lifetime of a valid context. It's simple and it makes sense: you cannot use library functions before the library has been initialized or after it has been shut down; and in the Windows-ATI-DLL case, that initialization must be done some time after main() has entered.

Or do you meant that this must be combined with the "list of resources" solution that was mentioned before? And that destroying the GraphicsInitialize object releases all the active GlResource instances?

If that really is necessary, then yes. I was had got impression that destroying a context implicitly freed its resources, though?