Xycaleth

What did you change to get further? Do you get any errors in the terminal or console when it froze up?

Do you have OpenGL drivers installed?

That seems unnecessary when you can use the alpha channel of the same texture though. Or better yet, add all the detail on to a separate texture and you save yourself 4 extra renders

Taking out the alpha channel doesn't stop depth from being written, even if it's completely transparent. At least I don't think it will.

 

So yeah, possibly a bug in nvidia's drivers. I'm interested in knowing why so many stages are needed to achieve that kind of effect though? What do the texture maps look like?

Interesting Do you see any errors or warnings in the console?

I would remove all those depthWrite and depthFunc commands. They're not necessary and can cause problems like this.

 

textures/mk_textures/multiblend_01
{
    qer_editorimage textures/mk_textures/multiblend_01
    q3map_globaltexture
    {
        map textures/mk_textures/block_base_01
    }
    {
        map textures/mk_textures/blender_01
        blendFunc GL_ZERO GL_ONE_MINUS_SRC_COLOR
        tcMod scale 0.25 0.25
    }
    {
        map textures/mk_textures/cracks_01
        blendFunc GL_ONE_MINUS_DST_ALPHA GL_DST_ALPHA
    }
    {
        map textures/mk_textures/blender_01
        blendFunc GL_ZERO GL_ONE_MINUS_SRC_COLOR
        tcMod scale 0.2 0.2
    }
    {
        map textures/mk_textures/sand_01
        blendFunc GL_ONE_MINUS_DST_ALPHA GL_DST_ALPHA
    }
    {
        map $lightmap
        blendFunc GL_DST_COLOR GL_ZERO
    }
}

If blender can open any of those files then you can use mrwonkos glm exporter

Ah ok. Good to see it's finally supported! in that case as long as the client code can be compiled, then it should just run. Provided OP has an rpi2.

@@anxietymuppet can you try an older build to see if it works, or to find when it started breaking?

You won't be able to run it as far as I know, even if you can get it to compile. The rpi only supports OpenGL ES and not OpenGL.

Ssao is broken as far as I remember it didn't look great anyway so better to leave it turned off

But DT mentioned his FPS drops only with postprocessing enabled. All of that is contained in the RB_PostProcess function.

So what I can remember, post processing includes: r_tonemap, r_dynamicglow, r_ssao. Try turning each one off? Multi sampling can make things slower too I think (in the post processing stage). Can't remember the cvar

That's odd. I wouldn't expect that much of a difference. What post processing effects do you have turned on?

How much is "so much fps"? What FPS are you getting before and after enabling r_postProcessing?

I'm going to guess the dedicated server can't load the MB2 game library because it's not been compiled for ARM architecture. So instead the server is running the base game instead.

You might have some trouble understanding everything that's going on if you're only just starting to learn but I'm happy to answer any questions you might have

 

Rend2 doesn't use deferred rendering so there's no concept of a normal buffer. You would have to write each pixel's normals into a separate texture during the regular shading.

rend2 never had parity with the vanilla renderer. These are missing:

• Surface sprites
• Flares
• Refraction shader
• Weather system
• Sky portals
• Marks on Ghoul2 models
• misc_bsp support

In terms of rend2-specific stuff, it was basically:

• Make it go fast
• Really polish off the existing rendering techniques (it didn't feel like all the effects came together to look consistent)
• Better antialiasing
• Better LOD support, including models, shader quality, etc
• Write documentation for new shader keywords + examples

In terms of SP, it's basically do all of rend2 again but for SP. There's a major problem in SP though where changing the renderer will crash the program.

Lego you say?! This sounds like a job for @@Scooper! #ScooperPlz

Let's say 3mb just for ease of calculation. 3mb = 3 * 1024 * 1024 bytes. You can set this calculation as the value of max saber data size, e.g.

#define MAX_SABER_DATA_SIZE (3 * 1024 * 1024)

You're allocating 1GB of memory there. If you can figure out how much space all of your sab files take up (select them all in windows explorer and it should tell you how much disk space they use) you can just set the size to that number (in bytes).

I've had a look over the ioq3 rend2 changes and they don't add anything useful really. It's just different function calls to do the same thing.

Those ports will only allow players to connect (as you've found already). Your server also has to communicate with the master server which uses a different port which I think is 29060.

I might have it lying around somewhere. I'll have a look.

I think it's 29060.