adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Scaling


From: Kai Sterker
Subject: [Adonthell-devel] Scaling
Date: Sun, 31 Oct 2010 11:34:07 +0100

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]