Hello

J'aimerai bien comprendre pourquoi ce prog est si lent sur ma Sam
Pourtant il est à peine plus compliqué que Quake qui lui tourne bien
A mon avis y a un problème de portage et/ou conception dans la version Amiga
Bref ça m'intrigue depuis longtemps et je voudrais y jeter un oeil
Mais je trouve pas les sources Amiga sur sourceforge : Ou sont elles ?
Et surtout où sont les sources de son "moteur" 3D ?

Alain

faut voir avec Kas1e sur amigaworld je ne connais pas son mail par contre

OK je connais bien kas1e je vais lui demander

MERCI

Cela serait super d'avoir ce jeu enfin utilisable !
Sur mon peg2, c'est également horriblement lent.

Alain, c'est l'occasion de devenir un héro OS4 :-)

Pour info : trop crevé pour traduire....
Enfin on sait pourquoi ce Tux est lent
Alain
------------------------------------------------------------------------------
>>>I can dig in on my HDD for sources, but in general its the same sources 1:1 from the SVN repo with version 0.6.2a. There is:

>>>http://sourceforge.net/projects/supertuxkart/files/SuperTuxKart/0.6.2/supertuxkart-0.6.2a-src.tar.bz2/download
> > BTW I have already checked the sourceforge sources and it
> dont seems to !include! any drawing code (ie GL)
> > So do you have the PLIB sources as it seems to use it for drawing ?
>
> Can't remember to be honest where actual drawing code done,
> but yep, i build PLIB expectually for that game, here is:
> http://os4depot.net/index.php?function=showfile&file=developme
> nt/library/toolkit/plib.lha


Hello again

Kas1e wrote
> As far as i remember, you can do "profiling" with wazp3d ?
> Maybe we can see what cause slownesses there ?

Yes have obtained a 45 MB log file :-/ only for some seconds of SuperTuxKart

I have found something
SuperTuxKart use (or PLIB do that ?) drawarray BUT for EACH polygon :-(
(me for cow3D I draw 1000 polygons each time that I call drawarray)

So for around 64 frames generated then drawarray() is called 68891 times
==> around 1000 drawarray per frame
(but intro dont have much polygon, last drawn frame call drawarray 4400 times :-((( )
==> Each polygon is truly draw with a drawarray
( drawarray can draw a full (single material) object)

Bad bad bad :-/

=============================================
From PLIB sources

void ssgVtxTable::draw_geometry ()
{
[...]
glDrawArrays ( gltype, 0, num_vertices ) ;
[...]
}


void ssgVtxTable::draw ()
{
[...]
draw_geometry () ;
[...]
}

But i didnt found what/where call draw() in SuperTuxkart or PLIB


Alain

Bonsoir

bref je resume : j ai trouve' pourquoi ce tux est si lent:
chaque polygon (triangle,rectangle,etc...)est trace' a coup
de gldrawarray() une fonction qui pourtant pourrais tracer
un objet entier ( des centaines ou des milliers de polygones)
si il utilise le meme materiau (texture)

bref un gros gachis qui passe inapercu si le driver (opengl ici minigl)
est tres optimise (genre a un statetracker qui bufferize
les tracage) mais un prog aussi con ca passe pas sur notre rustique minigl

BTW Meme si Wazp3D a lui un statetracker malheureusement
il est pas utilise avec drawarray qui est sense' etre utilise' de maaniere efficace


Alain

Du coup sa veu dire que tu peu fair quelque chose ou pas?

J ai trouve' la cause (apparente ) de la lenteur mais je sais pas encore
di je peut la corriger car je sais pas ou elle se produit dans le dizaines
de Mo de sources.
En plus avec une fonction fautive avec un nom aussi banal que "draw" c pas facile a trouver

je rassemble mes qques neurones demain et je verrai si je trouve...

Alain

si cette fonction est utilisée pour tous les polygones, tu dois la trouver dans une fonction "principale"/"centrale" bref un truc qui se voit bien dans le source :-)