I'm working on tuning up a program and a lot of the slow down comes from using draw_trans_sprite. Is there any way I can speed this up w/o adding additional libraries. As I said, I'm working on tuning up a program, so I don't really want to add more libraries to it.
I replaced one routine that drew a BLACK-filled bitmap to "dim" the screen with a simple draw_lit_sprite and noticed about 10fps increase! Now I also have a 300 X 300 area being drawn via draw_trans_sprite and seems to really slow it down. At home, my machine can easily pump 60+fps, but at work, on a 2.4GHz Celeron, she's lucky to go 30.
Am I sore out of luck?
]]>#1 Profile, Benchmark.
#2 Give code. There are optimization guru there.
What else ? I do not know. You do not want additional library, so refer to #1
]]>Tell us more about what kind of bitmap types and bitdepths are you using.
Could you possibly show some screenshots and describe how different areas are drawn there.
Would it be possible to make that small area to not being updated every frame?
[edit]
And yes, code would be nice. I'm bored and I might provide you with some nice graphs, similar to what I showed here, assuming your program compiles and runs on Linux 
Why no additional library? fblend depends only on Allegro.
At least look at the fblend code, because this style of speedup is the best you can do in software.
]]>Tell us more about what kind of bitmap types and bitdepths are you using.
Oh, right right. Everything is truecolor, color depth 32 bits. (I'm thinking of going to the wonderfull paletted world of 8-bit in the future )
Screenshot: I circled (in red) the area that is being translucent each frame.
{"name":"591418","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/b\/3b54ab9457c82ace6d391f0061127ed3.jpg","w":645,"h":485,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/b\/3b54ab9457c82ace6d391f0061127ed3"}
The green blocks are above the water, floating, rippling the water. The turned-off blocks are submerged under the water. I've got an option that turns off rippling the water all together, but it's still drawing it with translucency and the fps is just about the same.
[edit]
Why no additional library? fblend depends only on Allegro.
Well, originally, I wanted to keep it as close to vanilla allegro as possible. Plus, less libraries makes it less of a pain since I just supply the source to linux users. I've heard many good things about fblend, I'd just prefer to learn more about what I can do with what I have before adding more to it. Am I making any sense?
]]>Am I making any sense?
No. You just have to take a look at fblend source to see how to achieve what you need.
]]>Oh, right right. Everything is truecolor, color depth 32 bits
I hope you aren't using anything but regular bitmaps sitting in RAM.
How much rendering time is spent in drawing the translucent pixels? In percentages or in some other meaningful numbers?
]]>Allegro isn't going to get any faster with the blending routines despite what you do unless you forgo blending altogether. If you want faster blending you will need to look into a 3rd party options such as fblend.
]]>How much rendering time is spent in drawing the translucent pixels? In percentages or in some other meaningful numbers?
Well, if I take out both the water update and draw functions, back at home it would increase from about 60fps to 90fps. Also, I don't draw each pixel under a translucent mode. The pseudo-algorithm/logic of the water process is as follows
1) Stretch background image to the container size (placed on bmp called bImage)
2) Draw underwater bitmap onto bImage (the underwater bitmap is primarily magic pink, but objects get "submerged" onto it)
3) Stretch a water surface image onto bTransfer, draw bTransfer translucently over bImage (this is mainly a blue image and becomes more and more solid as the game goes, making the water appear...deeper)
4) Go through the WaveMap array, looking for non-zero values (meaning the water at that location is raised and/or lowered), _putpixel32 onto bImage using a spefic routine to figure out the color
5) Stretch bImage onto bTransfer (bTransfer is the area of the red circled area on the screenshot above)
6) Draw bTransfer using draw_trans_sprite, meshing with final buffer image, giving a glossy feel to the water (depending on what set_trans_blender is set to).
Steps 4 & 6 are the main buggers of the algorithm, but on a high-end machine, the effect is rather aesthetic (in my opinion at least, haha).
I took a look at fblend real quick. If I can just steal this function (or use it somehow) without having link fblend all together, that might be a solution.
| 1 | static void fblend_trans_32(BITMAP *src, BITMAP *dst, int src_x, int src_y, int dst_x, int dst_y, int w, int h, int fact) { |
| 2 | |
| 3 | if (fact == 128 || fact == 127) { |
| 4 | int i, j; |
| 5 | |
| 6 | for (j = 0; j < h; j++) { |
| 7 | |
| 8 | unsigned long *s, *d; |
| 9 | unsigned long color1, color2; |
| 10 | |
| 11 | /* Read src line */ |
| 12 | bmp_select(dst); |
| 13 | s = (unsigned long*)(src->line[src_y + j] + src_x * sizeof(long)); |
| 14 | d = (unsigned long*)(bmp_write_line(dst, dst_y + j) + dst_x * sizeof(long)); |
| 15 | |
| 16 | for (i = w; i; i--) { |
| 17 | |
| 18 | /* Read data, 1 pixel at a time */ |
| 19 | color2 = *s; |
| 20 | color1 = *d; |
| 21 | |
| 22 | if (color2 == MASK_COLOR_32) { |
| 23 | s++; |
| 24 | d++; |
| 25 | continue; |
| 26 | } |
| 27 | |
| 28 | color1 = ((color1 & 0xFEFEFE) >> 1) |
| 29 | + ((color2 & 0xFEFEFE) >> 1) |
| 30 | + (color1 & color2 & 0x010101); |
| 31 | |
| 32 | /* Write the data */ |
| 33 | s++; |
| 34 | bmp_write32((unsigned long)d, color1); |
| 35 | d++; |
| 36 | } |
| 37 | } |
| 38 | } |
| 39 | else { |
| 40 | int i, j; |
| 41 | |
| 42 | for (j = 0; j < h; j++) { |
| 43 | |
| 44 | unsigned long *s, *d; |
| 45 | unsigned long color1, color2; |
| 46 | |
| 47 | /* Read src line */ |
| 48 | |
| 49 | bmp_select(dst); |
| 50 | s = (unsigned long*)(src->line[src_y + j] + src_x * sizeof(long)); |
| 51 | d = (unsigned long*)(bmp_write_line(dst, dst_y + j) + dst_x * sizeof(long)); |
| 52 | |
| 53 | for (i = w; i; i--) { |
| 54 | unsigned long temp1, temp2; |
| 55 | |
| 56 | /* Read data, 1 pixel at a time */ |
| 57 | color2 = *s; |
| 58 | color1 = *d; |
| 59 | |
| 60 | if (color2 == MASK_COLOR_32) { |
| 61 | s++; |
| 62 | d++; |
| 63 | continue; |
| 64 | } |
| 65 | |
| 66 | /* Mutiply by the factor */ |
| 67 | temp2 = color1 & 0xFF00FF; |
| 68 | temp1 = (color2 & 0xFF00FF) - temp2; |
| 69 | temp1 = (((temp1 * fact) >> 8) + temp2) & 0xFF00FF; |
| 70 | color1 &= 0xFF00; |
| 71 | color2 &= 0xFF00; |
| 72 | temp2 = ((((color2 - color1) * fact) >> 8) + color1) & 0xFF00; |
| 73 | |
| 74 | /* Write the data */ |
| 75 | s++; |
| 76 | bmp_write32((unsigned long)d, temp1 | temp2); |
| 77 | d++; |
| 78 | } |
| 79 | } |
| 80 | } |
| 81 | |
| 82 | return; |
| 83 | } |
]]>
Well, if I take out both the water update and draw functions, back at home it would increase from about 60fps to 90fps
That doesn't seem all that big difference. Have you profiled your program?
Also you seem to be doing a lot of streching. Are you sure it is faster than using correct size from the start?
]]>Have you profiled your program?
Have any recommended profilers for WindowsXP? Googling...
]]>What compiler do you use ?
There are always a profiler with the compiler.
Example with gcc:
compile with -pg
Launch the program
Use gprof to have the information.
]]>Have any recommended profilers for WindowsXP?
As said, there is gprof. Also MSVC6 enterprise edition used to have a profiler, I'm not sure about the later versions.
Of cource as I said, if you could share your code I might take a look at it myself
And yes, code would be nice. I'm bored and I might provide you with some nice graphs, similar to what I showed here, assuming your program compiles and runs on Linux
I never saw this editted portion of your above post. Anyway, Toggles is on the depot and, if you have the right libraries (which I believe are listed in the readme), should compile on Linux if you get the 1.2.15 version. This code hasn't been touched since last August and doesn't include any of the recent optimizations I've been working on. I'm still new to the linux environment, so I haven't quite learned all the tricks to make it easier to supply to you guys.
[Edit]
I'd supply just the src code which I orginally had as a separate file, but I've since taken my site down and don't have that available atm. 
Everything is truecolor, color depth 32 bits.
You can use Fladimir's routines, but only for 32 bits alpha blending.
]]>Well, to be honest, I threw that simple fblend function (that I listed above) directly into my code and it worked pretty nicely. I also moved my logic around (do the blending then the stretching), which improved things. Now it's running at 85+fps on my home machine with the water. Not too shabby. I might still try to do the profiler thing, if not for simply educational purposes...
Credits to all!
]]>The function you posted doesn't use MMX when it's alvailable. Better use the whole FBlend to speed everything up even more.
I've always wondered why people are so afraid of third party libraries, anyways...
]]>I've always wondered why people are so afraid of third party libraries, anyways...
Because they go bump in the night and eat small children, why else? 
I've always wondered why people are so afraid of third party libraries, anyways...
Well, for me at least, the whole hobbyist game programming thing is 1) a hobby and 2) educational. Using more libraries makes option 1 more fitting, as you can produce a greater range of results faster but code-wise, the limit approaches "make_awesome_game();" Hence, I try to figure things out with what I have first, then add libraries if I ahve to.
Also, as I mentioned, I don't know how to properly make a linux binary, but I offer them the source so they can attempt to build it. Each library, as far as I can tell, adds to the amount of work they have to do. That I find very bad.
So, just stripping a function from the library seems to be the quickest and efficient solution to the bullet points above. Although, it doesn't do much for the knowledge-portion other than realizing I should never use draw_trans_sprite again. 
I should never use draw_trans_sprite again.
Why? what's wrong with draw_trans_sprite?
Right now I am using only draw_trans_sprite in some of my demos and there is no problem, at least in my PC (P4 2400MHz), perhaps I should test them in older machines? 
Just to mention that in the SVN version of AllegroGL, draw_trans_sprite() is implemented using OpenGL when drawing to screen, which means it can be quite fast.
]]>