Tag Info

Hot answers tagged

43

Simple answer: the game is divided into chunks, while you move around chunks are constantly being loaded behind your back before you can see them and thrown away when you leave the area. To every simple answer is a complex solution that weighs innumerable trade-offs in implementation... but you get the idea. For games where you think you can see tens or ...


16

You need to be "Reticulating Splines"


13

The typical things to pre-load is anything that you're going to need in realtime. Save for concepts like clipmaps and megatextures (where the idea is to load the parts you need, and iteratively update it as you move around in the world), you're going to want to keep everything you need for your level/area/whatever in memory rather than on disk. IO is ...


12

Previous answer pretty much nails it all. Also worth mentioning is Dungeon Siege I. Here's a paper from one of the developer which actually goes over some of the architecture needed to make it work and common pitfalls: http://www.floatingorigin.com/mirror/continuous-world.htm I'd say it's a must read if you actually want to implement something like that.


10

DrawableGameComponent's come with a certain amount of overhead - aside from the memory, every time you add a component to the collection it must be resorted (because components have a DrawOrder). You don't want to be constantly adding and removing components. For this reason, you don't want Bullet to be a DrawableGameComponent. Instead, you should make ...


9

Assimp seems to be a good choice and I will be testing this with my next project. It supports a huge array of formats including supporting bones and animations. Not just for model loading, but for changing from format to format, computing vertex and face normals, splitting meshes, and triangulating polygons. It is available under the BSD license.


9

Basically, I'd say that during the "Loading" process the game tries to load and precompute all operations that cannot be done in runtime. For example, retrieving images (to be used as textures) for the hard drive is usually a slow process. On the "Loading" step these images can be copied to RAM memory, which is muuuuch faster access storage, enabling ...


8

Welcome to OpenGL, where the fast things come for free and the easy things are made hard. If you thought that sample was long and complicated, "just for loading a texture", then you've seen nothing yet. Wait until you have to load DDS textures, process HDR textures, support cubemaps, render to a texture, etc. Loading a texture in OpenGL consists of two ...


8

I would avoid using reflection for something like this, and use a language-agnostic tagged blob format, or something like this (just one possible method for entity serialization): Have an ISaveable interface with a method that produces an Entity given a hunk of save data, and produces a hunk of save data given an Entity. public interface ISaveable { ...


7

First of all: how you do it doesn't really matter. Just do the very simplest thing that could possibly work. My current favourite way is with static methods in each class (ie: bullet, ship), like this: static Texture2D myTexture, myOtherTexture; // Call me from Game.LoadContent: public static void LoadContent(ContentManager content) { content.Load /* ...etc ...


7

For now, since calculating the paths mid-game is unnoticeable, that is the ideal approach. If / when it gets to the point where gameplay is interrupted by the calculations, then switch it over to per-calculating the paths before the level is loaded. Longer initial loading times are forgivable, but random FPS fluctuations during play generally aren't.


7

The general approach is called hysteresis: instead of immediately changing when you cross a border, you change only after you are some distance past the border. For the simplest example, suppose you want to draw a warning on the screen if you are too close to something. The straightforward code is: if distance < 20: draw warning But if you're ...


6

I've studied the DOOM source code a bit. I'll tell you how it's done in there. D_DoomMain contains all of the open/save/load functions, as well as a slew of other things. As it says at the beginning of the file, // DESCRIPTION: // DOOM main program (D_DoomMain) and game loop (D_DoomLoop), // plus functions to determine game mode (shareware, ...


6

Serialization would be the way to go, and as for the status-checking, you could have logic in the deserializtion method to do so.


6

Minecraft is a 3D game with a game world that is extremely large in size (practically infinite). Instead of 3D terrain derived from meshes, the terrain is represented by 3D Cubes. The world is procedurally generated and stored in small chunks, similar to what you described in your first potential solution. While playing Minecraft, chunks near the player ...


5

The simplest texture manager has one function: GetTexture. GetTexture checks its cache for a texture. If the texture isn't cached, it loads the texture. Then it returns the texture. Kapow! Done! That is sufficient for most small-scale indie games I've seen. You just don't have enough content for this to ever be a problem. One downside is that this can ...


5

Premature optimization is the root of much evil. If your goal is loading-time prediction, I would say leave the OS file-caching in place. It's probably general, but well-written, so I would say that you shouldn't disable it unless: You have a very good reason to do so, and You can measurably prove that disabling it is beneficial in your case. ...


5

BerickCook has expressed the idea correctly. Leave the calculations where they are if they work properly now. If you can do the calculation before and you are sure you will not need them mid-game, then do it before. Else do it after loading. If the calculation during the game is unnoticeable you could do it there. If at some point the complexity evolves and ...


5

I don't know how this feature would be implemented in your specific development environment, but the solution to the problem you describe is masking. Basically, apply a mask to the progress bar in the shape of your letters and then the stretched rectangle won't be rendered outside the mask.


5

I dont know how technically Sonic 2 bonus stages are done, they could be computed by the cpu/special custom chip (and thus realtime) or totally precalculated and stored inside cartridge (like a very low resolution movie). If you are using same color range, resolution and low framerate as sonic example you give, you should be able to get really lower than ...


5

It's been a while since I used C#, but I think you can structure your class something like this: public static class Tile { public static enum TileType { Air, Stone } public static bool IsSolid(TileType tile) { switch(tile) { case Air: return false; case Stone: ...


4

As the commenter said: check to see if your app runs fine when running as administrator, because if it does, that suggests something different. Otherwise, I think you're running into a straightforward access rights issue. You don't, as a rule, have the right to open any files under "C:\Program Files" with write access. So you don't get to save any files ...


4

I'd say this really depends on what type of game you're making, but some general points. Only load what you absolutly know you need immediatly, or you know you'll need soon Only remove things from memory when you absolutly know you wont need them again AND you need to load something that fits the constraints of #1 AND you've reached your memory limit A ...


4

If the loading screen is rendering, make sure it is not also locking resources which the loading thread needs to use. Easy way to tell if the loading screen is chewing up resources due to rendering too often - put a 1000ms Sleep in the render loop of the loading screen, and see if your loading performance comes back to normal.


4

The toString() part on its own doesn't seem so bad. I think one way of handling the re-loading of the objects would be through use of Reflection. // an example of a forName argument: "java.util.Map" Class loadedObjectClass = Class.forName(xml.getElementValue("clazzName")); Object loadedObject = loadedObjectClass.newInstance(); I'll also note some people ...


4

if( (NULL == strstr( (char const*)glGetString( GL_EXTENSIONS ), "GL_ARB_texture_non_power_of_two" ) ) ) //############ it points here ############// You are creating an OpenGL 3.2 context. glGetString(GL_EXTENSIONS) returns NULL because it has been deprecated in 3.0 and removed in 3.1. It was replaced by glGetStringi(GL_EXTENSIONS, i). See ...


4

What you're doing is multi-part loading assets, which is extremely common and a very sensible approach. You cannot avoid the 'pause' or black screen though, because the assets have to come down the wire at some point, right? So all you can do is make this process as attractive and seamless as possible. Either a nice preloader, or maybe showing the next part ...


3

I use STB Image for most image loading. A small self contained no strings attached implementation of png and other file formats.


3

I'd say no. Windows will be using spare memory for this caching - it's basically free. Unless you've got a fancy system to somehow expand your process memory to cache more data when Windows is under low load, and then contract it again when Windows decides it wants more memory, just let the computer do what it's good at it. I don't think increasing load ...



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