tuxkart-devel Mailing List for Tux Kart (Page 3)
Status: Alpha
Brought to you by:
sjbaker
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: Charles B. <cha...@ho...> - 2004-09-08 10:18:34
|
I can provide original loopable background music for all tracks in Ogg format. It'll be more along the classical lines (say, like the music from Diddy Kong Racing). _________________________________________________________________ Talk with your online friends with MSN Messenger http://messenger.msn.nl/ |
From: Ricardo C. <ri...@ae...> - 2004-09-07 10:37:13
|
That was what I was going to point. Anyway, some games (especially strategy ones) have their GUI based on resolution. So, it might not be a bad idea after all. Cheers, Ricardo Em Segunda, 6 de Setembro de 2004 20:37, o tux...@li... escreveu: > Update of /cvsroot/tuxkart/tuxkart/src/gui > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2502/src/gui > > Modified Files: > RaceGUI.cxx > Log Message: > Revert to earlier version, sorry, didn't realise GUI was done of an > orthographic projection differing in size to the screen size > > Index: RaceGUI.cxx > =================================================================== > RCS file: /cvsroot/tuxkart/tuxkart/src/gui/RaceGUI.cxx,v > retrieving revision 1.41 > retrieving revision 1.42 > diff -u -d -r1.41 -r1.42 > --- RaceGUI.cxx 6 Sep 2004 19:20:11 -0000 1.41 > +++ RaceGUI.cxx 6 Sep 2004 19:37:08 -0000 1.42 > @@ -201,9 +201,9 @@ > int h = (int)(glTexture->h * scale_y); > > if(x == SCREEN_CENTERED_TEXT) > - x = (getScreenWidth() - w) / 2; > + x = (640 - w) / 2; > if(y == SCREEN_CENTERED_TEXT) > - y = (getScreenHeight() - h) / 2; > + y = (480 - h) / 2; > > drawTexture(glTexture->texture, w, h, red, green, blue, x, y); > } > @@ -306,8 +306,8 @@ > int tenths = (int) floor ( 10.0f * (time_left - (double)(sec + > 60*min))); > > sprintf ( str, "%3d:%02d\"%d", min, sec, tenths ) ; > - drawDropShadowText ( "Time:", 28, getScreenWidth() - 140, > getScreenHeight() - 50 ) ; - drawDropShadowText ( str, 36, > getScreenWidth() - 180, getScreenHeight() - 80) ; + drawDropShadowText ( > "Time:", 28, 500, 430 ) ; > + drawDropShadowText ( str, 36, 460, 400) ; > } > > void RaceGUI::drawScore (const RaceSetup& raceSetup, int player_nb, int > offset_x, int offset_y, float ratio_x, float ratio_y) @@ -323,7 +323,7 @@ > else > > sprintf(str,"%3dmph",(int)(player_kart->getVelocity()->xyz[1]/MILES_PER_HOU >R)); > > - drawDropShadowText ( str, (int)(18*ratio_y), > (int)((getScreenWidth()-((strlen(str)-1)*18))*ratio_x)+offset_x, offset_y ) > ; + drawDropShadowText ( str, (int)(18*ratio_y), > (int)((640-((strlen(str)-1)*18))*ratio_x)+offset_x, offset_y ) ; #endif > > /* Show lap number */ > @@ -344,7 +344,7 @@ > pos_string [ player_kart->getPosition() ] ) ; > } > > - drawDropShadowText ( str, (int)(38*ratio_y), (int)(10*ratio_x)+offset_x, > (int)((getScreenHeight() - 58)*ratio_y)+offset_y ) ; + drawDropShadowText > ( str, (int)(38*ratio_y), (int)(10*ratio_x)+offset_x, > (int)(422*ratio_y)+offset_y ) ; > > /* Show player's position */ > sprintf ( str, "%s", pos_string [ player_kart->getPosition() ] ) ; > @@ -356,7 +356,7 @@ > void RaceGUI::drawMap () > { > glColor3f ( 1,1,1 ) ; > - World::current() ->track -> draw2Dview ( getScreenWidth() - 120, 40, > 120, 120, false ) ; + World::current() ->track -> draw2Dview ( 520, 40, > 120, 120, false ) ; > > glBegin ( GL_QUADS ) ; > > @@ -515,9 +515,9 @@ > case COLLECT_ZIPPER : zipper_gst -> apply () ; > zz = TRUE ; break ; > } > - > - int x1 = (int)((getScreenWidth() / 2 - 32) * ratio_x) + offset_x ; > - int y1 = (int)((getScreenHeight() - 80) * ratio_y) + offset_y; > + > + int x1 = (int)((320-32) * ratio_x) + offset_x ; > + int y1 = (int)(400 * ratio_y) + offset_y; > > glDisable(GL_TEXTURE_2D); > > @@ -580,8 +580,8 @@ > > void RaceGUI::drawEnergyMeter ( float state, int offset_x, int offset_y, > float ratio_x, float ratio_y ) { > - int x = (int)((getScreenWidth() - 50) * ratio_x) + offset_x; > - int y = (int)((getScreenHeight() - 350) * ratio_y) + offset_y; > + int x = (int)(590 * ratio_x) + offset_x; > + int y = (int)(130 * ratio_y) + offset_y; > int w = (int)(24 * ratio_x); > int h = (int)(220 * ratio_y); > int wl = (int)(1 * ratio_x); > @@ -657,7 +657,7 @@ > glAlphaFunc ( GL_GREATER, 0.1 ) ; > glEnable ( GL_BLEND ) ; > > - glOrtho ( 0, getScreenWidth(), 0, getScreenHeight(), 0, 100 ) ; > + glOrtho ( 0, 640, 0, 480, 0, 100 ) ; > > switch (World::current()->ready_set_go) > { > > > > ------------------------------------------------------- > 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=5047&alloc_id=10808&op=click > _______________________________________________ > Tuxkart-cvs mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-cvs -- Always think of something new; this helps you forget your last rotten idea. -- Seth Frankel |
From: Pascal G. <pa...@gu...> - 2004-09-06 17:31:52
|
As of current CVS version, the framerate as been greatly improved! On the beach and smoother than ever and impresses me... i guess not all tracks are broke into segments like that one ? i still wonder how come i get 2 to 4 fps in "little vulcano". the other hardly playable track is subsea with 10 to 20fps. -Pascal PS: am i the only one who often gets segfaults ? -- 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. <j....@vi...> - 2004-09-06 15:07:22
|
Hey Mazte, I know you're currently working on the physics, I was just wondering, have you tried pressing the jump key recently? James |
From: Ricardo C. <ri...@ae...> - 2004-09-06 14:50:59
|
Nope. Why? Does it support TTF fonts? The reason why I used SDL_ttf was because I was pointed to and there were already functions available to convert them into a texture. Cheers, Ricardo Em Segunda, 6 de Setembro de 2004 14:28, o Matze Braun escreveu: > Aehm did you actually take a look at what plibfnt does? > > Greetings, > Matze > > On Mon, 6 Sep 2004, Ricardo Cruz wrote: > > Em Domingo, 5 de Setembro de 2004 22:45, o Steve Baker escreveu: > > > Ricardo Cruz wrote: > > > > Oh, creating a texture for every character... > > > > > > Texture map switching would kill you. > > > > > > > But why not just using a pixmap > > > > format then (rather than the vectorial one - TTF)? > > > > > > ...or you could put all the letters into one font texture... > > > > That's what I meant about a pixmap image. > > > > > Oh - wait! That's how the game was originally written before > > > everyone who thought they knew better came along! > > > > I was the one that implemented the TTF support. I don't really like > > games using TTF for various reasons from speed performance to ugliness to > > the fact that it's hard (or impossible) to add a missing(s) character(s). > > By the way, its funny that even console developers use pixmaps rather > > than vectorial graphics because they know how cpu expensive they can be, > > but most games still keep using TTF. > > > > But fact was that everybody seemed to agree that TTF usage was the way > > to go and someone would do it anyway. Since I've already done some work > > on the RaceGUI code, I stepped forward. > > Anyway, it is still time to revert this. If any pixmap (whataver the > > format Plib likes the most) is purposed, just send it to me and I'll > > revert things to use that. > > > > Cheers, > > Ricardo > > -- What did Mickey Mouse get for Christmas? A Dan Quayle watch. -- heard from a Mike Dukakis field worker |
From: James G. <j....@vi...> - 2004-09-06 14:29:34
|
On Mon, 2004-09-06 at 12:31, Ricardo Cruz wrote: > But fact was that everybody seemed to agree that TTF usage was the way to go > and someone would do it anyway. Since I've already done some work on the > RaceGUI code, I stepped forward. > Anyway, it is still time to revert this. If any pixmap (whataver the format > Plib likes the most) is purposed, just send it to me and I'll revert things > to use that. > The general consensus seems to be that reverting to plib for the in game text would be a good idea, so yes, it would be good if you could do that. James |
From: Ingo R. <gr...@gm...> - 2004-09-06 14:22:57
|
Ricardo Cruz <ri...@ae...> writes: > Please, stop counter arguing the use of more dependencies. Even if > it is better for the user, Steve, the maintainer, already stated > that he have already experienced with that and it is a pain in the > ass to maintain. So, back off and stop bitching about this. If Steve doesn't want his mailbox filled with support mails there are some simple countermessures: - remove/hide his email address from Tuxkart game itself and place instead tuxkart-users/de...@li... in some good visible place, state that all mails should go there and let the users help themself - create a static linked binary, this is basically the 'support-free' solution, if it 'just works' people won't have a reason to complain - create a good configure script that states what exactly is missing and how to get it Removing the dependencies itself and creating so a whole lot of completly unnecessary work is by far the worst solution. Beside that, as far as I see it plib is actually the part of the depency tree that is the most 'non-standard', the SDL stuff has been used by hundreds of other games without problem. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Matze B. <ma...@br...> - 2004-09-06 13:28:17
|
Aehm did you actually take a look at what plibfnt does? Greetings, Matze On Mon, 6 Sep 2004, Ricardo Cruz wrote: > Em Domingo, 5 de Setembro de 2004 22:45, o Steve Baker escreveu: > > Ricardo Cruz wrote: > > > Oh, creating a texture for every character... > > > > Texture map switching would kill you. > > > > > But why not just using a pixmap > > > format then (rather than the vectorial one - TTF)? > > > > ...or you could put all the letters into one font texture... > > > That's what I meant about a pixmap image. > > > Oh - wait! That's how the game was originally written before > > everyone who thought they knew better came along! > > > > I was the one that implemented the TTF support. I don't really like games > using TTF for various reasons from speed performance to ugliness to the fact > that it's hard (or impossible) to add a missing(s) character(s). > By the way, its funny that even console developers use pixmaps rather than > vectorial graphics because they know how cpu expensive they can be, but most > games still keep using TTF. > > But fact was that everybody seemed to agree that TTF usage was the way to go > and someone would do it anyway. Since I've already done some work on the > RaceGUI code, I stepped forward. > Anyway, it is still time to revert this. If any pixmap (whataver the format > Plib likes the most) is purposed, just send it to me and I'll revert things > to use that. > > Cheers, > Ricardo > > -- > Q: What does friendship among Soviet nationalities mean? > A: It means that the Armenians take the Russians by the hand; the > Russians take the Ukrainians by the hand; the Ukranians take > the Uzbeks by the hand; and they all go and beat up the Jews. > > > ------------------------------------------------------- > 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=5047&alloc_id=10808&op=click > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > > |
From: Ricardo C. <ri...@ae...> - 2004-09-06 11:44:38
|
Em Segunda, 6 de Setembro de 2004 01:40, o James Gregory escreveu: > On Sun, 2004-09-05 at 23:32, Jason T. Rice wrote: > > So go ahead and flame him. The single font texture is THE definitive > > way it is done. Texture switching WILL kill you on an OpenGL or DirectX > > system. If you don't know what it means, Google for "Texture Switching" > > and I'll bet the experts point to some obscure 10 year old web page of > > Steve's. That is the reason that every commercial game you pick up has > > budgetted character textures into compact atlases and you never see a > > character, feature, deco or terrain piece jump across multiple > > textures. EVERY pro title uses a single texture font system to avoid it. > > As I said already, the use of ttf for in game text was a matter of what > was easiest, not what is best. At some point I'll experiment to see how > many FPS using ttf loses us. If it's more than maybe 5 fps or something, > then I might change it back to using a bitmap font. If it's less than > perhaps 5 fps, then the question is: another evening of coding or just > leave it for now to focus on other more important things? > Okay, made a simple test where I've enabled and disabled text drawing. The difference is huge in terms of performance, more than 20 fps, in my system. It might be possible to see with some tool where it spends more time, if the rendering, converting of SDL_Surface to textures or the drawing of textures. The use of a pixmap would decrease the frame rate needed, since it'd just take the time of drawing it to screen. Cheers, Ricardo -- The error of youth is to believe that intelligence is a substitute for experience, while the error of age is to believe experience is a substitute for intelligence. -- Lyman Bryson |
From: Ricardo C. <ri...@ae...> - 2004-09-06 11:21:35
|
Please, stop counter arguing the use of more dependencies. Even if it is better for the user, Steve, the maintainer, already stated that he have already experienced with that and it is a pain in the ass to maintain. So, back off and stop bitching about this. Steve, the fact that Plib doesn't support some stuff (even major like fullscreen) and even that some developers are more used to SDL and it speed ups their development, I think its reason enough for linking to this library. I just hope after the upcoming release, programmers will help porting the code to Plib, and implement in Plib what's missing. Cheers, Ricardo Em Segunda, 6 de Setembro de 2004 00:05, o Ingo Ruhnke escreveu: > "Jason T. Rice" <jt...@gt...> writes: > > Mail me when these guys go home. I code, model and do sound effects > > -- and hate sprawling dependency lists. > > Sorry, but the libraries that we use are the same that are used by > pretty much every second other OSS game too, so I really can't see how > that should ever be much of a problem. > -- Rudin's Law: If there is a wrong way to do something, most people will do it every time. Rudin's Second Law: In a crisis that forces a choice to be made among alternative courses of action, people tend to choose the worst possible course. |
From: Ricardo C. <ri...@ae...> - 2004-09-06 11:21:33
|
Em Domingo, 5 de Setembro de 2004 22:45, o Steve Baker escreveu: > Ricardo Cruz wrote: > > Oh, creating a texture for every character... > > Texture map switching would kill you. > > > But why not just using a pixmap > > format then (rather than the vectorial one - TTF)? > > ...or you could put all the letters into one font texture... > That's what I meant about a pixmap image. > Oh - wait! That's how the game was originally written before > everyone who thought they knew better came along! > I was the one that implemented the TTF support. I don't really like games using TTF for various reasons from speed performance to ugliness to the fact that it's hard (or impossible) to add a missing(s) character(s). By the way, its funny that even console developers use pixmaps rather than vectorial graphics because they know how cpu expensive they can be, but most games still keep using TTF. But fact was that everybody seemed to agree that TTF usage was the way to go and someone would do it anyway. Since I've already done some work on the RaceGUI code, I stepped forward. Anyway, it is still time to revert this. If any pixmap (whataver the format Plib likes the most) is purposed, just send it to me and I'll revert things to use that. Cheers, Ricardo -- Q: What does friendship among Soviet nationalities mean? A: It means that the Armenians take the Russians by the hand; the Russians take the Ukrainians by the hand; the Ukranians take the Uzbeks by the hand; and they all go and beat up the Jews. |
From: Matze B. <ma...@br...> - 2004-09-06 11:04:44
|
On Sun, 5 Sep 2004, Steve Baker wrote: > ... > > I wasn't enthusiastic about expanding the scope of the GOTM effort to encompass > a drastically re-engineered GUI - and I think (given the extension of the project > beyond the originally estimated 2 months) that I was correct. However, *had* I > been interested in doing that, PUI could have done the job perfectly well without > introducing more dependancies. Apart from all this other stupid stuff in this thread, here is the real problem! Steve: You didn't even accept the idea of changing the GUI. GoTM is not about getting some idiots who blindly implement your visions of a game, they have game-design ideas themselfes! Don't we have a right to discuss this a bit, since we planed to actually spend lots of our free time helping with the project? I'm really sad about the current state as I respect you as a great (opengl-) coder and the man who put LOTS of his time into plib and tuxkart. Greetings, Matze |
From: James G. <j....@vi...> - 2004-09-06 01:40:53
|
On Mon, 2004-09-06 at 02:02, Steve Baker wrote: > James Gregory wrote: > > > Because you've brought it up again, I'll put the case forward again. No > > dependencies are better than dependencies, sure. But given the choice > > between a crap GUI and no fullscreen mode, or a nice GUI and fullscreen > > mode but with dependencies, or a nice GUI and fullscreen mode and no > > dependencies but a couple of months of extra coding, which is best? > > There is NO indication that you can't have a decent GUI with the PUI toolkit > that TuxKart was originally using. It depends if by "decent" you mean "functional" or "looks like a computer game rather than a multi-coloured office application". > I explained that fullscreen mode should > be obtainable with PW - but if it couldn't we could modify it to do so (since > I also run the PLIB project - this should be easy). You never seemed like you were going to do anything about it. When SDL was originally put in it was guarded by #ifdefs, giving you a chance to say "OK, I'll sort out fullscreen with pw if you remove SDL". Instead you just responded with a flame. Our response was to say "Well, if you're going to be like that" and give up on trying to find a middle ground. > > I wasn't enthusiastic about expanding the scope of the GOTM effort to encompass > a drastically re-engineered GUI - and I think (given the extension of the project > beyond the originally estimated 2 months) that I was correct. Most of the basic GUI code was converted from Neverball to TuxKart in one evening, with maybe another evening's worth of my time spent improving it further. Where myself or other people have used the gui to write e.g. character select screens, it has been no more effort than if these screens were built using plib. So the only person who has put any sizeable amount of time into rewriting the GUI of tuxkart when using plib could have freed their time for other things is me. However, as I have freely admitted on multiple occasions, I don't know very much about OpenGL, and so it's not like I would have fixed e.g. the falling-through-the-track bug instead. The main obstacle to a release in the immediate future remains the 3D engine, yet this isn't something I could have done anything about. You could have, but you decided you'd rather see GOTM fail (which isn't going to happen, but it is delaying it hugely and it is going to mean it won't be as good as it could have been). You are being totally irrational in arguing that the reason for this GOTM going on so long is because I spent a couple of evenings switching over from plib for the gui. The real thing behind all of this is that you wrote PLIB and you'd like to see as many games as possible based on it. You are outraged that a version of a game that you originally did most of the work for now uses rival libraries instead. I guess in a world where people are motivated by the credit they gain (i.e. OSS), this sort of thing isn't surprising (RMS does it plenty too), but I still think it's stupid. > However, *had* I > been interested in doing that, PUI could have done the job perfectly well without > introducing more dependancies. Again, your definition of "perfectly well" is not shared by everyone. > > > As I said already, the use of ttf for in game text was a matter of what > > was easiest, not what is best. > > What would have been easiest would have been to use PLIB's font library and not > getting into having to cache fonts and all that nonsense. James |
From: Steve B. <sjb...@ai...> - 2004-09-06 01:03:31
|
James Gregory wrote: > Because you've brought it up again, I'll put the case forward again. No > dependencies are better than dependencies, sure. But given the choice > between a crap GUI and no fullscreen mode, or a nice GUI and fullscreen > mode but with dependencies, or a nice GUI and fullscreen mode and no > dependencies but a couple of months of extra coding, which is best? There is NO indication that you can't have a decent GUI with the PUI toolkit that TuxKart was originally using. I explained that fullscreen mode should be obtainable with PW - but if it couldn't we could modify it to do so (since I also run the PLIB project - this should be easy). I wasn't enthusiastic about expanding the scope of the GOTM effort to encompass a drastically re-engineered GUI - and I think (given the extension of the project beyond the originally estimated 2 months) that I was correct. However, *had* I been interested in doing that, PUI could have done the job perfectly well without introducing more dependancies. > As I said already, the use of ttf for in game text was a matter of what > was easiest, not what is best. What would have been easiest would have been to use PLIB's font library and not getting into having to cache fonts and all that nonsense. ---------------------------- 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. <j....@vi...> - 2004-09-05 23:42:27
|
On Sun, 2004-09-05 at 23:54, Steve Baker wrote: > James Gregory wrote: > > > > The in-game text in the old TuxKart was heavily pixellated and very > > ugly. > > Which is because it had to work on a typical card of that era - a > Voodoo-1 or -2 which had a hard limit of 256x256 as the largest > possible map. Sure, I never said "Oh Steve you idiot why on earth did you include such crap fonts??!?!", I simply pointed out why it had been changed. > Given the ability to use a 1kx1k for the fonts, that problem would > magically disappear. > > Given that SDL_ttf was already being used for the menu screens, by > > far the easiest way to fix this problem by just switching the text > > drawing calls to use SDL_ttf, rather than using one thing for menu > > screens and another for in-game status text. > > Well - don't spend too much time on it - SDL is the first thing I'll > be removing when you guys finish messing around. We know already. James |
From: James G. <j....@vi...> - 2004-09-05 23:40:51
|
On Sun, 2004-09-05 at 23:32, Jason T. Rice wrote: > Pardon me - I signed on early because the project seemed interesting, > but the minute you guys blew off the originator, a guy whose name shows > up at the end of 70% of the "OpenGL How To" searches on the Flightgear > lists, the Gimp lists and the OpenGL forums, I knew I'd be wasting my time. We didn't "blow him off", we just fundamentally disagreed about whether or not adding dependencies was acceptable. Despite this intractable disagreement we hoped that maybe Steve would be happy to work on the 3D stuff, which we all accept he knows far better than we do, and which is totally seperate from dependency issues. He said he didn't want to, which is his choice, and I don't hold any sort of grudge about this. But we certainly never said "we don't want you", or "we think we know better than you about 3D graphics". Quite the opposite, we have said "Steve, we don't know much about 3D graphics but you do, could you please help us?". But I just don't see how OpenGL expertise in any way makes you a better judge of whether or not adding dependencies is a good idea. Because you've brought it up again, I'll put the case forward again. No dependencies are better than dependencies, sure. But given the choice between a crap GUI and no fullscreen mode, or a nice GUI and fullscreen mode but with dependencies, or a nice GUI and fullscreen mode and no dependencies but a couple of months of extra coding, which is best? There is no right answer, but having a CV with lots of OpenGL stuff on it doesn't make your answer any more correct. > So go ahead and flame him. The single font texture is THE definitive > way it is done. Texture switching WILL kill you on an OpenGL or DirectX > system. If you don't know what it means, Google for "Texture Switching" > and I'll bet the experts point to some obscure 10 year old web page of > Steve's. That is the reason that every commercial game you pick up has > budgetted character textures into compact atlases and you never see a > character, feature, deco or terrain piece jump across multiple > textures. EVERY pro title uses a single texture font system to avoid it. As I said already, the use of ttf for in game text was a matter of what was easiest, not what is best. At some point I'll experiment to see how many FPS using ttf loses us. If it's more than maybe 5 fps or something, then I might change it back to using a bitmap font. If it's less than perhaps 5 fps, then the question is: another evening of coding or just leave it for now to focus on other more important things? > ... and to answer your question, 2 full titles on N64 - a pure OpenGL box. How does this make opinions on dependencies more valid? James |
From: Ingo R. <gr...@gm...> - 2004-09-05 23:05:53
|
"Jason T. Rice" <jt...@gt...> writes: > Pardon me - I signed on early because the project seemed > interesting, but the minute you guys blew off the originator, a guy > whose name shows up at the end of 70% of the "OpenGL How To" > searches on the Flightgear lists, the Gimp lists and the OpenGL > forums, I knew I'd be wasting my time. We DID NOT 'blew him off', he just went away all by himself for no good reason. > So go ahead and flame him. We didn't start the flaming, he started complaining about every change we did without giving us a useable other way to do it. If all people agree that the old GUI needed a complete rewrite since it was basically unusable and Steve tells you that we MUST stick to current PUI, that really wasn't all that helpfull. Same with fullscreen, plib simply can't do that at the moment. With VBO Steve told us that it "wouldn't much help", well it doubled the performance. Now if Steve just started fixing issues instead of telling us that we don't need that would have been a whole lot more helpfull. > The single font texture is THE definitive way it is done. Yes. > Mail me when these guys go home. I code, model and do sound effects > -- and hate sprawling dependency lists. Sorry, but the libraries that we use are the same that are used by pretty much every second other OSS game too, so I really can't see how that should ever be much of a problem. > Mail me when these guys go home. I code, model and do sound effects > -- and hate sprawling dependency lists. How about instead helping us RIGHT NOW and making this GOTM run a success instead of just complaining and slowing all this down even more with more and more endless flaming? We need help and are happy about everything we can get. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Steve B. <sjb...@ai...> - 2004-09-05 22:54:55
|
James Gregory wrote: > > The in-game text in the old TuxKart was heavily pixellated and very > ugly. Which is because it had to work on a typical card of that era - a Voodoo-1 or -2 which had a hard limit of 256x256 as the largest possible map. Given the ability to use a 1kx1k for the fonts, that problem would magically disappear. > Given that SDL_ttf was already being used for the menu screens, by > far the easiest way to fix this problem by just switching the text > drawing calls to use SDL_ttf, rather than using one thing for menu > screens and another for in-game status text. Well - don't spend too much time on it - SDL is the first thing I'll be removing when you guys finish messing around. ---------------------------- 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-09-05 22:52:16
|
Ricardo Cruz <ri...@ae...> writes: > It is also good to know that textures can help - haven't remember of those -, > but ugly stuff like those heads made of squares will not be helped: > http://rpmcruz.planetaclix.pt/trash/tuxkart-dinoface.png Thats just ugly because smooth shading is missing, with the flat shading it looks of course rather blocky. Anyway, polygon count really doesn't matter all that much, just look at a doom3 model: http://static.hugi.is/games/doom3/screens/doom3page3.jpg They are extremly edgy too, but due to some kickass bump-mapping and shading that doesn't really matter at all. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Jason T. R. <jt...@gt...> - 2004-09-05 22:24:07
|
Pardon me - I signed on early because the project seemed interesting, but the minute you guys blew off the originator, a guy whose name shows up at the end of 70% of the "OpenGL How To" searches on the Flightgear lists, the Gimp lists and the OpenGL forums, I knew I'd be wasting my time. So go ahead and flame him. The single font texture is THE definitive way it is done. Texture switching WILL kill you on an OpenGL or DirectX system. If you don't know what it means, Google for "Texture Switching" and I'll bet the experts point to some obscure 10 year old web page of Steve's. That is the reason that every commercial game you pick up has budgetted character textures into compact atlases and you never see a character, feature, deco or terrain piece jump across multiple textures. EVERY pro title uses a single texture font system to avoid it. ... and to answer your question, 2 full titles on N64 - a pure OpenGL box. Steve, Mail me when these guys go home. I code, model and do sound effects -- and hate sprawling dependency lists. JR James Gregory wrote: >On Sun, 2004-09-05 at 22:45, Steve Baker wrote: > > >>Ricardo Cruz wrote: >> >> >>> Oh, creating a texture for every character... >>> >>> >>Texture map switching would kill you. >> >> > >I must admit I don't actually know what that means. Though as I've >already said I was only talking about individual textures for numbers, >not letters, to begin with. As I said in more recent email it now looks >as though I'm not even going to do that. > > > >>>But why not just using a pixmap >>>format then (rather than the vectorial one - TTF)? >>> >>> >>...or you could put all the letters into one font texture... >> >>Oh - wait! That's how the game was originally written before >>everyone who thought they knew better came along! >> >> > >The general consensus, even if you don't agree, was that the old gui >sucked and needed replacing. Rather than write a whole new GUI from >scratch code was instead taken from Neverball, which was known to work >well and meet our needs. The Neverball GUI uses SDL_ttf, which was never >an issue in Neverball because it doesn't have much mid-game text, it >mostly gets used just for menu screens. > >The in-game text in the old TuxKart was heavily pixellated and very >ugly. Given that SDL_ttf was already being used for the menu screens, by >far the easiest way to fix this problem by just switching the text >drawing calls to use SDL_ttf, rather than using one thing for menu >screens and another for in-game status text. > >Also, as much as you'd like this GOTM to end up not working due to >dependency issues/SDL issues, it's not happening. The in game text can >be sorted out in a couple of hours. By far the biggest problem continues >to be the speed of the 3D engine. I don't know much about 3D engines, >and so I don't want to blame anyone or anything in particular for this, >but what I do know is that it's not the fault of SDL or SDL_ttf. > > James > > > >------------------------------------------------------- >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=5047&alloc_id=10808&op=click >_______________________________________________ >Tuxkart-devel mailing list >Tux...@li... >https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > > > |
From: James G. <j....@vi...> - 2004-09-05 22:00:14
|
On Sun, 2004-09-05 at 22:45, Steve Baker wrote: > Ricardo Cruz wrote: > > Oh, creating a texture for every character... > > Texture map switching would kill you. I must admit I don't actually know what that means. Though as I've already said I was only talking about individual textures for numbers, not letters, to begin with. As I said in more recent email it now looks as though I'm not even going to do that. > > But why not just using a pixmap > > format then (rather than the vectorial one - TTF)? > > ...or you could put all the letters into one font texture... > > Oh - wait! That's how the game was originally written before > everyone who thought they knew better came along! The general consensus, even if you don't agree, was that the old gui sucked and needed replacing. Rather than write a whole new GUI from scratch code was instead taken from Neverball, which was known to work well and meet our needs. The Neverball GUI uses SDL_ttf, which was never an issue in Neverball because it doesn't have much mid-game text, it mostly gets used just for menu screens. The in-game text in the old TuxKart was heavily pixellated and very ugly. Given that SDL_ttf was already being used for the menu screens, by far the easiest way to fix this problem by just switching the text drawing calls to use SDL_ttf, rather than using one thing for menu screens and another for in-game status text. Also, as much as you'd like this GOTM to end up not working due to dependency issues/SDL issues, it's not happening. The in game text can be sorted out in a couple of hours. By far the biggest problem continues to be the speed of the 3D engine. I don't know much about 3D engines, and so I don't want to blame anyone or anything in particular for this, but what I do know is that it's not the fault of SDL or SDL_ttf. James |
From: James G. <j....@vi...> - 2004-09-05 21:48:26
|
On Sun, 2004-09-05 at 22:49, Ricardo Cruz wrote: > Oh, creating a texture for every character... But why not just using a pixmap > format then (rather than the vectorial one - TTF)? > I was only suggesting to create a texture for every number plus a colon, not every character. Still, this is a lot of hassle, and MazteB reckons that a more simple caching system that checks if a piece of text has changed since the last frame, and if it has simply re-renders the whole thing, would be good enough. James |
From: Steve B. <sjb...@ai...> - 2004-09-05 21:45:54
|
Ricardo Cruz wrote: > Oh, creating a texture for every character... Texture map switching would kill you. > But why not just using a pixmap > format then (rather than the vectorial one - TTF)? ...or you could put all the letters into one font texture... Oh - wait! That's how the game was originally written before everyone who thought they knew better came along! ---------------------------- 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: Ricardo C. <ri...@ae...> - 2004-09-05 21:40:15
|
Oh, creating a texture for every character... But why not just using a pixmap format then (rather than the vectorial one - TTF)? Ricardo Em Domingo, 5 de Setembro de 2004 23:05, o James Gregory escreveu: > On Sun, 2004-09-05 at 22:00, Ricardo Cruz wrote: > > About the cache of textures, that is not practicable, since text is > > different all the time. You'd need tons of memory to cache all different > > combinations of texts. > > What I currently do is to cache TTF_Font, which already helps speeding > > it up. Though, I dunno if TTF_OpenFont() is all that expensive. > > It is possible to cache text textures. For numbers you have to do it in > parts - rather than having "9", "99" and "999", you just cache textures > for the numbers 0-9 for each font you want to draw numbers with, and > then put the textures together to create numbers, timers, etc. You also > need an individual texture for a colon (":") and "mph". > > You then have textures for "Wrong Way!", "Ready!", "Set!", "Go!", > "Congratulations!", "1st", "2nd", "3rd", etc, etc. > > I've started work but it's very boring. > > James > -- My ritual differs slightly. What I do, first thing [in the morning], is I hop into the shower stall. Then I hop right back out, because when I hopped in I landed barefoot right on top of See Threepio, a little plastic robot character from "Star Wars" whom my son, Robert, likes to pull the legs off of while he showers. Then I hop right back into the stall because our dog, Earnest, who has been alone in the basement all night building up powerful dog emotions, has come bounding and quivering into the bathroom and wants to greet me with 60 or 70 thousand playful nips, any one of which -- bear in mind that I am naked and, without my contact lenses, essentially blind -- could result in the kind of injury where you have to learn a whole new part if you want to sing the "Messiah," if you get my drift. Then I hop right back out, because Robert, with that uncanny sixth sense some children have -- you cannot teach it; they either have it or they don't -- has chosen exactly that moment to flush one of the toilets. Perhaps several of them. -- Dave Barry |
From: James G. <j....@vi...> - 2004-09-05 21:05:05
|
On Sun, 2004-09-05 at 22:00, Ricardo Cruz wrote: > About the cache of textures, that is not practicable, since text is different > all the time. You'd need tons of memory to cache all different combinations > of texts. > What I currently do is to cache TTF_Font, which already helps speeding it up. > Though, I dunno if TTF_OpenFont() is all that expensive. It is possible to cache text textures. For numbers you have to do it in parts - rather than having "9", "99" and "999", you just cache textures for the numbers 0-9 for each font you want to draw numbers with, and then put the textures together to create numbers, timers, etc. You also need an individual texture for a colon (":") and "mph". You then have textures for "Wrong Way!", "Ready!", "Set!", "Go!", "Congratulations!", "1st", "2nd", "3rd", etc, etc. I've started work but it's very boring. James |