myconid

That's my fault. WIP code. Odd thing is that the sky manager is calling stuff related to .tga files, even though none of the sky images are tga files. Do you have any weird mods installed? Make sure you completely clear your cache, too.

Great! I think the easiest way to get acquainted with how shaders work is to examine the existing shaders in binaries/data/mods/public/shaders/ and also wraitii code on github (hopefully that's the latest version, I'll poke him to check). GLSL syntax is fairly straightforward and all the functions are very well documented on OpenGL's website/wiki (look at Wikipedia's article for a general introduction). Documentation for ARB assembly is a little harder to come by these days, so for starters I highly recommend looking at Wikipedia and the ARB parts of this extremely handy reference sheet, and also any specs you can find on OpenGL's website. There are two elements to your task: first you need to pass the relevant parameters from the C++ into the ARB shaders (I believe wraitii already implemented a solution for this, using the texture coordinate registers, but IIRC it needs some cleaning up). Then, most of the work is in rewriting the shaders themselves in assembly. The main shaders used for model and terrain rendering are model_common.* and terrain_common.*, in both the GLSL and ARB directories, and there are other shaders for water effects etc. You should start with the model and terrain shaders, but then continue until the GLSL/ARB shader sets are as identical as possible (depending on how much time you have available). I should mention that Nvidia's free CG toolkit has the ability to convert GLSL to ARB automatically, but I don't know how practical it is to use in our case. Worth checking out. Of course, I'll be here if you have any questions or need any help.

Nope.

Yes, it does need a rebuild. (I changed the code a little to make it more "simplewater"-friendly...)

historic, what you are saying makes sense and I think I agree. It doesn't really matter what solution we choose, as long as we don't prevent anyone from modding the game in ways we didn't expect. Anyway, back to this bug report. The error is reported on line 160 of pathplacer.js. The problem function looks like a variation of the Bresenham algorithm for creating paths (I think), and the error occurs on this line: retVec.push(new PointXZ(x, z)); which simply adds a 2D point to a variable-sized array. Inspecting the array before the crash on the Alpine* maps (with a "very large" map size), I get a size in excess of 500k points! For reference, a "very large" map is 448 tiles wide, so there are no more than 200k points in the map, so there's something weird going on there. Moreover, the function seems to be called several times with gradually-increasing path sizes, which is definitely something that could result in OOM errors with a non-compacting GC. So, either it's something wrong with the algorithm, and it needs to be fixed, or, the 500k+ points are actually correct output, and the function should be changed to return the path one segment at a time to reduce memory usage (i.e. turn it into an object or closure or similar). Who's the maintainer of the RM scripts, btw? Spahbod?

All the relevant font licenses and required files are located in this directory. Are there any real licensing issues to attend to, or are we just trying to make repo maintainers nervous?

There's a limit to how detailed your objects can be - you can't have more than 65k vertices in a single model. If your models are too high res, you'll need to divide them into parts and then you can tell the engine to treat them as the same object.

Probably. It's easily fixable if it is, so don't worry too much about it. They are animated in-game, but not in Atlas (as with the regular water). As for taking depth into account, something like that will be really fast to do once the postproc manager is done (almost there). It'll require rendering of the water planes twice, but that won't have any impact on performance, I think.

Is the AI runtime the same as the rmgen runtime? I haven't looked too deep into those parts of the engine, but I was under the impression they were separate.

Of course, but since the game isn't that smart yet, the choices we have are to either hardcode an arbitrary value, or to expose it as a config setting. gameboy's bug report is an excellent example of why the latter might be a better solution at this stage in development: instead of telling him he can't use the map size he wants, we could have told him to change a value in the config.

Thanks, I'll look into it. Whoops, committed.

Ehm, I suppose I took that "rainbows and unicorns" comment as a personal attack, followed by a response that was incredibly tangential and argumentative, so I went into super-defensive internet geek mode. All this for the phrasing of a silly sentence... Herp derp.

Maybe you didn't mean to insinuate anything, but you said in the very first sentence of your first post that we aren't taking the law seriously. I see little evidence to show that's true, or that it has been true in the past, and as such it was an inappropriate comment. If you swallow your pride and read my post it is the only thing I objected to. Period. The rest of your post is pure BS and @#$%ion. I never objected to making a good faith effort to keep everything cleared, I never said anything about making decisions for the team. You are making stuff up. And to respond to some of your BS, we are not Wikipedia. We can't have 100 versions of the game for 100 different countries. If we keep worrying that "some judge in some country somewhere" could decide we infringed on some stupid law specific only to that country, we'll be paralysed and we'll never get anything done. The practical option is to pick one country and stay within the constraints of its legal system. If that country is the US, we have fair use. If that country is the UK, we have fair dealing. If that country is Hungary, we have whatever they have. If you don't buy the "fatalist idea" that IP law in 2012 is a get sued, ask questions later system, you are living in fantasy land - complete with rainbows and unicorns. If someone wants to hurt us, they'll sue us, take us offline and drag it on until the project is dead. This has killed countless small companies in the past, which were still in court after they went into bankruptcy proceedings because of legal fees. Even if you win at the end and even get your legal fees back, it's still curtains - there is no WFG and everyone's moved on! So, don't put words in people's mouths. And grow up, ffs.

Abstract programmer art - as if normal programmer art wasn't bad enough! (Just meant to be an example that shows the plane can be any shape.) Btw, Enrique wants to try these effects on his new hanging gardens building. I look forward to the awesomeness!

Guess that function is too new for GLSL 1.2. Fixed.

That's precisely the problem, isn't it? If someone wants to shut us down, all they need is an accusation and there's nothing we can do to prevent it. I also feel compelled to counter zoot's extremely unhelpful insinuation that WFG isn't taking the law seriously. So far, the team has done an excellent job clearing the rights to the material it uses, and it'll take more than a couple of sentences from Wikipedia (which almost certainly fall under fair use and similar legal exemptions) to convince me that we aren't already doing everything within our power to stay within the law.

Choose a smaller map size! The problem is with the engine, not your computer. historic_bruno, we shouldn't be hardcoding the JS runtime size, there should be a setting for it in the config.

Hey there! I might have an interesting task for you, should you wish to accept it. As you may be aware, in Alpha 11 there's been a lot of progress revamping the game's graphics code. For example, we've added support for normal and specular mapping, among many other things. However, the new effects have only been implemented in the high-level GLSL shaders, but not the older (and more widely compatible) ARB assembly shaders. Team member wraitii did some work porting them over, but that was some time ago, so his code is fairly out of date by now. I've been meaning to remedy that for a while, but other tasks and real-life obligations have been getting in the way. Your job would be to port the GLSL shaders to ARB. You can choose to update wraitii's code, or not - I leave it to your judgement. This will involve a bit of coding in C++ and quite a bit of coding in GPU assembly.

Has that ever stopped us before?

Producing it is easy. It's not producing it that is the problem.

Great work everyone!

What if you replace this specular.rgb = sunColor * specCol * pow(max(0.0, dot(normalize(normal), v_half)), specPow); with this specular.rgb = sunColor * specCol * pow(max(0.0, dot(normalize(normal), normalize(v_half))), specPow); in model_common.fs

Waterfalls: a few layers of animated textures on a static plane combined with "smoke" particle effects at points of impact will probably do the trick.

Done.

Btw, what I had in mind was much simpler than that. We could make this format <texture>filename</texture> syntactic sugar for <textures> <texture name="baseTex" file="filename"/> </textures> Since there are no other changes to the xml format, there isn't an "old" format, really (unless you're trying to run new xml files on an old build, but that's not a problem).