Jump to content

real_tabasco_sauce

0 A.D. Gameplay Team
  • Posts

    2.548
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by real_tabasco_sauce

  1. Well its moderate effort in general, but there may be a couple of things that would need to be done differently in a26 vs a27. I think I would just do sparta, roman, athens, carth, and mace updates in another community mod update. (carth and mace ones are pretty small). btw, if anyone just blurts out an idea for a briton team bonus I could do that super quick.
  2. @guerringuerrin unless there are other things that should go in this version, I'd say its about a week or 2 out. I thought about doing the roman/athens reworks in the community mod, but I thought the navy should go first, since its a completely new system (so probably needs plenty of balance work).
  3. @wowgetoffyourcellphone the branch works in a26, I just need some missing portraits, and they are mixed across different revisions, could you send me just the portraits for the naval overhaul?
  4. @wowgetoffyourcellphone it worked except for "Ship Combat Demo.pmp and .xml but this was the only case of spaces being used.
  5. Don't forget you'll need some art as well. Actors, etc. yes, I am quickly finding out how nice the git migration would be XD. I wrote a shell script to move the right files over.
  6. I was thinking a hotkey for upgrading units/towers would be great. Example applications: hotkeys for siege pack/unpack, scout tower upgrades and carth house upgrades to apartment, weapon switching with immortals, promotion to centurion.
  7. Ok I thought about it and I decided not to reconsider. I can't think of an example, at least not in an RTS game. no, damage would do that, also remember that ranged units can currently kill catas and bolts easily. I would argue 5 seconds easily achieves that. Its not like you can't plan their position if they pack faster. So "countering bolts" is just "Oh I see a group of bolts packing up, I guess I will walk away and take no damage." yeah that's really fun and cool, well played. Your last point really highlights their enjoyability (or lack thereof) to play at the moment. @Atrik I don't think you realize how much 10 seconds is. Its literally almost 1 percent of an 18 minute game.
  8. ah, makes sense. You can't assume gcc sadly. There is also clang. Also maybe the intrisic you use isn't available on ARM. Oh, so there's no way to check the compiler? I guess that makes sense lol. That definitely throws a wrench in it.
  9. @wowgetoffyourcellphone does the naval rework require a lot of other a27 changes? if not, I could replicate it in community mod so we can get it balanced for a27.
  10. yeah fair points all around. if some tech boosts construction speed, better to let it be standalone. any other recommendations for this next version? I have the following: non-random arrows reverted, -25% building arrow damage (fire rate) to equalize melee unit TTK. This means ranged units survive a little better compared to a26 vanilla arrows, but otherwise its the same. Pack time for bolts, catas 10s -> 5s. Immortals cost is now equal for ranged and melee, switch time now reduced a little more to 4s. Stone wall garrison space is doubled, allowing for 16 to fit on large stone walls and 8 on medium walls. Loom cost decreased from 200 food, 40s to 150 food 20s. the last two there are committed to svn already, so may as well test.
  11. ok, heres an idea: Let the carry capacity upgrades in the storehouse have a flat bonus to construction speed. Why: Wicker baskets, wheelbarrow, and cart are fairly underused, since in many games it is preferable to just build additional drop sites when gathering becomes inefficient. I think it would be great to add a small bonus to construction speed to each of these, something like 10%. It is perfectly realistic, and could add more options for civs that find themselves in need of many buildings. just a thought, and it would be easy to do in the com mod.
  12. How slow? On a good machine it's about 2-4 mins. I meant the game once it is built. For me, the build process is quite fast, under a minute. in game, we are talking 1 to 4 fps as soon as I start moving the camera. on anything but windows, yeah that's (hopefully) because I don't yet have code to use the GCC builtin.
  13. Also, my windows build with VS was very very slow without any changes at all. Is that the case for others?
  14. https://code.wildfiregames.com/D5282 it built, but didn't do anything.
  15. This sounds like the regicide + garrison hero infinite loop. If that's the case, it may be fixed by getting the community mod in the mod downloader, but you could also turn off the garrison option in match setup. @Norse_Harold is more familiar.
  16. Ok, I like the looks of this approximation: (from https://stackoverflow.com/questions/4930307/fastest-way-to-get-the-integer-part-of-sqrtn/63457507#63457507 and https://stackoverflow.com/questions/34187171/fast-integer-square-root-approximation) #include <algorithm> #include <array> #include <iostream> #include <string> #include <vector> #include <math.h> #include <time.h> unsigned char bit_width(unsigned long long x) { return x == 0 ? 1 : 64 - __builtin_clzll(x); } unsigned sqrt_lo(const unsigned n) noexcept { unsigned log2floor = bit_width(n) - 1; return (unsigned) (n != 0) << (log2floor >> 1); } unsigned sqrt_newton(const unsigned n, unsigned int P) { unsigned a = sqrt_lo(n); unsigned b = n; // compute unsigned difference while (std::max(a, b) - std::min(a, b) > P*P) { //P*P reduces iterations of while loop when using higher P. //printf("iteration\n"); b = n / a; a = (a + b) / 2; } // a is now either floor(sqrt(n)) or ceil(sqrt(n)) // we decrement in the latter case // this is overflow-safe as long as we start with a lower bound guess return a - (a * a > n); //could remove - (a * a > n); if using low precision. } int main() { unsigned Nums[29] = {27,28,29,30,31,32,33,34,35,36,37,38,39,40,44,45,46,47,48,58,59,60,61,62,98,99,100,101,102}; int P = 5; clock_t tStart = clock(); printf("Range value\tEstimate\tExact\n"); for (int i=0;i<29;i++){ unsigned test = Nums[i]*Nums[i]; printf("%i\t",Nums[i]); printf("%i\t",sqrt_newton(test,P)/P); printf("%i\n",(int)floor(sqrt(test))/P); } //printf("Estimate: %i\t",sqrt_newton(test)/P); //printf("Exact: %i\n",(int)floor(sqrt(test))/P); printf("Time: %.9fs\n", (double)(clock() - tStart)/CLOCKS_PER_SEC); } results: P = 1 P = 3: P = 5 P = 10: The only issue I found is that with 5 >= P >= 9, there are a couple points where the estimate is higher than estimates of larger ranges. (see P = 5) I could just go ahead and use this and see what happens. (id have to figure out the windows build process first).
  17. I was curious so I did some testing in this c++ reference: https://en.cppreference.com/w/cpp/algorithm/stable_sort and it seems like stable_sort() is faster when there are redundant values, but when they are made quite different on purpose, sort() is faster.
  18. int CompareLengthSquared(u64 cmpSquared) const { u64 d2 = SQUARE_U64_FIXED(X) + SQUARE_U64_FIXED(Y); // d2 <= 2^63 (no overflow) if (d2 < cmpSquared) return -1; if (d2 > cmpSquared) return +1; return 0; } https://code.wildfiregames.com/source/0ad/browse/ps/trunk/source/maths/FixedVector2D.h#:~:text=int CompareLengthSquared(,} ok so, yes the precision for lengths is 1 meter, but the differences are found for x^2+y^2, so for a 70 meter range archer, 1 meter out of up to 4900 is very little. So basically, the precision when sorting lengths gets higher the farther away the unit is: a single integer represents a range differences of 0.014 meters near 70 meters range. The relationship looks like this: The only thing is the relationship needs to be a parabola, so you can't just do (x^3/Px^2) because this would incorrectly rank units distances. I suppose the thing to do would be to use an integer square root estimation algorithm, and then integer division by the precision value. Then, the profiling would be needed to see if the potential improvements to sorting would be worth it. Even if its pretty similar, I think the impacts on the overkill situation would be nice. https://stackoverflow.com/questions/34187171/fast-integer-square-root-approximation
  19. Weird that it doesn't work in single player. Did you enter it in gamesetup or after the game started? I'll give it a try later.
  20. If the turn rate can be changed in JS, then maybe @Atrik idea of doing a quick mod to test it could be worth. The only question would be if there is a way that the host can communicate the selected turn rate every time a new game starts. Else the mod would have a hard coded turn rate, which would not allow us to test different values on different games. well looks like you wouldn't even need a mod to do this. You could do the following (and I'd be curious on the results): Set up a match with combat demo huge (in scenarios, demo maps) and choose different values with Engine.SetTurnLength(x); @phosit are the backticks included when typing this in the js console?
  21. Discussion about the overkill situation brought me to this vague idea: consider more units at an equal range, so that units spread out their damage a little. Ideally, a target precision value could be stored in the templates (higher for archers, lower for skirms for example) and then used to influence the 'EntityDistanceOrdering' on certain calls to the range manager. (Things like choosing the closest unit don't need to be super precise and maybe shouldn't be wrt overkill). https://code.wildfiregames.com/source/0ad/browse/ps/trunk/source/simulation2/components/CCmpRangeManager.cpp#:~:text=class EntityDistanceOrdering,}%3B Perhaps some replacement for .CompareLengths() could be used with an optional precision value (0.1,0.5,1,3,5,10). Since stable_sort is used, maybe this would also be faster with more 'equivalent' values?
  22. Keeping in mind I am by no means experienced here, I don't think you can expect a 1:1 effect on performance by changing the turn rate. So a 2.5x slower turn rate does not necessarily mean a 2.5x improvement in performance. Perhaps some tweaking of the turn rate would be fine (has 250 ever been done?), but I don't recommend going all the way to 2 turns per second. Also, the situation with collision size and pathing is interesting: in https://code.wildfiregames.com/D4970, we went back and forth with different values for pushing and found that the pushing situation is directly in conflict with pathing: preventing overlap directly makes pathing more awkward and making pathing less awkward requires overlap. I would totally support something like https://code.wildfiregames.com/D5037 which would allow for less overlap, but it would introduce some extra performance cost.
×
×
  • Create New...