26

In this situation, it is trivial and a no-brainer. I'll be bold and not look at the whole code. I'll assume that the function in which this switch statement is (Game::updatestate()) is called once per frame. This switch statement being called once per frame is a droplet in the ocean. Typically, graphics rendering, physics and AI take up much more CPU time ...


25

In fact, switch statements are more efficient than if-else chains for one simple reason: Switch tables! (Also known as branch tables or jump tables). The simple explanation is that in a typical switch statement, each case ends in a break statement, so the compiler can figure out that exactly one path is going to be taken upon entering the switch. So then ...


9

In my experience writing collision detection, mesh-based collision (triangles versus other triangles) are the most expensive form of collision in physics engines (PhysX, Havok). Unity uses PhysX internally, so this is no different. Because each computer and platform perform differently, exact numbers cannot be provided, but generally speaking the relative ...


8

I think it depends on several factors: How big your game is If your game is small and can fit memory, it's much easier to load everything at once and keep it in memory. If your game is strctured as levels, load everything you need and keep it in memory (e.g. UI, main character) and load each level resources when you need it. The nature of the game Open ...


8

The resolution for this could be the same you'd use for processing held keys on the keyboard. colliding = checkCollision(this, otherObject); if(colliding && !previousFrameColliding) { //trigger hit with otherObject } else if(colliding && previousFrameColliding) { //still in contact, do what you will here, or nothing } else if(!...


8

You've implemented your own wait function that keeps the CPU running a small loop instead of letting it process other threads. Call a sleep() method instead. It comes in various styles and flavors (depending on platform) or, if you want to keep your code portable, you could use Boost Thread e.g boost::this_thread::sleep( boost::posix_time::seconds(1) );


8

There is a surprising amount of confusion about how the compiler optimizes if/else chains vs switch statements. This is probably because there have been many changes over time in how compilers optimize these constructs. And even using the latest compiler versions, the answer depends on: what optimization level you are using, what values you are checking for,...


6

Basically its like Marthon said, that most engines simply redraw the whole scene on every render call and not only portions of the visible scene. What you are looking for is a way to limit the objects/tiles, that are actually rendered. If you have a 2d array of tiles, that are all same sized its pretty simple to find the start and the end index of the x and ...


6

Instead of using LookAt, you can have the shader force the object to be rendered facing the camera. Thus, no script needs to be added to the tree, and the extra work the shader does is very little. Here's an example: Billboard Shader Also, since they don't actually move or rotate (as far as the CPU is concerned) and share the same material, you can turn on ...


5

I only have some mild knowledge in unity, but here are some suggestions I hope you find useful. Split the whole simulation into a few things: Large waves Medium waves Small waves Boat's reaction water Water's reaction to boat The first two can be done by moving a tiled displacement map over a plane mesh. You have a large, low detail map which represents ...


5

I found usefull this algoritm for love2d engine (lua language) https://love2d.org/wiki/TileMerging -- map_width and map_height are the dimensions of the map -- is_wall_f checks if a tile is a wall local rectangles = {} -- Each rectangle covers a grid of wall tiles for x = 0, map_width - 1 do local start_y local end_y for y = 0, map_height - ...


4

This website discusses the problem and has implemented a triple-buffer solution as Roger suggested: http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part1/ http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part2/ http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part3/ http://blog....


4

With something like a sword swing, you don't actually care that much about the question "who am I colliding with right now?" What you care about is not state, but rather, change of state, that is, you're interested in knowing when the sword/enemy collision state changes from false to true. The only way you can measure changes in state is to compare your ...


4

great performance saving comes from caching geometries and materials. In your case, create CubeGeometry and MeshPhongMaterial objects only once and then use them when creating tiles - each tile will be separate Mesh but all pointing to same instance of material and geometry objects. Then do the same for all resources that can be reused - models, textures ...


4

I'm going to take a stab and recommend a hierarchical pathfinding algorithm, such as HPA*. Even though I'm not an expert in AI, I'm fairly confident in this guess because your generator sounds almost identical to the one in a game I'm working on, i.e. I've thought about this problem a bit too. HPA* (Hierarchical Path-Finding A*) is a method of optimising ...


