I know that I've seen people say that using fblend with a video bitmap can be slow, which it is. But, after much profiling and optimization, I've come to realize that triple buffering with all created bitmaps as video bitmaps give me the perfect 60 FPS. And the only thing that slows the game down is when I try blend something. Most of my blending is really a translucent background of a box or the screen fading to 200 translucency when the continue screen's up. Is there ANY type of way that I could use fblend, or any blender for that matter, without dropping my FPS from 60 to like 7?
Blending with video bitmaps in Allegro is slow. If you want blending, you'll have to go with memory bitmaps and FBlend, or OpenGL.
Alright. Thanks, Kitty. I'll just stick with triple buffering and not use blending. I'm really sacrificing a little to gain so much.
I think there is a hybrid triple buffering mode that uses a memory bitmap to render onto, which is then quickly blitted to the video bitmap which is to be displayed next. This could be your solution to blending and triple buffering. Of course you could use double buffering and some timers to lock your FPS to 60.
Hey Steve,
The Hybrid method is what I had before when the speed issue on different machines originated. The Hybrid method only really seems to achieve 60 FPS on P4 machines or any machine with a FSB of over 133. I'd rather not use double buffering because it looks choppy on some machines and I would like for this game to look flawless on ANY machine.
Also, I thought memory->vram was slow on some systems?
Also, I thought memory->vram was slow on some systems?
On most newer systems drawing to memory bitmap and blitting result to screen is the fastest way.
On most newer systems drawing to memory bitmap and blitting result to screen is the fastest way.
So what about older systems?
Also, when you say "blitting result to screen", do you mean using request_video_bitmap() or using blit to achieve the hybrid?
So what about older systems?
I don't know about Windows but for Linux, 500MHz P3 renders stuff to video ram just as fast as to regular ram.
Also, when you say "blitting result to screen", do you mean using request_video_bitmap() or using blit to achieve the hybrid?
I meant you have a single bitmap you draw to. After you are done drawing it you blit that to screen using regular blit.
I meant you have a single bitmap you draw to. After you are done drawing it you blit that to screen using regular blit.
Maybe I worded my question the wrong way. What I meant was, is this blitting method that you're speaking of using all memory bitmaps or video AND memory bitmaps?
I meant that everything is done in memory bitmaps and only the final image is blitted to video blitmap (screen).
Hey Hoho,
I know what you're trying to say, but I need to know how to do that. Talks of bitmaps and such are confusing to me and when people are giving suggestions, it sounds like something that I've already stated that I've tried. So..
Here's what I have right now:
request_video_bitmap(buffer); if(buffer == pages[0]) { buffer = pages[1]; } else if(buffer == pages[1]) { buffer = pages[2]; } else { buffer = pages[0]; }
With buffer being the video bitmap that everything's being drawn to. So, the call request_video_bitmap(), is that the same thing as blitting the final image to the screen?
Also, is "screen" a video bitmap or memory and how can you change the format? I think that is what's really confusing me.
No the hybrid has the best of both, the smoothness of triple buffering AND the ability to render to a regular bitmap for blending. You pretty much create 4 bitmaps, 3 for the screens, and 1 that you render to. You blit your memory bitmap to the screen you are about to request. In your case you would put a blit just before request_video_bitmap. Blit and request_video_bitmap do different things.
so in other words, in my case (Sorry if I'm being worrisome, but when you've been working on something this small for a week, you'd rather have things spelled out because you don't want to misinterpret anything and move on):
I would have a memory bitmap that I render all of my memory bitmaps and such to, then blit that same memory to my video bitmap "buffer", THEN call request_video_bitmap(buffer)?
If so, that's what I was doing before when speed became an issue. I DON'T want to use OpenGL or anything related to that. Right now I'm getting 38 FPS on my slower computer. That's what I don't get! I even upgraded the RAM from 256MB to 640MB, the gfx card has 128MB vram(which doesn't really matter if you're using memory bitmaps), and the processor is a Celeron 1.1 GHz. And I can't get anything more than a measly 38 FPS????? But on my P4 machine, 2.8GHz, with like 400MB of vram and 1Ghz of ram, of course, I get 60 no problem! But, I plan on other people playing this game, and I KNOW that a lot of people may not have a state of the art P4 with all the fixins. Sorry for venting, but this is getting so frustrating and I didn't really expect to be stuck with this issue for almost 2 weeks when I already don't have a lot of time to spend on this. If being stuck on something, I'd rather be stuck on something like near the end of the game. I can't really advance because there's no point if this issue isn't fixed. sigh If you want to see the speed code that I use, I got it from Spellcaster's site.
http://www.steinke.net/coding.php
| 1 | volatile int timerCounter = 0; |
| 2 | static void timerCounterUpdater() { |
| 3 | timerCounter++; |
| 4 | } |
| 5 | END_OF_STATIC_FUNCTION(timerCounterUpdater); |
| 6 | |
| 7 | |
| 8 | /* ... */ |
| 9 | |
| 10 | install_timer(); |
| 11 | /* Make sure the function and variable doesn't get swapped out */ |
| 12 | LOCK_FUNCTION(timerCounterUpdater); |
| 13 | LOCK_VARIABLE(timerCounter); |
| 14 | |
| 15 | /* Update timerCounter with 60 frames per second */ |
| 16 | install_int_ex(timerCounterUpdater, BPS_TO_TIMER(60)); |
| 17 | |
| 18 | |
| 19 | /* Inside your main loop: */ |
| 20 | |
| 21 | /* Never skip more than 6 frames per update */ |
| 22 | int maxSkip = 6; |
| 23 | int curSkip = 0; |
| 24 | if (timerCounter > 0) { |
| 25 | do { |
| 26 | |
| 27 | /* actual logic here */ |
| 28 | |
| 29 | /* Book keeping */ |
| 30 | timerCounter--; |
| 31 | curSkip++; |
| 32 | if (curSkip >= maxSkip) { |
| 33 | timerCounter = 0; |
| 34 | break; |
| 35 | } |
| 36 | } while (timerCounter > 0); |
| 37 | needsRefresh = TRUE; |
| 38 | } |
| 39 | |
| 40 | if (needsRefresh) { |
| 41 | needsRefresh = FALSE; |
| 42 | |
| 43 | /* display code */ |
| 44 | } |
I use this exact same code because its the smoothest movement I've been able to get.
Has anyone else used this code and gotten good results with mem->vram on a computer that's NOT a P4?
I would have a memory bitmap that I render all of my memory bitmaps and such to, then blit that same memory to my video bitmap "buffer", THEN call request_video_bitmap(buffer)?
Yes.
As for your other computer being so slow... not sure why it would be such a big hit, it is a Celeron though which makes me wonder. The code you posted from spellcasters site should lock the FPS to 60 no matter how laggy the machine, but a slower machine that can't keep up will of course look a bit jumpy. Other than that I don't really know how to help you.
Actually there are methods you can use to speed up the slower machine. I would research a method called Dirty Rectangles, this essentially only redraws what has changed between buffers rather than updating an entire screens worth of data. It's a simple method but requres more code and in some cases more memory.
Hey Steve,
You were a big help just by answering my hybrid question. At least I know I was doing THAT right! 
I'll just have to figure out something for the slower computers. Yeah, and I don't understand why this is an issue with a Celeron, too! I wonder if it has something to do with bus speed or something? I DID, on the other hand, change places where masked_blit was called and the pic wasn't a sprite to blit and I got a 3 FPS increase.. 
So now I'm at 41 FPS now.
EDIT---
What do yo know?? It was the clear_to_color call that I had in the drawing code. I was actually using it for screen transitioning, but it's REALLY not needed. Thanks for your help with this Steve! I wouldn't have been able to figure this out without you!