hey ho
now that yagl reaches completition i wanted some ppl to test this for me. it's a blitting test in 1024*768*32-bit. you can switch between fullscreen and windowed mode with alt+tab. the gfx module of yagl is pure software ( it's based on the fbgfxlib ) so don't go crazy if you got a really low framerate.
just extract this zip and start either of the two exe. simple.exe is the debug version thus slower but with full logging and memory leak detection. simpleo2.exe is the optimized release build
if you would post your framerate alongside your pc specs that would be really helpful
thx to z!re for putting the stuff up
http://goddess.selfip.com/yagl/yagl+dlls.zip
Debug: 68 FPS
Release: 77 FPS
Relevant System Specs:
2.2GHz AthlonXP (Barton, 512K cache)
400MHz FSB (200MHz DDR)
1024MB Dual-Channel PC3200 2.5 (200MHz DDR DC 2.5CL)
8x AGP Radeon x850 Pro, 256MB (500MHz GPU, 500MHz DDR3 (1000MHz))
y et
a nother
g ame
l ibrary
they both ran around 32 fps on my
P4 1.8Ghz
XP SP2
4 Mb video
i just got a white window with a few crosses on it and 'this is a test'
heres what happened with simple
Quote:C:\Documents and Settings\Derek\Desktop\yagl+dlls>simple
Leaked object at 003F3970 (size 752, audiolib/sfxdevice.:52)
Leaked object at 003F3CF0 (size 32, audiolib/sfxdevice.:53)
Leaked object at 003F3CB8 (size 12, 0048E89A)
Leaked object at 003F3C88 (size 8, decoder/decoder.cpp:39)
Leaked object at 003F3DF0 (size 12, 0048E89A)
Leaked object at 003F3D70 (size 88, sgfx/sgfx.cpp:451)
Leaked object at 003F3D38 (size 12, 0048E89A)
*** WARNING: GCC 3 or later is detected, please make sure the
environment variable GLIBCPP_FORCE_NEW (GCC 3.2 and 3.3) or
GLIBCXX_FORCE_NEW (GCC 3.4 and later) is defined. Check the
README file for details.
delete: freeing 003F3970 (size 752, 164 bytes still allocated)
delete: freeing 003F3CB8 (size 12, 152 bytes still allocated)
delete: freeing 003F3CF0 (size 32, 120 bytes still allocated)
delete: freeing 003F3D38 (size 12, 108 bytes still allocated)
delete: freeing 003F3D70 (size 88, 20 bytes still allocated)
delete: freeing 003F3DF0 (size 12, 8 bytes still allocated)
delete: freeing 003F3C88 (size 8, 0 bytes still allocated)
unregistered all decoders
simpleo2 just said
Quote:unregistered all decoders
also the mouse cursor was very flickery
thx a lot, the output of simple.exe is what the memory leak detector tells you about the memory usage. basically it says that everything got freed
so all is fine.
the unregistered all decoders is a printf if i overlooked thx for pointing that out.
the flickering mouse is due to the way fbgfxlib works and is something that can't be avoided ( unless you turn of the native mouse pointer and draw your own mouse pointer.
thx a lot for testing.
im not a guru on gcc stuff but if this appears
Quote:Leaked object at 003F3970 (size 752, audiolib/sfxdevice.:52)
then its is freed as shown, doesnt this mean that there was a leak but the gcc garbage collection got it?
no gcc has no garbage collector :p
the thing is this: the memory leak detector is registered at atexit, that is it will be called when the programm terminates. BUT some of the yagl modules have also registered a method to clean themselves up when the application terminates. now what happens is this: the memory leak detector will output a status report when it is called when the program terminates. the clean up methods of some modules of yagl haven't been invoke at that point as they were registered at atexit AFTER the memory leak detector was registered. so that means those get called AFTER the memory leak detector outputs the report. that means that memory allocated by those modules ( up until now only the decoder module "suffers" from this ) has not been freed before the memory leak detector reporst as the cleanup methods weren't called at that point.
what happens is that the memory leak detector is still active and will output when something is freed AFTER it has reported. so in the end this is output:
Code:
C:\Documents and Settings\Derek\Desktop\yagl+dlls>simple
HERE THE MEMORY LEAK DETECTOR IS CALLED FROM ATEXIT
NOTE THAT THE CLEANUP METHODS OF THE MODULES HAVE NOT BEEN CALLED YET AS THE MEM LEAK DETECTOR WAS REGISTERED FIRST WITH ATEXIT
Leaked object at 003F3970 (size 752, audiolib/sfxdevice.:52)
Leaked object at 003F3CF0 (size 32, audiolib/sfxdevice.:53)
Leaked object at 003F3CB8 (size 12, 0048E89A)
Leaked object at 003F3C88 (size 8, decoder/decoder.cpp:39)
Leaked object at 003F3DF0 (size 12, 0048E89A)
Leaked object at 003F3D70 (size 88, sgfx/sgfx.cpp:451)
Leaked object at 003F3D38 (size 12, 0048E89A)
*** WARNING: GCC 3 or later is detected, please make sure the
environment variable GLIBCPP_FORCE_NEW (GCC 3.2 and 3.3) or
GLIBCXX_FORCE_NEW (GCC 3.4 and later) is defined. Check the
README file for details.
NOW THE MODULE CLEAN UP ROUTINES ARE CALLED AND THE MEM LEAK DETECTOR NOTES TAHT BY SAYING "WELL I ALREADY SPIT OUT MY FINAL REPORT BUT THE OBJECTS I REPORTED ABOVE WOULD LEAK ARE NOW ACTUALLY FREED HURRAY!!!
delete: freeing 003F3970 (size 752, 164 bytes still allocated)
delete: freeing 003F3CB8 (size 12, 152 bytes still allocated)
delete: freeing 003F3CF0 (size 32, 120 bytes still allocated)
delete: freeing 003F3D38 (size 12, 108 bytes still allocated)
delete: freeing 003F3D70 (size 88, 20 bytes still allocated)
delete: freeing 003F3DF0 (size 12, 8 bytes still allocated)
delete: freeing 003F3C88 (size 8, 0 bytes still allocated) < 0 bytes still allocated means that now everything is alright and all memory was freed HURRAY
unregistered all decoders
again gcc/g++ has no garbage collector, java has, eiffel has but not c/c++.