I am writting a game using only sprites with alpha channel, obviously I am using only draw_trans_sprite for blitting.
The weird thing is that without optimization my game runs at 60fps, but when I use the compiler optimization options(devcpp): -O1, -O2 or -O3 the fps drops to 35 or less! what´s wrong here? code compiled with optimization options should run faster, I think.
It should run faster, unless there is a compiler bug. What is the version of gcc? It doesn't happen often to hit a bug with just a -O1.
Dev-C++ 5.0 beta 9.2 (4.9.9.2) with Mingw/GCC 3.4.2
I get it from here
The frame drop happens with draw_trans_sprite only, I am also using Fladimir´s blender routines and they run faster(as expected) with -O3, so I am not sure about the compiler bug.
Sounds like a compiler bug that is triggered by allegro's draw_trans_sprite(). But someone with the same compiler version should confirm.
Could you try out with -O2? -O3 may turn on some experimental stuff, that may or may not speed things up...
Could you try out with -O2?
draw_trans_sprite runs slower with optimizations enabled, I tried -O1, -O2, -O3, there is no difference it works slower, really slower, 60fps went to 35 fps.
Maybe there's something fishy in your FPS calculations? After all, I bet you're not compiling Allegro with different settings...
Do you do a complete recompile each time you switch the -On?
Try recompiling allegro with all asm turned off and see if the difference still occurs.
I compiled exalpha.c example 3 times, with -O3, -O2, and without optimization, these 3 files are attached, try them in your PCs.
Here is the exalpha source (slightly modified) I used.
After all, I bet you're not compiling Allegro with different settings...
I don't understand what you meant, can you reword it please?
He means, are you recompiling Allegro along with your program?
If not, then what optimisation options you specify should not influence draw_trans_sprite.
I think he means, that you only compile your project with different settings, not allegro.
Edit: beaten...
I am only compiling my project, I am using pre-built binaries for MinGW.
here is the compile log:
Building Makefile: "C:\Documents and Settings\pablo\Escritorio\Makefile.win" Finding dependencies for file: C:\Documents and Settings\pablo\Escritorio\allegro-misc-4.2.1\examples\exalpha.c Executing make... make.exe -f "C:\Documents and Settings\pablo\Escritorio\Makefile.win" all g++.exe -c allegro-misc-4.2.1/examples/exalpha.c -o allegro-misc-4.2.1/examples/exalpha.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -O3 g++.exe allegro-misc-4.2.1/examples/exalpha.o -o "draw_alpha.exe" -L"C:/Dev-Cpp/lib" -mwindows ../../../Dev-Cpp/lib/liballeg.a Execution terminated Compilation successful
Am I doing something wrong? if yes, then how should I compile my project with optimizations in devcpp?
Paul, by the way, my routines are optimized for anti-aliased sprite rendering, so they perform best when the percentage of translucent pixels is low.
Do you know how to use a profiler? That could help determine what's going on.
Paul, by the way, my routines are optimized for anti-aliased sprite rendering, so they perform best when the percentage of translucent pixels is low.
Anti-aliased sprites is exactly what I am using.:)
.
.
And your routines(with -O3) are faster than draw_trans_sprite(without optimization), but they are much much much more faster than draw_trans_sprite(with -O3).
Do you know how to use a profiler? That could help determine what's going on.
Yes, I'll profile it, however I don't need to profile anything to appreciate the speed lose in draw_trans_sprite with -On.
In fact, I could implement a run-length encoding of translucent sprites which might be even faster... but it'd be some work. However, it seems that these days the memory speed plays even a bigger role than before, so the MMX logic doesn't speed things up as drastically as in my old Pentium 800Mhz...
draw_trans_sprite wont change when you change your -On parameter. The problem would have to be somewhere else...
In fact, I could implement a run-length encoding of translucent sprites which might be even faster... but it'd be some work. However, it seems that these days the memory speed plays even a bigger role than before, so the MMX logic doesn't speed things up as drastically as in my old Pentium 800Mhz...
That would be great! more speed == more sprites on the screen.
I don't know, you are the expert, but if the RLE works on the alpha channel as I think it should, then blitting a big sprite, with an alpha channel like the one I posted below, should obtain a significant gain in speed, or not?
.
{"name":"591106","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/6\/26ca77ddda0e128005fa9f427b2fabba.png","w":320,"h":240,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/6\/26ca77ddda0e128005fa9f427b2fabba"}
.
draw_trans_sprite wont change when you change your -On parameter. The problem would have to be somewhere else...
Yes, but does someone know why -On in Devcpp makes exalpha.c run slower? without optimization it runs faster, what is wrong then?
I see no difference with gcc-3.4.6.
I see no difference with gcc-3.4.6.
I am using devcpp with GCC 3.4.2.
Did you try the binaries I posted in my previous post? they run at different speeds in my P4 2400Mhz, if you have a faster PC probably you would not notice the difference.
if the RLE works on the alpha channel as I think it should, then blitting a big sprite, with an alpha channel like the one I posted below, should obtain a significant gain in speed
Yes, indeed. The more there's either transparent or solid pixels, the faster it'd be.