tuxracer-devel Mailing List for Tux Racer (Page 3)
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: Jules B. <jm...@he...> - 2000-04-13 12:29:05
|
On Wed, Apr 12, 2000 at 11:09:30PM -0500, Steve Baker wrote:
> Jules Bean wrote:
>
> >
> > Points for *long* periods of being airborn - perhaps for each period
> > of being airborn for longer than 0.5 seconds.
>
> Well don't we have to have 'damage' scored on Tux for hard landings,
> hitting trees and stuff - and perhaps for scooting over rocks at high
> speed? (That's hard on your feathers you know!) That makes for somewhat
> contradictory requirements...I think a better way to reward long 'air
> time' is using tricks (see my comments below).
Contradictory requirements aren't a bad thing, necessarily. They force
you to try to make the right trade-off, which makes for an interesting
game.
As a (relevant) aside I don't think we should damage tux *too* much
for hard landings --- I've landed (on skis) whilst moving pretty
fast. Rocks and trees, definitely.
However, I agree with you about the tricks, definitely. That'd be cool.
>
> > 100? points for never using the paddle key
>
> I don't think you need to do that - if you have to resort to paddling,
> you've already lost so much time that you'll get a bad time score.
> No need for a double penalty.
But, in the current version at least, you can shave seconds of your
time by holding down the paddle key all time. The idea was to give an
incentive to doing the race 'pure'. Maybe the incentive should be
even bigger, given that on some tracks it might be *very* hard to beat
par without paddling.
>
> > Other bonuses might have to wait until we have 'special trick' keys.
>
> Yep! The (excellent) 1080 snowboard game on Nintendo 64 has that -
> and it's nice because they reward small numbers of points for doing
> basic tricks - but MUCH more points for doing them in combinations in
> quick succession while in the air. I guess that's incentive for
> getting long 'air time' - you can fit in more tricks in one 'combo'.
That sounds great to me.
> We might also want to consider 'bonuses' on the track:
>
> * Goodies you can hit to get a temporary boost of speed.
> * Things that repair your 'damage'.
> * Things that score bonus points.
> * Perhaps things like teleporters that take you to some other
> place on the track (better *or* worse).
Definitely. I think Jasmin's already mentioned that in his todo.
> This may be controversial - but I would like to propose that
> we aim for a common 'style' for such things between Tux Racer
> and my Quest for Herring game. (And "Tux-Kart" which may be my
> next effort). It would help the world of Tux-based games to
> establish a set of common themes like that.
I'd be very much in favour of that kind of consistency. But care
needs to be taken not to create an unofficial tux 'cartel' ;-)
We could even produce a semi-spoof semi-serious 'tux interface guidelines'!
>
> > Personally, I'm not too bothered about needing to 'finish' one track
> > before going on to the next, although perhaps this should be at the
> > course designer's option --- so some tracks are grouped into
> > sequences, and some aren't.
>
> I think it's important to give players a REASON to beat the game.
> We aren't offering cash prizes - but the ability to 'get onto the
> next level' is a powerful force to get people to keep playing until
> they beat the 'par' time. If all the courses are instantly accessible,
> people will visit each one quickly and have seen all that the game
> has to offer before they've even mastered one level.
You're right. I'm thinking of writing a net.essay on this very issue
- 'satisfaction' in games. Why do we go back to games, and what
should a game designed do to make sure we do? Obviously it's actually
much *easier* for competitive multiplayer games, since the incentive
is 'this time I'm going to beat him...'.
Often I keep playing games because I want to see the cool
graphics/effects. Which is funny since I'm not really into graphics
(my most-played game of all time is the text 'roguelike' angband).
But when I kept coming back to the Loki Heroes of Might and Magic
demo, it was because I wanted to see what a 'monk' looked like in
battle, etc.
In terms of scoring, I find it a tremendous motivator if you get those
corny little floating numbers which mean "you've just scored 10,000"
points. The instant gratification is somehow more important than the
score you get at the end of the level. It's nice to know immediately
how well the trick went. [You can then cancel the points dramatically
if tux lands badly]
>
> You'd want to make it EASY to 'open up' the first few levels - but
> make things increasingly hard right up to the end.
Mais naturellement...
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-04-13 04:34:45
|
Jules Bean wrote:
> Have a 'par' time, as Steve says. Score 1000 points for completing
> the level 'on par'. Otherwise, score 1000*[par/actual time], so 'half
> par' (which probably shouldn't be possible) gives 2000
> points. Alternatively, square or cube the [] portion to give slightly
> more reward for speed.
>
> Then, the bonus points. It's not clear to me all the things we'd
> want, but some ideas:
>
> 100 points for finishing the level in the air ('cos it looks cool)
>
> Points for *long* periods of being airborn - perhaps for each period
> of being airborn for longer than 0.5 seconds.
Well don't we have to have 'damage' scored on Tux for hard landings,
hitting trees and stuff - and perhaps for scooting over rocks at high
speed? (That's hard on your feathers you know!) That makes for somewhat
contradictory requirements...I think a better way to reward long 'air
time' is using tricks (see my comments below).
> 100? points for never using the paddle key
I don't think you need to do that - if you have to resort to paddling,
you've already lost so much time that you'll get a bad time score.
No need for a double penalty.
> Other bonuses might have to wait until we have 'special trick' keys.
Yep! The (excellent) 1080 snowboard game on Nintendo 64 has that -
and it's nice because they reward small numbers of points for doing
basic tricks - but MUCH more points for doing them in combinations in
quick succession while in the air. I guess that's incentive for
getting long 'air time' - you can fit in more tricks in one 'combo'.
Doing the same trick twice in a row doesn't constitute a combo in
1080...and if you fall off the board on landing, your score for
that set of tricks is zeroed.
We might also want to consider 'bonuses' on the track:
* Goodies you can hit to get a temporary boost of speed.
* Things that repair your 'damage'.
* Things that score bonus points.
* Perhaps things like teleporters that take you to some other
place on the track (better *or* worse).
This may be controversial - but I would like to propose that
we aim for a common 'style' for such things between Tux Racer
and my Quest for Herring game. (And "Tux-Kart" which may be my
next effort). It would help the world of Tux-based games to
establish a set of common themes like that.
For example, I have 'spinning herrings' in different colours
(Silver for a points bonus, Gold for a major prize, Red for
a random-ish special effect, Green for bad things you'd want
to avoid. I use small spinning Tux icons for 'extra lives')
This is a common thing to do in video games. The Nintendo
'Mario' games are like this - in ALL Mario games, a spinning
coin is for points, a mushroom is an extra life and so on.
This makes it easier for a player to pick up a new game
and get instant satisfaction without needing to consult
a manual.
> Personally, I'm not too bothered about needing to 'finish' one track
> before going on to the next, although perhaps this should be at the
> course designer's option --- so some tracks are grouped into
> sequences, and some aren't.
I think it's important to give players a REASON to beat the game.
We aren't offering cash prizes - but the ability to 'get onto the
next level' is a powerful force to get people to keep playing until
they beat the 'par' time. If all the courses are instantly accessible,
people will visit each one quickly and have seen all that the game
has to offer before they've even mastered one level.
You'd want to make it EASY to 'open up' the first few levels - but
make things increasingly hard right up to the end.
If we end up with a LOT of levels (as seems likely), then grouping
them obviously makes sense.
Obviously there needs to be an undocumented 'backdoor' for developers
to be able to skip on to whatever level they want to test. My Tux_AQFH
game uses a password you can type in during the game to enter 'cheat'
mode in which you don't take damage and can skip on to any level without
meeting the prerequisites of that level.
--
Steve Baker http://web2.airmail.net/sjbaker1
sjb...@ai... (home) http://www.woodsoup.org/~sbaker
sj...@ht... (work)
|
|
From: Jasmin P. <jf...@mu...> - 2000-04-13 02:58:46
|
On Wed, 12 Apr 2000, Jules Bean wrote:
> I've been thinking about scoring, too. Here's some vague ideas:
>
> Have a 'par' time, as Steve says. Score 1000 points for completing
> the level 'on par'. Otherwise, score 1000*[par/actual time], so 'half
> par' (which probably shouldn't be possible) gives 2000
> points. Alternatively, square or cube the [] portion to give slightly
> more reward for speed.
Makes sense.
> Then, the bonus points. It's not clear to me all the things we'd
> want, but some ideas:
>
> 100 points for finishing the level in the air ('cos it looks cool)
>
> Points for *long* periods of being airborn - perhaps for each period
> of being airborn for longer than 0.5 seconds.
>
> 100? points for never using the paddle key
>
> Other bonuses might have to wait until we have 'special trick' keys.
I was also planning on giving a bonus based on how much health remained
at the end of the track.
> Then we could have two high-score tables per track - a pure speed
> one, and a points one.
Sure, that would be neat.
> Personally, I'm not too bothered about needing to 'finish' one track
> before going on to the next, although perhaps this should be at the
> course designer's option --- so some tracks are grouped into
> sequences, and some aren't.
A lot of games require you to get a minimum score/placing on a circuit
of tracks before the next set is unlocked. That would be another way of
doing 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-04-13 02:54:55
|
On Tue, 11 Apr 2000, Steve Baker wrote: > Well, for the load time, possibly nothing can be done (well, you > could optimise - or perhaps do some of the work off-line) - but for > the previews the game could create snapshots of the course previews > as PNG's or something and display those instead of the fully rendered > versions. You could also render them at smaller size so you can see > all of the courses (or at least - say - nine of them at a time) and > pick them like that. > > This would have one interesting side-effect - which is that the > course designer could hide parts of the course that are supposed > to be a suprise by simply painting out the "suprise" section. Yup, that sounds like a pretty good idea. > The thing TuxRacer *urgently* needs IMHO is a goal to beat - something > as simple as a 'par' time stored in the level's config file with code > to prevent you choosing level 'N' until you've beaten the par time for > level N-1. That would be enough to make the program cross the boundary > from 'cool demo' to 'playable game'. I definitely plan on doing something like this. (Probably not as quickly as you'd like, though :-). Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Ingo R. <gr...@gm...> - 2000-04-12 15:42:41
|
Julien Canet <jo...@fr...> writes: > -Can i change the difference between the white and black for elev.rgb : > i mean i would like white pixels to make higher mountains? Something like: tux_elev_scale 12 -- ICQ: 59461927 http://pingus.seul.org | Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ | ------------------------------------------------------------------------' |
|
From: Jules B. <jm...@he...> - 2000-04-12 10:13:20
|
On Tue, Apr 11, 2000 at 10:11:23PM -0500, Steve Baker wrote:
> The thing TuxRacer *urgently* needs IMHO is a goal to beat - something
> as simple as a 'par' time stored in the level's config file with code
> to prevent you choosing level 'N' until you've beaten the par time for
> level N-1. That would be enough to make the program cross the boundary
> from 'cool demo' to 'playable game'.
*nods*
I've been thinking about scoring, too. Here's some vague ideas:
Have a 'par' time, as Steve says. Score 1000 points for completing
the level 'on par'. Otherwise, score 1000*[par/actual time], so 'half
par' (which probably shouldn't be possible) gives 2000
points. Alternatively, square or cube the [] portion to give slightly
more reward for speed.
Then, the bonus points. It's not clear to me all the things we'd
want, but some ideas:
100 points for finishing the level in the air ('cos it looks cool)
Points for *long* periods of being airborn - perhaps for each period
of being airborn for longer than 0.5 seconds.
100? points for never using the paddle key
Other bonuses might have to wait until we have 'special trick' keys.
Then we could have two high-score tables per track - a pure speed
one, and a points one.
Personally, I'm not too bothered about needing to 'finish' one track
before going on to the next, although perhaps this should be at the
course designer's option --- so some tracks are grouped into
sequences, and some aren't.
Comments?
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-04-12 03:14:35
|
Jasmin Patry wrote: > > and i can say that there are good performances during the course (nearly > > as a normal (smaller) course) but it takes a lot of time to load and > > have the 3d-preview. > > *nod* Unfortunately, I don't think there's very much I can do about that. Well, for the load time, possibly nothing can be done (well, you could optimise - or perhaps do some of the work off-line) - but for the previews the game could create snapshots of the course previews as PNG's or something and display those instead of the fully rendered versions. You could also render them at smaller size so you can see all of the courses (or at least - say - nine of them at a time) and pick them like that. This would have one interesting side-effect - which is that the course designer could hide parts of the course that are supposed to be a suprise by simply painting out the "suprise" section. The thing TuxRacer *urgently* needs IMHO is a goal to beat - something as simple as a 'par' time stored in the level's config file with code to prevent you choosing level 'N' until you've beaten the par time for level N-1. That would be enough to make the program cross the boundary from 'cool demo' to 'playable game'. It would then be necessary to grade the existing levels according to difficulty so things start off easy and get progressively harder. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-04-11 23:39:43
|
On Tue, 11 Apr 2000, Joseph Toscano wrote: > Hmm, well, they do loop, yes. They're set up to do so, but players such > as WinAmp and MikMod do not loop the mods correctly. What those players > do is just play the entire song over again, not following any looping > instructions. If SDL_Mixer doesn't want to loop the songs right (though > in Adonthell, the songs do loop right) then I'll put explicit commands > at the end of the song for correct looping. :) Ah, ok. I haven't tried playing them with SDL_mixer yet. > Thanks for the comments, BTW. I'm glad you like the songs and I'll be > writing a few more. :) I look forward to hearing them! 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-04-11 23:37:57
|
On Wed, 12 Apr 2000, Julien Canet wrote: > Hi, > I'm working on a 3600*120 course (it works with the latest versions but > not the older ones) and i would like to know: > > -Can i change the difference between the white and black for elev.rgb : > i mean i would like white pixels to make higher mountains? Increasing tux_elev_scale in course.tcl will do what you want, I think. That value specifies the height in metres between white pixels and black pixels. > -Can i change the maximum_trees? in a big course i need to put a lot of > trees Unfortunately, the only way to do that is to increase the value of MAX_TREES in course_load.c. I'll increase it for the next release -- is 8192 enough? :-) > and i can say that there are good performances during the course (nearly > as a normal (smaller) course) but it takes a lot of time to load and > have the 3d-preview. *nod* Unfortunately, I don't think there's very much I can do about that. > Tuxracer is so cool!!! Glad you (still!) think so! Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Joseph T. <sc...@pc...> - 2000-04-11 23:19:26
|
Jasmin Patry wrote: > I like them a lot! My only comment is that it would be nice if they > looped seamlessly, since that's how I will play them in the game. Hmm, well, they do loop, yes. They're set up to do so, but players such as WinAmp and MikMod do not loop the mods correctly. What those players do is just play the entire song over again, not following any looping instructions. If SDL_Mixer doesn't want to loop the songs right (though in Adonthell, the songs do loop right) then I'll put explicit commands at the end of the song for correct looping. :) Thanks for the comments, BTW. I'm glad you like the songs and I'll be writing a few more. :) --JT http://artists.traxinspace.com/scarjt/ |
|
From: Julien C. <jo...@fr...> - 2000-04-11 22:38:15
|
Hi, I'm working on a 3600*120 course (it works with the latest versions but not the older ones) and i would like to know: -Can i change the difference between the white and black for elev.rgb : i mean i would like white pixels to make higher mountains? -Can i change the maximum_trees? in a big course i need to put a lot of trees and i can say that there are good performances during the course (nearly as a normal (smaller) course) but it takes a lot of time to load and have the 3d-preview. Tuxracer is so cool!!! Julien |
|
From: Jasmin P. <jf...@mu...> - 2000-04-11 21:22:43
|
On Tue, 11 Apr 2000, Joseph Toscano wrote: > Hi, all. :) Hi! > I've written three songs for the game, sorta as just a "taste" for now. > They are all .it (Impulse Tracker) modules and can be successfully > played back with MikMod, or ModPlug in Win32. They can be downloaded > from: > > http://www.zeal-music.com/tuxrce.tar.gz (218k) Cool! I really like the feel, I think it's very appropriate for the game. I'm in a better mood already. :-) > tuxrce-1.it - The title-screen music. I assume there will be a nice > title screen with, y'know, the two choices, "start game" or "options." > If so, this is the music that will play. > > tuxrce-2.it - Options screen. If there's an option screen thingy for > selecting different parameters (like 3d stuff, sound volume) then here's > the music. Methodical and plotting. <g> > > tuxrce-3.it - A song for in-game play. > > I hope you like them. Please give me your comments; I'll be writing some > more soon if you still wanna keep me on the project. :) I like them a lot! My only comment is that it would be nice if they looped seamlessly, since that's how I will play them in the game. The options music loops the best, but even there there is a little jump. (That might be due to my player -- I'm using the mikmod plugin in xmms.) And yes, I definitely would like it if you stayed on the project! Thanks, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Joseph T. <sc...@pc...> - 2000-04-11 20:31:09
|
Hi, all. :) I've written three songs for the game, sorta as just a "taste" for now. They are all .it (Impulse Tracker) modules and can be successfully played back with MikMod, or ModPlug in Win32. They can be downloaded from: http://www.zeal-music.com/tuxrce.tar.gz (218k) tuxrce-1.it - The title-screen music. I assume there will be a nice title screen with, y'know, the two choices, "start game" or "options." If so, this is the music that will play. tuxrce-2.it - Options screen. If there's an option screen thingy for selecting different parameters (like 3d stuff, sound volume) then here's the music. Methodical and plotting. <g> tuxrce-3.it - A song for in-game play. I hope you like them. Please give me your comments; I'll be writing some more soon if you still wanna keep me on the project. :) --JT http://artists.traxinspace.com/scarjt/ |
|
From: Jasmin P. <jf...@mu...> - 2000-04-08 16:00:46
|
On Fri, 7 Apr 2000, Peter Allen wrote:
> Could I have some more details please, as I would quite like to muck
> around trying to add a sharp turn, which slows tux down. I'm not
> sure whether it would work, hence why I want to try it myself rather
> than add it to the end of your todo list.
I quite like the idea of a sharp turn. All of the motion in Tux Racer
is governed by particle physics (with the exception of tree collisions),
and calculated using an ODE solver. There is a routine in phys_sim.c
called calc_net_force() that calculates the net force on Tux, and that
force is then used to update his velocity and position.
If you look at calc_net_force(), you will see that steering works by
taking the frictional force vector (which points in a direction opposite
of Tux's velocity vector) and rotating it about the surface normal. If
Tux is turning left, then the friction vector will be turned to look
like this:
^ velocity
|
|
+ Tux
/
/
L frictional force
The magnitude of the frictional force is also increased to reflect the
fact that drag is increased when Tux puts his hand down (so turning does
slow him down, a little bit).
There are problems with this approach, though: Tux can actually "spin"
on surfaces with high friction coefficients (like rock) because the
frictional force is so large. This hasn't bothered me enough yet to
make me fix it :) (though I can think of a few approaches that should
work).
For sharp turns, you have a few options. You can play with
calc_net_force and change how the steering part works when a sharp turn
is being performed, or you can directly manipulate the velocity vector
in solve_ode_system (also in phys_sim.c). In the latter case, you would
want to do that around the point where adjust_for_tree_collisions() is
called (that routine directly manipulates the velocity vector if a tree
is hit). My bias is to try to do it with forces, but I realize that
some things can be tricky to do that way.
As for the keyboard code: There are several different "modes" in Tux
Racer; the current ones are START (the start screen), INTRO (the intro
animation before a race), RACING (the race itself), PAUSED, and
GAME_OVER. Each mode can register its own "loop" function (which gets
called between screen refreshes, and can also register its own keyboard
callbacks. If you look at racing_register in racing.c, it creates a
keyboard callback for the braking action by calling (comments added):
add_keymap_entry( RACING, /* the mode this entry is active in */
CONFIGURABLE_KEY, /* the user can change this binding */
"space", /* if all else fails, use this key */
getparam_brake_key, /* fn ptr that returns current binding */
brake_cb /* callback when key is pressed/released */
);
brake_cb is defined as follows:
START_KEYBOARD_CB( brake_cb )
{
plyr->control.is_braking = !release;
}
END_KEYBOARD_CB
The macros are defined in keyboard.h and expand to (more or less):
void brake_cb ( int key, bool_t special, bool_t release, int x, int y )
{
player_data_t *plyr = get_player_data( local_player() );
{
plyr->control.is_braking = !release;
}
}
I think it would make sense to implement sharp turns as a modifier key,
so you could add another field to plyr->control and implement it in the
same way as braking.
I hope this makes sense. If you have another other questions, feel free
to ask.
Cheers,
Jasmin
--
Jasmin Patry Master's Student, Dept. of Computer Science
jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/
|
|
From: Peter A. <P....@bi...> - 2000-04-07 06:59:00
|
Jasmin Patry wrote: > > On Thu, 6 Apr 2000, Peter Allen wrote: > > > Hi, > > I want to muck around with the controls on tuxracer, and have had a > > quick look at the code, and am now confused. > > Could someone give me a brief explanation of the structure of it, > > if it doesn't take too much time. > > If you simply want to change the key bindings, you can do that in > ~/.tuxracer. It's documented in the README. If you actually want to > change the way the keyboard code works, let me know and I'll try to > provide relevant details. Could I have some more details please, as I would quite like to muck around trying to add a sharp turn, which slows tux down. I'm not sure whether it would work, hence why I want to try it myself rather than add it to the end of your todo list. Thanks, Peter Allen |
|
From: Jasmin P. <jf...@mu...> - 2000-04-07 00:08:43
|
On Thu, 6 Apr 2000, Peter Allen wrote: > Hi, > I want to muck around with the controls on tuxracer, and have had a > quick look at the code, and am now confused. > Could someone give me a brief explanation of the structure of it, > if it doesn't take too much time. If you simply want to change the key bindings, you can do that in ~/.tuxracer. It's documented in the README. If you actually want to change the way the keyboard code works, let me know and I'll try to provide relevant details. > btw tuxracer is a _great_ game. Thanks for all the hard work... Thanks! Cheers, Jasmin |
|
From: Peter A. <P....@bi...> - 2000-04-06 20:58:48
|
Hi, I want to muck around with the controls on tuxracer, and have had a quick look at the code, and am now confused. Could someone give me a brief explanation of the structure of it, if it doesn't take too much time. TIA, Peter Allen btw tuxracer is a _great_ game. Thanks for all the hard work... |
|
From: Jasmin P. <jf...@mu...> - 2000-04-03 02:16:27
|
CVS has been updated for the 0.12 release (out now). One note: I added the script-fu scripts to CVS, but forgot to included them in the 0.12 release. I'll make sure they make it in the next one. 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-04-02 20:06:11
|
Jasmin Patry wrote: > Sounds pretty cool. By the time I'm ready to implement something like > that, PrettyPoly probably *will* be usable as a modeller. :-) I hope so - development on PrettyPoly has slowed down a LOT recently though - I need to put in some serious hours on it and hope that gets everyone else excited about it again. > I was actually just "blue-skying" in my last email -- for version 1.0, > I'll just go with simple placement of objects and worry about getting > fancier later on. Yep - good plan. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-04-01 17:13:14
|
On Sat, 1 Apr 2000, Steve Baker wrote: > Jasmin Patry wrote: > > I don't have a strong preference either way. Steve, it's your call. :-) > > Well, to be honest, my preference is to pick a better mod-like > format than '.MOD' itself - and just implement that into PLIB > once and for all. It's more grief now - but a lot easier to > maintain down-the-line. Ok. Given that it's not your preferred solution, I think I'll leave PLIB/mikmod integration for now, and go with SDL_mixer for sound support. Joseph (if you're still listening!), this means that I'll be able to play your music. 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-04-01 16:57:52
|
On Fri, 31 Mar 2000, Steve Baker wrote: > Well, GIMP 1.1.7 (which shipped with SuSE 6.2 - so it's been around for > a while) displays the mouse coordinates in the bottom-left corner of the > window all the time - so I guess that problem is dealt with. Yup -- I guess it's time to upgrade. > Well, if you are going to go that far, take your existing code from > within the game that converts the image maps into triangles - and > turn that into an offline tool. Have that tool export the triangles > into a 3D model file. Now import that file into a modeller and you > can add other 3D models interactively - build courses that don't > require a regularly gridded terrain - make tunnels and bridges, etc, etc. > > If your modeller can export animation nodes, etc (which PrettyPoly > does...although it's not yet usable as a modeller) - then that's > all you need. Sounds pretty cool. By the time I'm ready to implement something like that, PrettyPoly probably *will* be usable as a modeller. :-) I was actually just "blue-skying" in my last email -- for version 1.0, I'll just go with simple placement of objects and worry about getting fancier later on. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Ingo R. <gr...@gm...> - 2000-04-01 11:57:16
|
Jasmin Patry <jf...@mu...> writes: > 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. Gimp1.1 displays the current cursor position in the bottom left corner of the image, it has also a tool for geting the distance and angle between two pixels, but it won't give you subpixel values (1.0). > Perhaps this could be done with script-fu? No, script-fu is very limited and it is impossible to do such kind of things with it, only a real gimp plug-in would probablly be able to perform such a task. -- ICQ: 59461927 http://pingus.seul.org | Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ | ------------------------------------------------------------------------' |
|
From: Steve B. <sjb...@ai...> - 2000-04-01 06:09:07
|
Jasmin Patry wrote: > 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. Yep. > I don't have a strong preference either way. Steve, it's your call. :-) Well, to be honest, my preference is to pick a better mod-like format than '.MOD' itself - and just implement that into PLIB once and for all. It's more grief now - but a lot easier to maintain down-the-line. The snag is that I don't personally have the time to do that anytime in the next few months. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Steve B. <sjb...@ai...> - 2000-04-01 06:09:05
|
Jules Bean wrote: > > 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. It's not the opposite of my feeling. I also hate to include part of one library into the distribution of another. However, the alternative is sometimes to require all of our poor users to scour the web and download and install a half-dozen other libraries, some of which will inevitably be the wrong version - or won't install cleanly or something. I only rely on ONE other package (Mesa) in my present code - and even so, the volume of support email I have to answer for people who havn't installed it correctly is more than I like. I *hate* the idea of increasing that number unless it's absolutely necessary. I'm pretty sure that anyone who'se supported a reasonably popular OpenSource application for any amount of time will heartily concur. > 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... Well, yes - that's an option - dynamically link to MikMod. At least that way, games that don't want music don't pay the support price. But nearly all games need music - so I'm not sure it helps in practice. This problem is really putting a serious kink in OpenSource games development - I don't know *what* can be done about it. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Steve B. <sjb...@ai...> - 2000-04-01 06:09:04
|
Jasmin Patry wrote: > 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. Well, GIMP 1.1.7 (which shipped with SuSE 6.2 - so it's been around for a while) displays the mouse coordinates in the bottom-left corner of the window all the time - so I guess that problem is dealt with. > 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. Yep - I guess so. > 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. Well, if you are going to go that far, take your existing code from within the game that converts the image maps into triangles - and turn that into an offline tool. Have that tool export the triangles into a 3D model file. Now import that file into a modeller and you can add other 3D models interactively - build courses that don't require a regularly gridded terrain - make tunnels and bridges, etc, etc. If your modeller can export animation nodes, etc (which PrettyPoly does...although it's not yet usable as a modeller) - then that's all you need. Of course then you have a game like mine...which I guess doesn't come as much of a suprise! -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
2 messages has been excluded from this view by a project administrator.
