Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

full screen problems in windib/windx drivers #40

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

full screen problems in windib/windx drivers #40

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels
worksforme We can't reproduce the bug

Comments

@SDLBugzilla
Copy link
Collaborator

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.

@SDLBugzilla SDLBugzilla added bug worksforme We can't reproduce the bug labels Feb 10, 2021
madebr pushed a commit to madebr/SDL that referenced this issue Mar 19, 2023
…bsdl-org#40)

* check for validity of Y and UVplane by error checking metal calls

* added detailed messages
Wohlstand pushed a commit to Wohlstand/SDL that referenced this issue Mar 21, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
worksforme We can't reproduce the bug
Projects
None yet
Development

No branches or pull requests

1 participant