Running Blitz Full Speed/Drawing Images Offscreen
BlitzMax Forums/BlitzMax Beginners Area/Running Blitz Full Speed/Drawing Images Offscreen
| ||
| Hello. I have a couple of questions: 1. Is there a way to run one of my programs from the Blitz IDE, so that 99-100% of the processor time is devoted to it - without closing all the other applications (I usually have open down). Would I need to disable the Virus checker as well? 2. If I draw objects offscreen using the DrawImage command am I right in assuming that nothing will actually happen - I am doing this for a scrolling game. I figured I wouldn't need to do a check to see where the view window is because if Blitz *automatically* didn't draw such objects - then no processor-time would be wasted. Thanks for any help :) |
| ||
| 2) The GPU will auto clip the objects so there isn't that much of a hit. I did some stress tests a while back and there was a slight performance increase if you recognized an object was off the screen and didn't render it. But it was slight. However, if an object's alpha = 0 then you should not render it. ;) |
| ||
| 1. I do not think this is possible. In fact, I don't think it is possible at all. To not return time slices to any other apps running on the machine? I doubt it. 2. Try it and find out. Would be an easy thing to try. Draw 2000 images on screen check speed. Then draw 1000 on screen and 1000 off screen, check speed. Then just draw 1000 on screen, check speed. |
| ||
| I believe when you flip(0) most of the time, if not all, is absorbed by the application. I have gotten in to problems when trying to access other applications when running my main applications at full speed with flip(0). Sometimes I have to add a Delay(ms) for it to start giving access to the rest of windows but maybe there is another reason for it that I am not familiar with. |
| ||
| If you do a Flip 0 and you don't poll the system for events then you will hog the cpu (core). Even if you do wait for events, you will still hog most of the cpu time. Trying to draw an object off-screen takes some cpu and gpu time - the cpu has to send instructions to the graphics card about what to try to draw, and the graphics card has to think about whether any of the pixels are within the viewport. Of course it will clip the graphics since there is no offscreen areas in the backbuffer, but it still has to think about each pixel in the image to see if it's visible. So you do save at least some time if you can void even trying to draw such objects. But it's a matter of how much time you save, and for just drawing a bunch of 2d quads it isn't going to be that significant. |
| ||
| IH, I am pretty shure delay is how you free time for the cpu for other uses. this is a rip part of the flip command and its how it deals with it:
.
.
Local dt=_syncTime-MilliSecs()
If dt>0
Delay dt
Else
.
.
just look at the source for flip(). Yes, there is a possibility I am missunderstanding it. |
| ||
| Thank you very much for all the help I've just made a test program and it appears to be a *lot* faster by doing a check to make sure the image is going to be displayed inside the screen boundary before doing a DrawImage call. BTW will Flip 1 also absorb all the CPU time (like Flip 0) ? |
| ||
| 2. If I draw objects offscreen using the DrawImage command am I right in assuming that nothing will actually happen Nope, sadly. I've tested this in a realtime environment - drawing thousands of images off screen will result in a hit. Simply wrapping the drawimage command with soemthing that calculates whether the image is in visible boundaries gave me a 100 fps boost. Seems to me that something like this should probably be added straight into Max2D really. I did some stress tests a while back and there was a slight performance increase if you recognized an object was off the screen and didn't render it. But it was slight. My program suffered a ~20% decrease in speed, I wouldn't call that slight. |
| ||
| Flip 1 will be a bit friendlier to the operating system. If it has to wait for the vertical blank then it sits in its little loop (which someone pasted above) and if it's not time to do the flip yet it gives control to the o/s to do other tasks. So yes it's friendlier than Flip 0. Flip -1 is friendly too. Otherwise you can just use Delay 1 to give the o/s a little bit of time. |
| ||
| Ok - Thanks :) Yes it would be good - Hotcakes- if the DrawImage command automatically did these checks - but maybe they would slow down DrawImage commands that are inside the screen boundary - especially if you were drawing a large number of objects. I got a similar result to you performance-wise when I added the checks. |
| ||
| maybe they would slow down DrawImage commands that are inside the screen boundary Well, it's just a few extra checks to the width and height of the image and the screen res for each call. Of course that's not free. I couldn't see it being too expensive, though I havn't done any tests on a game that doesn't draw images off screen. |
| ||
| "My program suffered a ~20% decrease in speed, I wouldn't call that slight." Interesting. In my tests I had 1000's of objects, but not 1000's at a time being rendered off screen. I do stand corrected, because at that point if you have 100's of objects being rendered off screen that will indeed take a hit. I could see some kind of space game where there are lots of ships, planets, etc, flying around and in that scenario it would be better to compute the size of the objects taking into consideration scale, etc, etc, and if they are completely off screen don't render them. |
   |