Changing Screen Resolution!

Hi!

I ve post this question in an unrelated thread so I ll make a new one…

On resizing screen resolution all textures have to be destroyed and reloaded…

Is there any way we can resizing the screen resolution and/or toggle fullscreen
witout reloading textures?! (windows)

a routine sample will be apreciated!

Thx

Hi!

I ve post this question in an unrelated thread so I ll make a new
one…

On resizing screen resolution all textures have to be destroyed and
reloaded…

Is there any way we can resizing the screen resolution and/or toggle
fullscreen
witout reloading textures?! (windows)

a routine sample will be apreciated!

From your previous post, the guy you quoted mentioned glXCopyContext().
He says there is a windows function just like it. IIRC, Windows does
not have such a function - they excluded this functionality - and
decided to destroy your OpenGL context on fullscreen toggle -
specifically to the end of making OpenGL games seem fundamentally
inferior to Direct3D games. It’s one of the many subtle ways Microsoft
bends their implementation of accepted standards to justify the
creation of a new product; one which will probably work only on
Windows.On Sep 25, 2004, at 10:48 PM, Golgoth wrote:

Donny Viszneki wrote:

Hi!

I ve post this question in an unrelated thread so I ll make a new one…

On resizing screen resolution all textures have to be destroyed and
reloaded…

Is there any way we can resizing the screen resolution and/or toggle
fullscreen
witout reloading textures?! (windows)

a routine sample will be apreciated!

From your previous post, the guy you quoted mentioned glXCopyContext().
He says there is a windows function just like it. IIRC, Windows does not
have such a function - they excluded this functionality - and decided to
destroy your OpenGL context on fullscreen toggle - specifically to the
end of making OpenGL games seem fundamentally inferior to Direct3D
games. It’s one of the many subtle ways Microsoft bends their
implementation of accepted standards to justify the creation of a new
product; one which will probably work only on Windows.

the simple answer without FUD is: no.> On Sep 25, 2004, at 10:48 PM, Golgoth wrote:

Donny Viszneki <smirk thebuicksix.com> writes:

From your previous post, the guy you quoted mentioned glXCopyContext().
He says there is a windows function just like it. IIRC, Windows does
not have such a function - they excluded this functionality - and
decided to destroy your OpenGL context on fullscreen toggle -
specifically to the end of making OpenGL games seem fundamentally
inferior to Direct3D games. It’s one of the many subtle ways Microsoft
bends their implementation of accepted standards to justify the
creation of a new product; one which will probably work only on
Windows.

So there s no other way beside destroying and reloading all textures… damn…
got a love Microsoft… :wink:

THX Donny!

Golgoth wrote:

So there s no other way beside destroying and reloading all textures… damn…
got a love Microsoft… :wink:

THX Donny!

Just think about commercial games like Quake or Doom, they need to
reload everything after a resolution change too. No way arround it (at
least on windows).

Cheers,
Michael Prager

Golgoth wrote:

So there s no other way beside destroying and reloading all
textures… damn… got a love Microsoft… :wink:

THX Donny!

Just think about commercial games like Quake or Doom, they need to
reload everything after a resolution change too. No way arround it (at
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. 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.)On Sep 26, 2004, at 3:26 PM, Michael Prager wrote:

Donny Viszneki <smirk thebuicksix.com> writes:

Golgoth wrote:

So there s no other way beside destroying and reloading all
textures… damn… got a love Microsoft… :wink:

THX Donny!

