Hi!
I noticed that the RawRestoreScreen function is awfully slow.
Check out these frame dropoffs on my P4 2,4GHz (at 640x480):
8-bit: 390fps -> 280fps
16-bit: 200fps -> 145fps
32-bit: 100fps -> 75fps (even 45fps in a scrolling room of mine!)
Now imagine the framerate on slower computers...
All this by using a single RawRestoreScreen in the rep_ex, nothing else!
It's not surprising, I guess, since it has to copy an entire background image back onto the screen, right?
But most plugins don't seem to have this problem. Is it because they have direct access to the Allegro library functions? (I'm no programmer, so I'm sorry if I get this all wrong.)
If so, has the RawRestoreScreen function the potential for speed improvements in the future as well?
Since I suppose most of the time RawRestoreScreen is used just to clear the screen, how about this:
An additional layer/overlay of some kind in front of the background image. The rawdraw functions could draw upon this layer and a RawClearScreen(0) for example could simply wipe this layer clean?
There are so many sweet things that can be done with the RawDraw functions, it would be a shame not to use them because of speed issues of a single function.
Thanks for reading. :)
RawRestoreScreen just does a raw bitmap copy from the RawSavedScreen to the current background - there's not really any way I can optimise that.
Plugins don't tend to have this problem because they aren't copying such large chunks of data on a regular basis.
Bear in mind, a 640x480x32 image is 1.2 MB, and in repeatedly_execute called 40 times a second that's 48 MB/sec of raw memory copying, which is bound to impact the overall game speed.
That's the problem. Is there no way around this if all I want to do is clear the screen (with the background image intact)?
Is it (technically?) necessary that the RawDraw functions manipulate the background itself?
I don't know what other people use them for, but wouldn't a seperate rawdrawing-layer in front of the background be an alternative?
I imagine simply having to wipe this layer would speed up rawdraw operations significantly.
There could be a seperate layer, but it would probably be slower since it would have to be drawn transparently on top of the background on a regular basis - much like an overlay.
Generally, the RawDraw functions arne't used in repeatedly_execute, but are used from time to time to change what's on the screen. I'm not sure that ther'es an easy solution to speed them up.
If I understand you correctly, with this approach the frame rate would go slightly down in general if you use RawDraw functions at all, with a significant performance gain if you use them in rep_ex?
Sounds like a good trade-off to me. :)
Well, all RawDraw functions take time, yes. The performance hit won't usually be noticable, unless you use RawRestoreScreen or RawDrawFrameTransparent in repeatedly_execute.
So if you just use the Raw functions to alter the look of a scene now and then, there shouldn't be any performance hit.
What I mean is this:
If you DON'T use the RawDraw functions in rep_ex, and only use them now and then as you say, there won't be a noticable difference if you use an additional overlay to draw upon.
But, if you DO use the RawDraw functions in rep_ex, there will be a significant performance gain since you don't have to use RawRestoreScreen to clear the screen.
Wouldn't this RawDraw overlay be a nice thing implement then?
Well, that depends on the performance overhead of having an extra overlay on the screen. For example, try creating a full-screen sized character or CreateGraphicOverlay and see when happens to your frame rate.
A single-color, partly transparent graphic overlay double the screen size causes about 15fps dropoff on my computer (640x480x32).
You're right, not much difference to RawRestoreScreen... :-\
Thanks anyway. :)
Edit: One last thing.
You said:
QuotePlugins don't tend to have this problem because they aren't copying such large chunks of data on a regular basis.
You mean restoring the background image?
Then how does the SnowRain plugin manage to be so fast? It has to clear the screen too somehow, right?
AGS redraws the screen each game cycle anyway, so the snow/rain plugin just re-applies its effects each time.
I see. Thank you!
Sorry for being such a pain, but if plugins can draw directly onto the screen (that gets redrawn by AGS), could that be made possible from within AGS too?
Actually I suddenly have a strange idea, but I don't know if it's feasible to implement.
That is, if you rawdraw with colour 0, instead of painting with solid colour, you paint with pixels from the saved screen in RawSaveScreen(). This can be handy in wiping out a portion of stuffs raw drawn on a portion of the screen and you can make many other effects with it (obviously).
It might be better to have say:
RawSetDrawMode(MODE_RESTORE);
RawSetDrawMode(MODE_NORMAL);
to keep code compatibility.
Interesting idea - could be quite a hassle to implement though, I'll have a think about it.
The main performance hit is in scrolling rooms, obviously, since it has a larger image to copy.
So how about only restoring the current screen area? That would boost performance considerably for me.
After all, the function is called RawRestoreScreen. :)
That should be relatively easy to implement, no?
I have my dynamic rain script up and running, I'm just not quite satisfied with the speed. The script execution and rawdraw functions themselves are very fast, only the rawrestorescreen function needs optimizing.
It can be slow if there're multiple bg frames too, as the raw draw functions draw on all frames simultaneously, so the RawSave/RestoreScreen() functions has to save/restore all the frames simultaneously.
I don't quite agree on just restoring the visible viewport part, as it can be quite messy that it doesn't restore the off-screen changes.
So I think implementing some other functions to restore part of the BG may be a better idea (like I suggestioned before, even only one function that restore a rectangular area can be handy).
Yeah, come to think of it, a simple rectangular function would be even better.
The way my rain script works, you assign layers of rain to rectangular target areas, so you can also do rain outside a glass window, for example.
Such a function would enable me to restore just the target area. Should be awesome.
QuoteIt can be slow if there're multiple bg frames too, as the raw draw functions draw on all frames simultaneously, so the RawSave/RestoreScreen() functions has to save/restore all the frames simultaneously.
Really? :o
Good to know, thanks.
Actually, only the current background frame is used by the Raw functions.
Some sort of RawRestoreArea function is a good idea, I'll add it to my list.
Heh actually I'd never tried rawdrawing on a room with multiple frames before, but someone did a test and told me it was drawing on all the frames, so I believed it and I think it should be done that way.
Now I had just done a little test, and verified that it only draws on the current frame, BUT that can cause problems.
The problem was that I just noticed if you use RawRestoreScreen() it will restore the saved screen to the current frame. This can be messy if you do something like below (but can also be handy if it's your intention):
In a room with 2 different bg frames do this:
- When in frame #0, RawSaveScreen() and then raw draw something on it.
- Switch to frame #1, and call RawRestoreScreen()
The result was that frame #1 got overwritten by the saved bg image of frame #0
I think this feature can be handy if you are aware of how it works and always do things right, otherwise it can be confusing.
So I think it's okay staying that way, but needs to be more documented of teh phenomenon so people using these features can be more adware of it.
Yeah, I'll document this behaviour in the manual.
I think it can be useful, because you can do neat tricks by restoring one frame onto another.
But the down side is that you cant rawdraw on 2 or more frames simultaneously, and then restore them both to their original states (unless the player leaves the room).
--EDIT--
I suddenly have an idea, is that you can save up to 5 bgs simultaneously (because there're a limit of 5 bg frames/room currently I think). So all we need is a new function:
RawSelectScreenSlot(int slot)
which will select the save slot you save the screen to or restore from.
I know this can increase memory consumption drastically but it's the game creator's own resposibility to choose whether he should use it (if a slot is not used, it won't consume memory, furthermore these saved bgs are automatically destroyed when the player leaves the room currently I think).
Of course, it would also be nice if we can have functions like:
RawSaveBGframe(int frame)
RawRestoreBGframe(int frame)
which can operate on frames currently not visible.
I know that's fantasy, but it's just a sudden idea flown up in my mind, they're not feature requests and I don't really need them (at least for now), just think they can be nice and probably not difficult to implement.
Interesting idea - yeah they wouldn't be hard to implement. But, I haven't heard anyone really needing such a feature, and as such it would seem a waste of time to add it.