0002238: Full screen mode on PPC Mac is a shade of yellow, except where green normally. - OSX

(0008888)
Footkerchief (manager)
2010-06-21 12:04

Do you have any screenshots of this problem? What PRINT_MODE are you using? Have you tried updating your graphics drivers?

(0009204)
MrWiggles (reporter)
2010-06-28 01:06

http://s296.photobucket.com/albums/mm198/aliceingorelandpictures/?action=view&current=Picture7.png [^]

And water is also invisible.

Driver updates is a none issue for Macs largely.

[PRINT_MODE:2D]

(0009207)
oliver (reporter)
2010-06-28 02:47

Do you get the same effect when zooming in windowed mode? If so it's probably the scaling code at fault.

(0009209)
Footkerchief (manager)
2010-06-28 05:50

Do you still get this problem if you change the PRINT_MODE?

(0009399)
Footkerchief (manager)
2010-06-30 13:11

Reminder sent to: MrWiggles

Do you get the same effect when zooming in windowed mode?

Do you still get this problem if you change the PRINT_MODE?

(0009448)
MrWiggles (reporter)
2010-06-30 23:51

When zooming in window mode while under 2D, no the issues does not happen.

Switching to 2DSW seem to have fixed the issue.

(0009449)
oliver (reporter)
2010-07-01 00:31

I think I see the problem. When creating a tile, the 2D HW renderer calls SDL_CreateRGBSurface() with SDL_HWSURFACE and expects the returned surface to have the pixel format specified. However looking at the actual SDL code, it seems that when SDL_HWSURFACE is specified, the pixel format of the actual screen is used, not the one specified in the call. (The manpage actually contradicts this, you need to look at the SDL code itself)

Presumably on this particular PPC hardware, the underlying screen format in fullscreen mode is then something other than the RGBA layout that the tile renderer expects.

I'm not sure quite why we're requesting a HW surface there anyway: the code calls SDL_DisplayFormat (via SDL_Resize) on the returned surface eventually, which should return a HW surface where appropriate anyway. Maybe the fix is to just always initially create a SW surface for tiles, regardless of the 2D vs. 2DSW setting.

(0009555)
oliver (reporter)
2010-07-02 20:04

I've put a patch which makes this change at http://s3test.randomly.org/df/2238/dflibgraphics-2drenderer-use-swsurface.txt [^]

It makes no difference on my Linux system, so at least it doesn't break anything. Performance is unchanged, but 2D and 2DSW performance are essentially identical on my system anyway.

Unfortunately I don't have an OSX environment to build/test on.

(0009564)
MrWiggles (reporter)
2010-07-03 02:55

If willing to provide instructions, I'd give it a go.

(0009684)
Baughn (manager)
2010-07-06 08:28

Setting HWSURFACE (and that entire branch) is legacy code from before we used a resizer.

I've taken care of it.

Notes
(0008888) Footkerchief (manager) 2010-06-21 12:04	Do you have any screenshots of this problem? What PRINT_MODE are you using? Have you tried updating your graphics drivers?

(0009204) MrWiggles (reporter) 2010-06-28 01:06	http://s296.photobucket.com/albums/mm198/aliceingorelandpictures/?action=view&current=Picture7.png [^] And water is also invisible. Driver updates is a none issue for Macs largely. [PRINT_MODE:2D]

(0009207) oliver (reporter) 2010-06-28 02:47	Do you get the same effect when zooming in windowed mode? If so it's probably the scaling code at fault.

(0009209) Footkerchief (manager) 2010-06-28 05:50	Do you still get this problem if you change the PRINT_MODE?

(0009399) Footkerchief (manager) 2010-06-30 13:11	Reminder sent to: MrWiggles Do you get the same effect when zooming in windowed mode? Do you still get this problem if you change the PRINT_MODE?

(0009448) MrWiggles (reporter) 2010-06-30 23:51	When zooming in window mode while under 2D, no the issues does not happen. Switching to 2DSW seem to have fixed the issue.

(0009449) oliver (reporter) 2010-07-01 00:31	I think I see the problem. When creating a tile, the 2D HW renderer calls SDL_CreateRGBSurface() with SDL_HWSURFACE and expects the returned surface to have the pixel format specified. However looking at the actual SDL code, it seems that when SDL_HWSURFACE is specified, the pixel format of the actual screen is used, not the one specified in the call. (The manpage actually contradicts this, you need to look at the SDL code itself) Presumably on this particular PPC hardware, the underlying screen format in fullscreen mode is then something other than the RGBA layout that the tile renderer expects. I'm not sure quite why we're requesting a HW surface there anyway: the code calls SDL_DisplayFormat (via SDL_Resize) on the returned surface eventually, which should return a HW surface where appropriate anyway. Maybe the fix is to just always initially create a SW surface for tiles, regardless of the 2D vs. 2DSW setting.

(0009555) oliver (reporter) 2010-07-02 20:04	I've put a patch which makes this change at http://s3test.randomly.org/df/2238/dflibgraphics-2drenderer-use-swsurface.txt [^] It makes no difference on my Linux system, so at least it doesn't break anything. Performance is unchanged, but 2D and 2DSW performance are essentially identical on my system anyway. Unfortunately I don't have an OSX environment to build/test on.

(0009564) MrWiggles (reporter) 2010-07-03 02:55	If willing to provide instructions, I'd give it a go.

(0009684) Baughn (manager) 2010-07-06 08:28	Setting HWSURFACE (and that entire branch) is legacy code from before we used a resizer. I've taken care of it.

Issue History
Date Modified	Username	Field	Change
2010-06-09 21:24	MrWiggles	New Issue
2010-06-21 12:04	Footkerchief	Note Added: 0008888
2010-06-21 12:04	Footkerchief	Tag Attached: AWAITING UPDATE
2010-06-21 12:07	Footkerchief	Tag Attached: SDL-only
2010-06-28 01:06	MrWiggles	Note Added: 0009204
2010-06-28 02:47	oliver	Note Added: 0009207
2010-06-28 02:47	oliver	Issue Monitored: oliver
2010-06-28 05:50	Footkerchief	Note Added: 0009209
2010-06-30 13:11	Footkerchief	Note Added: 0009399
2010-06-30 23:51	MrWiggles	Note Added: 0009448
2010-07-01 00:31	oliver	Note Added: 0009449
2010-07-01 07:00	Footkerchief	Tag Detached: AWAITING UPDATE
2010-07-02 20:04	oliver	Note Added: 0009555
2010-07-03 02:55	MrWiggles	Note Added: 0009564
2010-07-06 08:28	Baughn	Note Added: 0009684
2010-07-06 08:28	Baughn	Status	new => resolved
2010-07-06 08:28	Baughn	Fixed in Version	=> 0.31.09
2010-07-06 08:28	Baughn	Resolution	open => fixed
2010-07-06 08:28	Baughn	Assigned To	=> Baughn
2010-07-09 21:06	oliver	Issue End Monitor: oliver

Relationships