myconid

Ok, I'll do that tomorrow, as it's getting pretty late here. The gentangents option does serve a purpose, so I'll leave it in but make it even clearer that both are needed to use the new effects. My rationale: Technically, tangents are not needed when GLSL is enabled but the normal/parallax materials aren't being used (i.e. when the material quality options are set low enough). Tangents use extra GPU memory. Not huge amounts, just 16 bytes per model vertex, shared between all model instances. That's around 400K extra for a fairly complex model like the Roman CC. This can add up, and may cause problems for older GPUs with very limited memory - those aren't powerful enough to use the fancy materials, anyway. The new effects will also get ported to ARB (wraitii has already done some work on that), so the option will be relevant there as well.

Just noticed this thread! Ok, removed the commented stuff and changed the ugly conditional. So far so good! Alternative materials are loaded instead of the current material, not in addition to it. The idea is that models always try to load the best-quality material available, and if the user's config settings aren't high enough, an alternative material is loaded that uses fewer effects (this goes on recursively until an acceptable quality level is reached, or no alternatives are available -- it's also possible to have several alternatives in a single material, as long as the quality values are in descending order). It could have been done the other way around, of course, by starting at the lowest-quality material and going upwards, though either way the idea is pretty much the same.

Actually, I have access to the internal SVN repo now, and I'm ready to commit everything. If that's what you're referring to, then expect it to be in by tomorrow evening (GMT)! I'm delaying in case someone tests the ARB mode and finds any glitches, though hopefully there won't be any. Not sure if that repo autobuilds Windows binaries, though. I've seen the binaries in the "system" directory, but I don't know if they're kept up to date.

I did forget to include the grass. The custom alphamaps should work in ARB mode too, come to think of it. Grepped through all the decals again, just to make sure. Thanks for testing! Latest code: https://github.com/myconid/0ad/tree/merged-patch5

Here's a few tests you can try: Modelmapping: Look at Roman CC and Mars Temple 2 models for AO/parallax/normal/specular/emissive mapping. Look at windy trees when in the game and in Atlas after pressing "Play". Smoothlos: Los should move smoothly around units. It should toggle correctly from the dev console. It should not be visible at all in Atlas. Terrainmapping: "Biome alpine/Alpine cliff" uses triplanar, normal and specular mapping. "Biome desert/Desert city tile" uses a custom alphamap. "Grass/Grass1 spring fancy" uses the special grass material. "Snow/Snow grass 2" uses normal and specular mapping. Heightmap: In atlas, File/Import heightmap. Choose an image file (not too huge!). In the first three, also check if ARB and Fixed modes work as expected (there should be no visible changes). Pay special attention to decals, as I've had to modify those manually and since they are stored all over the place I might have missed some (I just spotted a broken decal in Campaign Test map, fixing that now).

I'm rebasing stuff straight into the patches, so I do that as a crude way of keeping a history. Messy, but that's what I use git for. The error in terrain_common.vs was actually a typo in the declaration of a_uv0. For some stupid reason I typed vec3 instead of vec2... for UVs! Done. Smoothlos may look like it works independently of preferglsl, but it actually depends on a GLSL shader that has no ARB equivalent yet, so it won't work if your GPU doesn't support GLSL. Thanks, glad to hear that!

Okay, I'll commit the patches tonight. If there are mistakes, they'll show. k776, this may affect ARB as well, as there have been a lot of changes to how things are done in the background. I'm most apprehensive about the changes having been tested quite extensively in GLSL mode but almost not at all in ARB mode. Echelon9, wraitii, thanks for the suggestions and for testing.

Okay, 3/4 patches are completed and ready for review! 4th is easy and should be done by tomorrow at the latest. Each patch is saved as a separate commit in this branch: https://github.com/m...e/merged-patch4 Running a bit late for Alpha 11, I guess... but if someone can step up and review this, there might still be a chance. Edit: Ok, 4/4 patches are ready. I don't want to commit anything to SVN without it being reviewed first, as these bring rather extensive changes so there's always a possibility of silly bugs that could be caught now. Please review them in the order committed, let me know what needs to be changed and I can take care of committing to SVN now that I have access.

The patching sort of works when I do that, though it looks like it corrupts the textures and they fail to load.

patching file binaries/data/mods/public/art/textures/terrain/types/water/foam.png patch: **** malformed patch at line 1113: \ Pas de retour chariot à la fin du fichier "No new line at end of file". It also appears in the patch, at the end of all binary files.

Thanks. It appears these aren't graphics-related errors, but event handling errors from the window manager. They seem to be caused by either SDL or OSX, not Pyrogenesis: #15 0x0000000100d62dd1 in QZ_PumpEvents () #16 0x0000000100d3bad8 in SDL_PumpEvents () #17 0x0000000100d3bf61 in SDL_PollEvent () <- function in SDL to access input events #18 0x0000000100017afd in PumpEvents () at ../../../source/main.cpp:181 <- our code calls ^ where our code just does this: SDL_Event_ ev; while (SDL_PollEvent(&ev.ev)) <- this line, though there's no way the engine could cause this call to fail {... Why are these triggered by my changes? Good question, as there's nothing in my code that relates to event handling! The main difference from an event-handling perspective is that the drawing phase takes longer than before, so maybe this forces an unexpected SDL or OSX bug to the surface. My instinct would be to open a bug report for this and let it be for now (especially as the errors don't seem to be harmful), though maybe that wouldn't be the best way to go about it. Any other programmers have thoughts on this?

Oh well, since I can find literally no info on any of these errors, we'll have to do the digging ourselves. This line looks particularly interesting: Sat Jul 28 21:42:43 s030454t.local pyrogenesis[36019] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. You'll need to start the game with gdb (look for a tutorial if you don't know how, it's fairly easy). Of course, things will be much easier if you edit the game's config to set fullscreen to false. You'll need to set a breakpoint on the "CGErrorBreakpoint" symbol (with "break CGErrorBreakpoint" in the gdb console), so the engine's execution will be paused when an error occurs. Type "bt" in gdb to get a backtrace and post it here. Then type "c" to resume execution, until another error occurs. When another error occurs, do the same thing. There seem to be at least three different messages here: kCGErrorTypeCheck, kCGErrorIllegalArgument and kCGErrorRangeCheck. You need to resume and repeat for at least three times.

First, some compilation errors: ../../../source/renderer/TerrainRenderer.cpp: In member function ‘bool TerrainRenderer::RenderFancyWater(const CShaderDefines&, ShadowMap*)’: ../../../source/renderer/TerrainRenderer.cpp:912:43: error: ‘glGenFramebuffersEXT’ was not declared in this scope ../../../source/renderer/TerrainRenderer.cpp:913:59: error: ‘glBindFramebufferEXT’ was not declared in this scope ../../../source/renderer/TerrainRenderer.cpp:925:108: error: ‘glFramebufferTexture2DEXT’ was not declared in this scope ../../../source/renderer/TerrainRenderer.cpp:1022:45: error: ‘glDeleteFramebuffersEXT’ was not declared in this scope You need to add "p" to the front of the function names, due to how they are imported in glext_funcs.h. ../../../source/renderer/WaterManager.cpp: In constructor ‘WaterManager::WaterManager()’: ../../../source/renderer/WaterManager.cpp:73:23: warning: converting to non-pointer type ‘GLuint {aka unsigned int}’ from NULL [-Wconversion-null] Use "0" not "NULL" (better), or use an explicit cast (should work, but kinda funky). And then, there's this: ERROR: CCacheLoader failed to find archived or source file for: "shaders/glsl/waves.xml" ERROR: Failed to load shader 'glsl/waves' Segmentation fault You have to use "svn add" on any unversioned files you want to include in your patches. Please use git in the future, it's much easier to test from.

My thought exactly. If someone can direct me to the high-poly model of that statue, I'd love to have a stab at it.

Ah yes, that looks like the sort of thing I had in mind. Nice work!

Ok, might as well chip in with some thoughts on the topics being discussed: There must be some sort of core design document. For anything except the simplest projects you must have at least some idea about where you're headed - and that includes even the most "agile" development styles. Of course, I'm not suggesting to have every single aspect of the game fully specified before any development takes place (that's just as bad as having nothing at all), but you must have some sort of rough plan about what you need and how the pieces should fit together. I'm ok with a historical setting, but I'm not sure if it'll be too boring and constraining. Maybe we could spice it up by taking elements of various ancient civilisations and mixing them in interesting ways, creating a new world that resembles our own but has its own history and lore. I'm not opposed to having some supernatural elements in the game (it's just a bit of fun after all), but if we do I'd prefer they are not overdone in the cliché fantasy style where you have lightning bolts flying everywhere. What if instead the laws of thermodynamics work a little differently in this imaginary world, so we can create pseudo-scientific explanations for the phenomena we encounter to enrich the world's backstory? I've been thinking about what's the best way to use 0ad's engine for an RPG, while having maximum code overlap so 0ad benefits from these changes as much as possible (at the end of the day, that's the main goal). Thinking back to AoM, I'm pretty sure there were RPG-like "quests" in some of the campaign scenarios, so realistically that should be our basis for the control system etc, but with extra RPG elements. I can think of at least three popular RPGs whose gameplay would translate beautifully into that sort of gameplay with minimal code changes: Neverwinter Nights, Fallout and Baldur's Gate (all use different engines; look for let's plays on Youtube) - there are probably many others. I'm not sure if these games are strictly ARPGs, but from a programming POV they'll definitely be the easiest (and ultimately the most useful) to try to implement in Pyrogenesis. Finally, I'd like to stress a point made by Gen.Kenobi: While RPGs usually have a far-reaching main storyline that spans the entire game and progresses as you complete the main quests, the real meat is not the main storyline (one can typically go through the whole storyline and finish the game in like an hour), but the exploration and side-quests, which gradually reveal more trivia about the characters and gameworld. This means the gameworld needs to be a really really interesting place (both visually and in terms of backstory), as that's what the game is really about.

Thanks! At the rate we're going we'll probably have these in by Alpha 11! If not, I'll provide some screenshots. My laptop really sucks at video capture, though (if only I had an SSD!). Or, do you need these before Alpha 11 is released? Yes, but the problem wasn't with matrix multiplications, it was with truncating mat4 into mat3 using the matrix constructors.

It is, he's telling us that's fixed. The second screenshot he posted is of the unmodified game, and it has the problem we fixed. The first screenshot only has the shadowmapping problem, which is unrelated.

Looked it up. The Alt+Enter shortcut is inherited from SDL, and the problem is on their end (the fullscreen toggling is not implemented on Mac yet). As there's no way to change resolutions from inside the game, I guess we can leave this be. (Maybe you can try different resolutions in the config, but that probably won't make any difference.) Yeah, I want to know about this too.

