k776
-
Posts
721 -
Joined
-
Last visited
-
Days Won
6
Posts posted by k776
-
-
Excellent work. Your latest changes work flawlessly. It looks like this commit (https://github.com/stwf/0ad/commit/e118770c61f84b8c4c14fbecd79a0cb7d9f43077#diff-0) stopped actionGain from being set though.
Other than that, it's working great on Mac. Have you been able to try this on Linux and Windows?
If it works on all 3 operating systems, then we can start moving ahead to include it into Alpha 10 hopefully :-)
Anything I've missed from the TODO list?
* Sounds intensity based on position
* Sounds intensity based on zoom level
-
The Nvidia GTX 560 should do the trick.
-
The AI is slow because each one keeps it's own entity list, data for where to build etc etc. They don't share, so an 8 qBot game will be 7x slower than a 1 qBot game.
Various components in it too could be sped up, like the AI finding what to harvest (i.e. is it reachable), where to build, among other things.
And path finding has been getting slower as more things get added to the game. Philip is already working on the path finder, but I don't know when it'll be finished.
-
1
-
-
The GeForce 210 only has 512mb of graphics memory. I would recommend for that size screen a card with double that (1GB of graphics RAM).
That said, the game is in Alpha still, and has various places it needs optimization. The path finder is slow, the AI is slow (so a 8 player game against AI is very slow).
So even with better hardware, you'd still get slowness. Might be best to try out the game in a lower res first, e.g. 1280x800.
-
Thanks stwf. I'm giving this a go now.
For those with git repos of the project, here is stwf's work: https://github.com/stwf/0ad/commits/new-sound-manager
-
1
-
-
A lot of things will be optimized once the games main features are implemented. Namely pathfinding and AI. Steps to optimize the path finder have already been taken, but on hold at the moment. See all of Philip's reports at: http://www.wildfiregames.com/forum/index.php?showtopic=152701) ... it's a lot heavier than I thought it would be, in terms of the graphics. ... is this caused by the fact the game is still in Alpha? Will it be optimized in terms of demanding graphics, kind of?2) When testing the game with AIs, I also noticed some huge slowdowns.
Gameplay is important to us. We have several big features to finish before the game enters the Beta stage, and then some. And we have two depts, one for gameplay features, another for artwork. So we don't have to chose one or the other. :-)3) RTSs (just like most modern games) started to give more priority to graphics, instead of gameplay.... gameplay is the most important thing on a RTS. ... Are there any reasons for me to be worried? Is gameplay the most important thing on 0AD, like it should be?
Depends on how many people want to make an AI for it. We want include them all by default, but the best will be, and then we might setup a place for AI writers to upload their creations. We don't know yet... we'll cross that bridge if we get to it.4) AOE2 ... there were like 500 AIs for that game, ... What can I expect on 0AD, regarding the AI department?
I'm not sure what AutoQueue is sorry, so I can't say if we'll have it or not, but if we did include it, we'd welcome a patch which adds a config setting to game setup or something (when we have a more comprehensive game setup screen). That's the beauty of open source. If something doesn't work, help make it better.5) Last thing, this one regarding the famous AutoQueue option that some RTSs have. -
I've added a ticket for this bug at http://trac.wildfiregames.com/ticket/1353
-
I've added a ticket for this bug at http://trac.wildfiregames.com/ticket/1354
-
@nu111: I'm afraid performance issues will be an ongoing thing until we have implemented most of our features. The reason is, we don't want to optimize now and make it harder to add things later. Once all the core features are in (which will be soon), then we can start profliing code and optimizing the slowest bits.
Philip has already begun work on a new path finder though, but it's on hold at the moment while we bake some goodies into Alpha 10.
-
1
-
-
Alpha 10 has a new AI API, which should perform better. I was able to play against 8 qBots, and while still slow, wasn't as slow as Alpha 9.
-
Welcome. Thanks for your interest in the game.Hello, I'm looking to help out with development in my spare time
When in single player, Esc should open the menu and pause the game. If the menu is already open, it should close the menu and resume the game.1) Which do we want it to do? Pause (like the pause key) or open the Menu?1b) If we want it to open the Menu, do we want to pause the game as well?
1c) What should happen if it is a network game?
In network games, it should not pause at all, just toggle the menu.
Also, ESC maps to closing dialogs like the chat window. This shouldn't be broken. So only open and pause when no dialog is open already.
I'll leave a more experience developer to answer the other questions.
-
I think you can make an announcement through the admin cp I think, which should put it in all forums.
-
nocompile, a.k.a mosque, a.k.a trajan has been making heaps of modifications to his local copy. Several of his bug reports look like they result from his modifications.
@nocompile: Don't report bugs if you have modified the game in any way. It has to be an identical copy of the game on both ends. You just cause extra work for the devs when you post bugs that only exist in your copy of the game.
-
Hey all,
Lets discuss the architecture for the new sound system. The following is what I have so far. When we have a solid plan, I'll update http://trac.wildfiregames.com/ticket/1223
New Sound System
We need a new sound system, that works on Windows, Linux and Mac. Optionally also works on Android systems, so design with cross-device in mind (wrappers, apis etc), but focus on the operating systems first before mobile platforms.
The new sound system needs support for music and sound clips, and should work on both the main menu and ingame. The same system should handle things like background music, button clicks, ambient noise etc.
The implementation should be 100% C++ object oriented, but should have JS interfaces so that GUI events can trigger sounds (like button presses).
Details
Terminology: 'stack' (collection of 'tracks' on a 'queue'), 'track' (object linked to the 'target' sound to be played)
The sound system should support multiple named stacks. A new track can be added to any named stack. Stacks are worked through concurrently (multi-threaded?), playing through their tracks first in order of priority, then the order the track was added to the queue.
If a track of high priority comes into the stack, the current sound should fade out, and the priority one should fade in, then fade back to the one it was playing (requires the system have a 'pause' for tracks so that they can resume from the spot they were stopped, rather than restarting). More on track fading later.
A stack can be unlimited in size, or can have a limit. Default is unlimited. If a limit is set, when a new track is added and the limit of the stack is reached and a track of lower priority doesn't exist to replace, the stack simply discards the track that was added. This prevent many async sounds piling up and running all at once (like 100 soldiers moving, which should not create a giant "KA-THUNK" when they move).
If a stack has 'async' set to false, the stack waits until each tracks target finishes playing before popping the track off the queue and initiating the next track (useful for music). If the stack has 'async' set to true, the tracks target starts playing and the stack pops the track right away, and moves onto the next track. Default is async true.
For music in particular, we don't want it stopping suddenly and starting the next one instantly. So if a track has a fadeIn value, this is the amount of milliseconds that a volume should go from 0% to 100%. If another track is playing, the same time is used to fadeOut the playing track. The default is no fading (for things like quick unit actions, button clicks, etc).
TODO: Describe fade between tracks, Describe gain adjustment on zooming, Describe gain adjustment on distance from center screen
Basic JSON representation
{
"actions": {
"limit": 10,
"async": true,
"tracks": [
{ "target": "chop.wav" },
{ "target": "mine.wav" },
{ "target": "chop.wav" },
{ "target": "chop.wav" },
{ "target": "mine.wav" }
]
},
"ambient": {
"limit": 10,
"async": true,
"tracks": [
{ "target": "tree_falls.wav" },
{ "target": "fish_splash.wav" },
{ "target": "tree_falls.wav" },
{ "target": "tree_falls.wav" }
]
},
"music": {
"limit": null,
"async": false,
"tracks": [
{ "target": "peace1.wav", "priority": 2, fadeIn: 1500 }, # this would play second
{ "target": "peace2.wav", "priority": 2, fadeIn: 1500 }, # this would play third
{ "target": "war1.wav", "priority": 1, fadeIn: 750 } # this would play first
]
}
} -
Kickstarter needs a U.S.A. address and U.S.A. bank account, and conforming to U.S.A. tax laws, so it doesn't work for a world wide team of developers.
Pledgie on the other hand can go into any Paypal account, so isn't tied to U.S.A. address, account or laws.
So Kickstarter is not for us, we might stick with Pledgie. But thanks for the feedback.
-
We had a person working on sound for Mac but he disappeared, so we're back to the beginning :-(
Sound is planned for Alpha 11, which should hit about July this year, all things going well.
-
This doesn't work well because the units disappear behind the building when the camera is rotated by default.
Having them on the two sides facing the camera makes the most sense (which is what it does at the moment, IIRC).
-
Please file bug reports at http://trac.wildfiregames.com/newticket
-
Please file a bug report at http://trac.wildfiregames.com/newticket
-
LOL. Got more?
-
An interesting thought gudo, but it would require every single donator to agree to the use of their money.
@Erik: I think we have enough mentors now. Last year we had two (Philip and Brian). Now we have Philip, Alex (fxcSanya), Ben (historic_bruno), Jereon (vtjs), and Jonathan (quantumstate).
Collectively there should be enough people to mentor the applicant.
-
Do we even qualify for GSoC? If we do, and we get selected, I think we should get them working on core things, like working with Philip on path finding, or on technologies, and profiling/improving the heck out of the game to make it faster.
-
Awesome map.
Not-so awesome frame rate when playing it. Yikes! We need a way for the game to dynamically scale shadow quality based on the amount of entities.
-
I saw your commit. Nice work on all the new random maps.
But you copy and paste the same starting unit positions code, and there is probably lots of other duplicate code (like the terrain randomizing stuff).
Can you please clean this up into a single file? The cleaner these random maps can be, and the more reusable the code, the better.
IF we have a ingle file with different functions for starting positions, random terrain, tree placement etc, it'll be easier for new users to make random maps.
See what you can do. Thanks.
Stances
in Game Development & Technical Discussion
Posted
I don't know if we want to make things too configurable... We'll probably just have 3 stances as default, Aggressive, Defensive (default for soldiers), and Stand Ground, with a hidden (unselectable) stance for women (Flee when attacked unless tasked to fight back).