40

Don't delete this Even implicitly. - Ever - Deleting an object while one of its member functions is still on the stack is begging for trouble. Any code architecture which results in that happening ("accidentally" or not) is objectively bad, is dangerous, and should be refactored immediately. In this case, if your monster is going to be allowed to call '...


21

Instead of queuing events in a buffer, queue up deletions in a buffer. Delayed-deletion has the potential to massively simplify the logic; you can actually free up memory at the end or beginning of a frame when you know nothing interesting is happening to your objects, and delete from absolutely anywhere.


15

The Concept Fundamentally, a scene graph is nothing more than a bi-directed acyclic graph which serves to represent a hierarchically-structured set of spatial relationships. Engines in the wild tend to include other goodies into the scene graph, as noted. Whether you see that as the meat or the cow probably depends on your experience with engines and ...


13

It's mainly used for frustum/occlusion culling and minimizing the collision checks between the objects. Not true. It's mainly used for programming convenience and hierarchial animation. There is no way culling and collision checks benefit from scene graphs. Quite the opposite, actually, since it's required to calculate and cache the world space data before ...


12

It's possible to make your shader system more data-driven, so that you don't have so much shader-specific code laying around for uniforms and vertex formats, but rather set them programmatically based on metadata attached to the shaders. First the disclaimer: a data-driven system can make it easier to add new shaders, but on the other hand it comes with ...


8

Neither is needed. The choice of scene graphs or spatial partitioning or both is a matter of optimisation. And until you have a functioning game, you have nothing to optimise. So obsessing over this sort of detail now is counter-productive to the creation of your game. My advice: make the game, then measure which bits of it are slow, and finally fix ...


8

You can easily have coordinates going into the millions on units with an int. You can go all the way up to 2,147,483,647 units in the positive or negative direction. Procedurally generated worlds are not actually infinite. They're just very very big. If you think that 2 billion isn't enough, use a long to store your chunk coordinates, then you can go up to 9....


7

I tend to disagree with Trevor Powell's answer as there are clearly two different kinds of optimization here. One is optimization after the fact and to make the slow parts go fast, which is what he has touched on, but the other is designing your data structures and flow control to be at least reasonably efficient and sensible in the first place. The second ...


7

You seem to be treating your scene graph as a tree - each scene contains N boats, each of which contains its own copy of the "boat" scene graph, etc. This is not fundamentally wrong, but can certainly be improved upon. The following diagram illustrates my understanding of your current approach, for a scene with two boats1: Rather than storing N copies of ...


6

Yes, Transform component has Parent Transform. http://docs.unity3d.com/Documentation/ScriptReference/Transform-parent.html


5

