historic_bruno

We already have alpha testing (thanks to 11475), we just don't have it enabled by default since it can cause rendering artifacts depending on the model. To try it, set forcealphatest=true in your config file. It was discussed in #0ad-dev about a year ago, including Gambia River http://irclogs.wildfiregames.com/2012-03-05-QuakeNet-%230ad-dev.log, http://irclogs.wildfiregames.com/2012-04-03-QuakeNet-%230ad-dev.log

Simplest solution: make the dialog wider so the text fits, or we could use angled/rotated text if the GUI engine supported it, or we could use icons if there are any obvious ones for Ally, Neutral, Enemy, It's one of those things a player really only needs to learn once, and then they understand the layout, so there's clearly a tradeoff. Is there a better control than unlabeled checkboxes for selecting diplomatic stance in the first place?

I'm no OpenGL expert, but I think the issue would be more to do with efficiency in the implementation rather than difficulty of programming it, because there will be a lot of boats constantly moving around. Ideally there would be other interactions between boats and water, like wakes and splashes. Currently water is a single flat plane, which is simple and efficient, but also has limitations as you observe. Maybe someone knowledgeable about shaders can weigh in and tell us how difficult/feasible more realistic effects would be.

In fact, I think you'd be ideal for that, given all the great work you've done in the past with icons and stuff Having some mockups would be nice, and having someone to ask when new features get added and need UI work, would be even better! Here are some things that come to mind: * Session diplomacy box * Tooltips are inconsistent and ugly, especially in game (unit training, construction) * Post-match summary screen * Game options menu (not implemented yet, work in progress [leper]?) - and see in game Menu > Settings * In game unit stats screen (not implemented yet) * Multiplayer lobby (not implemented yet, but work in progress) * Large text boxes: in-game manual, "technical details" on main menu, history / civilizations menu, anything with transparent black background * Various dialog boxes: try joining a non existent game and see the ugly status dialog, or in game Menu > Resign * Error dialogs: try running game with -autostart="foo" option to see an ugly error * Various "widgets" positions and appearance: frame rate counter (Alt+F), game time (F12) You can probably find more. I'm sure working on the overall theme would be useful too.

I agree completely about needing someone to consult for UI stuff. If the programmers have a direction from someone minding the aesthetic issues, we will make it happen. The current UI is very ugly, especially the partly transparent black boxes all over the place, layering issues, ugly/inconsistent resize behavior, etc. That would be a worthy task for someone who need not even touch the code. The crashing issue should be fixed, if I'm thinking of the same bug as you are, but the game will currently end when the host leaves or is disconnected. It would be nice if the other players could continue playing, but I suspect that wouldn't be trivial given the current network architecture. Maybe if we support multiplayer saved games, we could come up with a decent way of continuing them after interruptions.

This is true, but if it got approved and sold in the Microsoft app store, that would be a huge advantage for distribution, so it would probably be worth the effort if the app store takes off. I wouldn't have a problem with this as long as the source code is freely available, and as you say there's really nothing we could do to stop it being sold, given the GPL licensing. Though I'm not sure about the artwork licensing and how that works. Personally I think working on Android or iOS ports would be easier and capture a larger section of the mobile market, but both have their drawbacks as well.

How are you making the game portable, using the -writableRoot option or something else?

It's somewhat of a bug, since it basically doesn't work at default window size on wxGTK (depending on the theme). My personal preference would be having collapsible panes for each section you see there on the side panel, so they could collapse and fit on screen. The problem is those aren't officially available on wxWidgets 2.8 (they are in 2.9). We could also use a scrolled window, like I recently added to the environment tab.

Mythos, you could remove the old Pledgie link in yours

Sounds like Philip is making good progress on that, he's already got a Git server up and running, and much of the conceptual work is done. Last I heard he was starting to work on the update script / package which will be what people use to get the latest Windows build / precompiled libraries. (If there's been more progress than that, I need to read the past 1-2 days logs to see it) Of course even when the technical work is done, we'll need to write tutorials so everyone knows how to work with Git.

We still have one to fix from A13. Just saying...

These aren't graphics specific but are relevant: http://trac.wildfiregames.com/ticket/1810 http://trac.wildfiregames.com/ticket/1811 Maybe http://trac.wildfiregames.com/ticket/823 -- it only mentions the idle worker button, but the GUI work needed applies to any of them. There should probably be a separate ticket though for each function still needing implemented.

In Atlas, there are basically two states: * "Reset" where the game UI is hidden, the game is essentially paused but not in the same way as a normal game, it's like the map was just loaded and initialized, so it needs a special case to deal with that. This is Atlas' default state, no sound should play. * "Simulation test" where the session UI is shown and the game may be run at some arbitrary speed (0.0 = paused, but as you've seen it's not handled through global variables like a normal game). So the point with Atlas sound is not to pause or mute it at all, but to reset it to nothing in the "Reset" mode. When it's in "simulation test" mode, it doesn't really matter what happens with sound IMO, since that's a much less common case, but we could also special case pause to mute the sound. Atlas doesn't minimize or pause automatically, so it's not necessary to handle that. If you can provide some API for sound manager to reset sound to default state with nothing playing (all buffers cleared), I or someone else can write some AtlasUI / GameInterface code to use it. Unless you really want to delve into AtlasUI, it's not too bad once you get used to it, but you do have to realize it's running in a separate thread from the game engine and thus custom message passing is used to control and query the engine.

