Bon, j'ai une #two pseudo fixée:

TWO-RC.lha

Au niveau des nouveautés:
- utilise mpega.library.
- saturation sonore fixée.
- doit normalement marcher sur Sam.
- mode d'écran 32 bits au lieu de 16 (un peu plus lent).

J'ai malheureusement totalement chié mon assembleur à l'époque et j'ai très peur que cela empêche la demo de fonctionner sur une Sam. Dites moi très vite ce qu'il en est, car si ça ne fonctionne pas, je suis parti dans des jours et des jours de code pour fixer cela.

Toute remarque est la bienvenue, dites moi notamment si vous trouvez que le mode d'écran 32 bits ralenti trop la demo, si vous souhaitez avoir un requester pour choisir votre résolution etc...

Je sais, c'est #One qu'il faut fixer, mais #Two utilise le même moteur, et est plus petite. Je préfère bosser sur elle avant d'attaquer la grosse.
Message édité par : Crisot / 14-10-2010 02:53

Salut

Fonctionne Nickel sur SAM440ep ;-)

100% CPU utilisé mais c'est fluide pour moi (jamais vu avant puisque SAM440).

Apres, si elle devrait utiliser moins de 100% de CPU, je ne sais pas....

Hello Crisot,

Nickel ici également sur la Flex; également 100% du CPU utilisé, mais c'est souvent le cas avec les démos, le 440 n'étant pas un foudre de puissance brute....
;-)

Sur ma Sam-Flex 800 MHz, la démo passe très bien (je me fiche de savoir si le CPU est utilisé à 100%).
Petite remarque le niveau sonore est si élevé que le son sature mon ampli (j'ai rédui le niveau).
Autre remarque : les blancs arrivent très vite à faire "tache" !
Je n'ai pas su déterminer dans quelle résolution la démo tourne sur mon moniteur, mais la surface est totalement utilisée ! Ecran en 16/9ème 1920x1080.

Oui, le son est encore un peu fort mais elle marche toujours aussi bien sur mon AmigaOne ;-)

Merci pour le fix qui lui permet de fonctionner sur toutes les machines, j'attends les autres avec impatience. :=!

Salut,

Au niveau du CPU, c'est juste au cas ou elle utilise 20% de CPU sur le A1, il y aurait un truc ;-)

@Crisot
On peg2/1ghz - 100% cpu load (for new version, and for the version from os4depot), and lockup at exit of whole OS for new version (with old one all is fine).

100% sur tous les CPU.

Par contre, dommage que ça plante sur Peg à la sortie.

Heu ouai les gars, c'est pas la peine de psychoter sur l'usage CPU hein, de toute façon dés qu'on demande un truc à Warp3D, ça monte à 100% :-)

Par contre ça fait chier cette saturation sonore, ici c'est niquel, j'ai le même niveau sonore que sur Tunenet lorsque je lis le même MP3 ( ? ? ?). Ca donne quoi pour vous le mp3 sur TuneNet?

Pour le crash en sortie du Peg... Là par contre je vois vraiment pas. Je vais bricoler un peu du coté de mon player audio, c'est la seule grosse différence avec la version qui a 4 ans.

@crisot
I can say, that 100% cpu loading is not because of Warp3D itself, but because you forget to add some kind of "pause-reply" to code (because for now you just have busy-loop looks like).

When i code TheVague diskmag (warp3d as well), i also have on the first releases 100% cpu loading, and i thinking that its because of warp3d crap, but , then i understand what need to do and for now it give 4-5% of cpu loading. Imho you have the same problem in code here.

I fix it by putting to the main routine that:

while(!esc)
{

//fix boosy-loop crap about getmsg/replymsg in loop;
WaitPort(window->UserPort);

//main loop
if(FALSE==GetInput(window)) {
printf("main input func failed\n");
goto panic;
}
}

Without "WaitPort" it give me 100% cpu loading as for you. I am sure on 99% that its the cause. Even if its not exactly the same problem, for sure its BusyLooping problem (for/while/etc) and need some sort of pause. You also can just fix it by some ugly Delay(1); stuff :)
Message édité par : kas1e / 14-10-2010 16:53