BurrickSlayer

Members
  • Content count

    16
  • Joined

  • Last visited

Community Reputation

184 Neutral

About BurrickSlayer

  • Rank
    Member
  1. About separating game logic from rendering

    Sorry, I've expressed myself mistakable. Yes, I know the order in which I want the nodes to be sorted and thereby I also know the depth they would have if I were using a depth buffer. If the children of each node appear in the correct order (for example sorted by their Y coordinate) and the tree is traversed in depth-first order, the order of traversal is equal to the order of how I want the nodes to be drawn. So yes, I could organize the scene tree in a way that the drawing order is correct. However, as I was trying to separate concerns in my architecture, I figured that sorting scene nodes so the renderer draws them in the right order is not excatly the best approach. Instead I'd prefer the renderer were able to sort the list of drawables by itself before rendering. Sorting the list of drawables is the problem I can't solve. The list is a flattended scene tree traversed in depth-first order. Because of that I can't sort the whole list by a simple value (e.g. the node's Y coordinates). Doing this would just mess up the hierarchy of nodes (nodes that reside on different layers would be mixed up). I hope this clears things up.
  2. About separating game logic from rendering

    SFML doesn't support depth buffering for its drawables. The depth buffer can be enabled when using OpenGL directly though. But even with depth buffering I would still not know in what depth the drawables have to be drawn. If I knew the depth value I could just use that value to sort the list of drawables. Unfortunately coming up with a depth value is the tricky part because each group of children has to be sorted individually. It's not a problem if I just sort the scene nodes in-place, as the visitor will then traverse the drawables in the correct order. If I leave the scene nodes unsorted, however, I have to sort the render list afterwards. This makes sorting the children far more difficult (at least that's how it seems to me).
  3. Composite pattern with parent pointer in C++

    The parent pointers aren't necessarily needed and now I'll try to do without them. I had them mainly for convenience so I could remove a component from its composite more easily. In any case the deleted flag is a good idea and I'll have this implemented. Such a flag should also work nice along with std::remove_if. Thanks for your suggestion.   I agree with you that a unique_ptr wouldn't be a good choice for components that are shared by multiple composites. My sample code was written with unshared components in mind (a simple tree structure), so that's why I decided for unique_ptr.
  4. About separating game logic from rendering

    Hello again, I've changed quite a few things in my code. Now I have a simple scene tree that contains transformations and drawables. Originally I wanted to keep the drawables out of the tree (it was supposed to be a transformation tree) but as the sprite and shape classes provided by SFML are both drawable and transformable I figured it would be reasonable to just leave them in there. I have also implemented a RenderVisitor that iterates the scene tree and collects the drawables. As to that I still have a question though. The visitor iterates the tree in depth-first order and thus the scene is also drawn in that order. This isn't quite the order I want the scene to be drawn, so I need to sort the drawables somehow. I can think of two ways to achieve this: 1. Sort the scene nodes in-place, so the visitor iterates them in the correct order. 2. Sort the the render list after the visitor has finished building it. Though I like the second approach better, I don't know how to express the rendering order in a value so it can be used by a sorting algorithm. Let's assume my scene looks like this:   Root | -------------------------- | | Layer1 Layer2 | | ----------------- --------- | | | | | A B C F G | --------- | | D E So there is a root node, two layer nodes and some other nodes denoted A to G. Nodes A, B, C, F and G are used by entities. A, for example, represents an entity that consits of only one sprite. B represents an entity that consits of two sprites (D and E). Consequently D and E should always be drawn along with B. This is the order in which the nodes are currently drawn (depth-first order):   0 | -------------------------- | | 1 7 | | ----------------- --------- | | | | | 2 3 6 8 9 | --------- | | 4 5 This drawing order is mostly like I want it: The first layer and its children are drawn before the second layer and its children, node B and its children are drawn together etc. However, the nodes used by the entities should be drawn in the order according to their Y screen coordinate so that entities at the bottom of the screen appear as if they were in the foreground. So let's assume I want to change the drawing order of nodes A, B and C so that B and its children are drawn first, then C, and last A:   0 | -------------------------- | | 1 7 | | ----------------- --------- | | | | | 6 2 5 8 9 | --------- | | 3 4 If I was sorting the scene nodes in-place this wouldn't be a problem as I could just specify sorting rules for each group of children. But as it is here all drawables are just in a plain list (assembled by the visitor) and I need some kind of uniform sorting value to sort the whole list. (I hope you know what I mean.) Any ideas how I could do this? Or would sorting the scene nodes in-place not be that bad (it feels somewhat dirty)?
  5. You might also be interested in this wiki article about the field of vision in roguelikes:   http://roguebasin.roguelikedevelopment.org/index.php?title=Field_of_Vision   There are some strategies explained. Perhaps they would fit your game?
  6. Composite pattern with parent pointer in C++

    Children can be moved into the composites, so there is no copy construction required:   // Option 1 composite.addChild(Composite::ComponentPtr(new Component())); // Option 2 Composite::ComponentPtr component(new Component()); // ... do some stuff with component ... composite.addChild(std::move(component)); I like it because I think it's quite expressive this way and self-documents the transfer of ownership.
  7. Composite pattern with parent pointer in C++

    @Pink Horror   Aah, thanks, I haven't thought of that. If I go with the composite pattern this will be a good option for setting the parent pointers.     I have left out some implementation details because I didn't consider them important at the time of writing my post. But now I see that the missing details have caused some misunderstandings. I'm sorry for that. I edited my first post accordingly. The children are stored in a vector member of the composite: std::vector<ComponentPtr> children; So this is what the addChild method actually looks like:   void addChild(ComponentPtr child) { child->parent = this; children.push_back(std::move(child)); } The unique_ptr is passed by value to show that the ownership of the component is transferred to the composite. And yes, the removeChild method also modifies the child's parent member. This is done by an iterator returned by std::find_if, though, so the passed const reference stays untouched. I hope this clears things up.   But now as you say it I'm not sure anymore if declaring the reference const was a good idea. The child is modified after all, just by other means than using the passed reference. @Hodgman     Unfortunately I have left out implementation details in my first post because I considered them not important at the time of writing. That was a mistake. There are more details about what the Composite class actually looks like in my answer addressed to Pink Horror (and in the edit section of my first post). So to be precise there is a bidirectional relationship between composites and their children: composite-has-many-children and component-has-a-parent. The parent pointer is not absolutely needed indeed. It's just convenient to know a child's parent as it makes removing nodes easier. If the parents are unknown I need to iterate the whole structure in order to find the vector that containes the node to be removed. ----- I'm not sure whether the composite pattern is the right choice in my particular case. Being able to treat components and composites the same is negligible for me because a visitor is used for iteration. Most components will be composites anyway so having a children vector in the leafs would be negligible too. Perhaps I'll just have a common base class for components that has both a parent and a children member. I need to think about that. Thanks for your suggestions!
  8. Hello all, I wanted to use the composite pattern in C++ but I encountered a problem in doing so. My code looks like that:   class Component { protected: Component* parent = nullptr; }; class Leaf : public Component {}; class Composite : public Component { public: typedef std::unique_ptr<Component> ComponentPtr; public: void addChild(ComponentPtr child) { child->parent = this; // ... } auto removeChild(const Component& child) -> ComponentPtr; };  The problem is that in the addChild method the protected parent member can't be accessed. I just have learned that an instance A can access the protected members of an instance B if and only if A and B are of the same type or B is derived from A. So the code shown above doesn't work for obvious reasons. Now I ask myself how to solve the problem of not being able to access the parent member. Currently I can think of some possibilities:Use a friend class/function/method to access the parent member.Make the parent member public or provide a public getter/setter method.Don't use the composite pattern. Instead have only a Component class that has both a parent and children.I can't decide on the first option because I've hardly used friends in C++ so far. I'm not too fond of the second option because setting the parent should not be part of the public API. When using the third option every component would be a composite. Whether this is to be considered a bad thing probably depends on what the code is used for. In my case it wouldn't be so bad. If an object isn't supposed to have children I just won't add any. What do you think? Are there any other alternatives?   Edit:   Unfortunately I have left out some relevant implementation details. As this caused some misunderstandings  I would like to add the missing details here:   class Composite : public Component { /* some code ommited */ public: void addChild(ComponentPtr child) { child->parent = this; children.push_back(std::move(child)); } /* some code ommited */ private: std::vector<ComponentPtr> children; };
  9. About separating game logic from rendering

    Thank you very much for all your suggestions. They help me a lot. @haegarr   I haven't used visitors before but iterating over the drawables seems to be a nice application for this pattern. I'll definitely try this out.   I should be able to handle this gracefully using visitors. It's a question of visit or not to visit then. @HappyCoder   I tried to implement a component system some time ago but I wasn't successful back then. Having never used a component system before (just heard about them) I was uncertain about several implementation details. For example I couldn't decide on how to establish communication between the components - should I just use something simple like this.owner.getComponent("transform") from within components or should I rather use a more elaborate messaging system? I'm still tempted to give it another try, though, because I quite like the idea behind component systems. I guess I have to take a deeper look into this once again. The many threads on this forums about implementing such systems should prove helpful to me. @DekuTree64   Sounds very reasonable to be. I'll do it this way and keep all drawables in a separate list.   SFML provides a Drawable interface class that sprites, shapes etc. are all derived from. I'll just derive a drawable group class from it that can contain other drawables. This should do the trick. @dejaime   I like component systems as well and as I said in my answer to HappyCoder I'll check them out once more.   I already own this book. In fact it was my first book about game programming. Back then I didn't know any C++ but I liked the book nevertheless and I can still recommend it today. That's where I learnd pathfinding, spatial grids and steering behaviours from. However, I already forgot about the messaging system presented in the book. Thanks for bringing this to mind! This should be of assistance in making a component system. @Norman Barrows Currently my plan is to decouple the things like that: the list of drawables (sprites, primitives, groups etc.) the list of entities the RenderVisitor that visits the drawables (the "filters" are implemented by visitors derived from this one) the camera/view (this is already done by SFML) @Goran Milovanovic   Yes, I would like to do it in a similar way and have an entity hold a pointer to a drawable (where a drawable can be a sprite, a primitive, a group of drawables etc.).
  10. A simple approach of implementing a field of view could be to use a modified midpoint circle algorithm. You can use this algorithm to clear a circular area around a given point on a fog of war map (for example). The algorithm looks something like the this:   // This code was taken from http://en.wikipedia.org/wiki/Midpoint_circle_algorithm, ported to JavaScript and modified // to draw a filled circle. function drawFilledCircle(centerX, centerY, radius) { var x = radius, y = 0, radiusError = 1 - x; while (x >= y) { drawLine(x + centerX, y + centerY, -x + centerX, y + centerY); drawLine(y + centerX, x + centerY, -y + centerX, x + centerY); drawLine(y + centerX, -x + centerY, -y + centerX, -x + centerY); drawLine(x + centerX, -y + centerY, -x + centerX, -y + centerY); y += 1; if (radiusError < 0) { radiusError += 2 * y + 1; } else { x--; radiusError += 2 * (y - x + 1); } } }  However, the code above doesn't take line of sight into consideration, meaning all tiles in range will be considered visible. To check for line of sight between two given tiles you could use Bresenham's line algorithm instead. Here it is (again JavaScript):   // This code is based on an example taken from http://de.wikipedia.org/wiki/Bresenham-Algorithmus function drawLine(fromX, fromY, toX, toY) { var deltaX = Math.abs(toX - fromX), deltaY = -Math.abs(toY - fromY), signX = fromX < toX ? 1 : -1, signY = fromY < toY ? 1 : -1, error = deltaX + deltaY; while (true) { drawPixel(fromX, fromY); if (fromX === toX && fromY === toY) { break; } if (error * 2 > deltaY) { error += deltaY; fromX += signX; } if (error * 2 < deltaX) { error += deltaX; fromY += signY; } } }  You could also combine both algorithms to get what you want: Collect all tiles within range using the first algorithm. Check for each collected tile if it is in line of sight using the second algorithm. Remove all tiles that are not in line of sight from the collection. You're done! This might not be the very best solution for your problem but it might be a start (and it should work I guess). I hope it helps!
  11. Hello everyone, lately I was thinking about how I could separate game logic from rendering for a personal game project of mine. I tend to think a lot before starting to write any code. Many times, however, I fail to come up with a suitable solution, so I thought it might be a good idea to ask here for help and suggestions. First let me tell you that the game I work on is similar to the Zelda, Chrono Trigger or Secret of Mana games as far as the visual appearance is concerned. So basically I have a tile map with sprites moving around. The game's scene is organized into layers with each layer referring to tile maps, entities and other stuff to render. Entities are the base structure from which concrete game objects are derived. Layers are used to group objects for rendering only, so entities from layer 1 can still logically interact with entities from layer 2. The scene also contains invisible objects like trigger areas that are not assigned to any layer. I don't use a typical scene graph as the scene doesn't have a deep transform hierarchy. The scene can be rendered in different ways:By default the scene is rendered as expected when starting and playing the game.The scene can also be rendered in edit mode when the ingame editor is fired up. In edit mode trigger areas and other normally invisible objects are drawn. The rendering of other objects might be altered or filtered out completely (for example if I don't want a specific layer to be drawn).As a third option the scene might also be used to draw a mini-map on screen.I have never separated game logic from rendering that much before so I can only guess what I have to do to achieve this. Maybe I should have three different renderers like DefaultRenderer, EditRenderer and MinimapRenderer. They could all have a draw method that takes a scene as an argument: DefaultRenderer::draw(const Scene&). I'm not sure though on how the renderers should figure out what to draw and how to draw it. Let's just assume I have a Scene class and a Monster class that look like the following pseudo C++ code (I use SFML if that makes a difference). For the sake of simplicity the scene contains nothing but entities.     class Scene { public: void draw() const { for (auto& entity : entities) { window.draw(*entity); } } private: std::unordered_set<std::unique_ptr<Entity>> entities; }; class Monster : public Entity { public: Monster() : Entity(), sprite(someSpriteSheet, monsterTextureRect) {} private: virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const; private: sf::Sprite sprite; };    How do I move the render logic out of these classes? Should I store the sprites in the scene directly so the renderers can iterate them easily? Is having several renderers the right approach after all? I would very much appreciate any help and suggestions on how to do this properly. Thanks in advance.
  12. Random world/space generation

    I don't know if this is what you're looking for, but there's a Space Graphics Toolkit for Unity with quite a lot of features. With it you can create planets, stars, nebulae, dust fields, asteroid belts, startfields and more. Some of them are procedurally created.
  13. If performance becomes an issue, you could give PyPy a try. Of course, you could give PyPy a try without having any performance issues, as well. According to the PyPy compatibility page pyglet works fine with PyPy. This is only true for pyglet 1.1.4, though, as PyPy doesn't support Python 3 yet. Here is the most recent status update for the py3k branch of PyPy (the branch that adds support for Python 3) in case you're interested: http://morepypy.blogspot.se/2013/06/py3k-status-update-11.html
  14. @Hodgman, @AllEightUp Thank you for explaining and sharing your experiences. I can now understand why keeping the project self contained and not messing with the external libaries' layouts is beneficial in many ways. I'll put the SFML distro into my "external" directory as is and add it to my project's build process using CMake. In order to do so I've already taken a deeper look into the tutorial project. Being the CMake beginner I am, I wasn't quite able to understand what was going on in the CMake scripts at first. After reading through the Cross Platform Test Driven Development Environment Using CMake articles, however, it was much easier. I haven't leveraged my newly acquired knowledge yet, but I'll do so in the next days, I hope. I'm looking forward to restructure other parts of my project with CMake for easier maintainability (e.g. making the framework a library to keep it separated from the gameplay stuff). @Matt-D Thanks! I have peeked into the book on Safari Books and put it on my ever growing list.
  15. Thank you both for your suggestions! @nhatkthanh This is similar to my current setup. All my external libraries are stored in D:\Libs\. In my project root directory I have a folder named paths, that contains symbolic links to the required external libraries. It works for me, so I'll probably keep it that way if it turns out to be the best option. @AllEightUp Your tutorial project is very helpful, thanks. I use CMake, too (along with QT Creator). I'm not very adept in it, yet, so your CMake scripts are also interesting for me. I'm not entirely sure what you mean with "avoiding modifications to the external libraries", though. Were you referring to how I split up SFML in separate directories for headers and platform- and compiler-specific bins and libs? I was inspired by way SFML handled external libraries, as the SFML repository contains DLLs and libs for OpenAL and libsndfile. They're added like this in /src/SFML/CMakeLists.txt:   # let CMake know about our additional libraries paths (on Windows and OS X) if (WINDOWS)     set(CMAKE_INCLUDE_PATH ${CMAKE_INCLUDE_PATH} "${PROJECT_SOURCE_DIR}/extlibs/headers")     if(COMPILER_GCC)         if(ARCH_32BITS)             set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "${PROJECT_SOURCE_DIR}/extlibs/libs-mingw/x86")             set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "${PROJECT_SOURCE_DIR}/extlibs/bin/x86")         elseif(ARCH_64BITS)             set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "${PROJECT_SOURCE_DIR}/extlibs/libs-mingw/x64")             set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "${PROJECT_SOURCE_DIR}/extlibs/bin/x64")         endif()     elseif(COMPILER_MSVC)         ...      I thought I could do it in a similar fashion.   Or should I rather use the script FindSFML.cmake instead? I just recently payed attention to this script.