SUGGESTION: Buffer background frame for RawDraw

Started by GarageGothic, Sat 22/07/2006 14:06:05

Previous topic - Next topic

GarageGothic

Since the DynamicSprite commands were introduced, I've been using them for pretty much any special effect in my games.  Certain effects, that required manipulation of the full screen were very slow though (due to repeatedly creating a sprite from a screenshot, duplicating it and cropping it within the same loop). For the same reason, I previously suggested adding the option of specifying coordinates in CreateFromScreenshot as in CreateFromBackground.
That is, until I saw the workaround used in SteveMcCrea's lake module of using ANOTHER background frame as a buffer. I.e. pasting the image onto that frame and using CreateFromBackground to manipulate parts of it. This was an ingenious solution and also helps greatly in a lot of other cases. This got me thinking about other uses for such a frame, and the problems it currently creates.

Therefore, I would like to propose the implementation of a 6th background frame. It would always be present, always the same size as the first frame, filled with the color (255, 0, 255) and not usable as an animating background frame. It would purely be used as a buffer for RawDraw routines.

1) This would make life easier for module makers, because the end user didn't have to be instructed to create an additional background frame for every room using their effects.

2) In addition, it could safely be used without messing up an animating background.

3) I assume a RawClearScreen is much quicker than RawRestoreScreen, speeding up pretty much any effect RawDrawing and creating DynamicSprites from the screen. (such as text deformation, colored text and other modules). It would also get rid of the issue - common when using multiple modules by different authors - of the screen being unnecessarily RawRestored several times each loop.

Thanks for reading this. I think this suggestion could be helpful to lots of people.

Pumaman

#1
Well, my plan is to objectise the Raw Drawing functions and in the process allow any dynamic sprite to be used as the "target" for the raw drawing, such that you could simply create a screen-sized sprite and then use it as your buffer. Not sure when I'll get round to doing that though.

GarageGothic

#2
Thanks for the reply, CJ. It sounds like this would solve the problem.

Perhaps when you change the RawDraw routines to support sprites,  you could think of adding a feature I've suggested before, of copying the alpha channel of one sprite to a DynamicSprite of the same size?

Edit by strazer:

Are you talking about this tracker entry?

SMF spam blocked by CleanTalk