Jump to content
The Dark Mod Forums

rich_is_bored

Member
  • Posts

    885
  • Joined

  • Last visited

  • Days Won

    18

Posts posted by rich_is_bored

  1. Don't let me pressure you. Everything you contribute is appreciated.

     

    I suspect the real culprit in both loading and storage space are all the plain text files that require parsing. Here's an example ripped straight out of the training mission...

     

     

    model { /* name = */ "func_static_200" /* numSurfaces = */ 0
    
    }

     

    Here we have a block from a .proc file. Notice the use of C style block comments in a file that content authors are unlikely to ever inspect. And what data is being conveyed? That the model for func_static_200 contains zero surfaces. 63 bytes to say essentially nothing.

    • Like 1
  2. Normal maps are interpreted by the engine as surface normals rather than colors and the form of compression applied must account for that. There are compression schemes well suited for normal maps and in fact DDS supports some of them. However TDM does not.

     

    Here's a cool experiment that proves the point. Convert a normal map into a jpeg. Now compare how it looks in game when applied as a normal map versus on the desktop as an image.

  3. Just a few keystrokes away are 30,000+ emails that demonstrate how HRC and those she surrounds herself with conduct themselves. But we're over here talking about language, mannerisms, and boasts of sexual conquest.

     

    The server in a home basement is enough to deem Clinton negligent, incompetent, and completely untrustworthy. Physical access is the most vulnerable attack vector and she clearly didn't know or care. And it's not just her. Think about how many idiots down the chain signed off on it in order for it to become a reality.

     

    Oh don't worry guys. It's cool. I won't use it for classified stuff. What a fucking joke.

     

    I'd be locked up for inserting a thumb drive into a government computer. Forget copying data to it. And yet she walks. The system is not compromised. The polls are not manipulated. Your ballots are counted. Carry on citizen.

    • Like 2
  4. I'm surprised to hear anyone is leaning towards a purchase after watching gameplay footage. From what I've seen it's a sandbox but roped off like an art exhibit.

     

    There's nothing of substance to explore. Just glorified white noise. It looks as if you could land anywhere on a planet, look around for a minute or so and know what all umpteen quadrillion square feet look like. The sky is green and the dirt is purple. That's nice. Where are the natural landmarks? I don't see any rivers, waterfalls, canyons, towering mountains, or volcanoes. The planets don't even appear to have poles or rings.

     

    I don't know that you have enough agency in the game to formulate your own goals. That might explain why so many people are min-maxing their equipment and jumping from planet to planet as quickly as possible. There's nothing else to do. It's not worth $60. Not even close.

  5. I don't imagine there's much to gain from parallelization with so much of the light gem being handled on the GPU in the form of additional render passes.

     

    You could opt for a simplified calculation on the CPU. It should be possible to lookup light texture values directly using a set of sample points and approximating the lighting from there. The six vertices that make up the prism would be an ideal match. Of course it's easier to say all this than to do it. You have to account for things like light color, flickering shaders, player leaning, and shadow volumes. But then I wonder how much work would be spent replicating things the renderer already does.

     

    Another possible route is simplifying the additional render passes. There's no reason to do per pixel lighting calculations on an non-textured, non-smooth shaded, primitive. Maybe there's a way to fold the light gem illumination into the existing interaction shader so you don't need additional passes at all.

  6. The indirect nature of this workaround seems to cause more problems than it solves. I think this and vertex colors are a dead end.

     

    Instead of trying to control the contribution of each render pass during composite with vertex colors, how about darkening the diffuse stage of each pass by 50 percent? The result should be equivalent. It should look something like this...

    translucent/example
    
    {
    
        // first pass
    
        {
            blend    bumpmap
            map    normalmap.tga
        }
        {
            blend    diffusemap
            map    diffusemap.tga
            rgb    0.5
        }
    
        // second pass
        // the scale function here is "inverting" the normal map so that it catches light from the opposite side.
    
        {
            blend    bumpmap
            map    scale(normalmap.tga, 1, 1, 0, 1)
        }
        {
            blend    diffusemap
            map    diffusemap.tga
            rgb    0.5
        }
×
×
  • Create New...