Re: [tuxracer-devel] Creating new levels (was: (no subject))
Status: Beta
Brought to you by:
jfpatry
From: Jasmin P. <jf...@mu...> - 2000-03-31 16:59:17
|
On Fri, 31 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > > It helps (for both speed and memory consumption) to keep the bitmap > > fairly narrow -- the width of 48 pixels that you mention above is > > reasonable. > > Well, not if you want more 'wiggly' courses. I think some of the > courses you see in (for example) the game "1080" for Nintendo 64 would > require much wider maps...and the runs take several minutes to complete. Yes, but we're talking about different things. I meant that a 48 by X course would be reasonable in terms of speed and memory consumption. Whether it's ideal in terms of gameplay is another story altogether. The view frustum culling and quadtree LOD code I added helps to speed things up for wider courses -- your course, for example, which is 80 pixels wide, used to run about 15-16 fps IIRC, and now it runs at 25+ fps (on my system). While I'm talking about performance, I should mention another important factor affecting framerates: triangle densities in the heightmaps. Most existing courses use something in the neighborhood of 1 pixel/metre (+/- 50%). One easy way to get larger courses is to sacrifice triangle density -- but then you have to take much more care when constructing the heightmaps (and there are still those meshing issues). > I would have thought that positioning 3D features other than simple > things like trees would require something other than an image map. > > I would use a separate text file containing something like: > > filename X Y Z Heading > > ...with the 'Y' component being optional to allow things to automatically > sit exactly on the terrain at their local origin. > > It's not as convenient as an image-based approach - but for objects > of more complexity than a tree, I think you need a better positioning > scheme. Yes, the issues are coming back to me now. It would be nice to strike a compromise between the easy visual placement of a bitmap and the extra control of a text file. Allowing the user to specify the object's (x,z) coordinates in image space would help. We'd need some easy way get the image coordinates of a point in the heightmap image -- the Gimp ruler is just lousy for this (at least in 1.0), and I don't know of any feature that displays the image coordinates of the current mouse position. Perhaps this could be done with script-fu? In any case, I doubt an extra text file is necessary -- this could all be done by adding an extra Tcl callback and the object positions/orientations could be specified via the course.tcl file. It would provide even extra flexibility if portions of the scene graph could be constructed in the course.tcl file. (I already have a basic scene graph in tuxracer -- that's how Tux himself is constructed, and it's all done in Tcl in tux.tcl). Animation nodes could be added to make some of the models move, and scripted callbacks could control be used to control the behaviour when a player is near or collides with the model, etc. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |