Messages

16

General / Re: SFML book, chapter 2 issue

« on: February 22, 2016, 03:37:40 pm »

I once read in a good book about C++ (More Effective C++ by Scott Meyers), that it is tempting to overload binary operators like '+', '-' etc. for non-arithmetic types, but most often it isn't a good idea because of its overly non-verbose syntax and your actual operation get's lost behind the simple and implicit + syntax. So because of that, I will never ever overload operator '+' and instead write a generic converter function with an explicit name to state what I am doing with the supplied type.
(One can still argue if an enum class of unsigned int is a non-arithmetic type, I do, with the exception of std::string)

17

General / Re: SFML book, chapter 2 issue

« on: February 22, 2016, 11:49:42 am »

Be careful when using enum classes in the context of the SFML Game Development book. The book uses the unsigned int representation of enum's to make bitwise operations on them. This does not work by default with enum class values. To make it work you either need to overload the bitwise operators for your enum classes, or, the simpler solution, casting the enum class values to unsigned int before doing bitwise operations.
I use the second solution but with a generic casting function, which casts an enum class value to its underlying type (for which you should define the underlying type for your enum classes like enum class Textures : unsigned int { ... };, which also means you are able to forward declare an enum class, which comes in handy when working with the context structure later in the book. )
here is the code for said function:

template<typename T>
constexpr auto to_integral( T t ) -> typename std::underlying_type<T>::type
{
  return static_cast<typename std::underlying_type<T>::type>( t );
}

18

General discussions / Re: Procedural Content Generation for C++ Game Development - another book using SFML

« on: February 22, 2016, 11:24:15 am »

Ah yes, finally a book on this topic with real life C++ code. This will come in handy in one of my planned projects. Thanks for the info.

19

SFML projects / Re: Screenshot Thread

« on: February 22, 2016, 11:13:11 am »

@Hapax: I am well aware of the mantra "Make games, not engines", but as it happens to be, I really like doing the engine / framework stuff  (which also means I am making the most over-engineered Pong clone ever, currently at 46 code files and still not done, whereas my first working Pong clone was done in one code file  )
But the debug draw overlay was really needed to further tweak the physics of the game, and without visual debugging, this is near to impossible.

@AncientGrief:
Yes I implemented that with the pre-processor, working with #ifdef _DEBUG #else #endif constructs. The drawing itself is handled in the base entity class via a split-up draw function. Entity.draw() just calculates the combined transformation and than calls drawCurrent(...) (which is virtual and overridden in derived classes) and if debug draw is enabled it calls drawDebug(...). Not very elegant but working, also this way the whole debug logic is not present in release builds, because it really hurts performance, like cutting framerate to 25% of release performance.

You can see for yourself if you want https://github.com/SeriousITGuy/SFML-Pong
(Entity.cpp and GameWorld.cpp are of special interest for the debug drawing)

20

SFML projects / Re: Screenshot Thread

« on: February 19, 2016, 02:04:43 pm »

Thumb up for Wolfenstein! 

Just added a debug draw overlay to my simple game framework. Needs some tweakin though to not go out of the view (see right paddle)



