tuxkart-devel Mailing List for Tux Kart (Page 8)
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel — TuxKart Developers.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(8) |
Jul
(46) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2002 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(192) |
Jul
(199) |
Aug
(137) |
Sep
(59) |
Oct
(28) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Steve B. <sjb...@ai...> - 2004-08-08 21:21:43
|
Ingo Ruhnke wrote: > I am also not sure how plib internally works, so pumping the track as > one huge mesh to it might not be a good idea. Some of the other tracks > where broken up in little segments, which might make it easier to cull > these when they are out of the view. Both collision code and rendering code will benefit IMMENSELY from having the track broken up into short segments. Without that, there is no way to cull by field of view - and the collision detection code will have to do really costly testing for just about every polygon. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Ingo R. <gr...@gm...> - 2004-08-08 19:03:23
|
James Gregory <jam...@bt...> writes: > Yeah, my computer totally can't cope with "On the beach" either. > I've also noticed the frame rate drops hugely each time a Tux comes > into view - maybe the model is slightly too detailed? Tux has around ~3200 triangles, the track itself around ~10000, in comparism the old geekokart has 870, the old tracks around ~1000. No idea exactly how much polys todays gfx cards can handle, but due to the horrible performance on startup I think the gfx card itself isn't yet the problem, but more the collision code or something like that. I am also not sure how plib internally works, so pumping the track as one huge mesh to it might not be a good idea. Some of the other tracks where broken up in little segments, which might make it easier to cull these when they are out of the view. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: James G. <jam...@bt...> - 2004-08-08 17:43:33
|
On Sun, 2004-08-08 at 08:06, Pascal Giard wrote: > Hi there guys, > i'm just confirming that tuxkart you can play with 2 joysticks. Cool, thanks for testing it. > > It's almost 100% playable, the only annoying thing is that lag prevents you > from turning. When I face a complex and/or deep part of the track, it lags, > and i can't turn. So it's impossible to really race against each other in "On > the beach". > > Has it something to do with the time delta ? (refresh intervals) > > My neighbor and i had _alot_ of fun in "Race Track" in which the gameplay is > very smooth/perfect. :) Yeah, my computer totally can't cope with "On the beach" either. I've also noticed the frame rate drops hugely each time a Tux comes into view - maybe the model is slightly too detailed? James |
|
From: Charles G. <ch...@ve...> - 2004-08-08 10:27:48
|
Retract, retract, retract, retract, retract... Charles Goodwin wrote: > It was the sad result of a night out on the town and one (or ten) more > bevvies than was good for me. > > Steve, I apologise and restract _everything_ in that email. > > Note to self: shut down computer before going out drinking. > > - Charlie > > Pascal Giard wrote: > >> I think your [Charlie] post is quite provocative... >> >> I hope it won't fall into a flamewar, split, angriness, etc. >> >> btw, AFAIK, Steve really did code cleanups and the multi-view. >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel |
|
From: Charles G. <ch...@ve...> - 2004-08-08 10:17:36
|
It was the sad result of a night out on the town and one (or ten) more bevvies than was good for me. Steve, I apologise and restract _everything_ in that email. Note to self: shut down computer before going out drinking. - Charlie Pascal Giard wrote: >I think your [Charlie] post is quite provocative... > >I hope it won't fall into a flamewar, split, angriness, etc. > >btw, AFAIK, Steve really did code cleanups and the multi-view. > |
|
From: Pascal G. <pa...@gu...> - 2004-08-08 07:19:12
|
Hi there guys, i'm just confirming that tuxkart you can play with 2 joysticks. It's almost 100% playable, the only annoying thing is that lag prevents you from turning. When I face a complex and/or deep part of the track, it lags, and i can't turn. So it's impossible to really race against each other in "On the beach". Has it something to do with the time delta ? (refresh intervals) My neighbor and i had _alot_ of fun in "Race Track" in which the gameplay is very smooth/perfect. :) -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php) |
|
From: James G. <jam...@bt...> - 2004-08-08 04:10:39
|
If someone else could write it that would be very nice of them, I don't know how all that materials stuff etc works so I don't know how to go about unloading it. Thanks, James |
|
From: Pascal G. <pa...@gu...> - 2004-08-08 03:36:30
|
I think your [Charlie] post is quite provocative... I hope it won't fall into a flamewar, split, angriness, etc. btw, AFAIK, Steve really did code cleanups and the multi-view. -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php) |
|
From: James G. <jam...@bt...> - 2004-08-08 03:33:24
|
On Sun, 2004-08-08 at 04:22, Charles Goodwin wrote: > So where is the multi-view stuff? We have people talking about > implementing it (again it seems) yet there is no obvious point where you > have already done the work. Erm, actually, to be fair, multi-view is there. The camera positioning is a bit off, but it definitely does work. James |
|
From: Charles G. <ch...@ve...> - 2004-08-08 03:21:45
|
Steve Baker wrote: > I've tried to do that - but nobody wants to listen to what I have to say > so it's just easier to let you guys bulldoze ahead and then clean up > whatever > mess is left at the end. You mean nobody submitted to your whim... everybody was listening except you. >> No offense Steve, but since GotM started you have done jack all. > > > That's not true. I added the multi-view stuff and did a ton of code > cleanup. Recently, I've not wanted to get involved because I'd be > spending all my time undoing what people have screwed up - that would > lead to interminable arguments which I really don't have the patience > for - so I'd prefer to duck out until the chaos dies down and restore > sanity at the end. So where is the multi-view stuff? We have people talking about implementing it (again it seems) yet there is no obvious point where you have already done the work. The only visible work you have done during GotM is to add people as developers to the sf.net tuxkart project. > The whole full screen business is a really trivial matter - if the PLIB > windowing library can't do it then let's make it do it Ruh-EALLY. We are WAITING. You simply ignored all messages to the list on this matter thus far. For you to turn around and say "make PLIB do it" is a bit rich. Why haven't you started already? Or are we the bitches who must do the master's bidding? (That's quite ironic given that I've contributed as much as you to this GotM, mostly noise.) > What's actually happened is that you've ended up attempting to do > virtually > a top to bottom rewrite with all new models, new libraries, new GUI - > the whole > works. You are dinking unnecessarily with things that are really > working just > fine. What's happened is that you've proved relatively DIFFICULT to work with thus far. Nobody is try to cause problems, they're just trying to help. But where is the maintainer? Not maintaining, just complaining. Another irony is that you asked for it all to be "rewritten" except for one thing; the GUI. > Frankly, it would have been easier for you to start afresh with a > completely > new game...but that would be ridiculous because you KNOW you can't > write a > complete new game in two months. *snore* > The GoTM concept is a good one - but failing to stay focussed on what was > the original scope of the work is what undoubtedly lead to your failure > to complete Pingus - and with only a few weeks to run, the same will > happen with TuxKart. *snore* When GotM is over, I suspect an apology from you will be the order of the day. - Charlie |
|
From: Ingo R. <gr...@gm...> - 2004-08-08 01:57:07
|
Steve Baker <sjb...@ai...> writes: > The whole problem with GOTM (from the maintainers perspective) is > that you set out to do a relatively modest amount of work just where > it was most sorely needed - something that could have been managed > in two months if everyone had stayed focussed on the original > objectives. This was all agreed before the voting and with my 100% > backing. We *ARE* focussed on the original objects, just to cite a bit from: http://happypenguin.org/forums/viewtopic.php?t=1407&postdays=0&postorder=asc&start=0 | 1) Better kart dynamics (skidding, etc). I didn't think I needed that | at the time - but enough people tell me it sucks without it that I | have to agree. Check, they are done, need for sure still lots more of fine tuning and stabilization, however basically work. | 2) Better eye-candy (smoke puffs, skid marks, etc) - these were not | feasible on a Voodoo-1 card. Check, the overall look of the game is improving from day to day. Skidmarks and smoke is however still missing. | 3) Improved collision detection (sometimes a kart will fall through a | hole in the terrain) Nobody, has yet started working on this issue. | 4) More tracks, better 3D models in general...this game was designed | for a graphics card that could draw maybe 1000 polygons at | reasonable frame rates. Modern cards can to a thousand times more | than that. Check, new tracks are comming, new 3d models are there as well. | 5) Better enemy AI (OK - *some* enemy AI!) - at present, the enemy | karts just steer to try to follow a curve laid down through the | approximate center of the track.. Ok, this one got wreaked a bit due to the new physics, but well, you can't keep everything working all the time. | 6) Split-screen Multiplayer maybe? MarioKart is a lot of fun in | multiplayer - so TuxKart would be too. Also in the works. | 7) Stuff like high score tables, option pages, action replay.... That is what the new GUI is supposed to provide. So I really can't see where we are much out of focus. The stuff that hasn't yet been done, simply hasn't been done due to the lack of people and/or time. Your help and knowledge is very welcome, since quite a few of us have little or no knowledge of working with 3d games. > You are dinking unnecessarily with things that are really working > just fine. I strongly disagree. The old GUI was NOT working just fine, it was completly useless for anything more than just jumping directly into the game without any character selection, highscore, game-modes or other elements that are a MUST HAVE for even the simplest game. > The GoTM concept is a good one - but failing to stay focussed on > what was the original scope of the work is what undoubtedly lead to > your failure to complete Pingus Pingus simply failed because half the people involved was still busy with SuperTux work and the other half simply run out of time due to real life issues. Beside that Pingus just was 'too much done', making it hard to find an entry point for new people and well, most work would have been on the content side anyway, which we all know it is hard to find people for. > - and with only a few weeks to run, the same will happen with > TuxKart. So far the progress is quite fine, we have 9 new karts in the work, 6 new tracks, better physics, better GUI, a fixed ac3d exporter, an export script for tracks, an fixed export script for cal3d for animations. Only issues that are still throublesome are AI and collision code. Your help would be very welcome. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: James G. <jam...@bt...> - 2004-08-08 01:33:48
|
On Sun, 2004-08-08 at 00:15, Steve Baker wrote: > Do you maintain any projects of your own? > > I maintain several...and have done so for many years. > > Unless you make things *extremely* simple then any game of any kind of > complexity at all will rapidly result in you getting 20 emails a day > from people who are having problems with it. > > It's bad enough helping people just to get OpenGL running - with > PLIB and Tuxkart. Adding more libraries to the mix (especially SDL > which is the WORST culprit in this regard) just makes things exponentially > harder to maintain. > Unless you've done this, you have no comprehension of how much hassle > it is. > > So - keep things SIMPLE. Definitely there won't be two versions maintained > by me. I never said there would be. Put a link to the Linux Game Tome forums and point people there if they have SDL-related problems, but I really can't see that many will do. > Leaving the GoTM 'version' under CVS is a given - that's what version > control is for. But having two versions for Joe Public to download? No way! I don't understand your irrational hatred for SDL. SDL: - is already installed on the computer of every single Linux user who plays games - is pre-installed on the sort of Linux distros that beginners use - uses package config to alleviate problems with different install locations - has an incredibly stable API - has a huge community of people maintaining it How exactly does this make it the "WORST" library maintenence-wise? I know I'm being incredibly hypocritical in that I said I wouldn't argue when I had no hope of changing people's minds, but, well, nevermind. James |
|
From: James G. <jam...@bt...> - 2004-08-08 01:11:21
|
On Sun, 2004-08-08 at 00:08, Steve Baker wrote: > The whole full screen business is a really trivial matter - if the PLIB > windowing library can't do it then let's make it do it rather than tossing > it out and starting over. However, this isn't something that in any way > stops people from doing what GoTM was supposed to be doing - it just > causes all of the ridiculous SDL hassles - which is now infecting the > joystick interface and who-knows-what else. Saying that fullscreen is "trivial" might be relatively true from a technical point of view, but from a player's point of view it's totally vital. The idea of GOTM is to do whatever is necessary to make a game more polished and playable so that at the end of the period you can say "download this and look at it as a game, not a tech demo of what might be". With TuxKart, lack of fullscreen was a major barrier to this. > The whole problem with GOTM (from the maintainers perspective) is that you > set out to do a relatively modest amount of work just where it was most > sorely needed - something that could have been managed in two months if > everyone had stayed focussed on the original objectives. This was all agreed > before the voting and with my 100% backing. > > What's actually happened is that you've ended up attempting to do virtually > a top to bottom rewrite with all new models, new libraries, new GUI - the whole > works. You are dinking unnecessarily with things that are really working just > fine. > > Frankly, it would have been easier for you to start afresh with a completely > new game...but that would be ridiculous because you KNOW you can't write a > complete new game in two months. "Top to bottom rewrite" is rather an exaggeration. Except tweaking the camera somewhat, none of the OpenGL/PLIB scene graph stuff has been touched, and that's by far the largest part of the game. I've seen people spend months writing simple 3D engines. I don't know whether you're ignoring this fact through modesty or a wish to make your argument seem less weak or what. Switching to SDL only took one evening, and much of that was spent just getting to know the TuxKart code, which I'd not previously seen. Switching the joystick code to SDL took like maybe an hour or something. Adding the new GUI took quite a bit longer than switching to SDL, because the code was taken straight from another game rather than a documented library designed to be used in other places. However, TuxKart /really/ needed a new GUI. Maybe if you're used to making flight simulators a pretty GUI doesn't seem very important, but TuxKart is supposed to be an arcade game, not a flight simulator. Can you imagine a Nintendo game with a GUI like something out of an office application? It totally ruins the experience. The same polishing concept applies to models - it doesn't matter how technically great a game is if the models don't look very impressive. You say that we are "dinking unnecessarily with things that are really working just fine", but that's the entire point. TuxKart already worked just fine, you could download it and play it and it worked. But games are about things not only working, but working nicely - looking pretty, feeling right, etc. We're making it work a bit finer. > The GoTM concept is a good one - but failing to stay focussed on what was > the original scope of the work is what undoubtedly lead to your failure > to complete Pingus - and with only a few weeks to run, the same will > happen with TuxKart. The original scope of the work was to take a game which was already functional and polish it - making lots of smaller changes with players in mind rather than showing off mad coding skillz by trying to add new features. By making changes to the models, GUI etc, that's exactly what we're doing. We haven't touched the underlying engine, or tried to add network play, or anything else as major as that. Also, as far as I can tell Pingus already is largely complete code-wise, it "just" needs more levels and artwork. James |
|
From: Steve B. <sjb...@ai...> - 2004-08-07 23:10:30
|
James Gregory wrote: > Then on the game's download page you could have both TuxKart 0.5 (which > would be TuxKart 0.4 but with the extra tracks etc from GOTM, plus > anything else you might want to keep) and then below that also TuxKart > GOTM 0.1 (which would be from the branch with SDL). > > You can then be as disparaging as you like about the GOTM version on the > page (this has huge amounts of dependencies so don't tell me if it > doesn't compile, all requests for support will be ignored, etc), but at > least then people have the choice. Do you maintain any projects of your own? I maintain several...and have done so for many years. Unless you make things *extremely* simple then any game of any kind of complexity at all will rapidly result in you getting 20 emails a day from people who are having problems with it. It's bad enough helping people just to get OpenGL running - with PLIB and Tuxkart. Adding more libraries to the mix (especially SDL which is the WORST culprit in this regard) just makes things exponentially harder to maintain. Unless you've done this, you have no comprehension of how much hassle it is. So - keep things SIMPLE. Definitely there won't be two versions maintained by me. Leaving the GoTM 'version' under CVS is a given - that's what version control is for. But having two versions for Joe Public to download? No way! ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2004-08-07 23:05:04
|
Ryan Flegel wrote: > On Sat, 07 Aug 2004 13:16:44 -0500, Steve Baker <sjb...@ai...> wrote: > >>It's completely unnecessary to do this switch - and it's a total >>waste of effort - both for you to put it in and for me to take it >>out again. > > I agree, if PLIB can do the job then we should be using PLIB. From > what I understand PLIB's input lib would work fine. Or am I mistaken? Sure it can do the job there are a ton of games and other interactive applications that use PLIB's joystick library. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2004-08-07 23:04:28
|
Charles Goodwin wrote: > I would hope you will be 'replacing' it with PLIB-relevant code rather > than 'removing' it. Depends on how much effort it would take. It might just be easier to dump it and start over. >> The idea of GOTM is to help a project - not to make a complete >> pig's breakfast of it. > > And the idea of GotM is for the maintainer is to play an active role. I've tried to do that - but nobody wants to listen to what I have to say so it's just easier to let you guys bulldoze ahead and then clean up whatever mess is left at the end. > No offense Steve, but since GotM started you have done jack all. That's not true. I added the multi-view stuff and did a ton of code cleanup. Recently, I've not wanted to get involved because I'd be spending all my time undoing what people have screwed up - that would lead to interminable arguments which I really don't have the patience for - so I'd prefer to duck out until the chaos dies down and restore sanity at the end. > There are unacceptable caveats with PLIB - the fullscreen one being > cheif among them (I run 1280x1024, a resolution I do not want to carry > over into the game which my CPU+GPU can barely handle _before_ the > models are enhanced). And you refuse to acknowledge, and hence solve, > them. The whole full screen business is a really trivial matter - if the PLIB windowing library can't do it then let's make it do it rather than tossing it out and starting over. However, this isn't something that in any way stops people from doing what GoTM was supposed to be doing - it just causes all of the ridiculous SDL hassles - which is now infecting the joystick interface and who-knows-what else. The whole problem with GOTM (from the maintainers perspective) is that you set out to do a relatively modest amount of work just where it was most sorely needed - something that could have been managed in two months if everyone had stayed focussed on the original objectives. This was all agreed before the voting and with my 100% backing. What's actually happened is that you've ended up attempting to do virtually a top to bottom rewrite with all new models, new libraries, new GUI - the whole works. You are dinking unnecessarily with things that are really working just fine. Frankly, it would have been easier for you to start afresh with a completely new game...but that would be ridiculous because you KNOW you can't write a complete new game in two months. The GoTM concept is a good one - but failing to stay focussed on what was the original scope of the work is what undoubtedly lead to your failure to complete Pingus - and with only a few weeks to run, the same will happen with TuxKart. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: James G. <jam...@bt...> - 2004-08-07 20:03:37
|
On Sat, 2004-08-07 at 20:53, Ingo Ruhnke wrote: > James Gregory <jam...@bt...> writes: > > > Then on the game's download page you could have both TuxKart 0.5 > > (which would be TuxKart 0.4 but with the extra tracks etc from GOTM, > > plus anything else you might want to keep) and then below that also > > TuxKart GOTM 0.1 (which would be from the branch with SDL). > > Forking into different branches would be a complete waste of time. > Heck, SDL isn't something that changes every few weeks and breaks API, > 1.2 has been pretty solid and widespread, I don't think that will > change in the near future. Maintaining that code should really be a > non-issue. I totally agree, however it's clear from Steve's emails that he simply isn't going to seem the same way as us on this. If other people want to argue with each other over this, that's fine, I know a lot of Linux people get a kick out of arguing over dependencies and libraries and licenses. But it's not going to change anyone's opinion, and as the CVS we're using right now belongs to Steve, arguing over it and not doing anything will basically just result in the version we're working on being wiped out at the end of the month. As far as I can tell, it's either get Steve to agree to a CVS branch, or fork the thing entirely ourselves, or otherwise abandon this GOTM. I am merely trying to make a suggestion somewhere inbetween these two extremes. James |
|
From: Ingo R. <gr...@gm...> - 2004-08-07 19:53:19
|
James Gregory <jam...@bt...> writes: > Then on the game's download page you could have both TuxKart 0.5 > (which would be TuxKart 0.4 but with the extra tracks etc from GOTM, > plus anything else you might want to keep) and then below that also > TuxKart GOTM 0.1 (which would be from the branch with SDL). Forking into different branches would be a complete waste of time. Heck, SDL isn't something that changes every few weeks and breaks API, 1.2 has been pretty solid and widespread, I don't think that will change in the near future. Maintaining that code should really be a non-issue. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Ingo R. <gr...@gm...> - 2004-08-07 19:49:36
|
Ryan Flegel <rf...@gm...> writes: > On Sat, 07 Aug 2004 13:16:44 -0500, Steve Baker <sjb...@ai...> wrote: > >> It's completely unnecessary to do this switch - and it's a total >> waste of effort - both for you to put it in and for me to take it >> out again. > > I agree, if PLIB can do the job then we should be using PLIB. From > what I understand PLIB's input lib would work fine. Or am I mistaken? As James already said, we are already using SDL for other stuff, so using it for the joystick too adds zero dependencies, it just unifies the code a little bit. Its really not that important after all and this discussion is most likly wasting more time than the little plib-js -> SDL-joystick switch took. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Ryan F. <rf...@gm...> - 2004-08-07 18:52:50
|
On Sat, 07 Aug 2004 13:16:44 -0500, Steve Baker <sjb...@ai...> wrote: > It's completely unnecessary to do this switch - and it's a total > waste of effort - both for you to put it in and for me to take it > out again. I agree, if PLIB can do the job then we should be using PLIB. From what I understand PLIB's input lib would work fine. Or am I mistaken? -- Ryan |
|
From: James G. <jam...@bt...> - 2004-08-07 18:34:56
|
On Sat, 2004-08-07 at 19:16, Steve Baker wrote: > James Gregory wrote: > > On Sat, 2004-08-07 at 08:22, Ryan Flegel wrote: > > As I have said before...I WILL NOT MAINTAIN SDL code. > > When you guys eventually leave this project, I'm going to have to > rip out all this SDL stuff...so unless you want to fork the code > base (and remember you'll be maintaining the game *forever* if you > do) - then please don't put SDL stuff in there. > > It's completely unnecessary to do this switch - and it's a total > waste of effort - both for you to put it in and for me to take it > out again. Would it be possible to make a seperate CVS branch for the GOTM version? Then on the game's download page you could have both TuxKart 0.5 (which would be TuxKart 0.4 but with the extra tracks etc from GOTM, plus anything else you might want to keep) and then below that also TuxKart GOTM 0.1 (which would be from the branch with SDL). You can then be as disparaging as you like about the GOTM version on the page (this has huge amounts of dependencies so don't tell me if it doesn't compile, all requests for support will be ignored, etc), but at least then people have the choice. James |
|
From: Charles G. <ch...@ve...> - 2004-08-07 18:32:03
|
Steve Baker wrote: > As I have said before...I WILL NOT MAINTAIN SDL code. > > When you guys eventually leave this project, I'm going to have to > rip out all this SDL stuff...so unless you want to fork the code > base (and remember you'll be maintaining the game *forever* if you > do) - then please don't put SDL stuff in there. > > It's completely unnecessary to do this switch - and it's a total > waste of effort - both for you to put it in and for me to take it > out again. I would hope you will be 'replacing' it with PLIB-relevant code rather than 'removing' it. > The idea of GOTM is to help a project - not to make a complete > pig's breakfast of it. And the idea of GotM is for the maintainer is to play an active role. No offense Steve, but since GotM started you have done jack all. Perhaps if you were actually doing something, then this whole SDL thing wouldn't have happened? You started off so eager, then bemoaned people having ideas that were not 100% fitting with your own, and then "disappeared into the void". If you aren't going to offer direction other than dictating what libs may and may not be used, it's no wonder things are going awry as far as you are concerned. There are unacceptable caveats with PLIB - the fullscreen one being cheif among them (I run 1280x1024, a resolution I do not want to carry over into the game which my CPU+GPU can barely handle _before_ the models are enhanced). And you refuse to acknowledge, and hence solve, them. - Charlie |
|
From: Steve B. <sjb...@ai...> - 2004-08-07 18:12:24
|
James Gregory wrote: > On Sat, 2004-08-07 at 08:22, Ryan Flegel wrote: > >>On Sat, 07 Aug 2004 03:38:41 +0000, >>tux...@li... >><tux...@li...> wrote: >> >>>Update of /cvsroot/tuxkart/tuxkart/src >>>In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7377/src >>> >>>Modified Files: >>> Driver.h joystick.h PlayerDriver.cxx sdldrv.cxx sdldrv.h >>>Log Message: >>>- Changed PLIB joystick stuff to SDL joystick stuff...Steve won't be happy >> >>Is this necessary? If you're moving something away from PLIB their >>should be good reasons, like there was for the GUI. I can't really see >>why there would be any problems with PLIB for input. > > > 1. The GUI was already using SDL for joystick input, as it is event > based (which PLIB doesn't do). Therefore it was already using SDL for > some joystick input, and using two different joystick libraries at the > same time seemed silly. > > 2. All the other input is already handled by SDL, so changing the > joystick to SDL unifies the input code somewhat. > > 3. Changing the joystick input to SDL doesn't add any more dependencies > as the joystick stuff is in the plain base SDL library > > 4. I wanted to add support for multiple joysticks, and though this is > admittedly possible with PLIB, it is easier with SDL. > > 5. The PLIB joystick code relies on you testing for hexadecimal codes, > which isn't very programmer-friendly. The joystick code in the game is > now much more readable. As I have said before...I WILL NOT MAINTAIN SDL code. When you guys eventually leave this project, I'm going to have to rip out all this SDL stuff...so unless you want to fork the code base (and remember you'll be maintaining the game *forever* if you do) - then please don't put SDL stuff in there. It's completely unnecessary to do this switch - and it's a total waste of effort - both for you to put it in and for me to take it out again. The idea of GOTM is to help a project - not to make a complete pig's breakfast of it. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: James G. <jam...@bt...> - 2004-08-07 17:57:55
|
On Sat, 2004-08-07 at 08:22, Ryan Flegel wrote: > On Sat, 07 Aug 2004 03:38:41 +0000, > tux...@li... > <tux...@li...> wrote: > > Update of /cvsroot/tuxkart/tuxkart/src > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7377/src > > > > Modified Files: > > Driver.h joystick.h PlayerDriver.cxx sdldrv.cxx sdldrv.h > > Log Message: > > - Changed PLIB joystick stuff to SDL joystick stuff...Steve won't be happy > > Is this necessary? If you're moving something away from PLIB their > should be good reasons, like there was for the GUI. I can't really see > why there would be any problems with PLIB for input. 1. The GUI was already using SDL for joystick input, as it is event based (which PLIB doesn't do). Therefore it was already using SDL for some joystick input, and using two different joystick libraries at the same time seemed silly. 2. All the other input is already handled by SDL, so changing the joystick to SDL unifies the input code somewhat. 3. Changing the joystick input to SDL doesn't add any more dependencies as the joystick stuff is in the plain base SDL library 4. I wanted to add support for multiple joysticks, and though this is admittedly possible with PLIB, it is easier with SDL. 5. The PLIB joystick code relies on you testing for hexadecimal codes, which isn't very programmer-friendly. The joystick code in the game is now much more readable. James |
|
From: Ingo R. <gr...@gm...> - 2004-08-07 10:26:57
|
James Gregory <jam...@bt...> writes: > I'd like to try and implement split screen multiplayer, if that's OK > with other people? Might be a good idea to make the game restartable from ingame first. Currently once you are on the race track you have no other choice than to quit the game completly and start from scratch if you want to change racetracks and such, which can be rather annoying. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
2 messages has been excluded from this view by a project administrator.
