tuxracer-devel Mailing List for Tux Racer (Page 5)
Status: Beta
Brought to you by:
jfpatry
Menu
▾
▴
tuxracer-devel — Mailing list for Tux Racer developers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(7) |
Mar
(90) |
Apr
(39) |
May
(9) |
Jun
(2) |
Jul
(3) |
Aug
(10) |
Sep
|
Oct
(8) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jasmin P. <jf...@mu...> - 2000-03-22 18:47:26
|
On Wed, 22 Mar 2000, Steve Baker wrote: > I suspect that either MikMod doesn't do that - or > perhaps that it uses some kind of dead-reckoning > mecthod to guess how much to send. A small error > in that estimate could build up over several seconds > and cause the problem I saw with glTron. I hope that problem has been fixed in SDL_Mixer -- but I don't know for sure. > Joseph Toscano wrote: > > Question, though: The Adonthell team is writing > > Adonthell using SDL. The people who wrote SDL integrated MikMod into a > > seperate add-on lib, SDL_Mixer. It works fine. Not sure what lib you're > > using for Tux Racer, of course. I wonder if MikMod can be rolled into > > that library somehow. > > Perhaps. I'm not sure it would help with MikMod's lockup problem > though. Hmm. I guess I'll just have to ask them... > Well, I do plan to add more music formats to PLIB *sometime* - but > I only have so many hours in the day. Tell me about it! :-/ Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Jasmin P. <jf...@mu...> - 2000-03-22 18:42:10
|
On Wed, 22 Mar 2000, Joseph Toscano wrote: > It might be a good tool, but writing .MOD music is utterly restrictive. > Extremely low sample quality (8000hz, 8-bit) and only four/eight > channels or something. Ouch. Ugh, that's certainly not very appealing. > Yeah, the MikMod_Update() routine takes for *ever* sometimes. I could > never understand that. Question, though: The Adonthell team is writing > Adonthell using SDL. The people who wrote SDL integrated MikMod into a > seperate add-on lib, SDL_Mixer. It works fine. Not sure what lib you're > using for Tux Racer, of course. I wonder if MikMod can be rolled into > that library somehow. Currently, I'm not really using any external libraries other than OpenGL/GLUT and Tcl (and glibc, etc.). I'm planning on using PLIB for its UI, scene graph, model loading abilities, etc., but nothing's keeping me from using SDL for sound. The downside is that it adds another dependency. When I get a chance, I'm going to look at glTron which also uses SDL and SDL_Mixer, to get a feel for how it's used. I'll also look at Pingus to see how it handles things -- I imagine the sound support is built into ClanLib? > I. . . *suppose* I could write music in MOD format, but. . . if the > music ends up in MOD format, it's better to have no music at all. It's > depressingly unimpressive. <g> It'd detract from the game if anything. Yeah. Until I settle on a library, maybe you should hold off writing anything. (I should warn you that I'm extremely busy with school and other projects right now, so please be patient...) Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-03-22 06:31:44
|
Joseph Toscano wrote: > Yeah, the MikMod_Update() routine takes for *ever* sometimes. I could > never understand that. Having written the sound module for PLIB, I can explain this easily. When the sound 'update' routine is called (presumably every frame), it has to generate enough sound into the sound board to last until the application program gets around to calling it again. You *could* generate 'enough' to last a couple of seconds - but if you did that, you'd run into trouble if the player pushes the 'fire' button 10 milliseconds later and needs a "BANG!!!" sound effect within a tenth of a second or so. You've already buffered up a couple of seconds of audio - so it would be two whole boring seconds between pushing the button and hearing the sound. So, you really have to generate a SMALL amount of audio data - but not so small that you'll have gaps in the sound when the graphics and game-play code takes a little longer than you expected. My PLIB library lets you set how much data to compute in each iteration. MikMod appears not to - which means (I think) that it has to set the time to some large number to allow for the worst case application. Hence MikMod isn't great for sound effects (IMHO). Another problem (which seems to afflict glTron sometimes) is that if every call to the audio 'update' function generates (say) 1/10th second of audio - but the application calls update (say) 20 times per second - then each frame the amount of queued up data going into the sound card will exceed the amount coming back out again and eventually, the buffer will fill up - causing the audio software to lock up until it empties. MikMod seems to do that a lot - which explains the occasional pregnant pause. What PLIB does in each 'update' call is to ask the OS how much data is queued up in the sound card - and only to generate just enough to 'top it up' to the required margin. I suspect that either MikMod doesn't do that - or perhaps that it uses some kind of dead-reckoning mecthod to guess how much to send. A small error in that estimate could build up over several seconds and cause the problem I saw with glTron. Dunno exactly though. Question, though: The Adonthell team is writing > Adonthell using SDL. The people who wrote SDL integrated MikMod into a > seperate add-on lib, SDL_Mixer. It works fine. Not sure what lib you're > using for Tux Racer, of course. I wonder if MikMod can be rolled into > that library somehow. Perhaps. I'm not sure it would help with MikMod's lockup problem though. > I. . . *suppose* I could write music in MOD format, but. . . if the > music ends up in MOD format, it's better to have no music at all. It's > depressingly unimpressive. <g> It'd detract from the game if anything. Well, I do plan to add more music formats to PLIB *sometime* - but I only have so many hours in the day. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Joseph T. <sc...@pc...> - 2000-03-22 05:14:11
|
Steve Baker wrote: > I've been using 'Funktracker Gold' (which is freeware for Linux). > It produces true 'MOD' files that PLIB can play. Of course it > may completely suck as a composition tool - I have no idea. It might be a good tool, but writing .MOD music is utterly restrictive. Extremely low sample quality (8000hz, 8-bit) and only four/eight channels or something. Ouch. > MikMod does better and can play LOTS of different mod-like formats, > but it's not that great for interactive applications. Yeah, the MikMod_Update() routine takes for *ever* sometimes. I could never understand that. Question, though: The Adonthell team is writing Adonthell using SDL. The people who wrote SDL integrated MikMod into a seperate add-on lib, SDL_Mixer. It works fine. Not sure what lib you're using for Tux Racer, of course. I wonder if MikMod can be rolled into that library somehow. I. . . *suppose* I could write music in MOD format, but. . . if the music ends up in MOD format, it's better to have no music at all. It's depressingly unimpressive. <g> It'd detract from the game if anything. --JT http://artists.traxinspace.com/scarjt/ |
|
From: Steve B. <sjb...@ai...> - 2000-03-22 04:52:30
|
Jasmin Patry wrote: > Yes, I definitely need music! Thanks very much for the offer. > > Steve, if you're listening: do you foresee any difficulties getting PLIB's > music player to player mod files created with Impule Tracker? I don't know the Impulse Tracker - but PLIB's MOD player can only play 'true' ".MOD" files. Other so-called 'mod' formats with different file name extensions don't work. Somewhere *way* down on my To-Do list is to expand the range of mod-like formats that I can support. I've been using 'Funktracker Gold' (which is freeware for Linux). It produces true 'MOD' files that PLIB can play. Of course it may completely suck as a composition tool - I have no idea. MikMod does better and can play LOTS of different mod-like formats, but it's not that great for interactive applications. I have to turn off the sounds on (for example) glTron because MikMod takes about 200milliseconds out to do it's audio buffer updates once every couple of seconds. It doesn't do that on every computer (it works OK on my Laptop and my box at work - but screws up on my home machine and my son's PC). The problem with it seems to be that it uses some automagical technique to decide how much audio data to pre-compute each update - and sometimes it picks a number that's WAY too big. I've taken this up with the author of glTron - but he couldn't reproduce the problem. The MikMod team didn't reply to my emails. PLIB's sound routines let you set this critical number yourself, and even change it on-the-fly depending on the needs of your game. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-03-21 13:47:34
|
On Sun, 19 Mar 2000, Joseph Toscano wrote: > Hello to the Tux Racer developers. :) Hi! > I'm the Linux game music guy. I've currently written scores to two Linux > games, both are in development. Pingus, of course (hi, Ingo!) and then > there's Adonthell, the sprawlingly big RPG. That game is going to be > excellent. Some very cool people working on it. Cool! I still haven't had a chance to try Pingus (sorry, Ingo!) -- the ClanLib site was down last time I tried. > Tux Racer caught my eye as being a very well-organized project. The > development seems to be going along nicely. Hopefully this game will be > yet another fine tribute to Linux. People must start taking notice now; > Linux has become a very viable gaming platform. > > My question is thus: Need music? :) If so, do tell. I'll whip up some > tunes. I write my music with Impulse Tracker and, as such, libmikmod can > play the music back very nicely. Yes, I definitely need music! Thanks very much for the offer. Steve, if you're listening: do you foresee any difficulties getting PLIB's music player to player mod files created with Impule Tracker? > Keep up the nice work, everyone! I hope I can help. Thanks, and I look forward to hearing some tunes! Cheers, Jasmin |
|
From: Andreas H. <sta...@ho...> - 2000-03-21 08:05:54
|
Hi there ! Nice project you have going on over there. But one thing that buggs me, why is Tux laying down? .. just place the god dam thing on a snowboard or something. That would make this game much better. /Andreas "god is real until declared integer" ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com |
|
From: Joseph T. <sc...@pc...> - 2000-03-19 22:06:07
|
Hello to the Tux Racer developers. :) I'm the Linux game music guy. I've currently written scores to two Linux games, both are in development. Pingus, of course (hi, Ingo!) and then there's Adonthell, the sprawlingly big RPG. That game is going to be excellent. Some very cool people working on it. Tux Racer caught my eye as being a very well-organized project. The development seems to be going along nicely. Hopefully this game will be yet another fine tribute to Linux. People must start taking notice now; Linux has become a very viable gaming platform. My question is thus: Need music? :) If so, do tell. I'll whip up some tunes. I write my music with Impulse Tracker and, as such, libmikmod can play the music back very nicely. Keep up the nice work, everyone! I hope I can help. --JT http://artists.traxinspace.com/scarjt/ |
|
From: Jasmin P. <jf...@mu...> - 2000-03-18 19:09:23
|
For those that are curious, I've placed a couple screenshots on the web of
Tux Racer with and without the LOD code active:
With:
http://tuxracer.sourceforge.net/images/tux_quadtree.gif
Without:
http://tuxracer.sourceforge.net/images/tux_no_lod.gif
The FPS values aren't exactly comparable (I took the screenshots with
different version of the game), but the gain you see there is
approximately correct. Also note that wireframe rendering is
significantly slower on my card than rendering filled polygons; I get
framerates about twice the ones shown there.
Jasmin
|
|
From: Jasmin P. <jf...@mu...> - 2000-03-18 18:56:48
|
On Sat, 18 Mar 2000, Steve Baker wrote:
[snip heightmap meshing discussion]
> Better still (IMHO) is to go to irregular triangle meshes and generate
> more triangles in areas of high curvature, etc. This is a REALLY deep
> subject though and it gets you into dynamic skinning techniques where
> you use more triangles close to the eye, etc, etc.
That's basically what I've done. It's still not perfect; the triangulation
pattern is fixed (at the highest level of detail) like this:
...
+-+-+-+-+
|\|/|\|/|
...+-+-+-+-+...
|/|\|/|\|
+-+-+-+-+
...
At least now it's symmetric. People should also be able to design their
courses at higher resolutions, with only a small performance hit. (I haven't
tried this yet, though).
> * Scheme where you need to reach a certain time in order to 'beat'
> a level so you can go onto the next one.
>
> * 'Ghost' - most racing games can record your last game and replay it
> as you play again (usually with your last run shown as a translucent
> version of yourself - hence the term 'ghost'). Thus you play against
> your previous run. This is VERY useful for improving your play and
> tuning your run to beat a tough level time.
Both good ideas.
Cheers,
Jasmin
|
|
From: Jasmin P. <jf...@mu...> - 2000-03-18 18:45:01
|
I've committed some more tweaks/fixes to the LOD code. Jasmin |
|
From: Steve B. <sjb...@ai...> - 2000-03-18 17:11:05
|
Jasmin Patry wrote: > > I thought of a few more. :-) That's the way it goes! > * Finish line/finishing area; there will be a large "Finish" sign > suspended on a metal structure at the bottom, with pictures of > spectators in the stands Just another 3D object - once you have those, it's easy. > * A sky image will be drawn; this will be a texture that can be selected > for each course. There is a guy (Curt Olson) who has written a 3D sky model for SSG - and which I hope we'll release in a future SSG release. It has sun, moon and stars and can be set to any time of day, etc, etc. The positions of the sun, moon and stars are astronomically correct - you even get eclipses and so on. Anyway, it's not ready *yet* but I'm assuming it's going to be there soon. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Steve B. <sjb...@ai...> - 2000-03-18 17:11:02
|
Jasmin Patry wrote: > > I've sketched out a roadmap (list of objectives) for Version 1.0. I'd like > some feedback on these. I think it's important to define a clear vision for > 1.0 so that the development has some direction. Here's what I propose: We talked a while back about using my PLIB libraries (especially SSG) in TuxRacer, if you did that then many of your objectives would be easy to do: > * View frustrum culling (performance enhancement, will help support larger > levels, especially wide ones) SSG does this automatically as it renders. > * Better meshing of the terrain (you may have noticed that some sloped > surfaces are smooth while others are rough -- this will fix that) This is a general problem with regularly gridded terrain (which is one reason I try to avoid using it). Essentially, you'd like to skin the terrain with quads - but they have to be planar. When you split the quad into two triangles, it's hard to know which diagonal to choose when you do the split. In fact, you simply can't tell unless your original height data is at higher precision than the resulting triangle grid. I suggest you get people to paint their terrain images at (say) 4x the resolution you intend to skin the terrain. Then your skinner can test which pair of triangles are the 'best fit' to the (say) 16 height points in the original painted image for that quadrilateral. However...when you start splitting some triangles one way and some the other, your triangle mesh generation techniques go to hell...ugh! You also start to need more general collision detection and so on. Better still (IMHO) is to go to irregular triangle meshes and generate more triangles in areas of high curvature, etc. This is a REALLY deep subject though and it gets you into dynamic skinning techniques where you use more triangles close to the eye, etc, etc. > * Sound and music. I haven't thought about this much (and I have no > experience with it). This is REALLY easy with PLIB. You only need a couple of lines of code to set it up - then one line to load a sound effect or an entire music file and one line to start it playing. Getting free sound effects and music off the web is pretty easy. > * Health power-ups -- floating objects (octahedrons, probably) that Tux > must hit to get extra health If you used SSG to add general 3D objects then it would be easy to make these be more attractive shapes. In my Tux game, I have spinning herring of various colours for this (or is that just a red herring?) > * Joystick support Again, PLIB makes this easy. > * Paddling (Tux pushes on the ground to speed up) This is the most important think IMHO. It's very bad when you get 'stuck' in a tiny hollow with no way out at all - and it's almost impossible to design levels where that can't happen. > * Some extra Tux animation during race (rotates head, feet flap in wind, > etc.) Easy in SSG > * Polygonal objects can be placed on the course, basic collision detection > works with these Easy in SSG > * Multiple tree types (different colours in trees.rgb file, or separate > rgb files?) Once you have 3D objects, trees become just another 3D object so this is a no-brainer. > * Built-in level editor I don't think you need this. > Please give me your feedback on this plan. Is there anything that you think > should be delayed until 2.0, or are there things missing from 1.0 that you > would like to see? Now's your chance... * Scheme where you need to reach a certain time in order to 'beat' a level so you can go onto the next one. * 'Ghost' - most racing games can record your last game and replay it as you play again (usually with your last run shown as a translucent version of yourself - hence the term 'ghost'). Thus you play against your previous run. This is VERY useful for improving your play and tuning your run to beat a tough level time. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Steve B. <sjb...@ai...> - 2000-03-18 17:10:57
|
Jasmin Patry wrote: > > I finished setting up the CVS repositories. There are two modules, > tuxracer and tuxracer-data. If would encourage level designers to use > CVS with their levels, if possible. You don't have to be religious about > it, but it will make file sharing easier. > > It would also be nice if a few people could stay up to date on the CVS > version; that would help catch bugs like the one in 0.11. :-) I'll try > to post a message here after I do a commit of any significance. > > Steve, I've added you to the developers list. Ingo, you don't seem to be > registered on SourceForge. If you send me your userid I'll add you too. Thanks for registering me. Can I suggest that new version announcements go *ONLY* to the 'announce' list since I'd expect people to subscribe to multiple tuxracer lists. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-03-18 14:57:38
|
On Sat, 18 Mar 2000, Steve Baker wrote: > (Apologies for slow reply - I've been on vacation for two weeks and > have >2000 emails to catch up with!) Welcome back! I hope your vacation went well. > Jasmin Patry wrote: > > :-) Since the game was written as a school project, using a third-party > > library wasn't possible. > > Prohibiting the use of 3rd party libraries is silly - and nobody > could possibly stick to it. What about Mesa? glibc? I didn't mean *any* third-party library. I meant one whose functionality would overlap with my objectives (i.e., stuff I was supposed to write myself). Cheers, Jasmin |
|
From: Steve B. <sjb...@ai...> - 2000-03-18 13:26:06
|
(Apologies for slow reply - I've been on vacation for two weeks and have >2000 emails to catch up with!) Jasmin Patry wrote: > > On Fri, 3 Mar 2000, Steve Baker wrote: > > > Jasmin Patry wrote: > > > > > > Ah, very cool. I hope to check out PLIB over the weekend -- I'd > > > already been meaning to look at it for its text capabilities. > > > > ...and GUI, sound and music :-) > > :-) Since the game was written as a school project, using a third-party > library wasn't possible. Prohibiting the use of 3rd party libraries is silly - and nobody could possibly stick to it. What about Mesa? glibc? That's a silly rule. > I'm encouraged by your description of how SSG > works -- it doesn't sound like it will be hard to use it to insert > additional objects into the track. It shouldn't be too hard. > Do you foresee any problems caused by the fact that PLIB/SSG is C++ and > Tux Racer is written in C? I'll have to include at least some C++, I > guess, for the classes in SSG that I subclass, but I should be able to > abstract the functionality that I use SSG for behind a C interface. Yes - you would certainly need to use C++ but since C++ can compile C programs just as well as C can, the implications of switching to C++ is no more than a couple of lines in a Makefile. These days, C compilers are often just C++ compilers with some parts turned off. There is really no need to stick with C anymore. > > In my Tux game, I did get problems with a fast moving Tux starting the > > frame completely on one side of a polygon - and ending it completely > > on the other. To fix that, I intersect a bunch of slightly overlapping > > Tux-sized spheres at intervals along his motion. > > Right, I had problems with this too. The correct way to do it in Tux Racer > would be to stretch out each sphere into a cylinder with hemispherical > ends, but instead I basically use the approach you use: the set of > physics equations in Tux Racer is solved using a variable time-step ODE > solver, which takes many steps in general for each rendered frame. Yep - just try writing code to intersect hemisphere-capped cylinders with arbitary geometry! > For testing collisions with the SSG objects, I might instead add > bounding (world-space) spheres to the Tux model, and then perform > collision tests with each of these spheres. That should give reasonably > accurate collisions. (Or can SSG do the intersection tests with > arbitrary ellipsoids?) No - only spheres and lines. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-03-14 04:49:12
|
I did most of the fine-tuning that I mentioned in the last email. Lighting now works. I replaced the view frustum culling algorithm with a more efficient version. Course edges should now look ok. The terrain is now rendered using compiled vertex arrays; since this is how Quake 3 does things I'm hoping that it will speed things up on certain cards/drivers (it makes no noticable difference on my Voodoo3). HOWEVER, when I do "tuxracer -indirect" I get a core dump on glLockArraysEXT(). Can somebody with a card that does indirect rendering (e.g. TNT/TNT2/nVidia) please try this and let me know if they get the same thing? Cheers, Jasmin |
|
From: Jasmin P. <jf...@mu...> - 2000-03-13 23:36:59
|
I've just made a checkin to CVS; it includes code to render the
terrain with adaptive levels of detail. The code for this was adapted
from a demo by Thatcher Ulrich <tu...@tu...>, described in this
Gamasutra article:
http://www.gamasutra.com/features/20000228/ulrich_01.htm
Some things still need work: course lighting doesn't work yet, and
there's some weirdness at the right and bottom edges of the terrain.
I'll be fine-tuning it over the next few days.
The affect of this code can best be seen in wireframe mode; hit F11 to
toggle it. You can use the F9 and F10 keys to decrease and increase the
amount of detail. For example, hit F11 at the start screen and then
hold down F10 -- you should see lots of triangles appear. Set debug to
"quadtree" in ~/.tuxracer to see some somewhat interesting diagnostic
messages.
Please let me know if you notice major problems, like compilation
problems, game or X server crashes, etc. (it runs fine on my setup :-).
BTW, I think this makes Tux Racer the first open-source game to have
adaptive LOD terrain. Anybody know any different? (I might be the only
person who thinks this is cool... :-)
Enjoy,
Jasmin
|
|
From: Ingo R. <gr...@gm...> - 2000-03-10 19:18:02
|
Hi, I removed the following files from CVS: aclocal.m4 Makefile Makefile.in configure src/Makefile src/Makefile.in since they are all automatically generated by autoconf and automake and should therefore not under CVS controll. I also added a simple script "autogen.sh" which generates these files automatically by running autoconf and friends. -- ICQ: 59461927 http://pingus.seul.org | Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ | ------------------------------------------------------------------------+ |
|
From: Jasmin P. <jf...@mu...> - 2000-03-10 06:39:19
|
I placed a copy of the development plan on the web page. I'll be updating it as I get stuff done and get more ideas (currently I'm getting ideas at a much faster rate than I'm getting them done :-). I've committed some stuff to CVS: - I added some options to the configure script - I reduced the complexity of the Tux model by reducing the resolution of the smaller objects in his body; this should gain you a few FPS - I relaxed some of the ODE parameters to try to get a few more FPS - I added some new parameters to ~/.tuxracer: forward_clip_distance (the distance in meters down the course at which geometry is clipped), backward_clip_distance (the distance in meters up the course at which geometry is clipped), and tree_detail_distance (the distance at which trees are rendered using two polygons instead of one). If tuxracer is slow, try decreasing these values (especially the first two). I decreased the default forward_clip_distance from 100 to 75, and this results in a fairly noticeable FPS boost. Note that this type of clipping is a stop-gap measure until I implement real clipping to the view frustrum. - I worked a bit on level 4. If you encounter any problems with this update, please let me know. Jasmin |
|
From: Jasmin P. <jf...@mu...> - 2000-03-07 01:19:58
|
I thought of a few more. :-)
On Mon, 6 Mar 2000, Jasmin Patry wrote:
>
> I've sketched out a roadmap (list of objectives) for Version 1.0. I'd like
> some feedback on these. I think it's important to define a clear vision for
> 1.0 so that the development has some direction. Here's what I propose:
* Finish line/finishing area; there will be a large "Finish" sign
suspended on a metal structure at the bottom, with pictures of
spectators in the stands
* The background drawing will be improved -- the distance of background
will not change relative to viewer
* A sky image will be drawn; this will be a texture that can be selected
for each course.
> * View frustrum culling (performance enhancement, will help support larger
> levels, especially wide ones)
>
> * Better meshing of the terrain (you may have noticed that some sloped
> surfaces are smooth while others are rough -- this will fix that)
>
> * Sound and music. I haven't thought about this much (and I have no
> experience with it).
>
> * High score list -- should be system-wide, not just per-user
>
> * Slicker, more professional UI -- better menus, better display during a
> race, perhaps a miniature display of course in a corner with current
> position displayed . Most of the settings in configuration file should
> be settable from within the game.
>
> * A health/damage system (Tux takes damage when he collides with things --
> based on the magnitude of forces exerted on Tux)
>
> * Turbo boost pads on the course (like in MarioCart) -- pass over a surface
> and get a speed boost
>
> * Health power-ups -- floating objects (octahedrons, probably) that Tux
> must hit to get extra health
>
> * Joystick support
>
> * Paddling (Tux pushes on the ground to speed up)
>
> * Some extra Tux animation during race (rotates head, feet flap in wind,
> etc.)
>
> * Trick mode (Tux can do tricks in mid-air to get points)
>
> * Polygonal objects can be placed on the course, basic collision detection
> works with these
>
> * Elevation mesh can be resampled automatically (detail level selected by
> user) to improve performance on slow cards/machines
>
> * An optional system-wide configuration file (/etc/tuxracer) is supported;
> defaults are taken from this file.
>
> * Better course directory structure (not restricted to numbers)
>
> * ~/.tuxracer should become a directory: ~/.tuxracer/config would be like
> the current ~/.tuxracer file; courses could be added to
> ~/.tuxracer/courses. The user could specify the order of courses in a
> ~/.tuxracer/index file.
>
> * Multiple tree types (different colours in trees.rgb file, or separate
> rgb files?)
>
> * Built-in level editor
>
> Wow, that's a pretty long list. I haven't estimated how long this will take.
> I'll do that when I have a bit more time.
>
> Here are some additional features that I left for "Version 2.0":
>
> * Other characters (e.g., Gown, Beasdie)
>
> * Can race against another (computer-controlled) character
>
> * Multiplayer (one same computer, or over network)
>
> * Other power-ups: e.g., rockets, oil slicks, terrain blasters, etc.
>
> Please give me your feedback on this plan. Is there anything that you think
> should be delayed until 2.0, or are there things missing from 1.0 that you
> would like to see? Now's your chance...
>
> Thanks,
> Jasmin
|
|
From: Jasmin P. <jf...@mu...> - 2000-03-07 00:08:09
|
I've sketched out a roadmap (list of objectives) for Version 1.0. I'd like
some feedback on these. I think it's important to define a clear vision for
1.0 so that the development has some direction. Here's what I propose:
* View frustrum culling (performance enhancement, will help support larger
levels, especially wide ones)
* Better meshing of the terrain (you may have noticed that some sloped
surfaces are smooth while others are rough -- this will fix that)
* Sound and music. I haven't thought about this much (and I have no
experience with it).
* High score list -- should be system-wide, not just per-user
* Slicker, more professional UI -- better menus, better display during a
race, perhaps a miniature display of course in a corner with current
position displayed . Most of the settings in configuration file should
be settable from within the game.
* A health/damage system (Tux takes damage when he collides with things --
based on the magnitude of forces exerted on Tux)
* Turbo boost pads on the course (like in MarioCart) -- pass over a surface
and get a speed boost
* Health power-ups -- floating objects (octahedrons, probably) that Tux
must hit to get extra health
* Joystick support
* Paddling (Tux pushes on the ground to speed up)
* Some extra Tux animation during race (rotates head, feet flap in wind,
etc.)
* Trick mode (Tux can do tricks in mid-air to get points)
* Polygonal objects can be placed on the course, basic collision detection
works with these
* Elevation mesh can be resampled automatically (detail level selected by
user) to improve performance on slow cards/machines
* An optional system-wide configuration file (/etc/tuxracer) is supported;
defaults are taken from this file.
* Better course directory structure (not restricted to numbers)
* ~/.tuxracer should become a directory: ~/.tuxracer/config would be like
the current ~/.tuxracer file; courses could be added to
~/.tuxracer/courses. The user could specify the order of courses in a
~/.tuxracer/index file.
* Multiple tree types (different colours in trees.rgb file, or separate
rgb files?)
* Built-in level editor
Wow, that's a pretty long list. I haven't estimated how long this will take.
I'll do that when I have a bit more time.
Here are some additional features that I left for "Version 2.0":
* Other characters (e.g., Gown, Beasdie)
* Can race against another (computer-controlled) character
* Multiplayer (one same computer, or over network)
* Other power-ups: e.g., rockets, oil slicks, terrain blasters, etc.
Please give me your feedback on this plan. Is there anything that you think
should be delayed until 2.0, or are there things missing from 1.0 that you
would like to see? Now's your chance...
Thanks,
Jasmin
|
|
From: Jasmin P. <jf...@mu...> - 2000-03-06 23:38:11
|
On 6 Mar 2000, Ingo Ruhnke wrote: > just another little script-fu. It creates a menu entry under > "Xtns/Script-Fu/Tuxrcare/New Level" and on click it creates a new > level from a given height and width with usefull default colors and > the correct layer names. Great! I modified it slightly to work under Gimp-1.0 (1.0 doesn't have FG-IMAGE-FILL). It's on the web. Here's an idea: I bet a level design tutorial would be useful for some people. Does anybody feel like writing one? Thanks, Jasmin |
|
From: Jasmin P. <jf...@mu...> - 2000-03-06 23:07:44
|
On Mon, 6 Mar 2000, Steffen Sobiech wrote: > Am Mon, 06 Mdr 2000 schrieben Sie: > > > > Look good. It worked on my system (a heavily patched RedHat 6.0 with > > KDE 1.1.1), though there were a few small problems: it gives an error > > message "ERROR: KFM is not running", even though it is. It also won't > > let me change the installation directory (though perhaps that's on > > purpose so that you don't have to write a ~/.tuxracer file). > > Yes, it was done on purpose... > The problem is that the .tuxracer file needs to be in every user's > home directory. Something like this would work with system wide > defaults. Maybe I can have KDE start a script instead of the actual > binary. That script could create a new ~/.tuxracer file if it doesn't > already exist... Ah yes, I hadn't thought about that. I think I'll add an (optional) system-wide configuration file (/etc/tuxracer) where default values would be obtained. > > Thanks a lot! I'll place it on the web site today. > Thank you, too! You're very welcome. Cheers, Jasmin P.S. Taking this back on-list... |
|
From: Jasmin P. <jf...@mu...> - 2000-03-06 16:24:15
|
I finished setting up the CVS repositories. There are two modules, tuxracer and tuxracer-data. If would encourage level designers to use CVS with their levels, if possible. You don't have to be religious about it, but it will make file sharing easier. It would also be nice if a few people could stay up to date on the CVS version; that would help catch bugs like the one in 0.11. :-) I'll try to post a message here after I do a commit of any significance. Steve, I've added you to the developers list. Ingo, you don't seem to be registered on SourceForge. If you send me your userid I'll add you too. If anybody else would like write access to the CVS tree, let me know; likewise if anybody would like extra/fewer privileges. Other tidbits: I added Ingo's Script-Fu script to the web page, as well as Steffen's GUI installer. Cheers, Jasmin |
2 messages has been excluded from this view by a project administrator.
