Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Maes

Question about textures compositing...

Recommended Posts

...since I'm now fiddling with the R_Init subsystem, I've come to the point where I must implement texture compositing, and here there seems to be a discrepancy between normal patches and textures.

Perhaps the answer is obvious, but the code doesn't make it very clear. Here goes:

Normally, stuff rendering sprites and graphics other than textures accept "patch_t" structs, and in turn they decode the packed columns stored inside them. Some routines even accept raw column_t and do the post_t decoding iteratively.

In MochaDoom this aspect has been replicated by using patch_t object that store an array of discrete column_t's, and each column_t then carries its raw, packed post data as-is (along with extra info such as where does each post start, what's the length of each post, how many posts are there, at which drawing offset etc. ).

This works wonders so far, and allows for simplifying some of the blitting routines while not sacrificing performance by splitting columnt_t's further into post_t objects. It's also very easy to address individual columns in patches.

However, I noticed that the R_GetColumn() function in r_data.c is supposed to return raw bytes, yet it can return interchangeably a raw packed column_t (from a patch_t lump), or, what should be a row to a cache with uncompressed composite textures, texturecomposite[tex] + ofs;

Now, the code that generate the latter, R_DrawColumnInCache, isn't very clear: it seems to accept just packed columns (and "draws" them on an uncompressed cache line) with an algorithm similar to that used in the various V_DrawPatch functions. Ergo, that led me to think that the composite texture cache is actually uncompressed. Is that correct?

If so, how do methods that call R_GetColumn() differentiate between receiving a (still packed) column_t or a reference to the (uncompressed?) composite texture cache?

I noticed that usually, function that call R_GetColumn() then store the result into a byte* buffer called dc_source, which is then used by functions such as R_DrawColumn(), which however seem to treat it as an entirely uncompressed column...so exactly what gives here? If a compressed column_t/post_t list was to be passed "as is", sit wouldn't be drawn correctly, the packed post_t data would be interpreted as a raw bitmap, headers and padding included.

Share this post


Link to post
Maes said:

..., that led me to think that the composite texture cache is actually uncompressed.Is that correct?

Yes, but only the composite columns are unpacked.

Maes said:

If so, how do methods that call R_GetColumn() differentiate between receiving a (still packed) column_t or a reference to the uncompressed?) composite texture cache?

They don't.

The only time you would get into this situation is when you try to draw a transparent texture where you wouldn't normally draw one (middle of singled sided line, upper or lower texture) and what you end up with is the packed texture drawn wrong (a mess).
Normally transparent textures (packed) are handled by R_DrawMaskedColumn.

Try making a test map with MIDGRATE as an upper texture then run it in chocolate doom to see the effect.

Edit:
This type of thing is going to cause you a slight problem with Java as you will be attempting to access data from outside the bounds of the array.

Edit 2:
The wiki mentions it here: http://doom.wikia.com/wiki/Tutti-frutti_effect

Share this post


Link to post

Hmm....that was exactly what I was going to ask next. So when it "tutti-frutties", it's actually reading beyond the normal array boundaries.

There's a number of ways this could be handled elegantly in Java too (e.g. checking if it's about to draw more column rows than there are bytes, and just limit the rendering loop, or allocate extra space for each each column, or store everything in the composite memory anyway, or mark columns with transparency and treat them specially in those situations).

Share this post


Link to post

You may want to keep a log of decisions like these. This is where you get to decide how close to vanilla you want to be.

Share this post


Link to post

Just have your array accessors detect if it's out of bounds, and if so return random garbage. It should simulate tutti frutti nicely.

If you want to emulate it, rather than merely simulate it, you'd need to establish a mapping of how it would look like in memory for Doom, from there find out what data it would access, and return that. This way, you would be sure that the ugly random pixels would be exactly the same ugly random pixels as in vanilla, which should be a reward in itself.


Alternately you could be boring and just return the index for the black color.

Share this post


Link to post
Gez said:

This way, you would be sure that the ugly random pixels would be exactly the same ugly random pixels as in vanilla, which should be a reward in itself.


Nah, in order to do exactly that I'd have to emulate the Z_Malloc flat memory model and store everything as byte chunks and unmarshal them into data structs upon use each time (currently this is only done at load time, for on-disk lumps and certain structs), which would be overkill for what I'm trying to do. I'm perfectly happy with leaving the task of object and memory allocation to Java :-p

Gez said:

Alternately you could be boring and just return the index for the black color.


I thought of having a sort of "default" animated column as background for such cases, so a fancy "barber pole" effect could be seen instead :-p

P.S.: besides, if per-byte vanilla Doom compatibility is desired in a Java applet (even moreso than ChocoDoom) then this is just about as close as one can get.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×