• Welcome to Powerbasic Museum 2020-B.
 

News:

Forum in repository mode. No new members allowed.

Main Menu

IceWalk

Started by Patrice Terrier, September 03, 2009, 04:46:22 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Patrice Terrier

IceWalk

This GDImage project is to show you, how to create an animation with more than 200 sprites, using one single multi-frame PNG bitmap composed of 12 frames.

There is only one real pinguin, the first one, all others are clone of the primary object.
In GDImage you can't make the difference between a clone and a "real" object, because they can all be manipulated to the same extent, using the same scope of properties.



...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Petr Schreiber

Patrice,

again very nice demo.
I got 25% cpu usage for single penguin, and 75% for the horde.
AMD Sempron 3400+ | 1GB RAM @ 533MHz | GeForce 6200 / GeForce 9500GT | 32bit Windows XP SP3

psch.thinbasic.com

Patrice Terrier

#2
Petr,

Thanks for the feedback, i am getting a 34% CPU average here, whatever using the single pinguin or the horde.

VISTA 64-bit and a Core 2 duo T7200 (2 Ghz) + nVidia GeForce GO 7600.

Note: that is pure GDImage graphic animation (no DirectX, no OpenGL).

Try to you reduce the size of the horde down to 100, with the %MAX_SPRITE parameter, you can also play with the %TIMER_DELAY as usual.
Would be interresting to make the same demo in OpenGL to see if there is a real gain on the CPU resource.

...

Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Patrice Terrier

#3
There are three factors that could slow down this type of animation.

1 - All the sprites, except the main one, are resized on the fly at each iteration, instead of doing it once for all at startup.
2 - Resizing uses bicubic to preserve the antialias quality, but it is much slower than simple HALFTONE mode.
3 - Many sprites are using variable opacity that is computed at each iteration, instead of doing it once for all at startup.

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Petr Schreiber

#4
Patrice,

I think the CPU usage on my PC is given by fact I still have single core, old model CPU (AMD Sempron 3400+ (1.8GHz true frequency)).
I don't see it as problem with the program here.

The beauty of OpenGL/Direct3D is that you can partially or completely "upload" the resources to graphic card (VA or display lists/VBOs), so the rendering can take basically zero CPU usage. But the problem of these APIs is that not-power-of-two images support was implemented quite recently, so you need to check for support of it in hardware. Also the hardware instancing is DirectX 10 / OpenGL 2.1 EXT / OpenGL 3.x thing, while one would expect this to be one of the first things graphic accelerator should do :)

With GDI Image you have no such a problems - it will work on all machines.


Petr
AMD Sempron 3400+ | 1GB RAM @ 533MHz | GeForce 6200 / GeForce 9500GT | 32bit Windows XP SP3

psch.thinbasic.com

Patrice Terrier

#5
Petr,

I have reworked the demo to reduce the CPU footprint, while keeping the nominal frame rate of the original GIF animation, aka 12 FPS.

Here are the result shown under task manager:

- Windows XP SP2 running on Dual Core 1, CPU = 33 to 34 %, the nominal FPS being respected.

- Windows VISTA 64-bit running on Dual Core 2 Duo, CPU = 24 to 33 %, the nominal FPS being respected.
 On the same computer in full screen mode (HD 1920 x 1080), CPU = 31 to 34, still running at the GIF nominal 12 FPS rate.

And for those that are not aware of it, the maximum FPS you can get on VISTA / W7 while running in cooperative mode is 64 FPS, everything else is false allegation.

Working in cooperative mode, means that you can still run the other applications  :)

Note: The EXE file has been cleaned up, with zXref.

...

Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Petr Schreiber

#6
Hi Patrice,

this version is definitely better!
Before CPU usage was 25% / 75%, now it is 17% / 66%.


My PC Is:
AMD Sempron 3400+, 1GB 533MHz RAM, Windows XP SP2 + all updates before SP3


Thanks
AMD Sempron 3400+ | 1GB RAM @ 533MHz | GeForce 6200 / GeForce 9500GT | 32bit Windows XP SP3

psch.thinbasic.com

Patrice Terrier

Hi Petr

I just post a new version of IceWalk, with further optimization, and a new version of GDImage.dll that has been compiled for the first time with PB9 instead of PB8.

It seems that compiled with PB9, it runs a little faster but i am un-sure, could you try it and let me know.

Thanks

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Petr Schreiber

The PB9 compiled version shows only as slightly faster on my PC,

instead of 17% I get for little moments 16%, and for 66% sometimes 63%, but it is occurs for short time interval, so it runs mostly at 17% / 66%. Which is still very nice improvement over the first original!

I can only recommend using PB9 over PB8, it seems so much more mature, nice new assembly instructions... I like it very much.


Petr
AMD Sempron 3400+ | 1GB RAM @ 533MHz | GeForce 6200 / GeForce 9500GT | 32bit Windows XP SP3

psch.thinbasic.com

Patrice Terrier

#9
Ok, thanks

So far i was still using PB8 to compile GDImage, because i never had problems with it (while i had some with PB9).

However starting from now, i will switch GDImage gently to PB9, and see if it could benefit of some of the new compiler features.

Added:
My own result on VISTA AERO (Core 2 Duo T7200, 2Ghz)

One single pinguin: CPU average value of 9%
With the hord: average value of 25%

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Patrice Terrier

The first post of this thread has been updated, to fix the ZIP file corruption caused by the "Server Collapse".

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com