Thread: [TuxKart-devel] Some notes
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel
|
From: James G. <jam...@bt...> - 2004-08-01 19:25:24
|
1. The new loading code means that the game only works if the exe is run from the game's root directory. I've changed some of the loading stuff to use the Loader class to fix this, but not all of it. 2. In tuxkart.cxx there are lines like "loader -> setCreateStateCallback ( getAppState ) ;", which made sense before but I don't think it does now that "loader" is something entirely different? 3. there's no chance it will compile now as I don't know how to change the autoconf stuff to make it make a makefile that includes my new files. It also now needs to link to SDLimage and SDL_ttf James |
|
From: Steve B. <sjb...@ai...> - 2004-08-01 23:17:19
|
James Gregory wrote: > 3. there's no chance it will compile now as I don't know how to change > the autoconf stuff to make it make a makefile that includes my new > files. It also now needs to link to SDLimage and SDL_ttf Guys I do not want dependancies on anything outside of PLIB. If you add that shit - I'll just take it right out again when GOTM goes away. I don't want the hassle of maintaining it and it flat out isn't necessary. ---------------------------- 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-02 00:57:49
|
On Mon, 2004-08-02 at 01:01, Charles Goodwin wrote: > On Sun, 2004-08-01 at 18:21 -0500, Steve Baker wrote: > > James Gregory wrote: > > > > > 3. there's no chance it will compile now as I don't know how to change > > > the autoconf stuff to make it make a makefile that includes my new > > > files. It also now needs to link to SDLimage and SDL_ttf > > > > Guys I do not want dependancies on anything outside of PLIB. > > > > If you add that shit - I'll just take it right out again when GOTM > > goes away. > > That was a strong word (the s... one). > > Anyway, AFAIK it's all being done with IFDEFS for the moment. If you > can maintain the PLIB side of those IFDEFS then everybody will be happy. > The problem is that PLIB doesn't seem to handle things in the way people > want/expect and asking questions via the mailing list is just an > abysmally slow way to progress when you have lots of questions. > > (Perhaps if you hung out on irc just once or twice?) > > I don't know the specifics other than fullscreen mode that was, erm, > declined more than answered (ie. "go with a borderless window") so it > would be useful if James or somebody could go over the various issues > that SDL is currently being used to solve. > > I'm pretty certain everybody would be happy to use PLIB only if they > knew how to, and that SDL can be considered a stop-gap solution until > the PLIB aspect is put in, but it's currently needed to aid progress. > > At least, that's my take on it. No, it will not longer compile without SDL, whatever IFDEFS you use. Steve, it's your CVS, so take it out if you want. Alternatively, I've got lots of free time right now, so if you want I can download the pre-GOTM version and commit it for you. However, I don't think many people will want to work on it as the GOTM project if we can only use PLIB. Maybe it would be worth doing a GOTM fork? Or maybe not. What do other people think? As for the issues with not using SDL: 1. No fullscreen mode 2. GUI-wise being limited to using what plib provides 3. Being limited in terms of file formats to what plib provides (e.g. no use of png, no use of physfs) 4. Far more people know how to program using SDL and its sister libraries than know how to use plib 5. Everyone who ever compiles games already has SDL, SDL_image etc in any case James |
|
From: Charles G. <ch...@ve...> - 2004-08-02 01:23:16
|
On Mon, 2004-08-02 at 03:00 +0100, James Gregory wrote: > No, it will not longer compile without SDL, whatever IFDEFS you use. > > Steve, it's your CVS, so take it out if you want. Alternatively, I've > got lots of free time right now, so if you want I can download the > pre-GOTM version and commit it for you. > > However, I don't think many people will want to work on it as the GOTM > project if we can only use PLIB. Maybe it would be worth doing a GOTM > fork? Or maybe not. What do other people think? I would really strongly recommend _against_ a GotM fork. Besides the fact that it would mean a new game to maintain (who'll be doing that?) it also completely goes against the spirit of GotM. I'm hoping Steve will let things slide for the moment, and phase out SDL once GotM is over so that TuxKart gets the GotM benefits (lotsa TuxKart goodness) and he only gets a little hassle (the SDL->PLIB issue) for those benefits. > As for the issues with not using SDL: > > 1. No fullscreen mode > 2. GUI-wise being limited to using what plib provides > 3. Being limited in terms of file formats to what plib provides (e.g. no > use of png, no use of physfs) What could you do about these, Steve? I completely understand, and even agree, with the desire to stick with pure PLIB. Is it acceptable to simply (or not so simply) unSDL things later on once GotM has passed and TuxKart has benefited? -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Matze B. <ma...@br...> - 2004-08-02 15:17:18
|
On Mon, 2 Aug 2004, James Gregory wrote: > On Mon, 2004-08-02 at 01:01, Charles Goodwin wrote: > > On Sun, 2004-08-01 at 18:21 -0500, Steve Baker wrote: > > > James Gregory wrote: > > > > > > > 3. there's no chance it will compile now as I don't know how to change > > > > the autoconf stuff to make it make a makefile that includes my new > > > > files. It also now needs to link to SDLimage and SDL_ttf > > > > > > Guys I do not want dependancies on anything outside of PLIB. > > > > > > If you add that shit - I'll just take it right out again when GOTM > > > goes away. > > > > That was a strong word (the s... one). > > > > Anyway, AFAIK it's all being done with IFDEFS for the moment. If you > > can maintain the PLIB side of those IFDEFS then everybody will be happy. > > The problem is that PLIB doesn't seem to handle things in the way people > > want/expect and asking questions via the mailing list is just an > > abysmally slow way to progress when you have lots of questions. > > > > (Perhaps if you hung out on irc just once or twice?) > > > > I don't know the specifics other than fullscreen mode that was, erm, > > declined more than answered (ie. "go with a borderless window") so it > > would be useful if James or somebody could go over the various issues > > that SDL is currently being used to solve. > > > > I'm pretty certain everybody would be happy to use PLIB only if they > > knew how to, and that SDL can be considered a stop-gap solution until > > the PLIB aspect is put in, but it's currently needed to aid progress. > > > > At least, that's my take on it. > > No, it will not longer compile without SDL, whatever IFDEFS you use. > > Steve, it's your CVS, so take it out if you want. Alternatively, I've > got lots of free time right now, so if you want I can download the > pre-GOTM version and commit it for you. > > However, I don't think many people will want to work on it as the GOTM > project if we can only use PLIB. Maybe it would be worth doing a GOTM > fork? Or maybe not. What do other people think? > > As for the issues with not using SDL: Hmm this more like issues when forcing ourself to use plib everywhere as much as possible. It's not really an SDL or not discussion. > > 1. No fullscreen mode > 2. GUI-wise being limited to using what plib provides We can still create a new GUI without SDL. It should be possible to replace the font and image loading code with plib stuff. (However image loading is a bit problematic since plib seems to only support power-of-2 images :-/) > 3. Being limited in terms of file formats to what plib provides (e.g. no > use of png, no use of physfs) Note that physfs has nothing to do with SDL. The thing that is lacking here is the plib loader API which only supports loading from FILE*. physfs support would be nice but really isn't that crucial for the game. > 4. Far more people know how to program using SDL and its sister > libraries than know how to use plib SDL is no replacement for plib. You need plib for scene graph and model-loading stuff, SDL doesn't provide such things. > 5. Everyone who ever compiles games already has SDL, SDL_image etc in > any case Very true, not using existing usefull libraries for the sake of keeping dependencies down doesn't make much sense. As I explained lengthy in the wiki we should concentrate on getting the autoconf stuff right and provide static binaries, so that people will have no trouble with the additional libraries. Greetings, Matze |
|
From: James G. <jam...@bt...> - 2004-08-02 16:20:13
|
On Mon, 2004-08-02 at 16:16, Matze Braun wrote: > > As for the issues with not using SDL: > Hmm this more like issues when forcing ourself to use plib everywhere as > much as possible. It's not really an SDL or not discussion. That's what I meant - by "SDL" I meant "libraries other than plib". > > > > 1. No fullscreen mode > > 2. GUI-wise being limited to using what plib provides > We can still create a new GUI without SDL. It should be possible to > replace the font and image loading code with plib stuff. (However image > loading is a bit problematic since plib seems to only support power-of-2 > images :-/) We could do, but why? As you say at the bottom of this reply: "not using existing usefull libraries for the sake of keeping dependencies down doesn't make much sense" > > 3. Being limited in terms of file formats to what plib provides (e.g. no > > use of png, no use of physfs) > Note that physfs has nothing to do with SDL. > The thing that is lacking > here is the plib loader API which only supports loading from FILE*. physfs > support would be nice but really isn't that crucial for the game. > This is true, this is a minor point - point 1 is most important, then point 2, then this is just one extra minor one on top. > > 4. Far more people know how to program using SDL and its sister > > libraries than know how to use plib > SDL is no replacement for plib. You need plib for scene graph and > model-loading stuff, SDL doesn't provide such things. I know that, this isn't "SDL vs plib", it's "plib only, therefore keeping dependencies down vs plib and SDL, therefore not having to constantly rewrite code that already exists elsewhere". > > 5. Everyone who ever compiles games already has SDL, SDL_image etc in > > any case > > Very true, not using existing usefull libraries for the sake of keeping > dependencies down doesn't make much sense. As I explained lengthy in the > wiki we should concentrate on getting the autoconf stuff right and provide > static binaries, so that people will have no trouble with the additional > libraries. I think that makes sense, but I get a rather clear impression that Steve strongly disagrees - he simply doesn't want TuxKart to use libraries other than plib, fullstop. James |
|
From: Charles G. <ch...@ve...> - 2004-08-01 23:59:53
|
On Sun, 2004-08-01 at 18:21 -0500, Steve Baker wrote: > James Gregory wrote: > > > 3. there's no chance it will compile now as I don't know how to change > > the autoconf stuff to make it make a makefile that includes my new > > files. It also now needs to link to SDLimage and SDL_ttf > > Guys I do not want dependancies on anything outside of PLIB. > > If you add that shit - I'll just take it right out again when GOTM > goes away. That was a strong word (the s... one). Anyway, AFAIK it's all being done with IFDEFS for the moment. If you can maintain the PLIB side of those IFDEFS then everybody will be happy. The problem is that PLIB doesn't seem to handle things in the way people want/expect and asking questions via the mailing list is just an abysmally slow way to progress when you have lots of questions. (Perhaps if you hung out on irc just once or twice?) I don't know the specifics other than fullscreen mode that was, erm, declined more than answered (ie. "go with a borderless window") so it would be useful if James or somebody could go over the various issues that SDL is currently being used to solve. I'm pretty certain everybody would be happy to use PLIB only if they knew how to, and that SDL can be considered a stop-gap solution until the PLIB aspect is put in, but it's currently needed to aid progress. At least, that's my take on it. -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Matze B. <ma...@br...> - 2004-08-02 00:43:52
|
On Sun, 1 Aug 2004, James Gregory wrote: > 1. The new loading code means that the game only works if the exe is run > from the game's root directory. I've changed some of the loading stuff > to use the Loader class to fix this, but not all of it. Huh? I added several searchpaths in start_tuxkart.cxx, so tuxkart should also run from other directories. I'm planing to do add some code that determines the directory of the executable (/proc/self...) so that it is even more smart than just adding . and TUXKART_DATADIR. > > 2. In tuxkart.cxx there are lines like "loader -> > setCreateStateCallback ( getAppState ) ;", which made sense before but > I don't think it does now that "loader" is something entirely different? No, the loader is still a subclass of ssgLoaderOptions, so the plib related stuff is still valid and correct. > > 3. there's no chance it will compile now as I don't know how to change > the autoconf stuff to make it make a makefile that includes my new > files. It also now needs to link to SDLimage and SDL_ttf Are you talking about the GUI code? Greetings, Matze |
|
From: James G. <jam...@bt...> - 2004-08-02 01:02:52
|
On Mon, 2004-08-02 at 01:41, Matze Braun wrote: > On Sun, 1 Aug 2004, James Gregory wrote: > > > 1. The new loading code means that the game only works if the exe is run > > from the game's root directory. I've changed some of the loading stuff > > to use the Loader class to fix this, but not all of it. > Huh? I added several searchpaths in start_tuxkart.cxx, so tuxkart should > also run from other directories. I'm planing to do add some code that > determines the directory of the executable (/proc/self...) so that it is > even more smart than just adding . and TUXKART_DATADIR. It can't find the image files. > > 2. In tuxkart.cxx there are lines like "loader -> > > setCreateStateCallback ( getAppState ) ;", which made sense before but > > I don't think it does now that "loader" is something entirely different? > No, the loader is still a subclass of ssgLoaderOptions, so the plib > related stuff is still valid and correct. Oh, OK, sorry. > > > > 3. there's no chance it will compile now as I don't know how to change > > the autoconf stuff to make it make a makefile that includes my new > > files. It also now needs to link to SDLimage and SDL_ttf > > Are you talking about the GUI code? > Yup, though grumbel changed the make stuff so it will compile now (and has done for some hours)...if you have the right libraries installed. James |
|
From: Ricardo C. <ri...@ae...> - 2004-08-02 09:55:54
|
Let me throw my 2 cents about this SDL issue. Em Segunda, 2 de Agosto de 2004 03:00, o James Gregory escreveu: > As for the issues with not using SDL: > > 1. No fullscreen mode --fullscreen is working fine here. Does it have problems in some systems? About the no possibility of using a size different than screen size, Steve said there shouldn't be any performance decrease. And I haven't noticed any either. > 2. GUI-wise being limited to using what plib provides I believe it is as rich as ClanLib GUI module and other GUI libraries. But even if we decide to do a custom GUI code, can't we use its image and text capabilities? > 3. Being limited in terms of file formats to what plib provides (e.g. no > use of png, no use of physfs) About PNGs, isn't JPEG supported? If yes, should be used. Files are even smaller with it. About physfs, isn't that a physics library? If yes, wasn't it decided that it would be better to make a home made physics. > 4. Far more people know how to program using SDL and its sister > libraries than know how to use plib Well, those people already knew TuxKart used Plib and there was no opposition regarding that. Besides, Plib is pretty small and I guess they already had time to learn, at least, the basics. > 5. Everyone who ever compiles games already has SDL, SDL_image etc in > any case > Why not linking to Allegro, ClanLib - you name it - as well. "Everyone who ever compiles games already" have those. ;D Sorry for anything stupid, Ricardo > James > > -- When a place gets crowded enough to require ID's, social collapse is not far away. It is time to go elsewhere. The best thing about space travel is that it made it possible to go elsewhere. -- R.A. Heinlein, "Time Enough For Love" |
|
From: Ingo R. <gr...@gm...> - 2004-08-02 12:01:39
|
Ricardo Cruz <ri...@ae...> writes: > Em Segunda, 2 de Agosto de 2004 03:00, o James Gregory escreveu: >> As for the issues with not using SDL: >> >> 1. No fullscreen mode > --fullscreen is working fine here. Does it have problems in some systems? > > About the no possibility of using a size different than screen size, Steve > said there shouldn't be any performance decrease. And I haven't noticed any > either. The latest CVS already uses SDL, so fullscreen is working fine there. Without use of SDL all plib-pw could do was open a borderless window at the size of your desktop, which naturally would result in a resolution a lot larger then needed, not something you want for lower end hardware. >> 2. GUI-wise being limited to using what plib provides > I believe it is as rich as ClanLib GUI module and other GUI libraries. ClanLibs GUI is much like plibs GUI something that I would call a 'business-gui', ie. provides all the widgets that you get from a normal gui toolkit, but little to no stuff that you would need for games (animated jumping letters, joystick controll, etc.). Its ok if you do a Transport Tycoon/SimCity type of game and just need a bit theming, but do any good for arcade games. > But even if we decide to do a custom GUI code, can't we use its > image and text capabilities? Neverball-GUI already provides all we need and doesn't depend on anything but SDL_image and SDL_ttf, which should be pretty much widespread since a whole lot of games use them. > About physfs, isn't that a physics library? If yes, wasn't it > decided that it would be better to make a home made physics. ODE was the physic library, physfs is a file loading library that does things like transparently 'mounting' zip files as directories and such. > Well, those people already knew TuxKart used Plib and there was no > opposition regarding that. Besides, Plib is pretty small and I guess > they already had time to learn, at least, the basics. This whole thing isn't about plib vs. SDL, we for sure will still use plib for all the scene-graph stuff and model loading stuff, its just that having support for TTF loading, pngs, jpegs and a real fullscreen mode would be extremly helpfull. >> 5. Everyone who ever compiles games already has SDL, SDL_image etc in >> any case >> > Why not linking to Allegro, ClanLib - you name it - as well. > "Everyone who ever compiles games already" have those. ;D Compared to SDL, Allegro and ClanLib are far less widespread and at least ClanLib also has the tendency to break the API every once in a while, so you not only have to have it installed, but also the right version. Beside that SDL_* does things we need, ClanLib and Allegro don't. Last not least I don't consider dependencies a bad thing, if some library does what you need, then use it. The solution to the dependency problem are binaries (static or with .so's included), no recoding the wheel over and over again just to keep the dependencies low. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Ricardo C. <ri...@ae...> - 2004-08-02 21:55:36
|
Em Segunda, 2 de Agosto de 2004 12:54, o Ingo Ruhnke escreveu: > Ricardo Cruz <ri...@ae...> writes: > > Em Segunda, 2 de Agosto de 2004 03:00, o James Gregory escreveu: > >> As for the issues with not using SDL: > >> > >> 1. No fullscreen mode > > > > --fullscreen is working fine here. Does it have problems in some > > systems? > > > > About the no possibility of using a size different than screen size, > > Steve said there shouldn't be any performance decrease. And I haven't > > noticed any either. > > The latest CVS already uses SDL, so fullscreen is working fine there. > Without use of SDL all plib-pw could do was open a borderless window > at the size of your desktop, which naturally would result in a > resolution a lot larger then needed, not something you want for lower > end hardware. > It really is weird that Plib doesn't support other resolutions than the=20 desktop. Steve, can't this be fixed? > >> 2. GUI-wise being limited to using what plib provides > > > > I believe it is as rich as ClanLib GUI module and other GUI libraries. > > ClanLibs GUI is much like plibs GUI something that I would call a > 'business-gui', ie. provides all the widgets that you get from a > normal gui toolkit, but little to no stuff that you would need for > games (animated jumping letters, joystick controll, etc.). Its ok if > you do a Transport Tycoon/SimCity type of game and just need a bit > theming, but do any good for arcade games. > I know what you mean and I have always agreed to making a home-made menu=20 oriented interface, rather than a scroll bar, push buttons and so on. My point was the one above, that I believe Plib can support simple things = as=20 image and true-type font handling. > > But even if we decide to do a custom GUI code, can't we use its > > image and text capabilities? > > Neverball-GUI already provides all we need and doesn't depend on > anything but SDL_image and SDL_ttf, which should be pretty much > widespread since a whole lot of games use them. > I guess it would be harmless to use SDL and bros. and, in the future, port= it=20 to use Plib stuff. > > About physfs, isn't that a physics library? If yes, wasn't it > > decided that it would be better to make a home made physics. > > ODE was the physic library, physfs is a file loading library that does > things like transparently 'mounting' zip files as directories and > such. > You do have to agree that Physfs sound like Physics. ;) > > Well, those people already knew TuxKart used Plib and there was no > > opposition regarding that. Besides, Plib is pretty small and I guess > > they already had time to learn, at least, the basics. > > This whole thing isn't about plib vs. SDL, we for sure will still use > plib for all the scene-graph stuff and model loading stuff, its just > that having support for TTF loading, pngs, jpegs and a real fullscreen > mode would be extremly helpfull. > My point was that programmers should make an effort to use Plib, but if it= =20 just takes too much time and doesn't do something right. But in the future, I guess it would be nice to fix Plib and make use of it. > >> 5. Everyone who ever compiles games already has SDL, SDL_image etc in > >> any case > > > > Why not linking to Allegro, ClanLib - you name it - as well. > > "Everyone who ever compiles games already" have those. ;D > > Compared to SDL, Allegro and ClanLib are far less widespread and at > least ClanLib also has the tendency to break the API every once in a > while, so you not only have to have it installed, but also the right > version. Beside that SDL_* does things we need, ClanLib and Allegro > don't. > > Last not least I don't consider dependencies a bad thing, if some > library does what you need, then use it. The solution to the > dependency problem are binaries (static or with .so's included), no > recoding the wheel over and over again just to keep the dependencies > low. James enumerated 5 reasons for the use of SDL. My point was just that it i= s=20 stupid to say that it should be used because everyone has it. Anyway, you say dependencies is not a =ABbad thing=BB. You do have to agre= e, that=20 even if it is in a very small degree, it is not really that good.=20 Dependencies mean bigger binaries, might have portability problems and the= =20 ask for more maintenance. Cheers, Ricardo =2D-=20 One evening Mr. Rudolph Block, of New York, found himself seated at dinner alongside Mr. Percival Pollard, the distinguished critic. "Mr. Pollard," said he, "my book, _The Biography of a Dead Cow_, is published anonymously, but you can hardly be ignorant of its authorship. Yet in reviewing it you speak of it as the work of the Idiot of the Centur= y. Do you think that fair criticism?" "I am very sorry, sir," replied the critic, amiably, "but it did not occur to me that you really might not wish the public to know who wrote it." =2D- Ambrose Bierce |
|
From: Pascal G. <pa...@gu...> - 2004-08-03 04:38:58
|
> James enumerated 5 reasons for the use of SDL. My point was just > that it is stupid to say that it should be used because everyone has > it. To some's opinion, SDL just answer various needs in order to improve tuxkart. To Steve's point of view, it's possible to improve tuxkart without SDL since some of those "needs" aren't that important. I can not comment on many issues, but i think it would be nice to be able to play fullscreen in 320x240 [on slow PCs]. > Anyway, you say dependencies is not a «bad thing». You do have to > agree, that even if it is in a very small degree, it is not really > that good. Dependencies mean bigger binaries, might have portability > problems and the ask for more maintenance. Bigger binairies, as long as the binairies are staticly linked. I agree that staticly linked binairies are usually bigger because the libs they depend on have more features than needed. IMHO, the issue here is that Steve believes we can achieve everything we need with Plib. Still, i think SDL isn't a portability issue as libsdl is available in debian for 11 architectures¹. As to either it needs more maintenance or not, it surely needs more. But some suggested (previously on this list) that someone else than Steve would maintain the non-Plib stuff. I might have misunderstood the msg behind: "If you can maintain the PLIB side of those IFDEFS then everybody will be happy.". -Pascal ¹ http://packages.debian.org/stable/libs/libsdl1.2debian or more generally: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libsdl&searchon=names&subword=1&version=all&release=all -- 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: Ricardo C. <ri...@ae...> - 2004-08-03 17:09:18
|
Em Ter=E7a, 3 de Agosto de 2004 05:27, o Pascal Giard escreveu: > > James enumerated 5 reasons for the use of SDL. My point was just > > that it is stupid to say that it should be used because everyone has > > it. > > To some's opinion, SDL just answer various needs in order to improve > tuxkart. To Steve's point of view, it's possible to improve tuxkart witho= ut > SDL since some of those "needs" aren't that important. > > I can not comment on many issues, but i think it would be nice to be able > to play fullscreen in 320x240 [on slow PCs]. > Yes, it is nice and I maybe necessary to have full screen support for=20 different resolutions. But not to make it running in slow PCs, because I don't think you can run= =20 TuxKart with software rendering and a crap cpu (even in a fast one it would= =20 be damn slow). The need for it is for cheap guys like myself that buy the bottom line of= =20 accelerated video cards and use a desktop resolution of 1280x1024. > > Anyway, you say dependencies is not a =ABbad thing=BB. You do have to > > agree, that even if it is in a very small degree, it is not really > > that good. Dependencies mean bigger binaries, might have portability > > problems and the ask for more maintenance. > > Bigger binairies, as long as the binairies are staticly linked. > I agree that staticly linked binairies are usually bigger because the libs > they depend on have more features than needed. > > IMHO, the issue here is that Steve believes we can achieve everything we > need with Plib. > > Still, i think SDL isn't a portability issue as libsdl is available in > debian for 11 architectures=B9. > > As to either it needs more maintenance or not, it surely needs more. > But some suggested (previously on this list) that someone else than Steve > would maintain the non-Plib stuff. I might have misunderstood the msg > behind: "If you can maintain the PLIB side of those IFDEFS then everybody > will be happy.". > First of all, I said it was in a small degree. And no, portability doesn't= =20 only dependend from the library, but from the use one makes of it. Cheers, Ricardo =2D-=20 modem, adj.: Up-to-date, new-fangled, as in "Thoroughly Modem Millie." An unfortunate byproduct of kerning. [That's sic!] |
|
From: Pascal G. <pa...@gu...> - 2004-08-03 21:21:29
|
Hi there guys, in the current CVS state, i was just wondering if tuxkart was suppose to be playable (drivable) ? With both Keyboard and analog joystick (Logitech Wingman RumblePad) it doesn't turn enough and it slides too much... not enough grip ? In fact, it slides on the sides while i've almost no speed... I'd be glad to help and fix the physic code, but so far, i don't get it. With a bit of explanation, i might be able to catch up. (I've a good knowledge of dynamic vector mecanics, but never used that knowledge in a computer environment/ in coding) Is the code entirely based on http://home.planet.nl/~monstrous/tutcar.html ? -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-04 03:53:25
|
On Tue, 2004-08-03 at 22:09, Pascal Giard wrote: > Hi there guys, > in the current CVS state, i was just wondering if tuxkart was suppose to be > playable (drivable) ? > > With both Keyboard and analog joystick (Logitech Wingman RumblePad) it doesn't > turn enough and it slides too much... not enough grip ? > > In fact, it slides on the sides while i've almost no speed... > I'd be glad to help and fix the physic code, but so far, i don't get it. > > With a bit of explanation, i might be able to catch up. > (I've a good knowledge of dynamic vector mecanics, but never used that > knowledge in a computer environment/ in coding) > > Is the code entirely based on http://home.planet.nl/~monstrous/tutcar.html ? Straver is doing the physics, and yes as you say it's unplayable at the moment. Apparently you can adjust the constants in the physics code using the number keys and then + and -, I don't know how much it just needs tweaking and how much the actual code needs changing. James |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X