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

Exclusive 8-bit palette in fullscreen with directx sometimes messed up #408

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

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.13
Reported for operating system, platform: Windows Vista, x86

Comments on the original bug report:

On 2008-05-30 19:35:28 +0000, Moritz Kroll wrote:

I have a very strange mostly reproducible problem on Windows Vista Business 64 SP1 on a Intel Core 2 Quad Q6600 with an NVIDIA GeForce 8600 GT (512 MB). Sometimes, when I start Wolf4SDL v1.5 (http://www.chaos-software.de.vu) in fullscreen at 640x400, the palette is partly or even completely wrong. Then any fading effects take a very long time and some colors fade much slower than others (smells like dynamic remapping of colors, although the palette is exclusively allocated with SDL_HWPALETTE and SDL_FULLSCREEN). The actual monitor resolution is then 640x480 and the lower 40 pixel of the 640x400 part get different colors than the rest of the screen.

Trying to create a minimal test case, I was able to make the bug more reliable in sense of reproducibility, although the results sometimes differ. And as I'm writing this, the bug does not appear at all... But I created several photos (screenshots don't show anything useful) and some videos with different settings to show this strange bug. They are available at http://www.stud.uni-karlsruhe.de/~uvaue/chaos/sdlpal/
The paltest.txt describes which defines were used for which tests.
http://www.stud.uni-karlsruhe.de/~uvaue/chaos/sdlpal/paltest2.cpp is the source code of the test case.

The set of test cases initializes video, audio and joystick for directx, then sets the video mode with different flags. Then it sets a palette with SDL_SetColors, writes a checkerboard to the screen surface, updates the rect and waits 3 seconds. After that it enters the main loop waiting for events and handling mouse buttons. While at most times, the screen looks correct when starting to wait the 3 seconds, the screen is heavily altered after the delay (see for example the videos of test4 and test9). As you can especially see in the test.txt file of test9, the surface content is changed during SDL_Wait and by calls to SDL_SetPalette!
Setting the palette with the left mouse button then changes the palette in different ways depending on the used flags and the mood of SDL or DirectX.
Recovering the surface data with the right mouse button, stabilizes the situation sometimes.

When fullscreen is disabled, everything always works fine (test11).

Expected results (with SDL_HW_PALETTE):
For STARTWITHGAMEPAL defined, a checkerboard with 256 different colors is displayed and pressing any mouse buttons doesn't change anything.
Without STARTWITHGAMEPAL defined, first one sees a gray screen with two white horizontal bars. Pressing the right mouse button doesn't change anything, but pressing the left mouse button shows the checkerboard by setting the correct palette.

Sorry for the confusing bug report, but if you have a look at the pictures/videos you'll understand my confusion.
To make it clear, I use SDL_HW_PALETTE and SDL_FULLSCREEN to get exclusive palette access for full 256 colors. Still test4 shows the typical 20 reserved colors.

On 2008-05-30 19:36:25 +0000, Moritz Kroll wrote:

Created attachment 254
Test case

On 2009-04-13 01:57:35 +0000, Sam Lantinga wrote:

There was a fix for DirectX palettes just checked in, can you try it out and confirm whether this issue is fixed?
http://www.libsdl.org/tmp/SDL-1.2.zip

On 2009-09-13 16:33:15 +0000, Ryan C. Gordon wrote:

Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.

On 2009-09-21 01:38:53 +0000, Sam Lantinga wrote:

There hasn't been any feedback on this in a year. Please reopen the bug if it hasn't been fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant