Leaderboard
Popular Content
Showing content with the highest reputation on 2018-05-07 in all areas
-
5 points
-
4 points
-
3 points
-
3 points
-
It's come to my attention that there was an approved plan for dropping FFP and ARB shader support some 6 years ago, but the dev that was working on it left so it never got done, and we've been arguing about it on and off ever since. According to a survey taken some 3 years ago or so over 95% of our users have support for at least openGL 2.1 (shader version 120) and more than 45% have support for openGL 3.3 or newer, while a good chunk support 3.0 or 3.1 as well. So this is what I propose: - We remove all traces that FFP ever existed, from config, shader effects, and anything in the codebase relating to those things. - We remove all traces that ARB shaders ever existed. There is basically no one using them and no one working on them. The legacy support is cluttering up the codebase and making it more difficult to support newer and more useful things. Additionally, I propose we add support for: - Automatically detecting hardware GL version to support whatever 3.0/3.1/3.3/4.x features the user's hardware allows (and that we can find good use for). - Allowing for choosing different GLSL shader versions automatically based on GL version support. - Creating a config/command line option for spoofing older GL versions for testing purposes, so it's possible for devs to manually choose which shader versions will be loaded. - And of course support for draw-call reducing features from GL3.1-3.3, based on whatever the user's hardware supports. Since some things have lower version requirements than others it makes sense to allow such things to be enabled incrementally so users can get as much as their hardware can provide. Finally, I think we should establish shader version 120 as the standard for legacy OpenGL 2.x support, since basically no users have GL 2.0 graphics cards and virtually everyone has support for 2.1. GLSL version 120 supports a couple of very convenient features that allow for efficient shaders, at least as far as what 2.x supports in terms of performance. Not every shader needs to be declared as #version 120 (if it doesn't matter then who cares), but it should at least be made allowable without question wherever it's needed. Note that a lot of shaders will likely remain as GL2.x simply because there's no benefit to upgrading them. The water shader and postproc shader(s) and even the terrain shader are good examples. At the moment the only shaders that I'm aware of that would benefit from GL3.x are model_common and the particle shader, to support drawinstanced and soft particles.2 points
-
For real that’s the great leader?! I wonder who this very good 0ad MP player named Kim Jung Un. He seldom plays but sometimes he said he can’t play well coz he has no mouse.2 points
-
true... I was mostly commenting on those Han period reliefs of "carriage chariots" with axemen. Unit diversity is greatly appreciated by most players (especially since we're all used to those immense Total War unit rosters). During the Han period chariots were steadily being replaced by mounted cavalry, and chariots became mostly used as command posts. But that does show that chariots were in fact still in use. Truth is that 500 BC to 1 BC is the timeframe that chariots were being replaced by mounted cav in every civilization that used them. That goes for every civ in the game as well. Even British chariot use has been greatly exaggerated in pop culture... But the 500 BC to 1AD timeframe without any chariots would be plain wrong. I think each civ should have an as complete unit roster as possible, strictly within the confines of historicity of course. Even if it only adds fun to SP matches (because indeed, chariots are a little useless in pro-MP matches). The point is to allow people to compose a (historical) army the way they see fit... Otherwise it all gets reduced to a single stale and boring format. Always the same army setup in every match is just blah... More units, more possibilities. I think too many historically accurate units have been culled/purged/ignored/sidelined because of questionable reasons. I would like to see a reversal of the trend (anno 2018, people expect options).2 points
-
2 points
-
2 points
-
2 points
-
Yeah, a nomadic system too. So, then you have these 4 styles of play to choose from, and one style can be used for each civ. Some are obvious choices, others you have to make compromises to fit a game environment. AOE style Villagers/Soldiers Civs with "professional" armies Empires Ascendant style Citizen-Soldiers/Female Citizens Delenda Est style Slaves/Citizens/Soldiers Slaves only gather, trained at the dropsites after building a Market Citizens suck at gathering, but are good builders which can build civic and economic buildings Soldiers can't gather, but can build military buildings Nomadic style "Egalitarian" : Use the Empires Ascendant style, but Female Citizens are also Citizen-Soldiers too Slaves bought at the Market Ranching/Corral bonuses and Looting bonuses Dropsites are Ox Carts Cheap, weak, packable buildings No territory effects Any of the above can be tweaked, streamlined, made more complicated, or hybridized based on the civ. So, Imperial Romans might use AOE-style, but add Slaves as cheap gatherers, a hybrid style. Or they could use the Delenda Est method, where the soldiers can also build. Spartans can use the Empires Ascendant style, but add Helot Slaves. Iberians could be strict Empires Ascendant style. Scythians and Xiongnu would have the Nomadic style, but maybe the CC of one does cast a territory effect for some kind of bonus, while the other's does not. Lots of possibilities here.2 points
-
Anti-Spam Mechanic Suggestion For as long as I have been playing it, 0 A.D. has been having problems with balance. In each and every of the last 6 releases (or perhaps more) there has been 1 "op" unit. That unit got spammed, it's that simple. Some may argue that we need a perfect counter system, then we don't need such a limitation as the following proposed feature. But then again, even if a counter system is implemented, I think that it is more effective in team games for each player to specialize a certain unit, then help out accordingly. It has happened in other games with perfect counter systems. It's very good from teamwork point of view but in ancient times armies weren't composed of 2 types of units. Alpha 17: Sword cavalry op, spam them and down opponent's cc with a rush Alpha 18-19: Hazy for me, I myself spammed archer champions and downed buildings, easily outranging them. Alpha 20-21: Champion rush and later spam. Alpha 21: Slinger spam. Alpha 22: Cavalry skirmisher/archer spam. No cav games: skirmisher spam + melee as fodder Summary: meh Proposal: Each unit increases cost of same unit type by 0.5/1%. This stackable "aura" would make such spams not as profitable and would incite some players to search for other, yet just as efficient army compositions featuring several unit types. As a side effect, this feature makes larger batch trains even more attractive, since they are trained at the cost of next unit only, not all those after. Example: +0.5% per unit +1% per unit Why did I choose 90 units? In Alpha 22 after players banned cavalry they started spamming skirmishers, it became common to see such armies marching about. Why this kind of anti-spam mechanic? It's easy to explain this 1%, the area is drained of possible soldiers, equipment is needed etc. Overdemand, this is the word under which 0 A.D. takes a step towards a more balanced future. In this post I am not siding with nor necessarily supporting other gameplay suggestions, I feel that this isn't a big overhaul. Some will say that this isn't enough, others will resent the passing of age-old strategies. From battalions to slaves and nomads, 0 A.D. has a vast choice of future paths, each leading to something different, something unique. The team is careful, taking steps slowly - sometimes perhaps to the detriment of progress - but they are I'm sure familiar with the problem the game faces and they wish the best for it. I'm not saying that we should throw all the gameplay suggestions away, just that they all encompass several changes that drag a train of other modifications with them and the team might not want to introduce them at least for now. Implementation: Ah, the step where all the enthusiastic developers say "meh" and go watch dog memes. It could be done with each unit class having a a stackable aura, but we know that global auras are problematic - especially when they come in big stacks. I'm not familiar with code so I wont say anything else but I hope it is possible to find a way. If you are still unmotivated, please click here Last one1 point
-
1 point
-
The unit AI for catapults seems to have been changed to make them more autonomous, packing and unpacking at will in order to attack moving targets on the map. Does anyone have a strong opinion about this? I kind of don't like it, but mine's just one opinion. I liked their previous behavior better.1 point
-
for siege weapons like shoushe it could work they have wheels, for others like ballista or any other attached to the ground it will need to unpack or it will look unrealistic1 point
-
I'm not sure if this actually fixes or minimizes the problem, because if a unit is OP, then it is stronger in the same numbers. So it is also already in effect before the cost become apparent. There is the problem that some units can be in comparison much more better or economic and there is the second problem that massed units can become invincible at some point. That's mostly Lanchesters Law, no? skirmisher spam + melee as fodder sounds good, no? Add the counters where missing and it should work out in theory. It does in sc2 and aoe2, doesn't it?1 point
-
Is your svn up to date? There was a bug that caused them to unpack/pack on their own not long ago, but that was fixed.1 point
-
1 point
-
I really don't know. It's possible though. Those are called impostors, and they only work at long as the angle between the camera and the object doesn't change by much. For games where you control a character with a fairly low camera angle and relatively slow movement across the terrain this can work fairly well. For 0ad it wouldn't really work at all.1 point
-
1 point
-
IIRC some engines replace 3D object (like trees) with a (pre-generated) 2D flat picture when viewing from further away, that would incredibly reduce the amount of tris on the screen, wouldn't it? (even though it might look a bit ugly when switching between 3D and 2D)1 point
-
Hello, I''m from Bulgaria, my nickname means lizard and it's spelled in english alphabet instead of the cyrillic. My real name is Simeon, which is the same as Simon (both are from the same hebrew Shimon- "to be heard or the act of hearing"). I love classic RTS, and of course 0 A.D.1 point
-
1 point
-
A few threads about trees and how to make them and whether they should be animated (which would likely have a performance hit). 1. I had a look, but I'm not sure what I can do. 2. Aleppo pines were introduced in 17452 where I believe the goal was to make flora a bit better. 600 triangles seem low to me but maybe it's achievable if you look at the video in the above spoiler. 3. About Palm Tropical agree it's way to much the trunks are 1000 tris in total (so around 333 each for simple cylinders) 5. Half of the fig polycount is in the trunk (654 triangles) 6. The new oaks were also made by Enrique and introduced in 17452 So same, He used to have a very precise idea about polycounts. That's something I will update in the documentation in the coming months.1 point
-
1 point
-
1 point
-
1 point
-
1 point
-
It's planned. I think it's even in the 3D Art Task Thread1 point
-
1 point
-
I remember the first time I hear about your country... 0 GMT what lucky. mine is -6 , so good morning Sundiata. @Alexandermb and @Skhorn are -4 Venezuela and Colombia.1 point
-
1 point
-
1 point
-
I was about to be surprised, but then I remembered that North Korea has RedStarOS as their official OS.1 point
-
1 point
-
1 point
-
Now, now, let's not upset a nuclear power... Maybe the scroll wheel/keyboard not working, and sanctions preventing them from importing new ones. In fact, the thaw in relations might be due to Kim's urgent need for a new mouse with working scroll wheel to play more 0AD... He's even prepared to give up his nuclear program, if he can just order that new mouse through Amazon... 0AD, a game of ancient warfare, has become a platform for world peace! Or maybe he just hasn't figured out yet how the zoom works?1 point
-
Hmm, it would be nice if these guys got their own Workshop/Range/Stable/Elephant Stables models. They use Egyptian models for now, which don't look bad, but they use Hellenistic/Ptolemaic props like shields and such that don't fit the Kushites.1 point
-
After that OSX bug, we'll repackage, test again and finish the trailer and release announcement. -__-1 point
-
Best not disappoint the Great Leader! Of course, I just didn't want the North Korean leadership to feel left out... Kim, if you're reading this, a Korean civ is on the shortlist By the way, this may well explain that weird Korean spam in the forums about casino's and gambling, that pops up every so often... Isn't there a MP-profile called Kim Jong-un or Kim Jong-il?? Who knows, maybe he's actually... ... ...1 point
-
1 point
-
Maybe after scouted it can change from unknown to civ name in italics in diplo window, and to observers random civs always appear in italics that way they don't reveal it to players.1 point
-
I'm with you, ffffffffffffff's suggestion is rather superfluous. Rather, I'd like it if a "Random" player's civ is not knowable until you've scouted them first. That seems like one of those little details that would be nice -- that the civ would show as "Unknown" in the diplomacy windows until one of their units or buildings comes into your vision range.1 point
-
1 point