R_GenerateLookup: Column without a patch...

[Quasar]

I want to get rid of this error in EE but I don't have a clue on how to setup a recovery mode for it. I'm hoping somebody can show me an option, since this error is absent from most other modern ports.

[Graf Zahl]

How much work are you willing to invest and what are your future plans?

Will you eventually support PNG and other graphics formats or create a unified texture manager like ZDoom has?

If so this would resolve itself automatically.

To be honest, just looking at R_GenerateLookup gives me headaches. Texture composition is so much easier if it's done as a real bitmap with the column data just referencing that bitmap.

[andrewj]

The easiest way to fix it: copy the nearest valid column into the empty slot. Probably as a separate pass before the texturecompositexxxx stuff.

[Quasar]

Graf Zahl said:

How much work are you willing to invest and what are your future plans?

Will you eventually support PNG and other graphics formats or create a unified texture manager like ZDoom has?

If so this would resolve itself automatically.

To be honest, just looking at R_GenerateLookup gives me headaches. Texture composition is so much easier if it's done as a real bitmap with the column data just referencing that bitmap.

Haven't totally decided where we're going with textures yet. My plate's too full with other stuff at the moment :) What I really need right now is just a quick fix; something dirty but that gets the job done.

R_GenerateLookup and R_GenerateComposite are candidates on my "Worst Code in DOOM" list, so you got that right.

[Scet]

I actually just got around to working on R_GenerateLookup and R_GenerateComposite today, so my information might be wrong. Hopefully it'll help though.

For textures with more than one patch(so "composite" textures), texturecompositesize[texnum] is just texture->width*texture->height and texturecolumnofs[texnum][x] is x*texture->height. So basically composite textures are just stored as large blocks and don't use the post/column system.

I actually got rid of texturecolumnlump and made every texture composite. Unfortunately I just discovered a few minutes ago that a side effect of this is masked middle textures not working, since they do use the post/column system and can only consist of one patch. I've managed to change R_DrawMaskedColumn to work with composites, but it just draws junk in the transparent areas.

[andrewj]

Scet said:

Unfortunately I just discovered a few minutes ago that a side effect of this is masked middle textures not working, since they do use the post/column system and can only consist of one patch. I've managed to change R_DrawMaskedColumn to work with composites, but it just draws junk in the transparent areas.

Heh, guess you now gotta implement a transparent color (e.g. TRANS_PIXEL = 247) and new column drawers that skip that special value.

[Gez]

andrewj said:

Heh, guess you now gotta implement a transparent color (e.g. TRANS_PIXEL = 247) and new column drawers that skip that special value.

Note that palette 247 is actually used for some graphics, especially in other Doom engine games (Heretic, Hexen...).

If I got what I've been told right, ZDoom uses palette index 0 for transparency and moves all other palette indices in the 1-255 range, getting rid of duplicates or triplicates; and uses a translation system to convert from the graphics' palette to the system palette.

[printz]

Why does this error halt Eternity and not vanilla Doom? Try the wad 1KILLTNG for instance. Since I don't know its setup by heart, I'll leave it to you to check up its new texture set. As far as I know, all it has replaced is the Wolfenstein texture patches, with other graphics, less wide than 128. They show up naturally in vDoom, but to make it run on Eternity I had to create a TEXTURE1 lump and edit the Wolfenstein textures to be as wide as their replaced patches.

[Graf Zahl]

Gez said:

Note that palette 247 is actually used for some graphics, especially in other Doom engine games (Heretic, Hexen...).

If I got what I've been told right, ZDoom uses palette index 0 for transparency and moves all other palette indices in the 1-255 range, getting rid of duplicates or triplicates; and uses a translation system to convert from the graphics' palette to the system palette.

What is does is to look for a duplicate of color 0 in the palette and if that does not exist, tries to eliminate one duplicate of another color to move color 0 there. Only if that fails, too, 0 is remapped to the closest color. Of the standard palettes none needs this, AFAIK.

[Scet]

I thought about adding a transparent color, but have decided against it. AFAIK you're supposed to be able to use all 256 colors, and since they're stored as bytes translating them won't work. Also it's a lot faster to use post->topdelta and skip the transparent pixels then to check each pixel.

What I plan to do when I finally get around to finishing my own Texture class is have each texture just consist of separate columns. Single patch textures will just point to the the patches columns. Composites will have columns[texture->width] with just one post per column equal to the textures height, with the patch columns drawn into them instead of a large buffer. This way my version of R_GetColumn will actually be faster than Dooms since I don't need to do any checks if it's composite or not, I just return the first post.

[Graf Zahl]

Scet said:

I thought about adding a transparent color, but have decided against it. AFAIK you're supposed to be able to use all 256 colors,

That's only an issue if all 256 colors are different (which they rarely are in a palette) and even the most minor discrepancy causes visual anomalies (not an issue with Doom.)

However, it will limit you to special graphics formats that explicitly store transparent data as non-pixels, which rules out each and every common graphics format in existence.

Scet said:

Also it's a lot faster to use post->topdelta and skip the transparent pixels then to check each pixel.

I seriously doubt that it is 'much faster'. It may have been a speed boost back in 1993 but today there's other factors which are much more deciding when it comes to execution speed. Doom's biggest performance bottleneck is the column drawer because it just rapes the CPU cache. Compared to that any performance loss from skipping pixels is almost insignificant.

(BTW, ZDoom calculates the column data on the fly for bitmapped textures so it can freely use all formats as both wall textures and flats.)

Guess why ZDoom contains a column drawer that renders 4 columns simultaneously.

[Quasar]

Scet said:

For textures with more than one patch(so "composite" textures), texturecompositesize[texnum] is just texture->width*texture->height and texturecolumnofs[texnum][x] is x*texture->height. So basically composite textures are just stored as large blocks and don't use the post/column system.

This was fooled with in BOOM in order to fix the bug known as Medusa Error, which prevented using multipatch textures as the middle texture on two-sided lines. So in fact I don't think I'm dealing with the same situation, but rather one that is a lot more complicated.