Archived

This topic is now archived and is closed to further replies.

dave

The Big 10 questions that could help alot of people, PLEASE READ!

Recommended Posts

Hi everyone, When it comes to developing a graphics (or grpahics engines) i and im sure many others would like to know: 1. Are most of todays latest levels created with mostly imported objects, or is alot of it done by manually describing the size of walls etc using an editor? 2. What is the approach for storing large amounts of level data? Im temporarily using text files and fscanf, i know this aint the best. Do the Pro''s use XML structure? 3. When it comes to things like optimizing the engine to make things render from back to front, is it done by a bubble sort or something? 4. Could someone suggest tutorials for : -: Light Mapping -: Alpha Transparency - i have tried everything ive seen suggested. -: FPS keyboard and mouse control (the maths aspect). -: Blending multiple textures to one surface/object in the scene. 5. Are PAK files similar to the CAB files found on CD/DVD''s. 6. One topic thats troubling me in particular is when using a spotlight the light passes through objects, which looks stupid. How can i stop this without going through the process of stencil shadows, or is that the best way? Can i do that without the shadows? 7. When i rotate an object with the world matrix, is there some sort of object axis(eseses) that moves with it? When i apply one matrix rotation, the others dont then change the object in the expected way. 8. How much information about the game/level etc is it sensible to load from files? I noticed on the quake engine that each haracters movement was mapped out in a textfile. 9. Does everyone use MFC or have you written your own classes specific to your needs? 10. Is it possible to use an index buffer when not using D3DXMESH''s? Every example i have seen so far either uses meshes with index buffers or vertexbuffers without index buffers. For example, if i want to draw half of the mesh stored. I hope these can be answered, if only just one of them. regards, ACE

Share this post


Link to post
Share on other sites
I nice way to put this in one sentence... I don''t have time to answer your questions... is that you should get yourself a nice thick book with beginning how to program games(Beginner not GURU )

Actual Linux peguins were harmed in the making of this message.

Share this post


Link to post
Share on other sites
Here are my first approximations to answers:

1. Props (lamps, tables, etc) are almost always going to be imported objects, but for things that may change size such as rooms or platforms, an editor is quite valuable. In particular, some games use a tile-based layout, where a piece of a wall or floor can be replicated on a grid to form a larger enclosed space. Your decision depends on what kind of artwork you need and what your processing requirements are.

2. Nothing wrong with text files, they''re easy to read and easy to change quickly. For various reasons, it''s better to have a binary format that can be read in also, as such:

(in development)
A. Read in text files, process, and store in memory
B. Save processed level data into a binary file

(in production)
A. Read in binary file directly to memory

This speeds up load times considerably. XML is easier for online parsing e.g. in an editor.

3. This depends on your implementation, but I would use insertion sort as objects are added, so you don''t have to resort everything when adding a single object.

4. I would really get a simple model and level engine before adding light mapping or texture blending. Input control should be out there, the math involved is mostly linear algebra and quaternions. Get a handle on those and you''ll have some idea how to approach it.

5. PAK files are (I believe) compressed file systems, like CAB or ZIP files. They make it easy to load a file from inside an archive, while transparently decompressing / decrypting it.

6. It seems what you''re talking about is shadows. Lighting is tough, there isn''t a really good comprehensive solution yet.

7. When you apply a rotation matrix, the axes (X, Y, and Z) rotate with the object, so the next rotation is relative to the new axes, which rotates the axes again, and so on. Quaternions are nice because they can always be decomposed into a single axis and rotation around that axis.

8. Where else would you load data from?

9. MFC is not needed for most games, the UI is usually drawn within the game.

10. I can''t answer that question right now.

Hope this helps.

Tom

Share this post


Link to post
Share on other sites
2. Generally use binary file IO.
5. Not sure about PAKs in general, but at least Quake3''s PK3s were simply ZIP files with a different extension. You could open them in Winzip.
6. You need a shadowing algorithm. One alternative to stencil shadows is shadow maps.
9. MFC, afaik, is used primarily for Windows GUIs, not games, which just create a fullscreen OGL/DX window, and do their own thing from there.