3

This depends on what operation you are performing on vectors. vectors are actually really fast. iteration is as fast as possible, since the vector does not store pointers but an array of objects in one straight block of memory, so iterating over a vertex is as fast as iterating over an array. And even the iterator-objects do not add a overhead, in production-...


3

If you already have SAT working, then you can pretty easily extrude an OBB along its linear velocity for a frame (i.e. create a swept OBB). The result will be a polyhedron, so you can use SAT with it. This only handles linear velocity, though, not rotational velocity. That's quite a bit harder because a rotating OBB sweeps out a volume that isn't a ...


3

Use neither, because both approaches involve loading and freeing GPU resources at runtime, which is slow and will lead to constant thrashing of video RAM. Instead what you should so is have knowledge of all UI resources needed at startup time, and load them all during program startup. Then when you need to use a resource for drawing, you just use the ...


3

When designing for current PC GPUs you are not playing after the same performance rules, as, for example, a cellphone or the Amiga. Modern GPUs are way more powerful than you can imagine and most of the time the bottleneck is not the drawing itself but actually the communication between your code running on the CPU and the GPU. Take a look at this answer ...


3

Many years ago Jos Stam started putting out his source code for fluid solvers. There is a very short bit of code that sets up a grid and solves the Navier-Stokes equations very fast. The full source is available on his page as well.


3

Plants vs Zombies just uses the N^2 algorithm, and they get quite a lot on the screen (on cell phones too...), so you are probably fine with just iterating. The absolute fastest would be using sweep and prune. The bullet physics library has a good implementation for reference. This is a good algorithm to just have in your toolbox if you make a lot of ...


3

My first suggestion is that you begin with the approach that you have posted, because it might be fast enough, and it's trivial to implement. Then if you identify a problem, move over to a more complex solution The simple approach suggested by MSDN is is basically just linearly iterating over every bullet and enemy, and checking every possible combination ...


3

Given that the rooms are procedural built, portals created and then populated, I have a couple of ideas. A* works really well on navigation meshes, and works hierarchically as well. I would consider building a pathfinding system that works at two levels - first, the room by room level, and second within each room, from portal to portal. I think you can do ...


3

If you are looking to create destructible terrain, the way I did this in Unity, is to only set colliders on the edge blocks of your world. So for example, this is what you would like to accomplish: All those green blocks contain a collider, and the rest of them don't. That saves a ton on computations. If you destroy a block, you can activate the ...


3

Maybe enum is not the best choice in this case. You could try building a "tile" class and derive several subclasses from it (farm from your example). This way you could implement some sort of levelling system (instead of having to create a value for each level (farm1, farm2 etc)) inside the class and give the several kinds of tiles unique abilities in form ...


3

enum is actually a good idea here, but what you want is for the enum to be: enum MapTileBuilding { defaultTile, homeBase, farm1, farm2 /*...and so on...*/ }; and a class class MapTile { MapTileBuilding building; ... //other members e.g. //structuralStrength //isOnFire //troopCount //incomeGenerated //etc. } ...which gives you the ...


3

Your points seem reasonable. For static elements that are set up once and never change, you can certainly pack them into a GL_STATIC_DRAW buffer and keep it alive for as long as needed. If you still have to move these static elements around in the screen, then this approach is not very interesting anymore because each would need a transformation matrix that ...


3

You may want to have each region contain a list of particles which are in it. Then, when you move each particle, check if it is in a new region - add it to the new region's particle list, and remove it from it's current one (based on your checking above). That way you can just tell each region to apply the force to the particles in it's list (the work has ...


3

Each product that exists in your world could be listed in an array or table in a database. Each product can then have a collection of Recipes. Instead of each Recipe actually containing a Product, the can simply reference the Products necessary to produce another Product. For example, let's say Cheese is made from Milk and Chemicals. :) All these things ...


3

Because switch statements work on only a single variable they can be optimized very easily compared to an if-else statement. The most naïve way to do so would be to determine the case using a binary tree. Of course, I doubt this is the reason for using switch in VVVVVVV. The amount of time saved is unlikely to be meaningful especially with branch prediction.


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