VOGONS


First post, by Ringtail

User metadata
Rank Newbie
Rank
Newbie

Sorry for yet another post about texture issues in Lego Rock Raiders, this is the game that keeps on giving issues. I just noticed this one recently; I'm using dgVoodoo 2.81 but it seems this issue seems to have existed since sometime after 2.70 for a while, probably whenever the issue with black areas in textures always being rendered transparent was fixed?

uWSGJtn.png
You can see around the rings of the drill in front of the camera that there's a black outline. This seems to be some of the pixels from the part of the image meant to be transparent (usually black) bleeding over into the visible area somehow.
xlr6g4O.png
(most transparent textures in-game are 8-bit BMP files, and are named something like A###_name with ### being the value in the file's color index that will be transparent, if that helps at all)

H1tARrM.png
The above image is using dgVoodoo 2.70, I actually don't remember what version this was and can't replicate it now? but it was before the issues with black in textures becoming completely transparent were fixed. I'm not sure when it was fixed, but it seems likely this issue was introduced when it was - you can see how the drill was meant to look here (there still is a slight amount of black but this is base texture issues - some have always looked like that, but a lot that do now didn't). I only just noticed this issue recently, so I don't know to what extent other textures are affected - it's not a major issue definitely, just a strange one.

8KUFsRr.pngGkfes6R.png
If I switch to a different videocard (in this case GeForce4 Ti 4800) it fixes this texture bleed issue, but also brings back some of the black transparency issues to a lesser extent (you can see the wall behind that building through the drill logo on top of it).

imDSoqD.png
Slug eyestalks are also affected - note the green outline around the texture on the left (normal 2.81) and how it's supposed to look on the right (GeForce4).
2QgPVW4.png

Hope it was okay to make a topic for this even though it's fairly minor. I'd thought about posting it in the regressive bugs topic but decided not too since it seemed more like an issue introduced from another bug fix, maybe? maybe not? Also this issue happens both with and without OpenLRR so it's not related to that allowing the game to run in true color mode. Video card is Nvidia GeForce GTX 1660 if that matters.

Reply 1 of 5, by Dege

User metadata
Rank l33t
Rank
l33t

Well, this is not a bug, it is how it's expected to work with dgVoodoo.

Texture colorkeying (omit rendering pixels matching the colorkey) works fine (without visual glitches) as long as the texture is sampled with point sampling.
Once bilinear/trilinear filtering is used, then the interpolated pixels at the edges won't match the colorkey so a black/green (colorkey color) edge appears.
dgVoodoo has another colorkeying method, to make the edge disappear, but that method isn't perfect too because it can cut out too many pixels.
There is no standard "expected" behavior because the DX specs don't say anything about it.

I remember my old Riva TNT2 had the latter kind of colorkeying implementation, so I implemented it for dgVoodoo.
All GF virtual cards applies full-cut (no edge) colorkeying, the others produce edges.
This was the case from the beginning, except that once I changed the default virtual card to use the edge-version colorkeying instead of the full-cut one.

Reply 2 of 5, by Ringtail

User metadata
Rank Newbie
Rank
Newbie

Well, I went and looked at old screenshots from before dgVoodoo and it turns out a few of them have the colorkeying issue too while most don't and do have the texture holes. Probably the fixed holes were really just the edges around them not being cut. I even looked at old pre-release screenshots and the issue was there too, turns out it's just an issue with this specific texture and the developers never noticed or fixed it.
I guess the Geforce settings are closest to how the game is intended to look. (edit later: actually I found other development screenshots with the color outlines, so I guess both really are valid.) Sorry for making a whole bug report topic over something I just never noticed before, and thanks for the explanation.

Reply 3 of 5, by xairo

User metadata
Rank Newbie
Rank
Newbie
Dege wrote on 2023-08-12, 13:19:
Well, this is not a bug, it is how it's expected to work with dgVoodoo. […]
Show full quote

Well, this is not a bug, it is how it's expected to work with dgVoodoo.

Texture colorkeying (omit rendering pixels matching the colorkey) works fine (without visual glitches) as long as the texture is sampled with point sampling.
Once bilinear/trilinear filtering is used, then the interpolated pixels at the edges won't match the colorkey so a black/green (colorkey color) edge appears.
dgVoodoo has another colorkeying method, to make the edge disappear, but that method isn't perfect too because it can cut out too many pixels.
There is no standard "expected" behavior because the DX specs don't say anything about it.

I remember my old Riva TNT2 had the latter kind of colorkeying implementation, so I implemented it for dgVoodoo.
All GF virtual cards applies full-cut (no edge) colorkeying, the others produce edges.
This was the case from the beginning, except that once I changed the default virtual card to use the edge-version colorkeying instead of the full-cut one.

Not sure if this is a related issue, but in another game the black texture disappears and becomes transparent. I'm not sure if it is only RGB (0,0,0) because it looks like some of the remaining black pixels are (0,0,0), so not sure what makes the black disappear. Any ideas how to fix this?
https://i.imgur.com/ApZwxzH.png

Reply 4 of 5, by ELK

User metadata
Rank Newbie
Rank
Newbie
xairo wrote on 2025-08-12, 17:13:
Dege wrote on 2023-08-12, 13:19:
Well, this is not a bug, it is how it's expected to work with dgVoodoo. […]
Show full quote

