Ykkrosh

Does the change in r9284 fix it for you?

Do you have VC++ 2008 Express SP1, or a pre-SP1 version? (Anything downloaded since August 2008 should probably be SP1, but I assume there's some version info in the About screen that might say). The documentation sounds like it should be supported in 2008 SP1, so I'm not sure why else it would fail.

It's not for pathfinding (it's no worse (and maybe actually better) to move one group of 80 units rather than two groups of 40). I think I remember it being largely due to fitting all the unit icons in the UI, when it showed a separate icon per unit - maybe that's not relevant now and the restriction could be relaxed. (Probably a question for Brian )

I think the main reason was that we want to support camera rotation, and most games seem to rotate the minimap to match the camera orientation, which makes sense since it should reduce players getting confused about which direction they're moving in; and rotating square minimaps is ugly, so circles work better. It seems some people prefer circles and some prefer squares and there hasn't been evidence of a large majority either way, and I don't remember anyone giving a non-preference-based argument for square maps, so we went with circles. I don't see why not. I think I'd kind of like to get rid of the GUI's automatic shading thing at some point in the future (since it adds complexity to the GUI renderer, and the renderer will probably need to be rewritten at some point (since it's a bit slow)), so it's probably nicer to use separate mouseover textures, if it's not much trouble to create them.

As far as I'm aware, for the game's perspective raw throughput is pretty much irrelevant: either we're loading from a cold disk cache and get killed by seeks, or else we're easily fast enough and don't need to worry since our data set is only tens of megabytes. I would (perhaps naively) imagine there might be optimisations that could reduce seeks (like maybe the game can request a hundred files at once, and they get read from disk in an optimal order rather than in the arbitrary order the game would otherwise load them in, or something) which might help, but I don't know how feasible that is. Something else that would likely help is enough thread-safety to read files from background threads - in particular the AI scripts sometimes want to synchronously read an entity template XML file, but they (will eventually) run in a thread so they can't use the VFS directly, and they can't proxy the requests through the main thread since the main thread might be spending the next 100ms rendering and will have terrible latency, so currently the main thread loads all the template files in advance, which hurts startup time quite a bit. If it was possible for the AI thread to load files on demand, while the main thread is busy rendering, that would probably be very nice. (It'd be okay to only allow a single thread in the VFS code at once and block the others, for this case - they don't need concurrent VFS usage.) I have no idea how much effort it'd take to add these features, but I expect they're what would help the game most. (Am I mistaken in thinking so?) About caches: I don't think the game has any particular need of file caching - most stuff is cached at a higher level (as textures, meshes, etc) and it seems a waste of memory to have it in multiple caches. So removing caching sounds fine to me.

I'd suggest not spending any effort on that - it's only a few tens of kilobytes of memory so it really doesn't matter.

Shift-D to open the developer thingy, enable time warp, hold down space to fast-forward, press backspace to jump back a few seconds (except that's fragile and definitely won't work when you've got AIs).

As long as it's within the bounds of the NDA

You can already run the game like "pyrogenesis -quickstart -autostart=Oasis -autostart-ai=1:testbot -autostart-ai=2:testbot" to set up AIvAI, then use the 'time warp' mode in the game or do Engine.SetSimRate(10) etc in the console to speed it up. (It should give the same outcome each time since it's deterministic - I guess at some point I should let the random seed be changed.)

Diamonds probably wouldn't make sense since they wouldn't match the default camera angle (which is looking northwards across the square map). I think it's best to stick with a single design, rather than being continually indecisive about map shapes, so just go with the circular minimap in the GUI. For compatibility with old square maps I can make it draw them in the minimap with suitable scaling so they fit, with some black around their edges, rotating like circular maps do, so it won't look particularly pretty but there's no rush to get rid of all those maps immediately.

If we add a weather system then that kind of cloud thing should be good to include (and should be easy, assuming it's basically just a large repeating texture that scrolls across the ground). Incidentally, I've played a bit with specular maps (currently done by creating a second texture with the specular intensity in the alpha channel, with the assumption that a normal map could be added in the RGB channels at some point in the future; I don't know if that's a convenient way of editing the textures though). It's a simple extension to the shaders, but I think it needs some non-trivial architectural changes to the renderer (to support per-object materials - some need the specular shader, some need the standard shader instead, some might want an alpha-tested material, etc), so unless it's urgently desired I'll probably think about it slowly before getting it to a committable state.

Yeah, particles won't interact well with other alpha-blended objects (like trees or water). I think to some extent that's unavoidable (because alpha blending is evil) - there might be some possible improvements, but I believe particles intersecting alpha-blended trees will never work well. (Trees intersecting trees don't work either, for the same reasons.) (Particles are generally an incredibly inefficient way to implement fog anyway, so they shouldn't really be used for that ) Particles popping into view is a (known) bug - currently it only draws them when the actor's meshes are visible, and it needs to compute the particle emitter's bounding box so it knows when they are potentially on-screen and need to be drawn. I ought to fix that

We do make use of lots of open source libraries, and if we added physics then we'd use an existing library rather than rewriting it from scratch. Integrating something like that is still a lot of work, though, and the benefit doesn't seem compelling enough yet. Switching to a third-party rendering engine would be a lot more work than that (including the time taken to learn it, port all of our content to new file formats, etc), so for now I think it's less work to incrementally add features to our current custom rendering code. Depth of field sounds fairly useless in an RTS game, since the whole world is at pretty much the same depth from the camera . Other things would be nice, but are probably less critical than getting the gameplay working first.

I think all the "DRI R300 Project" devices reported here are r300c (vs "X.Org R300 Project" which are r300g, and "X.Org" which are r600g) (does that sound correct?). That looks like about 3% of users are still using r300c so it seems important to not break badly for them - hopefully it'll be sufficient to switch to the fixed mode and show a warning suggesting they update their system.

You probably need to run "make clean CONFIG=Release" before rebuilding.

About default.cfg: Thanks, fixed. Shader mode doesn't use GLSL shaders, it uses GL_ARB_fragment_program/GL_ARB_vertex_program which those drivers claim to support (by advertising those extensions), so I don't see why it would fail. It's always possible there's bugs in the game, but since it seems to work on most other drivers I'd probably assume it's just driver bugs. I don't know any way of automatically detecting that it's going to fail, so if this affects stable release versions of Mesa (not just recent Git versions) I guess we probably need to add stuff to hwdetect.js to force the disabling of shader mode on r300c drivers, which isn't nice since it really ought to work on those devices

Looks like you're running an old version of the executable (since RenderPathVertexShader was removed from the code recently), so presumably not the one you built - maybe you built pyrogenesis_dbg.exe but ran pyrogenesis.exe? I think the autobuild .exe will have this problem so I'll recompile that now.

Hmm... I think there's actually two problems here. The Blender file has 3 keyframes, each rotating by 120 degrees (I assume) in the same direction, but when we import the Collada file it acts like the third keyframe has rotation 0 instead of 360, so between the 2nd and 3rd keyframes it rotates backwards. That might be a problem in Blender's Collada exporter or our Collada importer or our code that uses the importer, so I guess I ought to investigate that. The other problem is that our graphics system stores the animations with (I think) 30 keyframes per second (regardless of the input animation) and then interpolates smoothly between each keyframe, and when it reaches the end of a looping animation it interpolates between the last keyframe and the first, to avoid any sudden jumps. So even if the animation was imported correctly, it'd interpolate from 360 degree rotation to 0 degree in 1/30th of a second. In this case we really want a sudden jump, so I'm not currently sure how to distinguish the cases and handle them correctly.

After Z we could go AA, AB, AC, etc. What's the ancient Greek for aardvark? (I think it makes sense to switch from alpha to beta once the game is basically feature-complete, so beta will just be fixing bugs and balancing gameplay. It'll be a while before we reach that stage, but I think that won't really take so long that we run out of letters )

I wrote some documentation - does that help a bit, and/or is anything particularly unclear? Those will likely need some engine extensions.

I added that XML into skeletons.xml (at the end, just before the </skeletons>), made an actor like <?xml version="1.0" encoding="utf-8"?> <actor version="1"> <castshadow/> <group> <variant> <mesh>temp/0ADIberianRammove.dae</mesh> <texture>null_white.dds</texture> <animations> <animation file="test/0ADIberianRammove.dae" name="Idle" speed="100"/> </animations> </variant> </group> </actor> and selected the actor in Atlas and it worked okay for me. (The only problem is it expects animations to be smoothly looping, with the first frame identical to the last frame (if I remember correctly), so the wheels turn forwards and then quickly spin backwards before starting again.)

It says "The os.is64bit function determines if the host is using a 64-bit processor" which doesn't sound like the right idea - some users run 64-bit kernels on 64-bit processors but with 32-bit userspace, so the game needs to be compiled in 32-bit mode. (Looks like that's what this change was for). I don't know whether that means Premake's code is doing the wrong thing or just that the documentation is imprecise, though.

Hmm, I guess the important distinction is that what we're using now is programmable shaders. Early graphics hardware (which OpenGL was originally designed for) just provided a fixed set of features that could be enabled or disabled or maybe hooked together in slightly different ways - there's a thing that calculates diffuse lighting per vertex, a thing that calculates specular lighting per vertex, a thing that computes fog, a thing that reads from a texture, maybe another for a second texture, etc, and they all connect together in a predefined order (originally because they were literally connected that way in the silicon, I expect). That's effectively doing shading, but the term shader usually isn't used in this context. You don't get much flexibility, so if you want to do a moderately complex graphical effect it usually requires some tricky combination of all the available features. With (programmable) shaders on modern hardware (c. 2003), you replace all of that fixed functionality with something much more generic that can run a programming language. It's a pretty restrictive and highly specialised programming language (especially the old-fashioned language we're using), but it basically lets you do whatever lighting/texturing computations you want - it doesn't care that you're doing diffuse lighting, it just knows you're multiplying two values together and dividing by a constant and adding a third value or whatever. That gives far more flexibility. Instead of having to twist your implementation of a graphical effect into the predefined sequence of functions, you just write exactly what you want and the graphics card does exactly that. The new brighter lighting model might be technically possible with our old fixed-function rendering code, but it's non-obvious and fiddly and might not actually be possible at all. In the new programmable shader system, it's two short lines of code and that's it.

It's pretty much all just boring technical details, so I'm not sure what kind of things you want explained . What it means in terms of implementation is that instead of writing code like this, we write code like this, which is probably equally incomprehensible, but it makes it much easier to write more complex graphical effects and it allows us to make better use of the user's graphics hardware. The difference with the lighting is also just boring technical details, with the consequence that it handles bright sunlight more accurately than the old approach.

If the architecture detection is currently only a problem on OS X (is that the case?), then using /bin/bash won't make a difference (since OS X always uses bash) and there's a danger it might introduce problems on other platforms that currently work, so it'd be safer not to change it unless the change fixes a real problem. (Using HOSTTYPE is a terrible hack anyway - probably what we ought to do is something like autoconf (maybe actually use autoconf) to detect what the compiler is really targeting.)