Project

General

Profile

Bug #534

Unable to change resolution

Added by mochtroid-x about 16 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
2008-10-09
% Done:

100%


Description

In svn 5018 you are unable to change to resolution higher than 640x480 without a crash or the screen being extremely scaled down in the lower left corner.

Labels: OpenGL Renderer

History

#1 Updated by danij about 16 years ago

I have no problems at all with changing resolution or even going from fullscreen to windowed mode using the current svn head, under Vista.

Most likely this a problem with the interface to SDL for window management which we don't use under Windows.

#2 Updated by skyjake about 16 years ago

I'm seeing this problem in OS X. Seems related to decorations and materials?

Process: Doomsday [25669]
Path: /Users/jaakko/Projects/deng/trunk/doomsday/mybuild/Doomsday.app/Contents/MacOS/Doomsday
Identifier: Doomsday
Version: 1.9.0 (1.9.0)
Code Type: PPC (Native)
Parent Process: sh [25668]

Date/Time: 2008-10-11 18:14:42.714 +0300
OS Version: Mac OS X 10.5.5 (9F33)
Report Version: 6

Exception Type: EXC_CRASH (SIGBUS)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 1

Thread 0:
0 Doomsday 0x000e3e10 R_MaterialCheckNumForName + 132 (r_materials.c:316)
1 Doomsday 0x000e3ec4 R_MaterialNumForName + 44 (r_materials.c:336)
2 Doomsday 0x00057e34 Def_GetDecoration + 108 (def_main.c:420)
3 Doomsday 0x0009cb30 GL_PrepareMaterial2 + 884 (gl_texmanager.c:3227)
4 Doomsday 0x0009cc0c GL_PrepareMaterial + 36 (gl_texmanager.c:3259)
5 Doomsday 0x000e41a8 R_MaterialGetDecoration + 56 (r_materials.c:442)
6 Doomsday 0x000ff65c updateSurfaceDecorations + 260 (rend_decor.c:649)
7 Doomsday 0x0010002c updateSideSectionDecorations + 1468 (rend_decor.c:811)
8 Doomsday 0x00100128 Rend_UpdateSurfaceDecorations + 228 (rend_decor.c:837)
9 Doomsday 0x0010024c Rend_InitDecorationsForFrame + 56 (rend_decor.c:866)
10 Doomsday 0x000e2288 R_BeginWorldFrame + 244 (r_main.c:536)
11 Doomsday 0x0004a5a8 DD_DrawAndBlit + 124 (dd_loop.c:214)
12 Doomsday 0x0004a4f0 DD_GameLoop + 92 (dd_loop.c:180)
13 Doomsday 0x0004b828 DD_Main + 1132 (dd_main.c:427)
14 Doomsday 0x001556f4 SDL_main + 1052 (dd_uinit.c:419)

#3 Updated by skyjake about 16 years ago

To make it crash, I use Ultimate Doom, start E1M1 and then "setres" to a different resolution (windowed mode).

#4 Updated by skyjake about 16 years ago

Further investigation shows that during AM_LoadData() (called from G_UpdateState during reset), GL_UploadTextureContent() is overwriting the memory allocated to the materials array, causing the crash.

This is the code that does the overwriting:

if((content->flags & TXCF_CONVERT_8BIT_TO_ALPHA) &&
(content->format DGL_LUMINANCE ||
content->format DGL_COLOR_INDEX_8 ||
content->format == DGL_DEPTH_COMPONENT)) {
int p, total = content->width * content->height;
byte *pixels = content->buffer;

for(p = 0; p < total; ++p)
    {
// Move the average color to the alpha channel, make the
// actual color white.
pixels[total + p] = pixels[p];
pixels[p] = 255;
}
content->format = DGL_LUMINANCE_PLUS_A8;
}

For some reason, the pixels array is pointing to the same area of memory where the materials array resides. Either the content->buffer is assumed to be of wrong size or there is some other confusion taking place.

#5 Updated by skyjake about 16 years ago

Revision 5944: Fixed memory zone corruption due to out-of-bounds access of content->buffer. This occurred when texture content was being uploaded without deferring. GL_UploadTextureContent() assumed that content->buffer was modifiable, which is only the case when the content has been deferred and copied to a separate buffer. Non-deferred content is still in the zone.

Also available in: Atom PDF