Makaqu

[qbism]

ogg would not be hard with external dll, see Quakespasm bgmusic, but I understand the principle of having it self-contained.

I didn't realize how many duplicate functions exist for interpolated vs. non-interpolated until searching occurrences of it in the code.

[mankrip]

I'm doing this to understand better how the MDL code works. After cleaning up and understanding everything, I'll see what else can be improved in it.

[mankrip]

Removed r_aliasuvscale and aliasvrect. Going to remove aliasvrectright and aliasvrectbottom now. Also replacing their x86 ASM calls and changing the indexes of refdef_t in asm_draw.h to compensate.

r_aliasuvscale was set to 1.0 and never changed, so it wasn't actually used. Definitely an experimental feature that Id Software dropped.

[edit] Removed a number of other unused variables and functions. It's amazing how much code there is that serves no other purpose than to confuse us.

A couple optimizations also went away, but those optimizations got disabled since the frame interpolation was added in the first versions of this engine.

[mankrip]

I just figured out that the position/rotation interpolations can be made smoother by interpolating each axis independently.

Also implementing .scale and .scalev interpolations. Alpha blending interpolation could also be implemented, but doesn't make much sense in 8-bit rendering.

[mankrip]

Refactored a lot of code. The clippling code for MDL models is a lot cleaner now, some more unused variables and functions have been removed, probably most of the interpolation code was rewritten, and the outlines for the cel-shading effect have been reimplemented in a much cleaner and faster way (though their actual drawing code still needs a huge rewrite).

There's still a lot to do. I've looked at how the MDL vertex compression works, and it should be easy to convert its vertex coordinates into floats upon loading.

[mankrip]

[Spike]

when rasterizing a triangle, first you transform+clip the verticies into 2d space.
then you have to figure out which edegs are which so that you can walk across the span from one edge to the next.
that's what the edge table is about - the two vertical edges of the triangle.
a triangle can be rotated in all sorts of ways when its actually drawn on the screen, which typically requires walking from the top, expanding outwards towards the middle, then going back in at the bottom or so.
of course, if culling is used, the triangle is guarenteed to be in a (anti?)clockwise order. which means the layout of the triangle can be determined _purely_ by the vertical positions of the verticies.
the side that has the middle vertex needs to be drawn with 2 bits in the middle. the other side only needs 1. if two verticies are on the same line then you can skip that part of the triangle entirely.

so that code is basically deciding which rules need to be followed to generate the span lists and interpolants properly.
its not the sort of function that really needs extra features or anything. Its D_RasterizeAliasPolySmooth that calculates your interpolants, and its that function that will be needed if you want to add things like fog (though chances are you can set up fog on a per-triangle basis rather than per-pixel).

[mankrip]

Thanks, I'm almost starting to understand it. It's just that I really want to understand how the whole MDL drawing works.

Fog isn't in my plans. But if I were to do it, I'd either calculate it per-entity (the fastest and less accurate way) or per-pixel, for maximum accuracy.

[leileilol]

Ambient per-entity fog is going to be ugly.

[mankrip]

Exactly. But on distant or small models (e.g. projectiles), it could look fine.

[leileilol]

But why ambient? I have per-entity fog which works quickly down the model spans and it's more precise than the world spans fog although my distance exponents are incorrect right now.

I did try ambient per-entity fog before and I didn't like how models look like ghosts at certain fog ranges.

[mankrip]

Because it should be the fastest method; get the entity's distance from the screen (which is already calculated by the depth sorting algorithm used for alpha blending), use the value to generate/select a tinted color shading map, and it's done. If multiple color shading maps are pre-generated for this, the impact on the rendering performance should be virtually zero. And unlike post-processed fog, this would also work properly on alpha blended entities.

I'd have to test it before deciding whether to use this solution, though.

Fog is a feature that requires an awful lot of testing and tweaking, don't help to speed up the content creation process (for mods or stand-alone games), and is also not a feature of the original Quake game, so it is something I don't feel inclined to work on. But I'm aware it's something that will be needed if I get serious about supporting community-made maps.

[mankrip]

[mankrip]

[mankrip]