Share this post


Link to post
Share on other sites
1. Are most of todays latest levels created with mostly imported objects, or is alot of it done by manually describing the size of walls etc using an editor?

Levels are created in editors, though the paradigms of the editor vary. Virtually all allow/support importing objects from general-purpose 3D modelers; some editors are actually scripts that run inside 3D modelers (eg SCEE Team SoHo's facial animation editor for The Getaway, which runs in Maya).

2. What is the approach for storing large amounts of level data? Im temporarily using text files and fscanf, i know this aint the best. Do the Pro's use XML structure?

XML is a bad idea. Yeah, it's easy to edit by hand, but the sheer size of level data makes that unrealistic. Typical level file formats are binary and tend to use compression to manage size.

3. When it comes to things like optimizing the engine to make things render from back to front, is it done by a bubble sort or something?

No, you perform occlusion test. That is, you determine whether a given object (or portion of an object) is visible from the current camera position. There are many, many techniques for doing this, but modern 3D APIs take care of the grunt work for you. A good Graphics textbook will fill you in to your heart's delight (I recommend Computer Graphics: Principles and Practice by Foley, Van Dam, et al. Check your local/college library).

4. Could someone suggest tutorials for...

Google.

5. Are PAK files similar to the CAB files found on CD/DVD's.

Yes and no. PAK file format[wotsit.org]

6. One topic thats troubling me in particular is when using a spotlight the light passes through objects, which looks stupid. How can i stop this without going through the process of stencil shadows, or is that the best way? Can i do that without the shadows?

You gave no specific details (API, implementation, render states, etc); expect no specific answer.

7. When i rotate an object with the world matrix, is there some sort of object axis(eseses) that moves with it? When i apply one matrix rotation, the others dont then change the object in the expected way.

The cumulative effect of world matrix rotation is exactly the reason why the model matrix exists.

8. How much information about the game/level etc is it sensible to load from files? I noticed on the quake engine that each haracters movement was mapped out in a textfile.

"It depends." It depends on how much RAM is available, on the size of your levels, on the number of objects, on...

9. Does everyone use MFC or have you written your own classes specific to your needs?

MFC is the devil. Microsoft released the Windows Template Library but provided no support for it. Both have been supplanted by the Windows.System.Forms namespace of the .NET Framework. For GUI programming, switch to .NET.

[Can't help with the last question; haven't been paying attention to DX until now, what with the release of MDX.]

[Edit: "HTML Gone Wild!"]

[edited by - Oluseyi on March 28, 2004 4:46:14 PM]

Share this post


Link to post
Share on other sites
I was going to post my answers, but I would just be repeating what others have already said. So, my answer to your ten questions is:


ditto

Share this post


Link to post
Share on other sites
6. Walls and objects in a 3D computer-generated world don''t automatically stop light from passing through them to surfaces behind them like real-world walls and objects do. This is where you would need stencil shadows. However, this can be extremely slow for infinite spotlights. You need to look at attenuation, which is the distance over which a light is effective. Then, you can limit the number of polygons which are affected by the light, and limit the amount of stencil shadowing you need to do. Doom III uses this method, as do the vast majority of modern shadow-using games...


Windows 95 - 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can''t stand 1 bit of competition.

Share this post


Link to post
Share on other sites
since no one else will, Ill answer # 10.

yes you can use index buffers without using directx meshes. I actually recommend using index buffers for pretty much all of your geometry, as most video cards love index primitives.

yes and you can use index buffers to only draw parts of a model at a time. For example you would have a mesh with a vertex buffer and an index buffer. The index buffer would hold indices grouped by the texture they use. So your IB (index buffer)would hold 3 diffrent chunks of indices. the first chunk would be for the parts of the model that use texture 1, the second chunk would be for the parts of the model that use texture 2 ect... the vertex buffer would not be broken down into chunks because it doesnt need to be. Then when it comes time to render you do this:
set vb,
set ib,
set texture 1
render all the indices inside chunk 1,
set texture 2
render ib chunk 2
set texture 3
render ib chunk 3

get the idea? ... i hope that answers your question. oh yeah and just so were clear, you cant have an index buffer without a vertex buffer. but you can have a vertex buffer by itself.

Share this post


Link to post
Share on other sites
quote:
Original post by ace_lovegrove
1. Are most of todays latest levels created with mostly imported objects, or is alot of it done by manually describing the size of walls etc using an editor?



I guess a mixture of in-house level editing tools and stock model editors (3DS etc).

quote:

2. What is the approach for storing large amounts of level data? Im temporarily using text files and fscanf, i know this aint the best. Do



Text files and fscanf isn''t bad. It''s a bit inefficient though (in terms of space and speed). Most people will eventually replace their text files with a binary format, even if using text files during development. However I''ve seen some games that store at least some of their data as text files.

quote:

the Pro''s use XML structure?



Not normally for very large structures; XML is extremely inefficient (much worse than txt files). Some games use it for runtime configuration (example: weapons definitions, user prefs etc).

quote:

3. When it comes to things like optimizing the engine to make things render from back to front, is it done by a bubble sort or something?



Probably not. It might use a bubble sort (or insert sort), but more likely some kind of space partitioning (BSP, Quad-tree, oct-tree etc).

quote:

5. Are PAK files similar to the CAB files found on CD/DVD''s.



Conceptually identical. Don''t worry about them too much.

As far as I''m aware, the original reason that pak files (/ wad files etc) were used was that under DOS filesystems, storing lots of small files is incredibly inefficient.

When DOOM came out (back in 1993), the 11Mb WAD file was a much more efficient way of storing their data than around 10,000 files of an average of 1k each.

11Mb was a lot in those days. Most people had HDs measured in the 100s of Mb, so you could easily have used up someone''s entire disc if you stored the files individually.

I think that a lot of games use uncompressed pack files (DOOM certainly did) for faster access.

Of course with the advent of huge discs, and most OSs now use a more efficient filesystem (but still has some slack space), the original motivation for using pack files is now mostly gone.

It is still quite nice to have a smaller number of files though; for example, if you have one file per level (mission, campaign etc), it makes end users sharing levels easier.

quote:

9. Does everyone use MFC or have you written your own classes specific to your needs?



I don''t think the MFC GUI classes are very suitable for using in games. You can still use the MFC for other things though.

I don''t know how many commercial games use MFC; my guess is not a lot. It doesn''t do much that''s useful to games programmers and its licence probably doesn''t allow its use on other platforms than Windows (PS2, Cube etc) (And there are probably no non-win32 implementations either)

Mark

Share this post


Link to post
Share on other sites
XML is getting hated on a lot here for its supposed inefficiency. It's worth noting that ZIP/etc. compression these days makes this argument more or less moot; but it is often still better to store data which is more "numeric" in nature (and consistent) in a binary format. XML is also friendlier (though still not particularly awesome) for manual editing, if it happens to be needed.

There are a lot of pages on the c2.com wiki about this. You should probably read them in order to get a balanced opinion.

[edited by - Zahlman on March 29, 2004 5:43:38 PM]

Share this post


Link to post
Share on other sites
quote:

Original port by markr
Of course with the advent of huge discs, and most OSs now use a more efficient filesystem (but still has some slack space), the original motivation for using pack files is now mostly gone.



Not really, modern FSs actually allocate *more* per block than old style FSs (because we have larger discs), plus the fact that seek times are still a (major) limiting factor. A single large file that can be read sequentially still beats a bunch of little files. Of course the actual real world performance depends very much on your loading implementation, and the amount of wasted space for individual files is likely to be trivial compared to the size of a game install (perhaps 5-10MB out of 2GB).

Share this post


Link to post
Share on other sites
quote:
Original post by Zahlman
XML is getting hated on a lot here for its supposed inefficiency. It''s worth noting that ZIP/etc. compression these days makes this argument more or less moot...
No, it doesn''t. XML isn''t being "hated on" for its file size inefficiency, but rather for its runtime inefficiency. Parsing the entire tree takes time, and is virtually mandatory for even the most atomically minute XML operation.

Share this post


Link to post
Share on other sites
quote:
Original post by ace_lovegrove
1. Are most of todays latest levels created with mostly imported objects, or is alot of it done by manually describing the size of walls etc using an editor?


Some editors (Morrowind, Neverwinter Nights) use imported pieces of geometry for walls, buildings, etc. These are popular for games that have a wide variety of outdoor environments and are meant to be easily moddable but don't have a big speed requirement. Some editors (Quake, Unreal, Half-Life), generally for FPS's which want to be as fast as possible and mostly take place indoors in small rooms and corridors, use a system called BSP (Binary Space Partition) trees to store their level data for faster rendering; this generally requires that people shape the walls and rooms out of "brushes" in the game's editor so that it can be easily converted to BSP data. Random objects like lamps or statues are sometimes still imported objects.

quote:

3. When it comes to things like optimizing the engine to make things render from back to front, is it done by a bubble sort or something?


Not sure if this was just a typo, but you usually want to render front to back, not back to front. You should render all regular objects front to back (so that the engine can just skip rendering objects that are already occluded by something in the front), and then render all transparent objects back to front. It's good to keep opaque and transparent objects in two different lists to make this easier.

quote:

6. One topic thats troubling me in particular is when using a spotlight the light passes through objects, which looks stupid. How can i stop this without going through the process of stencil shadows, or is that the best way? Can i do that without the shadows?


If it's a static spotlight (doesn't move around), and a static object (like level geometry), you can do it with a lightmap (look for a tutorial). If it's a moving spotlight or a moving object, you need to do some kind of shadow algorithm (stencil or projection both have good points and bad points).

