Ykkrosh

(By the way, we are (or at least I am) speaking as ourselves rather than as a voice of the group, so the expressed opinions and feelings may differ wildly. That seems friendlier than having everything filtered as PR output, but probably more likely to cause confusion in some cases. I'll try to avoid causing extra confusion in the future )

About the Calculator image: it was just intended as a small joke, so I apologise that it gave the wrong impression. As was implied in that thread, we are working to release a gameplay video, though it's taking a while to get all the pieces organised (particularly with a number of people having been away or busy over the holiday, and since it's not something we've done before) so it'd be a very late "New Year's present" now.

The engine is written in C++, and the gameplay scripts are written in JavaScript. The latter is the parts that modders are likely to work on - it includes the high-level AI, interaction between units, interaction between units and the user interface, etc. JavaScript is probably also much easier to learn than C++ - I expect there are thousands of JS tutorials on the web, though unfortunately I don't know which ones are any good (and a lot are probably bad, in promoting bad habits and in confusing language features with DOM features)... Does anyone here have any suggestions?

Here's a sneak preview of what we're planning to release. We just need to fix a few balance bugs between the Oct and Dec sides, and I think we're planning a quick rewrite of the engine into Python so it can handle unlimited-length integers, but it's making good progress.

By putting a lot of effort into various tricks - there's high-poly models when you get really close, lower-poly ones as you move further away from a unit (because it's small enough that you can't see the difference), and flat sprites when you get far enough away. (That's why you can see a kind of wave travelling up a group of units as you zoom out, at least in MTW and RTW (I haven't played M2TW), as they switch to lower-detail versions which look similar but not exactly the same. The same is done for the trees in Oblivion, and probably in a number of other games.) We're focusing on different areas instead - we don't have additional low-detail versions of any model, since they wouldn't be as useful for us as for the TW games (because we have a more standard RTS camera where you're normally about the same distance from any unit, not looking at an entire army spreading into the horizon). But we do have units of the same type having different clothing patterns, shield patterns, hair colours, faces, etc, avoiding the clone-army look of RTW (since we're concentrating on much smaller battles, where individuals are more important). If we had unlimited resources (on the programming side and the art side) we could probably work out a way to have more detailed units without slowing down in large battles, but unfortunately we don't (and nor does any other game developer) so at some point we have to make tradeoffs between detail, performance, consistency, hardware requirements, effort, complexity, etc, and currently those tradeoffs mean we don't look like M2TW and don't have noses

I've committed some changes that add a 'record' button to the cinematics display - select a track, click record, choose somewhere to save (the file probably should always be given an extension of ".mp4", else I have no idea what it'll do), maybe change the bitrate (the default is just about bearable), then it'll generate the video. Be careful not to do anything that will disturb the window while it's rendering, and eventually it'll finish and you can view the output. (Well, you might be able to view it - I don't know what video players support .mp4 files. I've just been using VLC which does everything I tried and, most importantly, has an unskinned interface.) It's far from polished, but it should at least work a bit

Would it matter if we had to cheat to make it flawless? In particular, there are ugly issues with shadows and reflected objects disappearing around the edges of the screen (because they're outside the view of the normal camera, and so they're not drawn at all, even though they're still affecting visible parts of the scene) - I believe Nicolai was working on some code to fix that but hasn't finished it. We can avoid that problem by making the game always draw everything even if it's not visible on the screen, which makes it go a lot slower but gives the correct appearance - it's just cheating a little bit

Having looked at the details a bit, it appears it should be fairly straightforward export video from the game (/Atlas) directly - then it could ensure there's a consistent framerate by moving the camera slower than real-time, which would avoid any jerkiness. (In particular, the FFmpeg library seems to make it reasonably straightforward to create video files (e.g. MPEG4 AVI) - even high-quality MP4 is going to be much smaller than a series of PNG or JPEG images, and can be easily loaded into a video editing program for later processing, so it should be quite a usable solution). I think it would just require splicing a few bits of existing code together - I'll poke around with it tonight to see if I can get something that works

It looks like Google has at least one Firefox fan, who uploaded more recent imagery for that area - but sadly Microsoft doesn't . (Warning: link doesn't work in Opera, and only half works in Firefox...)

I've not actually played either AoK or AoM - but from the perspective of someone making tools for modders, AoM is certainly not as nasty

That's probably safe to say (though it's probably safe to say the same for a large proportion of all software projects ever developed, and at least we haven't gone over budget ) - we're still making progress, but there's still much left to do before it could be called finished. For me personally, I've already got a lot out of working on this project and with these people, so I think I have a different perspective to that of 'outsiders' who will only get any value from the project when it has released something - I occasionally have to remind myself that the destination is as important as the journey

We've already got a unit viewer which does that kind of thing (since it's useful for us too) - the problem is that although it only needs our graphics code, the .exe contains all of the other code from the game and editing tools. That's things like unfinished networking code, which we need to consider the security of, as well enough of everything else so you could play the whole game (if you had the right data files) which is not what we want to release quite yet

