tuxracer-devel Mailing List for Tux Racer (Page 4)
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-31 17:24:21
|
On Fri, 31 Mar 2000, Jules Bean wrote: > I know this is the opposite of Steve's feeling, but personally I hate > it when open-source projects gratuitously 'include' a version of > another library instead of linking to it. With a well-known library > (whatever that means) whichever distribution (of whichever OS) you use > should have a handily pre-prepared version. > > If the concern is that it makes it harder for *all* PLIB users, then I > would certainly recommend the mikmod support be optional in > PLIB... you'd only need mikmod installed if you wanted to use it's > file loading code in your PLIB game... Yes, those are good points. The crucial factor is whether any modifications are required to mikmod (I don't think so, though). The advantages of including the code are convenience for the user, and the fact that you only need to test against one version of the library. I don't have a strong preference either way. Steve, it's your call. :-) Cheers, 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-31 17:14:26
|
On Fri, 31 Mar 2000, Jules Bean wrote: > Rather than inventing 'Yet Another' textual file format, can I suggest > you use an existing one? My current two favourites are XML or Scheme > (the latter only makes sense if you planned to embed a scheme interp > anyway, but that *is* quite good way of allowing scriptability - > e.g. abominable snowmen wondering around ;-) > > The rationale for this is that parsers are moderately annoying to > write and debug (I've written a few) and any simple language you > design may later turn out not to have the power you need. XML and > Scheme, due to their nested nature, are capable of representing > arbitrary information relatively compactly, and you can just link in a > well-known stable lib to parse the file. Yes, I agree, and that's why I use a Tcl interpreter to interpret ~/.tuxracer and the course.tcl files. Adding new Tcl commands is very easy, and that's what I would do to specify the locations and orientations of objects on the course (instead of using a separate text file). Cheers, Jasmin |
|
From: Jasmin P. <jf...@mu...> - 2000-03-31 17:05:03
|
On Fri, 31 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > It needn't add dependencies to PLIB either, if you include a > > stripped-down version of libmikmod in PLIB (e.g., the drivers could be > > left out). SDL_mixer does this too. > > OK - that's certainly possible. > > Is MikMod pretty stable now - or do new versions still appear regularly? A new version appeared in mid-February, so apparently development continues. I'm not sure if development is concentrated on the drivers or on the loaders/players, though. > I'd hate for you to hack out a MikMod subset - only to find that you > have to keep doing that every few months when MikMod changes. Yes, that could be somewhat of a pain. I'm not sure why SDL_mixer followed that approach. Perhaps some minor changes were required to mikmod itself (though I didn't see any sign of that). > Let me know if there are changes that you might need in PLIB to make > this easier. Ok. Unfortunately the free time I was going to spend this weekend looking into this has been eaten up with other commitments, but I'll get to it as soon as I can. Cheers, 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-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/ |
|
From: Jules B. <jm...@he...> - 2000-03-31 11:46:15
|
On Fri, Mar 31, 2000 at 02:57:44AM -0600, Steve Baker wrote:
>
> I'd hate for you to hack out a MikMod subset - only to find that you
> have to keep doing that every few months when MikMod changes.
I know this is the opposite of Steve's feeling, but personally I hate
it when open-source projects gratuitously 'include' a version of
another library instead of linking to it. With a well-known library
(whatever that means) whichever distribution (of whichever OS) you use
should have a handily pre-prepared version.
If the concern is that it makes it harder for *all* PLIB users, then I
would certainly recommend the mikmod support be optional in
PLIB... you'd only need mikmod installed if you wanted to use it's
file loading code in your PLIB game...
Jules
--
Jules Bean | Any sufficiently advanced
jules@{debian.org,jellybean.co.uk} | technology is indistinguishable
jm...@he... | from a perl script
|
|
From: Jules B. <jm...@he...> - 2000-03-31 11:43:23
|
On Fri, Mar 31, 2000 at 02:52:44AM -0600, Steve Baker wrote:
> Jasmin Patry wrote:
> 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.
Rather than inventing 'Yet Another' textual file format, can I suggest
you use an existing one? My current two favourites are XML or Scheme
(the latter only makes sense if you planned to embed a scheme interp
anyway, but that *is* quite good way of allowing scriptability -
e.g. abominable snowmen wondering around ;-)
The rationale for this is that parsers are moderately annoying to
write and debug (I've written a few) and any simple language you
design may later turn out not to have the power you need. XML and
Scheme, due to their nested nature, are capable of representing
arbitrary information relatively compactly, and you can just link in a
well-known stable lib to parse the file.
Jules
--
Jules Bean | Any sufficiently advanced
jules@{debian.org,jellybean.co.uk} | technology is indistinguishable
jm...@he... | from a perl script
|
|
From: Steve B. <sjb...@ai...> - 2000-03-31 08:00:26
|
Jasmin Patry wrote: > > ...hence the sources have to be able to make a particular amount > > of sound on-demand. Since MikMod doesn't let you tell it how > > much to generate, that's not likely to work. > > Actually, it does let you tell it how much sound to generate, and that's > what SDL_mixer does. SDL_mixer doesn't use any of libmikmod's supplied > drivers or mixers (it sets up its own libmikmod driver using mikmod's > "virtual channel mixer interface"), and calls mikmod's > VC_WriteBytes( buffer, len ) to fill the audio buffer. It looks fairly > straightforward. OK - you've obviously looked more deeply into this than I have - so I'll bow to your superior knowledge. > > Hence we could call MikMod to create however much it feels like > > - store it in a buffer and just hand 'X' bytes over to SL - keeping > > what's left for next time. Not very elegant - but it ought to be > > do-able. > > No, not elegant at all, and that's not what I had in mind. Excellent - since there is a better way. > It needn't add dependencies to PLIB either, if you include a > stripped-down version of libmikmod in PLIB (e.g., the drivers could be > left out). SDL_mixer does this too. OK - that's certainly possible. Is MikMod pretty stable now - or do new versions still appear regularly? I'd hate for you to hack out a MikMod subset - only to find that you have to keep doing that every few months when MikMod changes. > > I'm biassed though...and right now, I don't have time to do > > either modification. > > Understood (I wasn't asking you to do it, I was offering to look into it > and do it myself). Now that's the kind of thing I like! Let me know if there are changes that you might need in PLIB to make this easier. -- 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-31 07:55:24
|
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. > > Another good thing (i know i'm boring sometimes) could be to specify in > > course.tcl others rgb files to load for others objects (houses, other kind > > of trees etc...) and also specify your code for colors (in your new rgb > > files you would say that a color represent this object etc...). > > Yes, I plan to do something very much like that. :-) 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. > > By the way, tuxracer and tuxaqfh are my 2 favourites linux game projects!!! > > Cool! :-) Double-cool!! :-) -- 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-30 02:50:59
|
On 30 Mar 2000, Ingo Ruhnke wrote: > just for the fun of it I created another script-fu, which is able to > load a tuxracer level from a directory into a single image. Cool! > BTW. Should I add all the script-fu's to the tuxracer CVS module, > "tuxracer/contrib/script-fu/" might be the correct place? Yes, that's a very good idea. That directory sounds good to me. Thanks, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Ingo R. <gr...@gm...> - 2000-03-30 02:43:50
|
Hi,
just for the fun of it I created another script-fu, which is able to
load a tuxracer level from a directory into a single image.
BTW. Should I add all the script-fu's to the tuxracer CVS module,
"tuxracer/contrib/script-fu/" might be the correct place?
;; Tuxracer - Load all files of a course into a single image
;; Copyright (C) 2000 Ingo Ruhnke <gr...@gm...>
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2 of the License, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; if not, write to the Free Software
;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
(define (load-image pathname filename-raw)
(let ((filename (string-append pathname filename-raw)))
(car (file-sgi-load 0 filename filename))))
(define (script-fu-tuxracer-load-level pathname)
(let ((image_elev (load-image pathname "/elev.rgb"))
(image_trees (load-image pathname "/trees.rgb"))
(image_terrain (load-image pathname "/terrain.rgb")))
(let ((width (car (gimp-image-width image_elev)))
(height (car (gimp-image-height image_elev))))
(let ((new-image (car (gimp-image-new width height RGB))))
(let ((layer_elev (car (gimp-layer-new new-image width height RGB "elev" 100 0)))
(layer_trees (car (gimp-layer-new new-image width height RGB "trees" 100 0)))
(layer_terrain (car (gimp-layer-new new-image width height RGB "terrain" 100 0))))
(gimp-image-add-layer new-image layer_trees 0)
(gimp-image-add-layer new-image layer_terrain 0)
(gimp-image-add-layer new-image layer_elev 0)
(gimp-layer-add-alpha layer_trees)
(gimp-layer-add-alpha layer_terrain)
(gimp-layer-add-alpha layer_elev)
(gimp-edit-copy (aref (cadr (gimp-image-get-layers image_elev)) 0))
(gimp-floating-sel-anchor (car (gimp-edit-paste layer_elev 0)))
(gimp-edit-copy (aref (cadr (gimp-image-get-layers image_trees)) 0))
(gimp-floating-sel-anchor (car (gimp-edit-paste layer_trees 0)))
(gimp-edit-copy (aref (cadr (gimp-image-get-layers image_terrain)) 0))
(gimp-floating-sel-anchor (car (gimp-edit-paste layer_terrain 0)))
(gimp-display-new new-image)
(gimp-image-delete image_elev)
(gimp-image-delete image_terrain)
(gimp-image-delete image_trees)
(gimp-displays-flush))))
))
(script-fu-register "script-fu-tuxracer-load-level"
"<Toolbox>/Xtns/Script-Fu/TuxRacer/Load Level..."
"Tuxracer - Load all files of a course into a single image"
"Ingo Ruhnke"
"2000, Ingo Ruhnke"
"2000"
"RGB RGBA"
SF-FILENAME "Directory:" "/home/ingo/cvs/tuxracer/tuxracer-data/courses/.")
;; EOF ;;
--
ICQ: 59461927 http://pingus.seul.org |
Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ |
------------------------------------------------------------------------'
|
|
From: Jasmin P. <jf...@mu...> - 2000-03-29 23:52:56
|
On Wed, 29 Mar 2000, Julien Canet wrote: > Hi, > first, the idea to design levels with a 2d program and the course format is > really really great! > i designed a course who works (but not a really good course) and i tried > to make another one in800*48 (and higer ones) more complex and i can't > launch it, here is what i get: > [root@localhost 7]# tuxracer > video memory unprotecting > it seems it is too big or too complex (terrain really complex) because the > same course resized to 600*36 works (but slow): > What are the limitations? Hmm, it's possible that there's a problem in 0.11.* that prevents large courses. That section of the code has undergone major changes for the upcoming 0.12 release (which will be out very soon), and I just did a test on a 80x1024 course that worked fine. > I would like to make a really huge course (one that takes at least 3 > minutes to play) > Have you got advices to do that? The longest course that I've made takes about 1 minute to play. You should be able to make a longer course by simply making the bitmap longer... speed shouldn't suffer too much in version 0.12 since only the "nearby" portions of the course are displayed. Probably a bigger problem is memory consumption, but I think you'd have to make your course very large before that became a problem. 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. > When i save my level in rgb i choose "no compression": may i compress it? Yes, compressed rgb images are supported. > Another good thing (i know i'm boring sometimes) could be to specify in > course.tcl others rgb files to load for others objects (houses, other kind > of trees etc...) and also specify your code for colors (in your new rgb > files you would say that a color represent this object etc...). Yes, I plan to do something very much like that. :-) > And i have an idea (just a suggestion) do you know snobow kids on > Nintendo64? No, I haven't played that. > It looks like tuxracer and also mariokart: if you planned to make courses > vs computers or other players maybe you can do things like in snowbow kids: > at the end of the course you take a (i don't know the word in english) that > takes you to the beginning of the level and the course against others > players continue, (you have a number of laps to complete). I like that idea -- it would provide an easy way to extend the duration of races. Are you teleported to the top of the level, or is there a chairlift or other physical mechanism? (I speak French so you can tell me the French word :-). > By the way, tuxracer and tuxaqfh are my 2 favourites linux game projects!!! Cool! :-) Cheers, Jasmin |
|
From: Jasmin P. <jf...@mu...> - 2000-03-29 22:51:47
|
On Wed, 29 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > > > One disadvantage of SDL is that it's not as portable as PLIB (Linux is > > the only fully supported UNIX-type platform). I'll look into > > integrating the libmikmod code (loaders/players) into SL, if it's > > something you'd like to see added to PLIB. > > I believe that someone looked at that once before. I don't think > it's impossible - but it may not be that easy either. > > SL works with a central mixer that asks the various music sources: > > "Please make me X milliseconds of audio right now" > > ...hence the sources have to be able to make a particular amount > of sound on-demand. Since MikMod doesn't let you tell it how > much to generate, that's not likely to work. Actually, it does let you tell it how much sound to generate, and that's what SDL_mixer does. SDL_mixer doesn't use any of libmikmod's supplied drivers or mixers (it sets up its own libmikmod driver using mikmod's "virtual channel mixer interface"), and calls mikmod's VC_WriteBytes( buffer, len ) to fill the audio buffer. It looks fairly straightforward. > Hence we could call MikMod to create however much it feels like > - store it in a buffer and just hand 'X' bytes over to SL - keeping > what's left for next time. Not very elegant - but it ought to be > do-able. No, not elegant at all, and that's not what I had in mind. > Personally, I hate to add dependancies on yet more libraries > since that adds so much to support hassles down the line. > So, given the choice, I'd prefer to add whatever new music > formats to the existing MOD player in SL rather than constructing > some elaborate kludge to get MikMod's player to drive SL's mixer. I wouldn't consider this an eleborate kludge. It would use an exposed aspect of libmikmod, without relying on libmikmod's drivers or mixers. It needn't add dependencies to PLIB either, if you include a stripped-down version of libmikmod in PLIB (e.g., the drivers could be left out). SDL_mixer does this too. > I'm biassed though...and right now, I don't have time to do > either modification. Understood (I wasn't asking you to do it, I was offering to look into it and do it myself). Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Julien C. <jo...@fr...> - 2000-03-29 21:07:14
|
Hi, first, the idea to design levels with a 2d program and the course format is really really great! i designed a course who works (but not a really good course) and i tried to make another one in800*48 (and higer ones) more complex and i can't launch it, here is what i get: [root@localhost 7]# tuxracer video memory unprotecting it seems it is too big or too complex (terrain really complex) because the same course resized to 600*36 works (but slow): What are the limitations? I would like to make a really huge course (one that takes at least 3 minutes to play) Have you got advices to do that? When i save my level in rgb i choose "no compression": may i compress it? Another good thing (i know i'm boring sometimes) could be to specify in course.tcl others rgb files to load for others objects (houses, other kind of trees etc...) and also specify your code for colors (in your new rgb files you would say that a color represent this object etc...). And i have an idea (just a suggestion) do you know snobow kids on Nintendo64? It looks like tuxracer and also mariokart: if you planned to make courses vs computers or other players maybe you can do things like in snowbow kids: at the end of the course you take a (i don't know the word in english) that takes you to the beginning of the level and the course against others players continue, (you have a number of laps to complete). By the way, tuxracer and tuxaqfh are my 2 favourites linux game projects!!! Thanks Julien Jasmin Patry a écrit > On Tue, 28 Mar 2000 jo...@fr... wrote: > > > Hi all! > > tuxracer is really great! > > Hi! Glad you like it! > > > A friend (3d artist) and me would like to know how to make new levels: > > can anyone tell me how to do that or where to get infos? > > We have no ideas how to do that so please explain in details. > > It's actually pretty easy -- you don't need any 3D modelling > experience at all, just a 2D paint program like Gimp. There are some > details in the README distributed in the source package (see "Creating > New Courses"). The elevation for each course is specified using a > greyscale bitmap, the terrain types (snow, ice, rock) are specified > using another bitmap, and the tree positions are specified with (you > guessed it :) yet another bitmap. A good place to start looking would > be the files in <tuxracer-data>/courses/1. > > Ingo Ruhnke has created a couple of really useful Gimp scripts that > make the whole process of creating and editing a level much easier -- > they're on the web page. > > If you have any questions, please let us know. When I get a chance > (or somebody else volunteers to do it :) I want to create a level > creation tutorial on the web page... > > Also, I soon hope to allow course designers to add arbitrary 3D models > to a level, so your 3d artist friend will be able to use his/her > skills. > > Cheers, > Jasmin > > -- > Jasmin Patry Master's Student, Dept. of Computer Science > jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ > > _______________________________________________ > tuxracer-devel mailing list > tux...@li... > http://lists.sourceforge.net/mailman/listinfo/tuxracer-devel |
|
From: Steve B. <sjb...@ai...> - 2000-03-29 06:03:29
|
Jasmin Patry wrote: > > On Mon, 27 Mar 2000, Steve Baker wrote: > > > Jasmin Patry wrote: > > > > Erm - I'm not sure - my son and I played it for a while and then dumped it > > when the gameplay wore a bit thin. If the SDL version is under a month > > old then we probably have the pre-SDL version. > > 0.59 beta (the first version to use SDL) was released on 5 March 2000. > > > The bottom line (for me at least) is that you need to have a call into > > the sound generation/mixing stuff to tell it how much it's allowed to > > generate ahead of time each time it's called. Only the application can > > know how long that should be. > > Yes, I agree. I did some digging in SDL and SDL_mixer today and it does > allow you to specify how much data to buffer. I'm not sure if it allows > you to change that amount at run-time, but that seems to be an > improvement over the libmikmod mixer. There are potential problems due > to the non-determinism of thread scheduling, but my guess is that in > practical situations this shouldn't be a problem. > > One disadvantage of SDL is that it's not as portable as PLIB (Linux is > the only fully supported UNIX-type platform). I'll look into > integrating the libmikmod code (loaders/players) into SL, if it's > something you'd like to see added to PLIB. I believe that someone looked at that once before. I don't think it's impossible - but it may not be that easy either. SL works with a central mixer that asks the various music sources: "Please make me X milliseconds of audio right now" ...hence the sources have to be able to make a particular amount of sound on-demand. Since MikMod doesn't let you tell it how much to generate, that's not likely to work. However, if we only used MikMod for music, we would probably care much less about latency. Hence we could call MikMod to create however much it feels like - store it in a buffer and just hand 'X' bytes over to SL - keeping what's left for next time. Not very elegant - but it ought to be do-able. Personally, I hate to add dependancies on yet more libraries since that adds so much to support hassles down the line. So, given the choice, I'd prefer to add whatever new music formats to the existing MOD player in SL rather than constructing some elaborate kludge to get MikMod's player to drive SL's mixer. I'm biassed though...and right now, I don't have time to do either modification. -- 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-29 04:07:08
|
On Mon, 27 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > Erm - I'm not sure - my son and I played it for a while and then dumped it > when the gameplay wore a bit thin. If the SDL version is under a month > old then we probably have the pre-SDL version. 0.59 beta (the first version to use SDL) was released on 5 March 2000. > The bottom line (for me at least) is that you need to have a call into > the sound generation/mixing stuff to tell it how much it's allowed to > generate ahead of time each time it's called. Only the application can > know how long that should be. Yes, I agree. I did some digging in SDL and SDL_mixer today and it does allow you to specify how much data to buffer. I'm not sure if it allows you to change that amount at run-time, but that seems to be an improvement over the libmikmod mixer. There are potential problems due to the non-determinism of thread scheduling, but my guess is that in practical situations this shouldn't be a problem. One disadvantage of SDL is that it's not as portable as PLIB (Linux is the only fully supported UNIX-type platform). I'll look into integrating the libmikmod code (loaders/players) into SL, if it's something you'd like to see added to PLIB. Cheers, 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-29 03:42:36
|
I'm going to be putting a 0.12 release out soon (probably on Friday), so if anybody has any courses they've been working on, please send them to me. Thanks! 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-28 13:25:51
|
On Tue, 28 Mar 2000 jo...@fr... wrote: > Hi all! > tuxracer is really great! Hi! Glad you like it! > A friend (3d artist) and me would like to know how to make new levels: > can anyone tell me how to do that or where to get infos? > We have no ideas how to do that so please explain in details. It's actually pretty easy -- you don't need any 3D modelling experience at all, just a 2D paint program like Gimp. There are some details in the README distributed in the source package (see "Creating New Courses"). The elevation for each course is specified using a greyscale bitmap, the terrain types (snow, ice, rock) are specified using another bitmap, and the tree positions are specified with (you guessed it :) yet another bitmap. A good place to start looking would be the files in <tuxracer-data>/courses/1. Ingo Ruhnke has created a couple of really useful Gimp scripts that make the whole process of creating and editing a level much easier -- they're on the web page. If you have any questions, please let us know. When I get a chance (or somebody else volunteers to do it :) I want to create a level creation tutorial on the web page... Also, I soon hope to allow course designers to add arbitrary 3D models to a level, so your 3d artist friend will be able to use his/her skills. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: <jo...@fr...> - 2000-03-28 06:27:43
|
Hi all! tuxracer is really great! A friend (3d artist) and me would like to know how to make new levels: can anyone tell me how to do that or where to get infos? We have no ideas how to do that so please explain in details. Thanks Julien |
|
From: Steve B. <sjb...@ai...> - 2000-03-28 04:22:17
|
Jasmin Patry wrote: > > Just curious. Are you both talking about the latest glTron with SDL? > > I think Andreas just recently starting using SDL. > > Yes, I am. My guess from past posts is that Steve has only tried the > old version that uses libmikmod -- though I'd be very interested to hear > otherwise. Erm - I'm not sure - my son and I played it for a while and then dumped it when the gameplay wore a bit thin. If the SDL version is under a month old then we probably have the pre-SDL version. I presume that since the problem appears to be in MikMod that it would apply just as much to SDL - but since the symptoms don't show up on all CPU speeds, it's kinda touchy. > Steve, do you mind if I quote portions of your messages on this topic to > the SDL/SDL_mixer people? I'd like to hear what they have to see on the > topic. Sure - although I'm sure they are aware of the issues. The bottom line (for me at least) is that you need to have a call into the sound generation/mixing stuff to tell it how much it's allowed to generate ahead of time each time it's called. Only the application can know how long that should be. -- 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-27 22:40:43
|
On Mon, 27 Mar 2000, Dave McClurg wrote: > >To the contrary - glTron is the game I have most trouble with. When > >the audio is turned on, the frame rate (on even a static scene) jumps > >from better-than-60Hz to worse-than-5Hz about once a second - making > >the game utterly unplayable. > > > >It doesn't do this on all machines - which is strange. > > > > Just curious. Are you both talking about the latest glTron with SDL? > I think Andreas just recently starting using SDL. Yes, I am. My guess from past posts is that Steve has only tried the old version that uses libmikmod -- though I'd be very interested to hear otherwise. Steve, do you mind if I quote portions of your messages on this topic to the SDL/SDL_mixer people? I'd like to hear what they have to see on the topic. Cheers, Jasmin P.S. Btw, I didn't receive a copy of Steve's message that Dave's message is in reply to. It's not in my procmail logs so I know I didn't delete it accidentally. Weird. (It's in the archives, though.) |
|
From: Dave M. <dp...@ef...> - 2000-03-27 17:04:41
|
>> I've had a look at gltron >> and it seems to be very easy to use SDL_mixer to play music. The >> quality is excellent too. It uses pthreads so no explicit updates >> are necessary, which should solve the problems reported by Steve with >> libmikmod. > >To the contrary - glTron is the game I have most trouble with. When >the audio is turned on, the frame rate (on even a static scene) jumps >from better-than-60Hz to worse-than-5Hz about once a second - making >the game utterly unplayable. > >It doesn't do this on all machines - which is strange. > Just curious. Are you both talking about the latest glTron with SDL? I think Andreas just recently starting using SDL. |
|
From: Steve B. <sjb...@ai...> - 2000-03-26 06:04:40
|
Jasmin Patry wrote: > I've had a look at gltron > and it seems to be very easy to use SDL_mixer to play music. The > quality is excellent too. It uses pthreads so no explicit updates > are necessary, which should solve the problems reported by Steve with > libmikmod. To the contrary - glTron is the game I have most trouble with. When the audio is turned on, the frame rate (on even a static scene) jumps from better-than-60Hz to worse-than-5Hz about once a second - making the game utterly unplayable. It doesn't do this on all machines - which is strange. (The following comments apply to a single CPU machine) The thing is that putting a process into a second thread in no way assures that it'll run at appropriate times. You are at the mercy of the kernel's scheduler - which isn't really designed for realtime stuff. If your main renderer is at higher priority than the music thread then it'll run until it chooses to give up the CPU or until it runs out of it's timeslot. This can result in the music thread not running often enough - so the sound breaks up. If the music thread is at highest priority then it may run at inappropriate times causing it to swallow large chunks of time in one go - causing the video to hesitate at odd times. If they are at the same priority - then you may well see both of the above happening at different times. The solution is clear. You need your own scheduler to ensure that all processes get a fair chunk of the CPU every frame. You need each thread to voluntarily use only it's fair share of time - and to give back time often enough to let the other process run smoothly. Once you do that, you don't need the other thread...you might as well mung them together. Also, if you rely on the kernel scheduler, you can wave goodbye to portability. Linux's kernel might work OK - but what about Win95/98/NT/2k? Even within one OS, you'll get wildly different results with different sound cards - and with CPU's of differing speeds. This makes life impossible for the amateur developer who can't possibly test on a full range of systems. ...all of which brings us back to the problem with MikMod - which is that it doesn't give you control of how much time it consumes - and when. Even when running in a separate thread, it can get you into the kind of trouble that glTron has on my son's PC (but not on mine or the author's). So - my own sound library is deliberately designed to play nicely with 3D rendering by letting you tell it how often you intend to call it (and by implication, how much sound you want it to compute in each iteration). SL doesn't require a separate thread (and wouldn't work as well if it had one). > I've written Andreas to get some more info but the case for > SDL looks pretty strong. Well, I talk with Andreas quite a bit - he never did track down the sound problems with glTron on my kid's PC. > > If you'd like to hear the music I've written so far, I can put it up > > somewhere. > > Sure, that would be great! If they're not too large (under 1-2 MB) you can > just email them to me directly if that's easier for you. MOD files are rarely more than a few 10's of Kb - compactness is one of their great attractions. -- 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-25 23:16:47
|
On Wed, 22 Mar 2000, Joseph Toscano wrote: > Jasmin Patry wrote: > > Yeah. Until I settle on a library, maybe you should hold off writing > > anything. > > <grins> Too late. I've already written a title song and a song to be > played during the "options" menu. But I won't write any more until you > guys get the code stuffs sorted out. It's no problem for me. Thanks for taking the initiative anyway. :-) I've had a look at gltron and it seems to be very easy to use SDL_mixer to play music. The quality is excellent too. It uses pthreads so no explicit updates are necessary, which should solve the problems reported by Steve with libmikmod. I've written Andreas to get some more info but the case for SDL looks pretty strong. > If you'd like to hear the music I've written so far, I can put it up > somewhere. Sure, that would be great! If they're not too large (under 1-2 MB) you can just email them to me directly if that's easier for you. Cheers, Jasmin |
|
From: Jasmin P. <jf...@mu...> - 2000-03-25 22:40:47
|
I've committed changes that include paddling (mapped to "k" by default), and a first attempt at a damage system. Currently health is displayed but it doesn't have any effect on the game (i.e., the game continues even if health drops below zero). Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Joseph T. <sc...@pc...> - 2000-03-22 21:37:36
|
Jasmin Patry wrote: > Yeah. Until I settle on a library, maybe you should hold off writing > anything. <grins> Too late. I've already written a title song and a song to be played during the "options" menu. But I won't write any more until you guys get the code stuffs sorted out. It's no problem for me. If you'd like to hear the music I've written so far, I can put it up somewhere. --JT http://artists.traxinspace.com/scarjt/ |
2 messages has been excluded from this view by a project administrator.
