I'm not sure about answering your question. But you could get faster gfx results if you use AllegroGL or OpenLayer. 
What affects the speed of bliting of memory bitmaps -> memory bitmaps and memory -> video?
Bus Speed (FSB)?
Cache Memory?
RAM?
VRAM?
Amount of space on hard drive?
Or anything else you can think of?
I'm just really trying to understand this one thing that keeps bothering me: Even though 40 FPS is playable, but what is soooo different from having a 1.1Ghz, 100FSB, 640 RAM, 128 VRAM (which doesn't seem to old) and having 2.8Ghz, 400FSB, 1GB RAM, 380 VRAM?? I know that the later is a helluva lot faster, but why would someone HAVE to have that in order to achieve 60FPS?? Now there are points where I can get 57 FPS on the first computer, which is great, but as soon as I have to scale an image or have a large sprite displayed (640x300). I use this code for my timing loop:
| 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 a hybrid of double buffering and triple buffering (to achieve blending) and draw everything to a memory bitmap, then blit the mem bitmap to a video bitmap, then request the video bitmap.
Any suggestions will be of great use! If I can just get past this, I can leave you all alone and finish my work.
]]>YOu might be interested in downloading and compiling and running this file.
]]>
I'm not sure about answering your question. But you could get faster gfx results if you use AllegroGL or OpenLayer.
One last question to answer all my questions
Someone inform Lord Sauron that the One Question has been found.
]]>Look into dirty rectangles, there really is no sense to blit an entire buffer if you don't have to . Basically keep a list of dirty screen areas and only blit those, that should speed it up alot on older computers. You can literally acheive thousands of frames per second if you do things wisely.
I'm just wondering why you'd want to blit between various paging and bitmap types and then blit again to the screen. that's your bottleneck. And remember, using triple buffering has a completely different way of handling your display/logic code and when you're using video bitmaps (triple/paging) it's best to not do any locking of surfaces, whereas using memory bitmaps to the screen, it's best to lock. I think 
What is it you're trying to do?
]]>You can literally acheive thousands of frames per second if you do things wisely.
Or if you think wisely, you'll realize that FPS is a false benchmark 
YOu might be interested in downloading and compiling and running this file.
Thanks CGames, I'll run that in a few minutes. It looks like a great testing file that I really need to see!
I'm not sure about answering your question. But you could get faster gfx results if you use AllegroGL or OpenLayer.
Richard, I was considering that, but I don't want someone to HAVE to have OpenGL and such for it to run nicely. But, it seems I may have to reconsider in the future.
Someone inform Lord Sauron that the One Question has been found.
So friggin funny...:) But, I DO believe that it THE one question that will help in creating the ultimate solution for MY problems. I don't know about anyone else's.
What is it you're trying to do?
Hey Neil,
I just want to have smooth animations in my games for systems as low as 500 Mhz with 16 - 8 MB vram. I've tested an all vram->vram approach on that type of machine and the animations were flawless!! But I also want to use some blending as well, which I've found out that blending on video bitmaps is slow. So I was told about using all memory bitmaps for animation and when drawing to the screen, just draw the mem bitmap to a video bitmap and request it. Which has helped, and even achieved 45 - 50 FPS with like 30 sprites drawn, but with a bigger sprite drawn, it slows down to like 30 FPS and looks like slow motion sort of. I just want to know if that's the best I can get with a machine that isn't a P4 machine. I understand it may be slower on a 300 - 500 Mhz machine, but 1.1Ghz, 640 MB RAM, 128 VRAM?? That's what I want to know. If someone HAS to have P4 for the best results, fine. I just want to know if that's the best i can get for what I'm trying to do.
Or if you think wisely, you'll realize that FPS is a false benchmark
Hey Tom, yeah I know not to rely on FPS, but you can also tell in the animation some. For those of you whow need my drawing code:
The timing loop is already in the first post, I've drawn everything to a mem_buffer, then drew the mem_buffer a video buffer, than blited the video buf to the buffer, which is also a video buffer(for some reason, that way gave me a better performance). Then here's how the buffer is handled:
| 1 | // function one is called before the drawing is done |
| 2 | void BeginDrawing() |
| 3 | { |
| 4 | acquire_bitmap(buffer); |
| 5 | //clear_bitmap(buffer); |
| 6 | } |
| 7 | |
| 8 | // function two is called after everything is drawn to the buffer I'm using triple buffering |
| 9 | void EndDrawing() |
| 10 | { |
| 11 | release_bitmap(buffer); |
| 12 | |
| 13 | switch(videoupdatemethod) |
| 14 | { |
| 15 | case DOUBLEBUFFERING: |
| 16 | blit(buffer, screen, 0, 0, 0, 0, SCREEN_W, SCREEN_H); |
| 17 | break; |
| 18 | |
| 19 | case PAGEFLIPPING: |
| 20 | show_video_bitmap(buffer); |
| 21 | |
| 22 | if(buffer == pages[0]) |
| 23 | buffer = pages[1]; |
| 24 | else |
| 25 | buffer = pages[0]; |
| 26 | break; |
| 27 | |
| 28 | case TRIPLEBUFFERING: |
| 29 | do { } while (poll_scroll()); |
| 30 | |
| 31 | request_video_bitmap(buffer); |
| 32 | |
| 33 | if(buffer == pages[0]) |
| 34 | { |
| 35 | buffer = pages[1]; |
| 36 | } |
| 37 | else if(buffer == pages[1]) |
| 38 | { |
| 39 | buffer = pages[2]; |
| 40 | } |
| 41 | else |
| 42 | { |
| 43 | buffer = pages[0]; |
| 44 | } |
| 45 | break; |
| 46 | |
| 47 | default: |
| 48 | |
| 49 | break; |
| 50 | } |
| 51 | } |
Hope this helps! I'll let you know about my results for the test as well, CGames.
EDIT--
Hey CGames!! Thanks for that memtest program! That helped me out tremendously. It helped me optimize my code even more and maintain a consistant 50 FPS on my lower end machine! Thanks for all of your help all!
]]>Like I said, in the case of video buffers, don't acquire_bitmap, use that only for memory bitmaps.
]]>To clarify what Neil said (before someone quotes him out of context), only use acquire_bitmap when blitting from memory bitmaps (or non-accelerated video bitmaps) to a video bitmap.
]]>Wow, I'm impressed that program I wrote like 2 years ago came to any use
To clarify what Neil said (before someone quotes him out of context)
Thanks Matthew, you've saved me from X-G for another week
To clarify what Neil said (before someone quotes him out of context), only use acquire_bitmap when blitting from memory bitmaps (or non-accelerated video bitmaps) to a video bitmap.
And when doing this, I should acquire the video bitmap or the memory bitmap?
]]>You acquire the target video bitmap right before you do all the drawing and then release it immediately after. It should be as fast as possible, with nothing else occurring in between.
]]>Oh ok. Yeah, that's what I'm doing then. Thanks for your help!
]]>