Alright then, so the "Deep Forest" random map uses the "flora_tree_pine_animated" actor, which isn't supposed to be used. The rmgen Javascript needs to be changed to use a different actor. That doesn't fit in these patches, but it's still a (minor) bug. Thanks for reporting your findings, halcyonXIII!

Ah, I see now (my guess was wrong^). I'm looking at the model and it seems the root point is set correctly (it's set as a "point" in Blender, look at the outliner window). The problem is that this particular tree is animated. That is, someone added bones to it and animated it manually. It looks wrong in the game because it has two wind animations overlapping each other and doing weird things. Basically, the solution is not to use this model in the game OR remove the manual animation OR switch its material to the static "basic_trans.xml" material.

The system is a MacBook Pro, mid 2007 model, 2.2 GHz Core 2 Duo, 4 Gb, Nvideo 8600 GM 128Mb; running OS X 10.6.8. Especially where it concerns the graphics card it's not a fancy system, so perhaps I should try to disable a few things to see if matters improve? The flickering is a known issue with the shadowmap, not caused by my changes. It can be ignored for now. As for the errors, a search shows they're Mac-specific, though there's absolutely no info to go on (none!). Can you at least check if these were caused by my changes? You'll need to compile the vanilla code and make sure that preferGLSL is true in the config (even if they were caused by my changes, there might be nothing we can do about them). They aren't fatal, though, which is good. Edit: Ok, it looks like these errors have something to do with the Mac's window manager. Loads of applications have them, but there's no documentation and nobody has any solutions for them. FWIW, I found an old forum comment that suggested that changing resolutions sometimes helps (you can hit Alt+Enter in-game to switch from fullscreen to windowed in 0ad), though that's hardly a solution. I think this can go down as another driver/OS bug...

Well spotted, didn't see that! Technically, it is pulsating, that's how the effect works. I make two general assumptions: The trunk sways back and forth in the direction of the wind, and vertices higher up sway more (ie tree sways in the wind, but root is stable) Vertices further out from the trunk move in "waves", and vertices further away from the trunk move more (ie longer branches sway more) It looks like this particular model's "root" point is not set correctly in the model, so (2) looks wrong. The model needs to be corrected (it's probably the only one).

I thought I'd fixed that. Oh well, just remove the ".x" on line 205 of that file. Edit: Modified patch is attached below for anyone else who wants to test. modelmapping-final3.diff.zip

Instead of that you can use patch -p1 -i patch.diff Sorry I didn't say this before. I'm just so used to these things that I do them automatically and forget they aren't obvious!