Minor graphics issue with Employee of the Month.

[mrhingerdinger]

Alright, I got Employee of the Month working on DXWND. Everything loads perfect, except for 1 thing:
For whatever reason, some character's eyes and parts are transparent. Not all of them, but only some. Is there any way to fix this?

[mrhingerdinger]

Pay attention to SB's eyes in this video: http://www.youtube.com/watch?v=7RHwxxayKtE&feature=youtu.be

[mrhingerdinger]

Anybody wanna help?

[gho]

I will try, usual procedure, set a testbed, replicate the problem, squeeze your brains, pray for luck ... it will take some time, mostly depending on last item.

[gho]

Oh, my!
step 1 and 2 done: I now have a testbed with the replicated problem.
But the problem doesn't depend on DxWnd! The attached pictures (a screenshot and a little detail of the same picture) are taken from the game running in native mode without DxWnd, and all eyes are transparent. That excludes a DxWnd bug and, sadly, may make the task a little harder.
To have a second view of the problem, I added the d3d8.dll file from the d3d8_to_9 project: this is a wrapper that redirects all d3d8 methods to a d3d9 component. The result is identical, so it seems not a problem of the legacy d3d8, but possibly a real game bug.
Let me surf the web and search for a possible diagnosis. In the meanwhile, maybe some owner of older platforms (le's say Win7 or WinXP) could test the game in different conditions.

[gho]

Look this:
https://www.reddit.com/r/gog/comments/fafxco/spongebob_employee_of_the_month_transparent/
mrhingerdinger is not the first one to notice the problem, though the answer was rude: no GOG game, no interest! Let's see if we can do better.

[gho]

Another surprise: I hooked the game with DxWnd, default configuration (just drag & drop sb2.exe over the DxWnd window) and the textures are ok, both with and without d3d8_to_9 installed.
Of course, I take that you got the proble WITH DxWnd. THat's weird ...

[huh]

Hi, here on Win7 no eye problems (except those of my eyes hahaha) with or without DxWnd.

Update:
Well, maybe it's because the game runs in software mode here. But according to this video, I think it should run in hw mode.
https://www.youtube.com/watch?v=5Q2iRjZqI1c&hd=1

Update2:
Hmm I was wrong, the graphics came to me the same as when I put safe mode, but it's not like that ("sb2.exe" -sw).

Oh, the author of the video I mentioned used dgVoodoo as described here

https://www.pcgamingwiki.com/wiki/SpongeBob_SquarePants:_Employee_of_the_Month#Widescreen_resolution

therefore, the image in this video is smoother.

[gho]

That's a good idea: putting the game in wireframe mode demonstrates that the eyes are textured polygons exactly as any other 3D element in the game. So, why the eyes only get transparent? Maybe the white color is some sort of transparency character? Uhm...

[mrhingerdinger]

Cycle blending?

[gho]

Cycle blending?

Can you provide some direct link? I've browsed a lot of cyclette exercises and wire blending web pages ...

The attached picture seems interesting: it is the dump of SpongeBob textures, where you can see that his eye has a black pupil in a white cornea. Since the pupils are always visible, it seems that the eye's textures are used, so maybe the problem is only with the white color. So, it should be an alpha blending problem where the white was matched with transparent color.
But curiously my logs show that alpha blending is never set in the game. Maybe it is a unpredicted default used before alpha blending was disabled? Unfortunately, I can't do much of a testing since using DxWnd on my computer fixes the problem in any case. Perhaps I could post here an experimental release.

[gho]

Here is an interesting experiment: editing the texture above (It takes a little care and a good editor like GIMP to preserve the 16 bit color depth, Paint just saves at 24 bit depth!) and using the texture hack DxWnd feature I got rid of the SpongeBob's white pupils. It could be interesting to see if that fixes the problem in mrhingerdinger computer.

[gho]

Another little experiment: using DxWnd "Transp." flag in D3D tab you can force alpha blending mode on all operations. This produces semi-transparent textures with eyes that resembles pretty much the problem. Maybe the game omits to clear the alpha blending for the eyes only?

[gho]

@mrhingerdinger: could you try this experimental dxwnd.dll release? It is supposed to disable alpha blending in any case ...

[gho]

Ah! I found a way to replicate the problem adding to the DxWnd initialization of D3D session the following statement:
SetRenderState(d3ddev, D3DRENDERSTATE_ALPHABLENDENABLE, TRUE);
Curiously, it seems that the effect of the ALPHABLEND setting survives the termination of the D3D session and the program: I had the game working perfectly in native mode, then I got the attached screenshot with the patch, then running again the game in native mode the problem was still there!
In conclusion, it seems that the problem depends on a missing initialization of the ALPHABLEND mode at the beginning of the session, where only the eyes are processed, while the rest of the textures are processed ok with no blending.
Probably DxWnd should implement some sort of "Initialize alphablending" flag to be set to either "default", "on" or "off".

update
thisgs are not fully set yet!
My trick seems to work only after you enter the video options menu and make some change (I used to turn the shadows on and off). Probably there's something else to be done that happens only when you exit that game menu, I'll have to find what.
In the picture you can also notice how not only the eyes became transparent, but also the white SpongeBob hat. It seems that every white texture becomes transparent ....

[gho]

Getting closer: setting the alpha color & ALPHABLEND on is not the only way to have transparencies. Another way is to use an alpha video mode like RGBA 16 bit, where RGB colors are encoded with 5 bits and alpha is the 16th most significant bit, like this:

ARRRRRGGGGGBBBBB

Now I suspect that the game was designed for RGB565 mode, but for some mistake the game selects a RGBA video mode. This way, any slightly darker pixel would have a 16th bit off, so it would be opaque, while a full white fould be 0xFFFF with the 16th bit on and so fully transparent.
This is just a theory, but I modified the texture highlight routine to make it strip the 16th bit. The attached picture shows the result, where the white is slightly blue (befause it has now only 4 bits of red color, 0x8FFF) but it is steadily opaque, no matter how many times you run the game or enter / exit the options menu.
So now, if the 16th bit of RGBA video mode is the culprit, the best solution would be to eliminate all RGBA modes from the video capabilities and let the game use necessarily a RGB mode. Uhm ...

[gho]

This seems better. To use this experimental version, you have to replace dxwnd.dll with the attached one and, in addition, set the texture highlight flag.
The highlight operation here is just making a bitwise AND operation of each texture pixel with 0xF7FF, in practice stripping the least significant bit of the red color and so making the white a slightly (and unnoticeably) less blank pixel, enough to make it a non-transparent color.
The solution is probably not the final one (it's too a patchwork) but it works, and since the textures are only few and loaded once, the impact on performances is unnoticeable too.
One curiosity: the game installer pretends to install D3D8, but I never saw any usage of that one, all operations being made in D3D3. Is this the game software mode?

[huh]

Software mode can be turned on via sb2.exe -sw parameter, but I don't know if it uses Dx8.

[mrhingerdinger]

Seems like it fixed the problem!

[mrhingerdinger]

However, this causes another issue: the pink background on the net's texture shouldn't be there. Other than that, it works perfect!

[gho]

That's probably because we're using a mace to open the nuts. The reason for the transparent eyes is probably because the D3D engine was set to use white color as transparent color (pretty much as man games use thy highly unlike magenta color for the same purpose) and we fixed the problem by hammering every pixel in every texture and getting rid of one bit to make white a little less whiter. But in reality a better solution to the problem would be to simply disable the transparency setting and leave the pixels untouched.
I'll try to find a better solution for sake of semplicity.

p.s. is it simple to get to the net screen? In case it takes some work, would you mind posting here some savegame that brings me directly there?

[mrhingerdinger]

It's pretty simple, takes about 5-ish minutes. Follow this longplay: https://www.youtube.com/watch?v=5Q2iRjZqI1c

[gho]

In the meanwhile it seems I got the solution:
we must keep alone the D3DRENDERSTATE_ALPHABLENDENABLE and, instead, force turning off the D3DRENDERSTATE_COLORKEYENABLE setting. It seems to work with no need to change the texture colors!

[gho]

The attached picture is the dump of the net texture. Apparently, better than setting D3DRENDERSTATE_COLORKEYENABLE to off it would be setting it to on but using magenta color as transparent key color!
This could also be a legacy problem: maybe in older ddraw/d3d releases magenta was the default key color while on more recent environment it is now the white color.
To be investigated ...

[gho]

The situation is more complex than expected.
I found in the logs the traces of the relevant operations.
The key is the SetColorKey method applied to the texture surfaces. There are two different situations:
this one

GetSurfaceDesc(4): lpdds=0x9a53260 SurfaceDesc: GetSurfaceDesc Flags=0x1100f(DDSD_CAPS+HEIGHT+WIDTH+PITCH+PIXELFORMAT+CKSRCBLT) Width=256 Height=256 Pitch=512 Caps=0x10005000(DDSCAPS_TEXTURE+VIDEOMEMORY+LOCALVIDMEM) Caps2=0() Caps3=0() Caps4=0() CKSrcBlt=(0xf81d,0xf81d)  PixelFormat flags=0x40(DDPF_RGB) BPP=16 RGB=(0xf800,0x7e0,0x1f)
Blt(4): dest=0x9a53260 src=0xadf9298 dwFlags=0x1000000(DDBLT_WAIT) destrect=(NULL) srcrect=(NULL)
[NOPRIM] src=(NULL) dest=(NULL) at 210
TextureDump(4): lpdds=0x9a53260
TextureDump(4): lpdds=0x9a53260 hash=2C5D2B6D size=(256x256) bits=16 mask(ARGB)=0.0xf800.0x7e0.0x1f
GetColorKey(4): lpdds=0xadf9298 flags=0x2(DDCKEY_DESTBLT)
GetColorKey: ERROR lpdds=0xadf9298 flags=0x2 res=0x887600d7(DDERR_NOCOLORKEY)
GetColorKey(4): lpdds=0xadf9298 flags=0x8(DDCKEY_SRCBLT)
SetColorKey: lpdds=0x9a53260 flags=0x8(DDCKEY_SRCBLT) colors=(L:0xf81d,H:0xf81d)

Here SetColorKey sets a DDCKEY_SRCBLT color value of 0xf81d, that is binary 1111100000011101, so pretty close to a saturated magenta color encoded in a 16 bit space.
The net texture, as well as some others (see attaches at the bottom) is filled with 0xf81d pixels, so these should be transparent.
But there is another situation, that is this one:

GetSurfaceDesc(4): lpdds=0x9a54ac0 SurfaceDesc: GetSurfaceDesc Flags=0x1100f(DDSD_CAPS+HEIGHT+WIDTH+PITCH+PIXELFORMAT+CKSRCBLT) Width=64 Height=64 Pitch=128 Caps=0x10005000(DDSCAPS_TEXTURE+VIDEOMEMORY+LOCALVIDMEM) Caps2=0() Caps3=0() Caps4=0() CKSrcBlt=(0xffff,0xffff)  PixelFormat flags=0x40(DDPF_RGB) BPP=16 RGB=(0xf800,0x7e0,0x1f)
Blt(4): dest=0x9a54ac0 src=0xadf9678 dwFlags=0x1000000(DDBLT_WAIT) destrect=(NULL) srcrect=(NULL)
[NOPRIM] src=(NULL) dest=(NULL) at 210
TextureDump(4): lpdds=0x9a54ac0
TextureDump(4): lpdds=0x9a54ac0 hash=6D68C097 size=(64x64) bits=16 mask(ARGB)=0.0xf800.0x7e0.0x1f
GetColorKey(4): lpdds=0xadf9678 flags=0x2(DDCKEY_DESTBLT)
GetColorKey: ERROR lpdds=0xadf9678 flags=0x2 res=0x887600d7(DDERR_NOCOLORKEY)
GetColorKey(4): lpdds=0xadf9678 flags=0x8(DDCKEY_SRCBLT)
SetColorKey: lpdds=0x9a54ac0 flags=0x8(DDCKEY_SRCBLT) colors=(L:0xffff,H:0xffff)

here the color key is set to 0xffff, that is pure white. Is it wrong? Maybe not, since some textures seem to require a white background color, like the shadow texture.
I don't know ... apparently the game is not able to switch key color according to the different situations. Maybe it is a video card limitation, using a single key color for all surfaces?
In any case, I think I'll implement the forcing of COLORKEYENABLE value in DxWnd interface, it seems a reasonably handy feature.