Just think about commercial games like Quake or Doom, they need to
reload everything after a resolution change too. No way arround it (at
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 life icon
at 128 x 128 pixels should remain the same width and height at any screen
resolution… (otherwise, changing screen resolution from 1024x768 to 800x600
will shrinked all your pixel art and leave unwanted artefacts and/or lost of
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 new screen
resolution… to scale, position, and rotate any ui elements at their original
size…

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 distance
of the camera s pov… and it is called Multi sampling or mipmapping … and it
should be handle automaticly by opengl… i m not sure how that work regarding
loading and unloading all different texture resolutions… my guess is there s
a split between video card memory and video card processing (whats in
memory)… so all texture s resolutions are keept in memory but only one
resolution is going in to the rendering pipepline… (off topic probably)

Best regard Donny, just trying to clear things up! :slight_smile:

Golgoth> On Sep 26, 2004, at 3:26 PM, Michael Prager wrote:

Donny Viszneki <smirk thebuicksix.com> writes:

Golgoth wrote:

So there s no other way beside destroying and reloading all
textures… damn… got a love Microsoft… :wink:

THX Donny!

Just think about commercial games like Quake or Doom, they need to
reload everything after a resolution change too. No way arround it
(at
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
life icon
at 128 x 128 pixels should remain the same width and height at any
screen
resolution… (otherwise, changing screen resolution from 1024x768 to
800x600
will shrinked all your pixel art and leave unwanted artefacts and/or
lost of
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
new screen
resolution… to scale, position, and rotate any ui elements at their
original
size…

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
distance
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
regarding
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:
video memory
gpu power
playable resolution

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:

At 21:26 26/09/2004 +0200, you wrote:

Just think about commercial games like Quake or Doom, they need to reload
everything after a resolution change too. No way arround it (at least on
windows).

I’ve recently written a native win32 backend for my game and i don’t reload
the textures anymore, because i don’t allow the user to change the bpp
anyway, since the SDL doesn’t work well when SetPixelFormat fails. (well,
now i can add that feature, maybe :slight_smile:
Maybe the SDL could be fixed so it doesn’t request a new pixel format when
it’s not needed.

If you don’t change the bpp you don’t need to reload the textures when
using opengl through sdl on Windows, right?
Alt+Tabbing to minimized app, and then clicking or tabbing back won’t
cause any issues or require reloading of textures?On Mon, 27 Sep 2004 00:08:30 +0200, Hibernatus <combel_t at epita.fr> wrote:

At 21:26 26/09/2004 +0200, you wrote:

Just think about commercial games like Quake or Doom, they need to reload
everything after a resolution change too. No way arround it (at least on
windows).

I’ve recently written a native win32 backend for my game and i don’t reload
the textures anymore, because i don’t allow the user to change the bpp
anyway, since the SDL doesn’t work well when SetPixelFormat fails. (well,
now i can add that feature, maybe :slight_smile:
Maybe the SDL could be fixed so it doesn’t request a new pixel format when
it’s not needed.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Rob Sadedin
No Substance Software (www.nosubstancesoftware.com)

Donny Viszneki <smirk thebuicksix.com> writes:

Many independent games ignore this because it’s a lot of work they
don’t feel like doing,

U mean video memory management?

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.

Developping a 3d engine is such a great challenge… so interesting to learn
every day! my brain is swaping informations in memory all the time! :wink:

cheers!

Golgoth

Hibernatus <combel_t epita.fr> writes:

I’ve recently written a native win32 backend for my game and i don’t reload
the textures anymore,

what else do you use then to resize your screen resolution beside
SDL_SetVideoMode???

Jonathan Atkins writes:

Donny Viszneki wrote:

Hi!

I ve post this question in an unrelated thread so I ll make a new one…

On resizing screen resolution all textures have to be destroyed and
reloaded…

Is there any way we can resizing the screen resolution and/or
toggle fullscreen
witout reloading textures?! (windows)

a routine sample will be apreciated!
From your previous post, the guy you quoted mentioned
glXCopyContext(). He says there is a windows function just like
it. IIRC, Windows does not have such a function - they excluded this
functionality - and decided to destroy your OpenGL context on
fullscreen toggle - specifically to the end of making OpenGL games
seem fundamentally inferior to Direct3D games. It’s one of the many
subtle ways Microsoft bends their implementation of accepted
standards to justify the creation of a new product; one which will
probably work only on Windows.

the simple answer without FUD is: no.

Can I suggest someone make a note about this on the wiki under
SetVideoMode or WM_ToggleFullscreen, whichever is responsible?>> On Sep 25, 2004, at 10:48 PM, Golgoth wrote:

Not in the general case, but not “no”: you only have to reload textures
if you restart the OpenGL context, and you only have to do that if the
pixel format of the window changes. It’s possible to figure out if the
pixel format needs to change before actually doing so, and only recreate
the window and reset the context if so.

This allows changing fullscreen resolutions without a new context, and
also allows changing from a window to fullscreen if the desktop resolution
happens to use the same pixel format that you’re using (which is likely; I
think it only depends on the bit depth).

I don’t know how “portable” this is; that is, whether it works in practice,
or if it’ll trigger too many bugs in drivers, etc. It works for me, though,
and is valid according to the documentation (for what little that’s worth).On Sat, Sep 25, 2004 at 11:02:15PM -0500, Jonathan Atkins wrote:

the simple answer without FUD is: no.


Glenn Maynard

At 08:13 27/09/2004 +1000, you wrote:

If you don’t change the bpp you don’t need to reload the textures when
using opengl through sdl on Windows, right?

As Golgoth said: “what else do you use then to resize your screen
resolution beside
SDL_SetVideoMode???” :slight_smile: And last time i tried SDL_SetVideoMode lost the
opengl context so i had to reload the textures. But perhaps i’ve missed
something.

Alt+Tabbing to minimized app, and then clicking or tabbing back won’t
cause any issues or require reloading of textures?

No it won’t. Works well here.

(to Golgoth: i was talking about a backend that doesn’t use SDL :wink: