Doomworld Forums - R_GenerateLookup: Column without a patch...

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > R_GenerateLookup: Column without a patch...

Author

All times are GMT. The time now is 13:42.

Quasar
Moderator

Posts: 4484
Registered: 08-00

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.

06-06-09 17:49 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6960
Registered: 01-03

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.

06-06-09 18:09 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1344
Registered: 04-02

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

06-07-09 05:33 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

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.

06-08-09 01:39 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Scet
Member

Posts: 451
Registered: 05-06

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.

06-08-09 03:42 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1344
Registered: 04-02

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.

06-08-09 05:53 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6453
Registered: 07-07

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.

06-08-09 12:24 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6126
Registered: 06-06

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.

__________________
HELL GIVES.

06-08-09 12:37 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6960
Registered: 01-03

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.

06-08-09 13:14 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Scet
Member

Posts: 451
Registered: 05-06

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.

06-08-09 13:41 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6960
Registered: 01-03

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.

06-08-09 14:45 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

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.

06-08-09 17:38 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 13:42.

Doomworld Forums > Classic Doom > Source Ports > R_GenerateLookup: Column without a patch...

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >