Had some thoughts about the issue of scaling (in fullscreen mode) to the native screen resolution. Out came an implementation proposal of the stuff discussed earlier:
http://lists.nongnu.org/archive/html/adonthell-artwork/2010-08/msg00006.html In v0.3, scaling to double size was implemented by actually scaling each object after it had been loaded. This is probably efficient up to a certain factor, because scaling only has to happen once. However, it also increases the amount of drawing that is done per frame. Since objects overlap (and much more so with the 3Dness of v0.4), I guess that at some point memory consumption and rendering of large objects will cause more strain than scaling the final frame before it's blitted to the screen. Imagine a screen size of 320x240 and a 30% overlap: 320x240x1.3 = 99840 Scaled to 640x480 beforehand would give: 640x480x1.3 = 399360 Compare that with rendering 320x240 first and then scaling to 640x480: 320x240x1.3 + 640x480 = 407040 Virtually the same number of pixels for scaling a pretty small view by a factor of 2 after the frame is rendered. But we'll have a larger view and larger scaling factors as well, so I hope that proves my gut feeling right. The great thing is how this will make the implementation almost trivial. We update the screen class to return a shadow surface when the scaling isn't 1:1. This is always the size of the internal resolution. In the blit function, this is then scaled onto the actual screen surface. That limits all the changes to the screen class and leaves the rest of the engine untouched. It will probably also mean that a true SDL 1.3 backend could do the scaling on the GPU. Figuring out the internal resolution and scaling factor can be done automatically (with optional overrides via configurations where this might fail). Get the primary screen resolution and compare that to the min and max length and height we want to allow. If it fits inside, we're fine, otherwise we up the scale factor by 1, divide the screen resolution and check again until we find a match. The divided screen resolution will become our internal size of the shadow surface and we also store the scaling factor. (We'll need this for mouse or touchscreen input and of course for the blitting). Things to keep in mind when doing this: * Cutscene graphics need to have the size of the maximum internal resolution (640x512) and will probably have to be centered on screen. * GUI elements can not be implemented with a fixed width and height, but need to be adapted to the internal screen size dynamically. As an addition, this should also work for enabling scaling in the editors (where the user would be able to toggle the scaling factor dynamically at runtime). We'd have the screen class as the component where scaling will happen and (I hope) only a few places where coordinate conversion has to occur. Comment? Objections? Suggestions? Kai P.S: I know I wanted to concentrate on scrolling next, but I didn't have much inspiration for that yet. So better to work on stuff where I do have ideas. _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