Well, this is not a bug, it is how it's expected to work with dgVoodoo.

Texture colorkeying (omit rendering pixels matching the colorkey) works fine (without visual glitches) as long as the texture is sampled with point sampling.
Once bilinear/trilinear filtering is used, then the interpolated pixels at the edges won't match the colorkey so a black/green (colorkey color) edge appears.
dgVoodoo has another colorkeying method, to make the edge disappear, but that method isn't perfect too because it can cut out too many pixels.
There is no standard "expected" behavior because the DX specs don't say anything about it.

I remember my old Riva TNT2 had the latter kind of colorkeying implementation, so I implemented it for dgVoodoo.
All GF virtual cards applies full-cut (no edge) colorkeying, the others produce edges.
This was the case from the beginning, except that once I changed the default virtual card to use the edge-version colorkeying instead of the full-cut one.

Not sure if this is a related issue, but in another game the black texture disappears and becomes transparent. I'm not sure if it is only RGB (0,0,0) because it looks like some of the remaining black pixels are (0,0,0), so not sure what makes the black disappear. Any ideas how to fix this?
https://i.imgur.com/ApZwxzH.png

Well you could test if it's a related issue by adjusting a few settings.

First off try disabling bilinear and trilinear filtering.
Set Texturing Filtering to Point Sampled.
Try both Texturing Mipmapping to disabled and auto-gen with point filter. (Maybe it expects mip maps)[note that disabled in no mipmapping, auto-gen with point filter is mipmapping enabled, and auto-gen with bilinear filter is trilinear filtering]

If this works keep in mind it my be possible to use texture filters w/ "Force filter only if not point sampled" checkbox checked for higher quality results. If it doesn't you could also try setting both to app driven.

The second thing he mentioned was card specific settings.
There are only two settings.
Option A:
dgVoodoo Virutal 3D Accelerated Card
ATI Radeon 8500
Matrox Parhelia-512
Option B:
GeForce4 Ti 4800
GeForce FX 5700 Ultra
GeForce 9800 GT

I guess dgVoodoo Virtual SVGA Card could be considered option C. I'm going to assume it uses option A settings but this is a 2d only graphics card. Back in ye olde days there were only 2d cards, then when 3d came out you would buy a 3d card to add. As in you would have to have both a 2d video card and a 3d video card in your computer at the same time for 3d. You could NOT have only a 3d video card because it did not have 2d capabilities.

Reply 5 of 5, by xairo

User metadata
Rank Newbie
Rank
Newbie
ELK wrote on 2025-08-14, 06:00:
Well you could test if it's a related issue by adjusting a few settings. […]
Show full quote
xairo wrote on 2025-08-12, 17:13:
Dege wrote on 2023-08-12, 13:19:
Well, this is not a bug, it is how it's expected to work with dgVoodoo. […]
Show full quote

Well, this is not a bug, it is how it's expected to work with dgVoodoo.

Texture colorkeying (omit rendering pixels matching the colorkey) works fine (without visual glitches) as long as the texture is sampled with point sampling.
Once bilinear/trilinear filtering is used, then the interpolated pixels at the edges won't match the colorkey so a black/green (colorkey color) edge appears.
dgVoodoo has another colorkeying method, to make the edge disappear, but that method isn't perfect too because it can cut out too many pixels.
There is no standard "expected" behavior because the DX specs don't say anything about it.

I remember my old Riva TNT2 had the latter kind of colorkeying implementation, so I implemented it for dgVoodoo.
All GF virtual cards applies full-cut (no edge) colorkeying, the others produce edges.
This was the case from the beginning, except that once I changed the default virtual card to use the edge-version colorkeying instead of the full-cut one.

Not sure if this is a related issue, but in another game the black texture disappears and becomes transparent. I'm not sure if it is only RGB (0,0,0) because it looks like some of the remaining black pixels are (0,0,0), so not sure what makes the black disappear. Any ideas how to fix this?
https://i.imgur.com/ApZwxzH.png

Well you could test if it's a related issue by adjusting a few settings.

First off try disabling bilinear and trilinear filtering.
Set Texturing Filtering to Point Sampled.
Try both Texturing Mipmapping to disabled and auto-gen with point filter. (Maybe it expects mip maps)[note that disabled in no mipmapping, auto-gen with point filter is mipmapping enabled, and auto-gen with bilinear filter is trilinear filtering]

If this works keep in mind it my be possible to use texture filters w/ "Force filter only if not point sampled" checkbox checked for higher quality results. If it doesn't you could also try setting both to app driven.

The second thing he mentioned was card specific settings.
There are only two settings.
Option A:
dgVoodoo Virutal 3D Accelerated Card
ATI Radeon 8500
Matrox Parhelia-512
Option B:
GeForce4 Ti 4800
GeForce FX 5700 Ultra
GeForce 9800 GT

I guess dgVoodoo Virtual SVGA Card could be considered option C. I'm going to assume it uses option A settings but this is a 2d only graphics card. Back in ye olde days there were only 2d cards, then when 3d came out you would buy a 3d card to add. As in you would have to have both a 2d video card and a 3d video card in your computer at the same time for 3d. You could NOT have only a 3d video card because it did not have 2d capabilities.

I tried all your suggestions and nothing worked. Am I supposed to see any other differences when changing those settings? I could not see any difference at all.