Donny Viszneki <smirk thebuicksix.com> writes:
So there s no other way beside destroying and reloading all
textures… damn… got a love Microsoft…
Just think about commercial games like Quake or Doom, they need to
reload everything after a resolution change too. No way arround it
least on windows).
A resolution change is different than changing to full screen. Games
reload their textures after a resolution or color change specifically
to reformat them for the new video mode. If you are in 1024x768 video
resolution, then the game will load relatively large versions of all
textures for high texture detail. However, in 640x480, it will load
much smaller versions.
I must disagreed with this… screen resolution and textures
resolution are two
different things… for instance… normaly, ui items such as player
at 128 x 128 pixels should remain the same width and height at any
resolution… (otherwise, changing screen resolution from 1024x768 to
will shrinked all your pixel art and leave unwanted artefacts and/or
data… but will still take a 128 x 128 pixels texture in memory.
thats why you
need to notify your gl projection matrix on every resize what s your
resolution… to scale, position, and rotate any ui elements at their
This isn’t entirely relevant. Whether or not a game chooses to scale
your HUD objects under different resolutions so that they have the same
visual footprint has nothing to do with what I was talking about. What
I am talking about has to do with things in the 3D scene, not things
that are rendered “flush” with the screen.
The reason it does this is because at lower
resolutions, it may not be possible (or highly improbably) to see many
(or all) textures at a detail level that would benefit from a larger
texture map. Typically this downsampling occurs at the time the
textures are loaded (which is why it takes so long.)
if my understanding is correct, that will apply to 3d objects vs the
of the camera s pov… and it is called Multi sampling or mipmapping
You are so close to understanding what I’m saying it’s amazing you
didn’t make it all the way.
… and it
should be handle automaticly by opengl… i m not sure how that work
loading and unloading all different texture resolutions…
Yes, mipmapping is used to provide texture smoothing without having to
use extremely high detail filters in real-time. But that’s not what I’m
talking about exactly.
I’m talking about conservation of vide memory. This allows games to
load more things onto video memory (more textures,) or swap less data
with the video card to make up for the lack of room in video memory
(faster graphics performance, faster bus performance all around,) and
will work on more video cards (lower video memory requirements.)
Here is a really abstract example of what I’m saying. It’s a very
extreme situation so don’t say anything like “that’s so impractical it
would never happen.” It’s extreme deliberately so that you cannot miss
the point I’m trying to make.
Imagine you had very highly detailed images of the surface of Mars. And
you were making a space exploration game or something. Let’s say in one
mission you go into orbit around mars. If you load giant texture maps
you may not have enough room on video memory. Now mipmapping WILL speed
up PERFORMANCE of rendering because it decreases the level of filtering
needed in real-time. However you are still occupying a huge amount of
video memory. If a player is playing on a lesser machine, ergo a lower
resolution, taking up this much video memory is USELESS. The player
will NEVER SEE that level of detail of the texture map. OpenGL’s
mipmapping features will definitely do a good job at choosing which
level of detail to use WHILE RENDERING, but it does nothing to help you
choose which level of detail to use WHILE LOADING.
There are many aspects of computer gaming that are proportional to each
other relating to players’ video hardware:
As you decrease any one of these, you will likely find the other two
aspects decreasing (and many more aspects, but these are perhaps the
only real relevant ones.) Thus, if a person is playing at a lower
resolution on Machine-A than Machine-B, there’s a good chance he has
LESS VIDEO RAM than Machine-B. Thus you should try to load less data
into video ram on Machine-A than Machine-B.
Many independent games ignore this because it’s a lot of work they
don’t feel like doing, and in independent games, the number of
bottlenecks you iron out of your game engine are usually much lower
than that of commercial games. This bottleneck is not extremely high on
the list of bottlenecks, and thus can be ignored by developers if they
are already satisfied with their game’s speed, or if they are working
on bigger bottlenecks at the moment.
If there is still any confusion about this feel free to ask.On Sep 26, 2004, at 5:23 PM, Golgoth wrote:
On Sep 26, 2004, at 3:26 PM, Michael Prager wrote: