myconid

Right, I'll make it give a warning when it tries to load the old format - it should do that at least. The real issue is that the engine wasn't written to know when any shader inputs are unbound, and annoyingly enough, OpenGL doesn't offer any functionality to check that. A possible solution would be to keep our own parameter lists somewhere. The xml files in the arb/glsl directories are good candidates for that. Maybe something for Alpha 12...

Great work, Deiz. I'm relieved this has been resolved. I don't have the internal mod (nor do I know where to get it), so that never even crossed my mind. There was a script for updating actors, if you want to use it. XML validation would have been the answer here, which is possible to do, but a PITA to keep updated when the format keeps changing! If you recall, I wanted to deprecate but keep the <texture> tag because I was worried it would get to this, but historic_bruno wanted it removed. Doesn't matter though -- renderer stuff is finally clear for launch.

Okay, so: Why is the parent object's material affecting the props? Why is it happening even though all fancy materials are turned off? And why is it happening just to you? Since you have quality=0 in the config, player_trans_ao_parallax_spec redirects to player_trans, which doesn't have AO. Since the material doesn't have AO, the second UV stream is completely disabled. When you are using ARB, this doesn't even matter. As a test, set both the parent and prop's material to "player_trans.xml"...

Enrique, would you be interested in using detail maps? You could put extra greenery as decals on the walls, without using extra vertices.

Not to my knowledge...

Thanduel and HalcyonXII are two other Linux users with Nvidia cards that don't have this issue. Maybe there's something specific to your 9-series card, or maybe something specific to your system... For now, there are two things left to try: "ldd ./pyrogenesis" and post the result here. This will tell us whether the game is linking to the correct driver. I guess Nouveau/mesa drivers could be interfering, if they're present. Check in Nvidia's control panel thingy that vsync, antialiasing and other bells and whistles are turned off, in case they are causing problems.

Right, and it also seems that Spidermonkey doesn't even have a compacting GC yet: I'll go out on a limb and posit that gameboy's memory error wasn't a result of there not being enough free memory in the 96MB limit, it was because that 96MB became so fragmented due to the mark-and-sweep GC that the allocator wasn't able to find enough contiguous memory... It appears this is an issue they are trying to address in future versions (raising the memory limit could also help).

Yeah, I know. My point was that the error was caused when the window was switched, so it wasn't necessarily relevant to his loading problem. Is that a contiguous "mini-heap" of static size that is allocated every time, or is it just a limit on total allocations? If Spidermonkey uses a compacting GC, it's very likely that only half that will ever be available to the javascript program.

I don't know, man. You're reporting so many different problems and they all seem so random and unrelated...

Ah, that is useful to know! While shadows are not affected directly by distance, the shadowmap is scaled depending on the number/placement of models on the screen. As you zoom out, the scale of the shadowmap is changed to accommodate more models, so it may give the impression that the problem is related to distance. The shadowmap scale thing is only used with shadow filtering, so the facts fit. So it's the shadows that are interfering with the texture mapping. That's... entirely illogical. I wonder if it's silently failing because of a hardware limitation (very unlikely - your hardware is too new, and this happens when everything is turned off). More likely, it could be a driver bug - me and wraitii had to chase one down on his Nvidia card a while back. Out of curiosity, what happens when you completely disable shadows in the config?

I doubt that's it, unless his compiler is so horribly buggy that it's calling the wrong methods.

The LOD should be disabled in that revision (are you sure you recompiled?), and with it, parallax should be disabled as well. My theory is that the texture mappings (or the textures themselves) change as the shader is changed with distance due to the LOD system (I don't think this has to do with mipmaps). For some obscure reason, the parameters of the shader are being passed incorrectly, hence the visual artifacts. In GLSL mode, the parallax fades itself out to make the LOD transition less noticeable, thus "the texture mappings generally change rapidly with zoom". The fading doesn't happen in ARB because the shaders don't know and don't care about the LOD, but the shader is still replaced with an identical copy at a certain distance so you get a sudden transition. I can't see a reason why the shader parameters wouldn't be passed correctly. The code in ShaderProgram.cpp is fairly basic, and by disabling the optimisations the parameters are being rebound explicitly for every new model that is drawn.

Iberian Sandbox works perfectly fine here. Please rebuild now that I've disabled some more stuff and let me know what happens (you want commit 12630).

Deiz, give it another try please. Also, does any of this affect GLSL mode? Oh, what's your hardware, btw?

I think so.

Ah, I knew I'd seen something like that before. "There's no such thing as original thought."

I think the two might be related, and we're now a step closer to the root cause. That's my thought. There are a number of textures that are used in the GLSL shaders, but are bound to nothing in the ARB shaders. Maybe binding them to a dummy name would fix this...

Ok, commented out an optimisation that may have been the cause...

I like it! I agree with Enrique, make the outer ring skinnier and the images bigger. Also, maybe we shouldn't use screenshots on the label, as that says "bootleg" to me. How about two angry warrior heads, one on the left and one on the right, facing each other (like a staredown, this sort of situation). Don't know if there's any existing concept art that you could use. If you want, you could also try other round shapes that fit the shape of a CD. e.g. shields, coins. Better yet, use elements of decoration from ancient greek vases. Now, there's something interesting that I've never seen done before...

No new errors, though the problem seems to be intermittent now. Sometimes everything works fine, though other times it crashes on startup (I guess a segfault can be random, depending on what data gets overwritten). I'll clean workspaces and and recompile everything, just to make sure everything is current, and I'll let you know if it happens again.

The error is because SDL is failing to change the window size or resolution, but what isn't clear is if the error is separate from what is causing your game to hang when loading. So, for starters you should: change your config to run the game in windowed mode, and completely clear your cache.

In the latest version (2.63a) it's at File>Import>Collada, no need for a plugin.

We use SSE is some places for optimisation, but that can't be the problem because your CPU supports it. Something must be calling a function pointer that is either NULL or undefined. If that error is accurate, this probably takes place inside Nvidia's texture conversion library. A function pointer could be undefined if the linker fails... so my advice for now is to clear-workspaces, update-workspaces and then try running "make; make", to check if any errors come up. (basically, have you tried turning it off and on again )

That's more like my way of thinking about this. For the moment, I'll just point out that materials can be put into directories. For instance, model and terrain materials should go into different subdirectories of the materials directory. We should also start working on a standard about what effects constitute high/medium/low graphics, and have separate folders for each type.

I'm talking only about really complex buildings (which would need to be split into a large number of pieces), so this will be done very rarely. For other buildings, we can merge the small textures into a larger atlas to reduce the number of drawcalls, without increasing memory footprint (I've started looking at how we can do this for the Greek structures).