Actually, I don't think they've changed all that much - in terms of graphics we still don't require any features that aren't available on GeForce 3 (with the only exception being that the shiny water is limited to GF6/7 (I think)); and performance is acceptable for me on a 128MB GF4 even with self-shadowing enabled (which seems to really hurt performance on GF4s in any game), though we still haven't spent much time optimising our graphics code. The suggested CPU and RAM in the FAQ may be further off if you want the game to play smoothly, but it's impossible to tell with any accuracy until we've got the game feature-complete and optimised.

We have . (But it can't be "small" except in appearance, because it reuses a lot of the game's low-level and graphics and editor code - and we want to clean things up so it doesn't have to be compiled with the rest of the game's code too, so it'll take some time to get that done before releasing it.)

From here, a claimed explanation is: And 1024 (the vertical resolution) is also a multiple of 256, so a 24-bit framebuffer is precisely 3.75MB and you could make it nicely out of RAM chips no larger than 256KB without wasting any. 1024x768 is multiples of 256 too, and 1280x1024 is what you get when you add 256 in both directions. So it's not entirely arbitrary

Yep, we're still on the norwegian and have to get the danish phase done before moving on Mostly by cheating and using low detail units when you can't tell the difference. And by having large armies as one of the core features of the game and spending a lot of time (including three previous games) optimising and polishing the techniques

It seems to me that they're trying to simplify space, particularly solar systems outside our own - it's hard to talk about discovering new planets if there's no agreement over whether a certain rock is a planet or not. You can't define 'planet' by making a list of them - that worked for the nine we had here, but it won't scale up nicely in the future when we know about too many to count. And any definition has to be straightforward and consistent and not have special exceptions, if it's going to classify future lumps of rock reliably. And most consistent definitions would put Pluto in the same category as hundreds of other rocks that are floating around the sun, and are the same size and have similarly weird orbits. We don't want to make up mnemonics to learn the names of hundreds of planets, so that category is instead considered to be separate from the major planets, and Pluto falls in with that. Seems logical to me They said Uranus was a star for hundreds of years, and a comet for a month - but as they learned more about it and about the rest of space, they were willing to update their knowledge and start calling it something that more accurately describes what it is.

Noted here too - it's just cleaning up the code (updating comments, fixing warnings, renaming things to be more consistent, implementing our top-secret Roman lunar conquest campaign, etc), which is rather useful but not worth describing in great detail each time

But... uh... at least when we won, it was by two goals more than you - Sweden has only ever scraped by with one more than England

Is that the 0 A.D. Promotional Trailer? That page says "voiceover work from Zeus Legion, of professional vocal studio, S.A.V.A.G.E." and "Sounds effects credits go to Wyrmwood." - I believe the rest was made by WFG members, though I wasn't around at that time. (Oh, and do you happen to have the small version of it? I think we've lost that file and it might be nice to have it back )

I think having had the same email address publicly visible for about nine years, and having an infinite number of addresses (i.e. accepting "<anything>@hostname"), is a problem - I've had about 400 spam messages in the last week (including "delivery failed" messages for spam sent with my hostname (but a random username) in the From address), and 14,000 in the past 1.5 years, and that's after my ISP filters a lot of stuff automatically

Only about 8 hours so far today, but that's mostly because I didn't get out of bed until 1pm.

Like sesquipedalian pleonasm and circumlocution? (Unfortunately I have no idea where to look for words that are "sophisticated" but wouldn't sound stupid in a conversation )

The SiS M650 appears to have the basic features that we absolutely require, but it's missing some other pretty important features (like S3TC compressed texture support and a sensible amount of memory) without which the game will run really badly in its normal configuration. We can't have a special mode with low-poly models because we just don't have the resources to work on that, but we can easily reduce the texture quality and the number of decorative map objects (like bits of grass) as well as being able to disable shadows and water reflections, and so the game will let you configure those things. We really don't know how well the final game will run on older hardware, but it's definitely something we're aware of and want to accommodate

That's probably just me - it seems like I've seen too many screenshots where the bloom seems unpleasantly overdone and makes everything look blurry, kind of like when you go outside on a very sunny day and have to cover your eyes to avoid the glare from the ground or buildings or passersby with white clothing, or like some bad dreams I used to have where I could get the impression of vision without being able to really see anything; and in the games it's like that effect permanently . (It also doesn't help that I can't see those effects in real-time on my own computer, so I'm unaware of what it really looks like (and am also possibly jealous of those who can )) Ignoring my feelings: It seems that games which support HDR were designed around that from the beginning - as far as I'm aware (though I'm not a graphics programmer) it's fairly fundamental to how the game's graphics engine works, and can't just be stuck on later. (And our renderer wasn't designed for that kind of thing - it was originally aimed at the GeForce 3, and it would be too costly to completely redesign the renderer and all our art data to focus on more recent hardware features.) I'd guess bloom is easier to add as a kind of hack, so that might be more possible. It's probably less worthwhile in an RTS game than in most other types of game, since the camera is almost always aimed downwards and not at the sky (which is where the blooming seems to be most commonly used) - but it could be a nice addition to the higher-end water shaders when they're reflecting the sun or bright sky. But I'm still not a graphics programmer (nor an artist), and I don't know how hard that would be or whether it's worth the effort, so, um, I don't have any useful answers