You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bug report was migrated from our old Bugzilla tracker.
Reported in version: don't know Reported for operating system, platform: Windows (All), x86
Comments on the original bug report:
On 2006-01-31 11:27:23 +0000, Sam Lantinga wrote:
Date: Wed, 04 Jan 2006 22:20:12 +0100
From: Manuel Bilderbeek manuel@msxnet.org
To: sdl@libsdl.org
Subject: [SDL] PRINT (Print Screen) key event and full screen problems in wind
-- Message: 19392 -- Next: 19393 ----------------------------------------
Then the second problem. Our emulator has a way to set the output window
to 960x720 (3 times 320x240). When setting SDL to full screen, this
works fine on X11 and with the windib driver. On one of our (Windows
using) team mate's laptop, he gets a 1400x1040 resolution (with borders)
then. But, when using the windx driver, he gets an error, caused by the
fact that no surface can be created with a SDL_SetVideoMode call... A
similar thing happened on one of our other Windows team member's machine.
Normally, SDL simply does the next-larger resolution with borders, which
indeed worked for the windib driver. But it did not work for the windx
driver! So, why doesn't it work with windx, while it does work with
windib, that resolution, albeit with borders on 1400x1050?
If we modify the code and choose the nearest resolution ourselves
(1024x768), it does work on that same system.
On 2006-03-14 01:29:26 +0000, Sam Lantinga wrote:
I tried this myself, on my desktop PC, and the DirectDraw driver chose 1024x768 and centered it just fine.
I've sent Manuel e-mail asking if the bug is still active with CVS code.
On 2007-02-12 06:19:59 +0000, Ryan C. Gordon wrote:
As we're coming up on a year without hearing more on this bug, we'll assume it really was fixed at some point and flag the bug as WORKSFORME.
Please reopen if the bug is still present.
--ryan.
The text was updated successfully, but these errors were encountered:
The code in OGC_UpdateTexture was not calling DC_FlushRange() after
modifying the texel data. Since the code obtained when adding this call
is very similar to the implementation in OGC_UnlockTexture(), move the
texture updating code into a common function.
This bug report was migrated from our old Bugzilla tracker.
Reported in version: don't know
Reported for operating system, platform: Windows (All), x86
Comments on the original bug report:
On 2006-01-31 11:27:23 +0000, Sam Lantinga wrote:
On 2006-03-14 01:29:26 +0000, Sam Lantinga wrote:
On 2007-02-12 06:19:59 +0000, Ryan C. Gordon wrote:
The text was updated successfully, but these errors were encountered: