Re: [TuxKart-devel] Slowness - really related with Karts?

[Jason T. R. <jt...@gt...>]

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
>
>  
>