If that's something you want, make a Trac ticket for it The same goes for the other requests in the topic, and they could likely be given the "simple" keyword. We have lots of potential programmers at the moment looking for intro tasks, so the more simple tasks we have to chose from, the better.

There's also a ticket for it on Trac: http://trac.wildfiregames.com/ticket/1852

Never underestimate what an artist can do with even rudimentary tools I've seen particle systems do amazing things, somewhat more advanced than 0 A.D.'s system, but particles nonetheless. Not sure I've seen the type of effect Pureon is wanting in this topic, and they're very inefficient, we should probably limit how much we rely on particles, there will be many such damage effects rendered during sieges.

Maybe related to recent unit interpolation changes? e.g. #1858, #1865

I thought that was only temporary behavior, and eventually we'd have proper herding and corralling, where the animals would provide a steady stream of resources and civ-specific bonuses, without requiring any micro.

Keep in mind that there's a config option "pauseonfocusloss" that can be changed, so the game doesn't necessarily pause when it loses focus. Do you play in windowed mode? Try it, and switch from the game quickly to say, a chat window, and back, and listen to what happens A few things that could address the specific example you mentioned: 1.) adding in-game volume controls with hotkeys [planned] 2.) transitioning to a quieter "menu music" on pause [planned?] 3.) fading music out completely on minimize, but not for a focus change in windowed mode (not sure the engine currently distinguishes these, which are fairly different use cases) 4.) speaker volume knob, or an OS volume control hotkey if available, many keyboards and laptops have shortcuts for this Sometimes there's a tendency to add an option for everything, but maybe time for muteonfocusloss or muteonpause in the config?

Sweet vid I think the particle system would need some tweaking or additional effects added to achieve what you're looking for, in particular, I'm not sure if it supports a burst or explosion effect yet. Keep in kind that the "particles" will always be simply textures facing the camera, and not like bits of 3D shrapnel flying through the air. Maybe it's possible to approximate damage that way, but it's difficult to get my head around how it would be done... Anyone know if shaders could accomplish shrapnel-like effects and how much effort it would be? And even if we don't go as far as in that video, we do need to show structure damage somehow...

Also the projectile hit animation needs some thought on how to make it efficient while appearing random and believable, I don't think it should use the skeletal animations currently supported by the game. Need more detail on how exactly it would look: will it be a generic shrapnel explosion or specific to each target, will the target need to show the damage accordingly at the spot it was hit, and it might help to see some examples in other games.

About r13347, the music cuts off abruptly whenever the game window loses focus, even if it's just to tab over to some other window. I think in any case the music should gradually fade to silence, but I'm not convinced losing focus should necessarily pause the music. I think there are multiple cases to consider: fullscreen vs. windowed, minimized vs. lost focus. There's probably a better argument to be made for muting paused games; we could also transition to a quiet music track (Omri is working on one such track I think, to play in the game menus).

So Philip and I discussed this more today and came to agreement that: 1.) the time and space required are reasonable for saved games, 2.) it's nowhere near fast enough for full OOS checking, but also 3.) full OOS checking is really only desirable and practical during development and once AIs are multithreaded, that will add additional latency which is unacceptable, so 4.) it's probably best to not serialize the AI state for OOS checking. In other words the special case should be full OOS checking which can exclude any components we want, while allowing us to benefit from automatic AI serialization in all other cases. AI devs will be especially pleased with this, as they will have only a handful of general rules to remember and won't typically need to write custom (de)serialization code (hopefully never). I have yet to attempt to convert Aegis or the other AIs to test them. Mostly it's a tedious process of going through and testing for any (de)serialization errors or class like objects that weren't registered, and fixing those problems. Also a heads-up: with Yves work on upgrading Spidermonkey, the AI framework may need some substantial changes related to sharing data between script contexts. Not sure on the details but apparently new Spidermonkey is stricter about that.

The test is very simple and will only take a minute Start the game in windowed mode as you say. Then in OS X system settings, change the display resolution while the game is running, to some other resolution. See if the cursor offset is there and if it seems like the bug you reported. I believe this is one and the same issue, what is happening is that the resolution is changing after the game enters fullscreen mode, maybe due to special handling of Retina displays, and SDL 1.2 isn't handling that correctly. So far in my tests, SDL 2.0 seems much better on OS X, for example resizing and toggling fullscreen mode works flawlessly (on 10.8, not tested on e.g. 10.5 yet...)

Don't forget, we have looting, so if you demolish someone else's structures, you can indeed recover some of the resources. And I agree with Mythos that it wouldn't be bad to have a similar concept when destroying your own.