Messages

1

General discussions / Re: SFML Game Development -- A book on SFML

« on: November 13, 2014, 12:12:23 pm »

Thank you for the reply and the useful suggestions (sf::VertexArray, should I ever need it).

For the GUI, you could first draw the world's view as you know it from the book, and then switch to a default view (starting at the origin and using the window's size) where the GUI elements are drawn.

Otherwise, it depends a bit on what flexibility you need. Do you need picture-in-picture (e.g. a small part of the window drawing another scene) or minimaps? Split-screen? I would not handle the view inside a scene node, because the whole scene graph (i.e. the game's scene) is usually rendered at once, from one point of view.

Right, switching between views is indeed what I had in mind, but I am unsure how to propagate the inputs to this elegantly. For example, suppose a rightclick ought to open a menu, or that in the airplane game, the user input could affect the scrolling speed of the world.

Currently, the user input flows through a CommandQueue, which only affects SceneNodes. I can, for example, build a separate queue for commands to view, but this doesn't strike me as good design. So, alternatively, I could have a pointer to a special SceneNode in World, like PlayerAircraft* mPlayer which, being a SceneNode, can read inputs through the CommandQueue.  I could then in the World::update do something like if(mPlayer->isMenuOpen()) openMenu();.

I suppose the latter is in line with the book's implementation, but it somehow seems a bit circular and I am not really liking the idea that the entity would need to know about views and store data about it (such as the bool isMenuOpen() function).

Am I making any sense or am I completely off tracks here?

2

General discussions / Re: SFML Game Development -- A book on SFML

« on: November 13, 2014, 10:11:59 am »

I'd call myself an intermediate C++ developer (and completely new to game development), and as such feel like the book was specifically aimed at me. I most certainly learned a lot of useful patterns reading it, thank you. I have some questions, some which were already asked and answered in this thread (such as why use heap allocation in ResourceHolder), and would greatly appreciate any replies:

1. What are the most obvious optimizations one might do? In my project, there is no collision detection, but rather it is about entities moving randomly on a map. As it stands, I can draw of the order of 10000 animated entities before I take a frame rate hit. I don't plan on ever having this many entities on screen at once, but might have a comparable number in the in-game world. Do you suppose the lowered performance is due to the many draws and that optimizations related to drawing i.e. culling would be the way to go? Alternatively, might this be because of the SceneGraph traversals and the scattered form of the data, meaning that I would need to group the relevant data better for less cache misses? Obviously I could try to parallelize the code, too, which should result in speed improvements.

2. What is a sensible way to control Views? The book implementation only has a View in World and player input through CommandQueue does not, and cannot, affect this. Does it make sense to have Views in SceneNodes and how could I, say, draw a dynamical GUI with buttons for the player to click, or have the player input control the scrolling of the view of the World. I understand how to technically use views and have an ugly hack in place, but I am asking if someone might be able to think of some nice organization for the code.

I have other questions (mostly about code organization), but I think these will do for now. Finally, I should say that I did not read the book cover-to-cover, but skimmed some parts, so I apologize if some of these were already discussed therein.