Thread: [TuxKart-devel] New command line options
Status: Alpha
Brought to you by:
sjbaker
From: Pascal G. <pa...@gu...> - 2004-07-19 05:27:48
|
Hi there guys, i've just commited some changes to the CVS adding the possibility to choose your screen resolution and removing the window borders. [more comments below for those interested]¹ you might want to try choosing your desktop resolution in fullscreen. mine is 1024x768, so in order to play fullscreen: ./tuxkart --screenMode 6 --noBorder again, all the options are listed with --help... but as you might observe, --noBorder isn't there. The reason is simple, i want a full-fledge --fullscreen option but didn't find how to proceed yet. i'd appreciate some cues ;) anyway, that's it for now... -Pascal PS: please try my modifications and send your comments, there're well appreciated! ¹ It was quite easy to change the resolution, i used reshape(x,y). it's pointing on setScreenSize(x,y). At the moment, what annoys me is that the way i do it, either of them need to be called before pwInit because pwInit determines the size of the window. Outside pwInit, I don't know how to change the window size yet... Another thing is that the SplashScreen (InitialScreen) isn't scalable yet. -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) |
From: Steve B. <sjb...@ai...> - 2004-07-19 23:51:00
|
Pascal Giard wrote: > but as you might observe, --noBorder isn't there. The reason is simple, i want > a full-fledge --fullscreen option but didn't find how to proceed yet. > > i'd appreciate some cues ;) The 'pwInit' call is the thing here. void pwInit ( int x, int y, int w, int h, int multisample, char *title, int border, int num_samples ) ; ...setting 'border' to FALSE gets rid of the window decoration, setting 'w' and 'h' to -1 forces them to the full width or height of the screen. Hence you can have full screen windows with or without borders and non-full screen windows with or without borders too. > At the moment, what annoys me is that the way i do it, either of them need to > be called before pwInit because pwInit determines the size of the window. > Outside pwInit, I don't know how to change the window size yet... pwSetSize, pwSetOrigin or pwSetSizeOrigin PW is an extremely simple windowing system - the documentation for it is here: http://plib.sourceforge.net/pw/index.html ---------------------------- 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: Pascal G. <pa...@gu...> - 2004-07-20 07:15:10
|
> setting 'w' and 'h' to -1 forces them to the full width or height > of the screen. Hence you can have full screen windows with or > without borders and non-full screen windows with or without borders too. > > > At the moment, what annoys me is that the way i do it, either of them need to > > be called before pwInit because pwInit determines the size of the window. > > Outside pwInit, I don't know how to change the window size yet... > > pwSetSize, pwSetOrigin or pwSetSizeOrigin > > PW is an extremely simple windowing system - the documentation for > it is here: > > http://plib.sourceforge.net/pw/index.html thank you for the hint. see the CVS for the changes. -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) |
From: Paul B. <pb...@sb...> - 2004-07-20 01:25:04
|
On Monday 19 July 2004 12:18 am, Pascal Giard wrote: > Hi there guys, > i've just commited some changes to the CVS adding the possibility to > choose your screen resolution and removing the window borders. > [more comments below for those interested]=B9 Cut From Wiki: >PascalGiard has added some options to the command line: > > --track n Start at track number n. First track is 0. > --nbrLaps n Define number of laps to n. > --reverse Enable reverse mode. > --mirror Enable mirror mode (when supported). > --screenMode n Set the screen mode to: > 0: 320x240 5: 960x720 > 1: 400x300 6: 1024x768 > 2: 512x384 7: 1152x864 > 3: 640x480 8: 1280x1024 > 4: 800x600 > --noBorder Disable window borders/decoration. > I like the command line options, but I can see the need for another option.= =20 Please consider adding a list command to list out the existing tracks by in= =20 some logical order. Maybe sorted by theme, difficulty?, name, etc... e.g.: tuxkart --list Track# Name Type Difficulty ---+------------------------+--------------------+--------- 0 - Random track [any] [any] 1 - Dry Gulch Desert Easy 2 - Shifting Sands Desert Medium 3 - Arctic Expressway Snow/Ice Medium 4 - Herring Highway Snow/Ice Easy =20 5 - Falling Waters Water Easy 6 - Raging River Water Hard 7 - Sunny Beach Water Medium ... Just a thought. PBoese Tuckart-devel lurker |
From: Pascal G. <pa...@gu...> - 2004-07-20 07:18:54
|
> e.g.: tuxkart --list > Track# Name Type Difficulty > ---+------------------------+--------------------+--------- > 0 - Random track [any] [any] > 1 - Dry Gulch Desert Easy > 2 - Shifting Sands Desert Medium > 3 - Arctic Expressway Snow/Ice Medium > 4 - Herring Highway Snow/Ice Easy > 5 - Falling Waters Water Easy > 6 - Raging River Water Hard > 7 - Sunny Beach Water Medium > ... > > Just a thought. what do you guys think of that ? i could easily add it... -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) |
From: Arnaud Q. <arn...@fr...> - 2004-07-20 17:28:53
|
Pascal Giard wrote: >>e.g.: tuxkart --list >> --listtracks or --list-tracks would avoid possible confusion... >what do you guys think of that ? > > yeh, might be useful to find which number for the desired track to be launched with --track Arnaud |
From: Pascal G. <pa...@gu...> - 2004-07-21 06:25:53
|
> --listtracks or --list-tracks would > avoid possible confusion... i've just commited new modifications: --listTracks made its way thru. '--screenMode n' became '--resolution X Y' where X and Y are your desired width and height. -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) |
From: Pascal G. <pa...@gu...> - 2004-07-20 17:39:25
|
> --listtracks or --list-tracks would > avoid possible confusion... > > >what do you guys think of that ? > > > > > yeh, might be useful to find which > number for the desired track to > be launched with --track the list could be directly included when calling --help unless we fear a big --help output. the thing that concerns more is that a user can definitly change it's tracks later on. We could even, at some point, create packages that contains more tracks. So i don't think it's a good idea to have some hardcoded information. I'd use *trackNames, which is created by parsing data/levels.dat . The limitation of course is that i won't be able to determine a race type and/or difficulty. -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) |
From: Ingo R. <gr...@gm...> - 2004-07-20 18:08:34
|
"Pascal Giard" <pa...@gu...> writes: > the list could be directly included when calling --help unless we > fear a big --help output. '--help' should just give a list of command line options and not clutter up valuable screen space in a terminal with track names or other data (there are after all just 24 lines per default). > the thing that concerns more is that a user can definitly change > it's tracks later on. We could even, at some point, create packages > that contains more tracks. So i don't think it's a good idea to have > some hardcoded information. In the long run tracks should all go into their own directory, so a --track option should just act on the filename or directory name. So currently it should be like: ./tuxkart --track data/geekopeak.loc or even better just: ./tuxkart data/geekopeak.loc Anyway, the whole command line options are mainly meant for debugging to surpass the in-game GUI, so changing them later to something else is really a not an issue. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Ricardo C. <ri...@ae...> - 2004-07-21 10:31:58
|
Em Ter=E7a, 20 de Julho de 2004 19:08, o Ingo Ruhnke escreveu: > "Pascal Giard" <pa...@gu...> writes: > > the list could be directly included when calling --help unless we > > fear a big --help output. > > '--help' should just give a list of command line options and not > clutter up valuable screen space in a terminal with track names or > other data (there are after all just 24 lines per default). > I believe he meant that the list should be shown when passing '--help=20 tracks-list', not just '--help'. Ricardo =2D-=20 Smoking Prohibited. Absolutely no ifs, ands, or butts. |
From: Pascal G. <pa...@gu...> - 2004-07-21 16:13:08
|
> > '--help' should just give a list of command line options and not > > clutter up valuable screen space in a terminal with track names or > > other data (there are after all just 24 lines per default). > > > I believe he meant that the list should be shown when passing '- > -help tracks-list', not just '--help'. With current version in CVS (at least available to developpers), just use "./tuxkart --listTracks". -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) |
From: Charles G. <ch...@ve...> - 2004-07-21 16:30:54
|
On Wed, 2004-07-21 at 12:03 -0400, Pascal Giard wrote: > With current version in CVS (at least available to developpers), just use > "./tuxkart --listTracks". EEEEWWWWWWWWWWWW!!!!! Who uses CapitalLetters in --app-arguments? "./tuxkart --list-tracks" please! -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
From: Pascal G. <pa...@gu...> - 2004-07-25 21:37:30
|
Hi there guys, i'm trying to get to understand more about why tuxkart currently loads tracks this way in order to add support for ~/tuxkart/tracks/{*.{loc,drv,ac},levels.dat} (like listed at http://netpanzer.berlios.de/tuxkart/index.php/Tasks). Firstly, that perhaps only Steve can answer: i'm wondering what is the purpose of the constant MAX_TRACKS ? can't we just look for a \0 or ' ' in levels.dat ? I'm also seeking for ideas in order to cleanly support two tracks directories. I know some ugly ways to implement it, but would definitly appreciate to find/learn-about better solutions. -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: Paul B. <pb...@sb...> - 2004-07-27 02:43:18
|
FWIW Department: I'd like to see levels.dat go away. The Track directories should be dynamically parsed. And even if someone screws up and gives themes and tracks the same name, the parser should not choke, but display all themes/tracks it finds. How it gets displayed in the menus is another matter. Here we just want to populate a structure with all the theme/track information needed by the game engine and UI. There should be NO sharing of textures or models between themes. They should be standalone entities. Any common items like karts, players, herrings and effects are assumed to be elsewhere. Of course it might be nice to have themeable overrides for the herrings and maybe other common elements. (Hmmmmm) Maybe a nice recursive method could be used to populate the theme/track info structures. The names of directory's should not be significant to the parser. In fact the whole hierarchy should be case insensitive. The parser should be indifferent to DOS/UNIX line endings. (I think the current .loc parser tuxkart/plib already handles this) Within each THEME directory there should be ONE .nfo file: There should be a .loc file for each track within a that theme directory. The .drv will also be at this level. Subdirectories for models, textures, and audio exist to organize the common componets of the theme. The parser must be robust should not choke if it does not find any directories or files. Errors for missing items should be sent to stderr or whatever method plib supports for OMG messages are mandatory to make developers lives easier. The track/theme directory hierarchy could go something like this: ( where <...> are directories and [...] are files and # set off comments.) <Players_root> <Theme_root> <Theme_dir_1> [theme.nfo] : Theme Name, Theme Background image?, Theme Music? #PARSE ME for Theme info #Theme info - Maybe the menu system could change the background and #theme music as the player scrolls through the available themes/tracks #Would probably require some code to make the transition between images #and music smooth. Obviously these ideas are currently outside of the #agreed upon enhancements for the current revision. Perhaps in the #future.. [track_a.drv] : Drive file [track_a.loc] : Location file - Track Name, Track Music, Herrings, etc... #PARSE ME for track info [track_b.drv] [track_b.loc] ... <models> : models, animations... [track_a.ac] [track_b.ac] [widget.ac] [widget.bones] ... <textures> [texture.rgb]... <sources> : storage for theme development files... #Possibly not distributed with binary distributions? [something.blend]... [bricks.xcf]... <audio> [blam.wav]... :Theme specific sound files... [rockon.mod]... <Theme_dir_2> ... <Theme_dir_n> Gosh it's late and I've rambled on too long here. Hope someone can make sense of this. Improve it, reprove, dicuss... G'nite. Pb - Tuxkart Lurker Flames invited! On Sunday 25 July 2004 04:27 pm, Pascal Giard wrote: > Hi there guys, > > i'm trying to get to understand more about why tuxkart currently loads > tracks this way in order to add support for > ~/tuxkart/tracks/{*.{loc,drv,ac},levels.dat} (like listed at > http://netpanzer.berlios.de/tuxkart/index.php/Tasks). > > Firstly, that perhaps only Steve can answer: > i'm wondering what is the purpose of the constant MAX_TRACKS ? > can't we just look for a \0 or ' ' in levels.dat ? > > I'm also seeking for ideas in order to cleanly support two tracks > directories. I know some ugly ways to implement it, but would definitly > appreciate to find/learn-about better solutions. > > -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) > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel |
From: Pascal G. <pa...@gu...> - 2004-07-22 04:14:57
|
> EEEEWWWWWWWWWWWW!!!!! > > Who uses CapitalLetters in --app-arguments? > > "./tuxkart --list-tracks" please! fixed! --no-start-screen Quick race. --track n Start at track number n (see --list-tracks). --list-tracks Show available tracks. --laps n Define number of laps to n. --players n Define number of players to either 1, 2 or 4. --reverse Enable reverse mode. --mirror Enable mirror mode (when supported). --fullscreen Fullscreen display. --no-borders Disable window borders/decorations. --screensize WIDTH HEIGHT Set the screen resolution (e.g. 320 200). --version Show version. -Pascal -- Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker) Projet [e]MoviX[2] (http://movix.sf.net) Debian Project (http://www.debian.org) |
From: Arnaud Q. <arn...@fr...> - 2004-07-22 17:36:41
|
an autogen.sh would be useful for cvs usage. The one from plib is fine. I can do it if somebody give me the right (sf user: uzuul) Arnaud --- Debian Developer OpenSource Developer (Network UPS Tools, ...) |
From: Paul B. <pb...@sb...> - 2004-07-23 01:22:02
|
I think there is a script called "reconf" that's already in the root that does the same thing. Pb On Thursday 22 July 2004 12:36 pm, Arnaud Quette wrote: > an autogen.sh would be useful for cvs > usage. The one from plib is fine. > > I can do it if somebody give me the > right (sf user: uzuul) > > Arnaud > --- > Debian Developer > OpenSource Developer (Network UPS Tools, ...) > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel |
From: Matze B. <ma...@br...> - 2004-07-23 10:58:20
|
newer autoconf packages come with the "autoreconf" tool, so autogen.sh should be a thing of the past for 95% of projects... Greetings, Matze On Thu, 22 Jul 2004, Arnaud Quette wrote: > an autogen.sh would be useful for cvs > usage. The one from plib is fine. > > I can do it if somebody give me the > right (sf user: uzuul) > > Arnaud > --- > Debian Developer > OpenSource Developer (Network UPS Tools, ...) > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > > |