Hi, Forgive the newbie question. I haven''t programmed a game in over 15 years (although I still continued to program). Technology certainly has changed! I''m trying to develop a 3D maze game like the old Labrynth game from way back when. I''m not looking for extravagant graphics, just simple lines for now. What techniques are used to actually render the walls as if you were standing in the maze looking forward? I have an array of bytes inidcating 0 for open space and 1 for a wall. I can turn and move just fine through it, but I''m struggling with the graphics. Can anyone help? Techniques, terms, pointers are greatly appreciated!

If your grid is constantly sized squares, you might want to have a look at raycasting. A few links: one, two (you want pxdtut1-8; they''re in Pascal, and some of the docs aren''t relevant today, but there are a few on raycasting), three. It''s not too difficult to get one up and running here - you''ll probably end up using software rendering for it, though, rather than fancy 3d tech. It''s the method that was used for Wolfenstein 3D so it might bring back fond memories .

DirectDraw (get the DirectX SDK from microsoft''s site) would be handy for 2d pixel plotting; there are plenty of tutorials around and it''s fast enough for this sort of thing (i.e., as fast as your code allows ). You could also google for OpenPTC - the site that hosts it is being renovated, but you might be able to find another copy of it somewhere. OpenPTC basically lets you fiddle with an array of pixels then copy it to the screen with minimal overhead (there''s also TinyPTC, which is an even slimmer version).

If you want to take advantage of the power of modern hardware then you have to look at 3d acceleration. There are two technologies of interest here: Direct3D and OpenGL. They both allow the same sort of thing; here''s NeHe, who''s site has a heap of tutorials to get you started. In short, both APIs let you tell the graphics card what to draw at high-ish level. There''s no difference in speed between the two.

The 3d graphics concept is simple enough. You define polygons (enclosed shapes, usually triangles or sometimes quads) in your scene by specifying their vertices, which just means their corners. You tell the 3d card what shapes to draw and include the transformations (moving them around, rotating them or scaling them, for example). At the end of that, you have a lovely 3d scene!

You store your vertices with 3 floating point numbers for the x, y and z values in 3d space (the z axis goes into or out of the screen depending on the API you choose, since they use slightly different coordinate systems). You might also need two coordinates for the position in a texture map (a picture that gets drawn across the shape), which are usually in the range 0.0 to 1.0.

The hard part in a 3d scene is knowing what not to draw. You can send any amount of data to the graphics card but there''s wasted effort there. The extra stuff won''t be drawn to the scene (it''ll be removed somewhere along the way in the stages from your code to getting the scene onto the screen), but it still has to take up graphics card time. If you can cull out large areas of the scene at once then you save a lot of time. Frustum culling is handy for this. An analogy; I''m sitting in Scotland. If I was tasked with doing a real-life simulator, I would have to reject a lot of scenery (like, for example, several other continents) at an early stage. There''s no point in me deciding whether to draw New York if I can''t even see out of my own town! There are plenty of visibility algos for indoors if you want better performance (e.g. BSP trees and portals).

I''d suggest that you head over to NeHe''s and have a look through some of the 3d tutorials (one deals with moving around in a 3d scene, IIRC). You can also have a look at GameTutorials.com -- especially the OpenGL section. There are some examples of collision detection against walls and so on.