Developer Thread

by **CARPEDIEM** » Mar 2, 2001 @ 1:08pm

Btw, i get the same speed increase. these are my scores on my E-125 @ 200.7 Timerefresh: 3.74 fps demo1: 6.6 fps These scores using the latest .cfg from 999 It's Pretty playable on the casio i must say. Im also drawing a gray sky, because if i draw it with the optimized functions, framerate on the timerefresh test drops to 3.5 Last modification: CARPEDIEM - 03/02/01 at 10:08:15

by **Dan East** » Mar 2, 2001 @ 1:18pm

That's what I do, I just don't release the buffer every frame. At the beginning of the drawing I see if I have the buffer still. If not, I get it. I have rewritten those routines completely from what you have (I think). Now I calculate all drawing parameters up front, so the actual drawing is totally generic. This allows the exact same drawing routine to work for portrait, both landscape modes, and other types of devices, without having any conditional logic. The reason I don't release the buffer each frame is because Microsoft says you don't have to, but it does not work that way on MIPS and SH3 devices (apparently you have to release each frame). Notice the conflicting info, this is straight out of the Game API docs (do a search for GAPI, then select the document "Animating Graphics" ) : To continue drawing more data on the screen, call GXBeginDraw to get a pointer to the VFB. As soon as drawing is complete and no later, call GXEndDraw. Note Consider the performance cost of these calls when implementing them in your application, because they will typically be done 20 or 30 times per second. It is acceptable to draw several frames between the GXBeginDraw and GXEndDraw calls, but you must remember to call GXEndDraw in WM_KILLFOCUS if necessary. Ok, so they say you should release the buffer "as soon as drawing is complete and no later", and two sentences later say "It is acceptable to draw several frames between the GXBeginDraw and GXEndDraw calls". So to me that means you can hang onto the buffer until you get a WM_KILLFOCUS message. Even then the only reason you give up the buffer is if you want to be nice to whatever application gained the focus. Thanks again Microsoft! Dan East Last modification: Dan East - 03/02/01 at 10:18:13

by **norvain** » Mar 2, 2001 @ 6:17pm

I have some numbers that you all might find interesting: (Timming done on my Casio E-125@150mhz) Gapi BeginDraw : 0.031ms Gapi EndDraw: 3.052ms total: 3.083ms per frame for Gapi ( ~324fps) So calling EndDraw as little as possible isnt super critical, but definately something to think about..especially in Quake where 1fps speedup makes a tremendous difference. Data Copying on the otherhand is a problem.. Numbers from some of the methods I tested: Word->Word : 19.928ms(W/GAPI)50fps(~44fps) Memcpy : 11.841ms(W/GAPI)85fps(~67fps) If anyone has some asm blitting routines that would make a huge difference. Last modification: norvain - 03/02/01 at 15:17:27

by **Dan East** » Mar 2, 2001 @ 6:45pm

Thanks, Norvain. Any idea why the buffer must be retrieved / released every frame with MIPS and SH3 devices? Do you see this behavior? Dan East

by **Phantom** » Mar 3, 2001 @ 11:02am

0.2 fps speed increase?

That's a disaster! I spend at least 10 hours on that! Anyway, apparently I'll have to think better about wich code needs to be changed...

by **norvain** » Mar 3, 2001 @ 5:53pm

All I can do is speculate but I believe it comes down to 2 things: first GX.dll is made by Casio, so its possible that they were listening to Microsoft and following the spec directly secondly, The Casio Pocket PC's have Video DRAM as opposed to a spot in memory like the IPAQ, so it most likely has something to do with the way the DRAM is updated... Speed could also be another factor, given that Mem->Mem copies are faster than Mem->Video thus updating the screen once should be faster. Display Memory may also be banked, requiring the driver to do bank switching when it copies the buffer over to DRAM, so direct Writes would be very complicated and slow down the system( as well as make GAPI Platform Specific, which is bad) Jimmy of Jimmysoftware.com has written his own GAPI less display drivers, maybe he can shed some light on this or share his secret

Last modification: norvain - 03/03/01 at 14:53:59

by **CARPEDIEM** » Mar 8, 2001 @ 1:30pm

Dan, when are you going to send me the 0.05 source?, I have some time now since i failed the exam and that means an extra year of college

so send them to carpediem@velocom.com.ar (don't forget the .ar) when you can.

by **Dan East** » Mar 10, 2001 @ 10:11am

I'm trying to get a fixed point conversion working properly. If I don't have any luck by later today I'll send you what I've got without that improvement. Dan East

by **CARPEDIEM** » Mar 10, 2001 @ 12:32pm

Great Dan. BTW, the old source you sent me was configured to be optimized for maximum speed, but also inline function expansion was set to: "Any suitable" You might want to change that to "__only inline" for an extra 2 frames per second.

by **Dan East** » Mar 10, 2001 @ 12:44pm

Thanks, but I already had the iPaq optimization settings at "any suitable" for automatic function inlining. The other targets will have default settings in some cases. I try to make changes to all configurations, but I don't always succeed.

Dan East

by **CARPEDIEM** » Mar 10, 2001 @ 1:21pm

No no... I don't think i expressed myself properly. What i mean is that i DO know that you have it set to: "Any suitable", i didn't have it set to that, and when i did my framerate decreased more than 2 frames per second. What i would like you to try is to set it to: "Disable*" or: "Only__inline" The "Any suitable" option decreases performance on mips devices, i'd like to see what happens on ARM devices.

by **CARPEDIEM** » Mar 10, 2001 @ 2:22pm

Nevermind, 999 tried an ipaq build and he didn't notice a speed increase. I wonder why it gets so slow on casios when you use the "any suitable" option.

by **Dan East** » Mar 10, 2001 @ 2:43pm

Okay, I reread your last post. So it runs slower with function inlining enabled on MIPS devices? One disadvantage of the MIPS devices is that they require very strict 4 (or is it 8?) byte data alignments, otherwise the processor is severely handicapped (like 5-10 times slower processing unaligned data). I don't know if inlining functions could hurt data alignment or not. Dan East Last modification: Dan East - 03/10/01 at 11:43:38

by **randall** » Mar 10, 2001 @ 2:56pm

Mips devices use 32-bit data aligning, otherwise they slow to a crawl. So yeah, that would be 4 bytes as you stated. OOPS, sorry, didn't realize this was the developer thread. Last modification: randall - 03/10/01 at 11:56:16

by **CARPEDIEM** » Mar 10, 2001 @ 4:18pm

Ok here's the deal with the configuration directives of eVC++. I've been going through the different configurations options and got results ranging from 4.5 fps to 7.0 fps on the demo1 test. If you select: "Any suitable" and at the same time you choose the DEFAULT processor on code generation, you get a huge fps drop. In contrast, if you choose procesor 4100 AND "Any suitable" you get 0.3 more fps. so i guess this is the best config for mips devices: Optimization: "maximize speed" Processor: "4100" Inline function expasion: "Any suitable"

Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Re: Developer Thread

Sort

Forum Description

Moderators:

Forum permissions