(and yes I'm still working on a Pong clone, it makes adding features to the framework more simple)

21

Feature requests / Re: Vulkan Support

« on: February 18, 2016, 01:25:32 pm »

Vulkan is also compatible with less GPUs than OpenGL 1.1.

Well if you could supply some evidence for that would be cool. Since what I read about Vulkan, it's supported on every hardware OpenGL is currently running on, it just depends if you get a Vulkan driver for that stone age GPU only supporting OpenGL 1. And since the next major SFML Version will get away from OpenGL 1 (I remember some of the devs stating that somewhere here in the forum) in favour of newer OpenGL, this point is defeated in itself. And if you still sit on OpenGL 1 Hardware and need to support it, don't upgrade to a newer SFML release, you can stick with older versions of SFML if you need to without problems. So this is not a valid argument to stay away from innovation.

At the moment I don't seed the "urgent" need to support Vulkan, as everything SFML does with OpenGL, it does so very well. Also Vulkan is the new kid on the block, and as OpenGL has already stood the test of time, let Vulkan mature before really investing time and brainpower into it. Let the big ones play with it first, let them iron out the child deseases and then it's time for a library like SFML to support it.
I see only one real pro argument, and this is the whole validation layer thing, which helps develop "safe Vulkan code", otherwise you crash your graphics drivers at runtime, which helps in overall better code quality. And the new shader format sounds interesting, and it is portable which is also a big plus for cross platform games.
TLDR: Maybe when it's time, but I don't feel like this time is now.

22

Feature requests / Re: sf::Rect extension

« on: January 26, 2016, 10:16:18 am »

Getting position and size as vectors is more convenient to use in my opinion. I'm upvoting this!

23

General / Re: Z-Ordering/Sorting in SFML using sfml-tmxloader

« on: January 20, 2016, 04:25:02 pm »

As this has nothing to do with SFML itself, you probably won't find any help here.

24

Feature requests / Re: copy constructor?

« on: January 20, 2016, 04:19:13 pm »

enlighten me please how can I make a copy of an sf::Sprite

Thank you.

You can always use the copy constructor without it being declared and defined by the programmer because your compiler will generate it for you with the default semantics, as long as the programmer does not forbid the default generated ones ( =delete; in C++11).

This is not visible because the default versions of dtor, copy ctor, copy assignment, move ctor and move assignment are not exposed in the API. This is accounted for in C++11 too, where you can explicitly define them in the API with =default; (which SFML doesn't actually do because it doesn't use C++11 yet)

And yes, you should read a book about the C++ basics.

25

General / Re: SFML 2.0 Linux installation issue

« on: January 18, 2016, 03:26:03 pm »

/usr/bin/ld: warning: libGLEW.so.1.5, needed by /usr/local/SFML-2.0/lib/libsfml-graphics.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libjpeg.so.62, needed by /usr/local/SFML-2.0/lib/libsfml-graphics.so, not found (try using -rpath or -rpath-link)

You should read more carefully, the problem is right in the first lines of your error message. SFML has additional dependencies which are not provided via the official download for linux binaries. You need to install them by yourself.
Best option would be to build SFML 2.3.2 yourself from source.

26

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: December 29, 2015, 10:36:57 pm »

As the book is on sale I just grabbed a copy and gone through the TOC. Looks very interesting, some things seem familiar from previous books, but some things look very interesting. Thanks for the work, I look forward to read and test it

27

SFML projects / Re: Selba Ward

« on: December 15, 2015, 08:23:03 am »

Very cool stuff, indeed useful Thanks, as always Hapax.
I will take a look especially at Progressbar, because that's something I want to implement in the next weeks.

28

SFML projects / Re:creation - a top down action adventure about undeads

« on: December 10, 2015, 07:59:02 am »

I also use one global data structure which holds (non-owning) pointers to all engine subsystems (which are owned by the main application class), like renderer, audio, logger (even a blackboard for simple data exchange between different game states). In my opinion it is a simple and at the same time elegant solution to this problem. So everthing I do is to pass this global object to all gamestates, and from there every state has access to all engine subsystems.
I think in the book SFML Game Development the same concept is used, and it worked perfectly.

29

Feature requests / Re: sf::Distance ?

« on: December 09, 2015, 10:43:26 am »

I was recently thinking about something similar when looking at Box2D and integrating it into a SFML app. There is one step needed to do that, you need to convert your pixel sizes from the SFML objects to meters for the Box2D objects and vice versa. That's not a complicated thing to acomplish with converter functions, but something like sf::Distance would make this easier.

But I don't know if it is really a needed feature for a multimedia library like SFML, as the only use case I can think of is physics integration, which is clearly the scope of the client code, not SFML.

30

Graphics / Re: resource manager

« on: December 08, 2015, 10:21:23 am »

A better solution would be to look up the key in the map, and if the returned iterator equals std::end() you can savely insert, otherwise just return the already inserted value (actually only the second value of the std::pair).

And btw. is the resource manager of SFML Essential a rather bad example overall, badly implemented singleton and stuff. You may want to consider the book SFML Game Development, as it gives a much better implementation of a resource manager class.