-
Posts
1.146 -
Joined
-
Last visited
-
Days Won
8
Everything posted by quantumstate
-
My friends... the time has come.
quantumstate replied to Mythos_Ruler's topic in Introductions & Off-Topic Discussion
This sounds awesome . Rome was always my favourite TW game. -
This looks beautiful as always, it looks like it might also be playable:). I shall have to try it out sometime.
-
Application to help as a translator
quantumstate replied to hadware's topic in Applications and Contributions
Thanks for your offer but we are not currently doing any translations since there will be a lot of changes to the text in game as it develops, this would mean that the translations would rapidly become inconsistent and would need lots of unnecessary work. Also we do not have a translation system set up yet. Around the time we reach Beta we will start asking for translators. -
The AI doesn't have access to sufficiently detailed pathfinding information currently. The AI will need access to the standard pathfinder otherwise there will always be small inconsistency bugs, I am not sure how feasible this will be, Philip could probably say.
-
Working out if they can access a resource is tricky. I think I will need to monitor units trying to gather and set a time out value so the resource is marked as inaccessible if they have been trying to reach it for too long without managing to gather from it.
-
This was mainly discussed on irc. You can take a look at http://irclogs.wildfiregames.com/2012-02-04-QuakeNet-#0ad-dev.log . That is the main discussion I found with a quick search but there are quite a lot of other mentions.
-
This should now be fixed.
-
This was the book I was looking at in http://www.wildfiregames.com/forum/index.php?showtopic=16056&st=120#entry241853. My pictures aren't very good quality though.
-
Hi, welcome to the forums.
-
I went an had a look at a book on Mauryan Indian art and architecture earlier. I have attached a zip with pictures (Big file). The quality isn't great, I should have been more careful taking the pictures so some text is a bit hard to read. Also the book had practically no information about normal buildings and had a comment that "Mauryan Architecture is the least known subject in Indian history." There is a lot about pillars, quite a bit about the caves and some information on palisades, a fancy pillared hall and some religious buildings. I have categorized the stuff by the chapters of the book. The "... - plates" folders contain the photographic plates from the back of the book along with an index of the plates. The number on the plates are pretty hard to read, however they should be in order (I skipped some uninteresting pages). I wrote down some stuff about the palisades. The palisades enclosed a city which was a parallelogram 9.2 miles long and 1.7 miles wide. The palisade was about 2.7m high and about 3m deep, there was space inside of it to walk and there was a roof (so people probably walked on top). There were loopholes for archers and 570 towers at intervals of roughly 67m t be used by archers. There were 64 gates, a possible archaeological find us a gate with a width of 4m but it is not certain that they found a gate. Sale wood was used which did not grow locally so must have been transported. On the outside there was a moat/ditch which was 184m wide and 14m deep (The books author suspects that this is not an accurate size, this comes from a historical source, there isn't archaeological evidence.) Another city had three moats with widths 25, 22 and 18m at a separation of 2m, one was kept muddy, one willed with water and the third was dry. Mud ramparts are also reported of varying size up to 11m high and 22 wide (also sounds unrealistically big). In general buildings were primarily built out of wood. Mauryan Indian Book.zip
-
Units with both ranged and melee attacks have been planned. I'm not sure quite how they would work though. For what you suggest with Centurions with a limited number of spears it could work with a cooldown timer so they would automatically get a new spear after 1 minute or something. This would save messy micro of picking up thrown spears etc.
-
While this looks pretty cool we have better uses for processing power when the game is running. Anything we implement has to be much simpler. Rivers would be nice though.
-
add some invisible padding to the image so it is 90x90 pixels.
-
I'd also be interested in taking a look.
-
For battle detection I think it would be good to use damage rate as a metric to determine when a battle is taking place. So if lots of units are being damaged then it is a major battle. The idea of taking the total army size into account sounds good as well. I don't think anyone is prioritising this above attack warning sounds. Attack warning sounds shouldn't need a whole discussion thread about when they should occur since the requirements for playing the sound are straightforward. Battles are a much more subjective idea and are more complicated to define.
-
I just tried this. It didn't have any effect on the shadow glitch. I have put a screenshot below, visually it flickers across the whole screen. The minimap problem only occurs when entities are being rendered. So viewing the shroud of darkness or an empty area of the map (had to create a custom on is atlas) makes the minimap look normal. This has no effect on the terrain flickering. Edit: (the red units are due to some debug code, not a bug)
-
Thanks, that was the problem, I ninja edited my post which you probably missed. I have attached an updated screenshot and normal map. These use float scale = 0.01; float height = 1.0; It looks good, I can't detect any framerate change when switching from no parallax to parallax. One concern is model popping which is very obvious. Putting in scale transition seems to work pretty well for this. if (dist < 100 && h < 0.99) { float scale = 0.01; if (dist > 65) { scale = 0.01 * (100 - dist) / 35.0; } float height = 1.0; float iter; float s; vec2 move; iter = (75 - (dist - 25)) / 3 + 5; ... Edit: as you can see in the screenshot I also get the shadow bug with glsl. This isn't anything to do with your changes though.
-
It is working fine for me now that I have changed 140 to 120. Your auto-generated normal/displacement map is pretty terrible for the roof tiles which makes it hard to see how well the shader is working. I made a rough improvement which I have attached. My screenshot uses this new map. On the roof sloping away from the camera the tiles seem to flatten at the top. It looks like clipping, I'm not sure what the cause would be though. (I remember trying changing the version number previously and it still failed but that was using your first patch, or I might have done something else stupid. Anyway it works now so i am happy ) (fabio: I am running Mint and haven't bothered to upgrade yet, thanks for letting me know) Edit: Looking at your shader it is clipping because you have float height = 0.5, so the top 50% of my displacement map gets clipped. I found that these settings were nicer. float scale = 0.008; float height = 1.0; This shows defects in my displacement map though (they are too pointy) I will try and correct it.
-
I have the open source radeon drivers OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 2.1 Mesa 8.1-devel (git-897af1d oneiric-oibaf-ppa) OpenGL shading language version string: 1.20 This makes the shader fail completely because it requires shading language 1.4 support. I can run http://nooshu.com/alteredq-a-webgl-ninja which claims to use displacement mapping, thought it looks slightly glitchy (scattered black pixels). This may not be of any relevance though.
-
That is for the first release of 0 A.D. so most will be done by Beta 1. Some smaller UI related stuff might happen after Beta 1 e.g. Distance Fog and Building Snapping.
-
A temporary workaround is Engine.SetSimRate(0.00001). The UI will be slow to respond to certain things though, e.g. things won't appear in the training queue instantly.
-
New GUI: Design & Features Discussion
quantumstate replied to Mythos_Ruler's topic in Game Development & Technical Discussion
I don't like tabbed layouts very much. It ends up adding extra clicks and hiding things that I want to see. I think that our current system with a tech tree for reference isn't too complicated. The only thing we have changed is that techs come in pairs. The idea of switching to a global Tech Tree sounds ok to me as well though. To add unit stats you can basically make it fit into the current UI with a bit of poking. I don't think it looks too crowded but I have the art skills of a programmer . -
It looks like an interesting idea. It would slow the game down quite a bit so I'm not sure I would want this as a standard map. Is the current Giant map size not large enough? Also a while ago on irc the idea of allowing the terrain height range to expand was talked about a bit. It should happen at some point, we can easily get 10 times the current size without worrying about resolution, then you can have really big mountains.