Yes, of course, but that's a demo, with high framerate requiered.

So I don't see why I should insert any IDLE time :-)

The faster the better.

@crisot
I think busy-loop just overhead everything :) I mean warp3d slow, but not _that_ slow to make these scenes works on 100% cpu loading :) Very possible that after you will put that "waiting" everything can be works even faster. Maybe you also have some main-hadler fucntion, in which you should put that wait, but not to the scene itself .. its hard to say without seeing the code, but imho that classic busy-loop, but not overhead by warp3d. I can be wrong of course, but i catch the same problems with w3d before. After i put that waitport stuff, everything works the same fast as before, but without cpu loading.

My 3D engine and the renderer calling W3D_DrawInterleavedArrayICantRemember() are in the same task.

No // of the soft/hard work.

But anyway, while waiting for W3D to return, the CPU is also 100%.

w3d is very tricky to code of course :) There is tons of functions which you can put here and it will give you that result, or here, and then that result. Pretty possible that you forget something somethere .. Did you use any "SwithScreenBuffer()" function ? If so, how it looks like ? For me it was like this:

void SwitchDisplay(W3D_Context *context,struct Screen *screen)
{


if(window_mode==TRUE)
{
WaitTOF();
W3D_FlushFrame(context);
W3D_WaitIdle(context);
BltBitMapRastPort(bufferrastport.BitMap,0,0,window->RPort,0,0,640,480,0xC0);
W3D_SetScissor(context, &SwiDisp);
W3D_SetDrawRegion(context, bufferrastport.BitMap, 0,&SwiDisp);
}



if(fullscreen_mode==TRUE)
{
#ifdef __AROS

WaitTOF();
W3D_FlushFrame(context);
W3D_WaitIdle(context);
BltBitMapRastPort(bufferrastport.BitMap,0,0,window->RPort,0,0,640,480,0xC0);
W3D_SetScissor(context, &SwiDisp);
W3D_SetDrawRegion(context, bufferrastport.BitMap, 0,&SwiDisp);

#else

buffer[drawBuffer]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort=0;
while (!ChangeScreenBuffer(screen, buffer[drawBuffer]));
drawBuffer ^=1;
W3D_SetDrawRegion(context, buffer[drawBuffer]->sb_BitMap,0, &SwiDisp);
// WaitBOVP(&(screen)->ViewPort);
WaitTOF();

#endif

}

Bravo pour ce fix. La démo tourne nickel sur ma Sam440ep Flex à 800 MHz. Je n'ai pas remarqué de différence notable de son entre la lecture du fichier mp3 dans TuneNet et au cours de la démo.

@Crisot
Btw, last post from Murakami also point that its just busy-loop problem.

The "main" problem about the 100% CPU use is I never wait for any vsync.

Of course, if the demo only runs 20 fps, the CPU will be 100%, because 20 fps means slow computer.

But in my case, even if the demo can reach more than 60 fps, I will never wait for vsync and continue displaying more and more fps. (100, 200... 500.... 124567697).

And I don't see any problem with a 100% used CPU in a demo. In fact, that's the goal.

Many effects of #Two can't even reach 60 fps on my 1.4 Ghz G4 + Radeon 9000 pro, so busy CPU is normal...

Low framerate+low CPU usage: THAT'S the real problem.

Citation : Crisot?

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?

Par rapport à d'autres fichiers mp3, le tien sature à niveau normal. Il faut réduire le volume pour que le son soit audible ;-)
Mais je n'ai pas les mêmes enceintes que les tiennes :#

Son saturé ici aussi (Flex). Le reste est "cool" :-)

C'est super fluide sur ma 440ep, le son est bon!

J'aimerai bien un systéme 3D aussi fluide sur ma Sam :-D

Bravo Crisot!!!!