quote:

7. When i rotate an object with the world matrix, is there some sort of object axis(eseses) that moves with it? When i apply one matrix rotation, the others dont then change the object in the expected way.


If you haven't already, you should look up some tutorials on Scene Graphs. A scenegraph is basically a big tree structure starting with the root (world) node, and then branching out to other objects. So you could say, have a turret attached to a tank attached to a carrier ship attached to the world, and rotating or moving certain nodes will affect all other nodes logically. All modern engines use some type of scenegraph.

quote:

8. How much information about the game/level etc is it sensible to load from files? I noticed on the quake engine that each haracters movement was mapped out in a textfile.


There is a school of thought that says anything that you might possibly want to tweak as you're working on the game should be loaded from an external file so that you don't need to recompile the entire game every time you, for example, want to tweak a soldier's movement a little bit until you get it perfect. Also, if you want people to be able to mod your game, or even if you plan on having level developers working with you on making the game, the more things you allow modifiable outside of the source code itself, the better.

quote:

9. Does everyone use MFC or have you written your own classes specific to your needs?


As others have said, almost no one uses MFC unless they need the Windows GUI. Even then, you're probably better off using WTL or .NET. If you're talking about things like CString and CMap and that stuff, then you're better off using the Standard Template Library (aka the STL). There are a lot of good tutorials on that too.


[edited by - makeshiftwings on March 29, 2004 6:40:04 PM]

Share this post


Link to post
Share on other sites
1) In Unreal Tournament 2004, there are two types of geometry that make up a level: brushes and static meshes.

Brushes are the basic primatives (rectangular prisms, cylinders, geodesic spheres, cones, etc) and are manipulated using the editor. Brushes can be either ''subtracted''(which creates empty space) or ''added''(which fills some of the space back up) to the world.

Static meshes are 3d models created in ''real'' 3d modelers like Maya, and can then be placed in the level using the editor. Inside the editor, they can be scaled and rotated, but not modified in any significant way. They are always ''added''.

Static meshes have the benefit that they are not used in any world calculations or processing except to test when they are visible. Because of this, they can be very high polygon and still require almost no power compared to brushes.

In the default levels included with the game, static meshes are used for everything from railings to light fixtures to elevators to fancy ramps and other decorations (like pipes).

Share this post


Link to post
Share on other sites