You compile your shaders and bind them into programs. You can use the same VBOs again and again but with different uniforms or even programs, in the same frame, without problems. For each program, your calls to glGetAttribLocation will return -1 if that attribute is not in the program, or has been optimised-out (e.g. you declare it but don't use it). ...


4

Most levels in 3D platformer games are built on a 3D grid. The old Tomb Raider games are very obvious about this. (Press forward and the character moves one square every time, you know you can jump 3 squares if you are running but only 2 if you are standing, etc.) Even more recent examples, such as Darksiders 2 follow the same idea. The character has a ...


4

What is a scene graph? A scene graph as used in videogames is defined as a tree of nodes, where each node has 1 parent or no parent. The node without a parent is called the root node, because it defines the start of the tree. Each node can also have 0 or more children. What are they used for? Suppose you have a game where tanks are driving over terrain, ...


4

Instead of letting the world to handle the deletion you could let another class's instance to serve as a bucket to store all deleted entities. This particular instance should listen to ENTITY_DEATH events and handle them such that it queues them up. The World can then iterate over these instances and perform post-death operations after the frame has been ...


4

Deep within the game engine your mesh is defined by your vertices, your indices (which define how to draw the triangles using the vertices), and its material (which consists of the shader as well as other parameters). Submeshes allow you to define separate lists of indices and materials (depending on the engine) over the same vertex data which is useful not ...


4

why not create a list of enemies in the level so the draw becomes: List<GenericEnemy> enemies;//filled during construction Render(){ //Render elements common to all levels draw(background); draw(playerSprite); for(GenericEnemy enemy : enemies) { draw(enemy); } } where GenericEnemy is a superclass of all enemy types,...


4

Before addressing the specifics of your question, I do want to point out that I disagree with your approach to your inheritance model. A Game generally does not implement a Scene but instead a Game consists of one or more active Scenes that are being rendered and updated in a main loop. It's important to think about whether a class relationship can be ...


4

Store the components and compute the matrix on-demand when you need it. Storing the matrix itself is inferior if you're ever going to be manipulating the transformation in any interesting or useful way, because floating point error can creep into the matrix after repeated successive mutations (such as rotations). This can result in a matrix that doesn't do ...


3

It's a little confusing as Unity conflates the organization of scene items with its transform hierarchy. There's no way to bucket or organization items without parenting them to another object. The best bet you will have is to make empty "folder" objects that have no components and no state but simply serve to be a named collection of objects. These folder ...


3

So firstly, I'd like to apologize if my question was poorly worded or if it was just confusing in general. I think I've figured out the proper solution now. It took a while because I had passed it off earlier after trying it and not immediately seeing desired results (I needed to basically remake my wooden manikin object from scratch). Basically, I found ...


3

In most game engines today the typical design is that a scene is a graph / tree of components some of which may be renderable. In a sense you are correct, every object is basically a node in a tree of things. You may have heard the expression "Entity Component System" and the expression "Component Composition" in relation to game engines and more ...


2

Use pooling and don't actually delete objects. Instead, change the data structure they are registered to. For example for rendering objects there is a scene object and all the entities somehow registered to it for rendering, collision detection etc. Instead of deleting the object, detach it from the scene and insert into a dead objects pool. This method will ...


2

I'm going to explain how my little engine does it, as whilst it is not generally tested against alternatives - its my approach and I haven't tried many others - it does explain how things can work: I store my scene in an octree or quadtree (recommend quadtree if the scene is mostly flat e.g. RTS even if units can have height; only go true 3D if things ...


2

You can implement managed-memory in C++ yourself, so that when ENTITY_DEATH is called, all that happens is the number of its references is reduced by one. Later as @John suggested at the begging of every frame you can check which entities are useless (those with zero references) and delete them. For example you can use boost::shared_ptr<T> (documented ...


2

You should separate the triangles in groups, as in making separate game objects, then assign a bounding volume to it and check the box geometry against the frustum planes to discard all triangles contained in the bounding volume. You need to separate objects in order to define a local coordinate space/object center for each triangle group that makes a 3D ...


2

Per-triangle culling is done by the GPU, so you should only draw entire objects. Some tips: Break down your scene into smaller objects, preferably doing it based on their material, so they are drawn in a single batch. Calculate a bounding box for each object, and intersect them with the view frustum. Discard or draw them based on this criteria. Use VBOs for ...


2

I would suggest implementing a factory that's used for all game object allocations in the game. So instead of calling new yourself, you would tell the factory to create something for you. For example Object* o = gFactory->Create("Explosion"); Whenever you want to delete an object, the factory pushes the object in a buffer that is cleared the next frame....


2

You might not need an anchor point in each node. When you make the 3D model, you can place it so that the origin is at the anchor point. For example, if you're making a human model, and you want the anchor point to be between the feet, then just make sure the origin is between the feet when you export from Blender, or whatever you are using. If you do want ...


2

Answering my own question: Looking at Actor's code, it seems to be as simple as overriding the default hit() method. The original code is: public Actor hit (float x, float y, boolean touchable) { if (touchable && this.touchable != Touchable.enabled) return null; return x >= 0 && x < width && y >= 0 && y <...


2

Scene graph organization is guided by the various consumers of the scene - see answer to "Scene Graph as Object Container?" Fundamentally, the scene graph associates objects such that they share some logic, physics, position, and/or render state. So concerning organization-by-type, except for very simple games it would be a mistake to treat the scene graph ...


Only top voted, non community-wiki answers of a minimum length are eligible