-
Posts
17.619 -
Joined
-
Last visited
-
Days Won
561
Everything posted by Stan`
-
https://code.wildfiregames.com/D3518
-
Might be some interesting stuff there https://trac.wildfiregames.com/browser/art_source/trunk/grafx and mockups/UI - Game
-
You could have a combination of pop count to 0 and entity limits to say 20. I believe @Freagarach also created a ticket for feature which would allow you to only have a pool of mercenaries (e.g 100 at the beginning of the game, and each player recruiting them would make the pool go down until it reaches 0 then no mercenary can be recruited anymore (one could also regrow that limit slowly))
-
@Thorfinn the Shallow Minded hgj @borg- it's already in. https://code.wildfiregames.com/rP23541
-
Can you upload the replay for @wraitii ?
-
For #1 you could use selection group name
-
Indeed strange, Let us know if it happens again
-
That was probably because it was a special test. We removed the IP address broadcast from such games, and use a different manner to join them now. So if the patch wasn't committed yet you wouldn't have been able to join.
-
Depends on whether you are using git or SVN. We need at least five hours to make an installer for Mac and windows. The version will always be that of the latest commit on trac.wildfiregames.com when the bundle started being built. We usually run those a night, european time.
-
If you warn us early enough, we can provide prebuilt bundles for Windows and macOS @MarcusAureliu#s
-
We're not closed to the idea far from it. What we're against is dropping all the users and devs (yes) that do not support it I have yet to see someone come here and make a vulkan patch, but it's one of the GSOC ideas. Maybe if @vladislavbelov has time to mentor it. I suppose one could play with the decay time to that effect.
-
Oh "timeframe" is a period of time. 0 A.D.'s timeframe is -500 B.C. - 1 A.D. (500 years)
-
Well I need to see your models as a mod in the game first, else I cannot assess their quality. Maya are way out of the timeframe, Zapotecs would work see the Terra Magna mod.
-
Mods and config files are kept between installs on Windows. You need to disable mods manually through the game UI or by deleting their folders.
-
Do you need help putting them in the game ?
-
That would be #3997
-
Fun fact, we actually have list of tickets, marked as needed for beta.
-
Translating the scenario editor?
Stan` replied to tbleher's topic in Game Development & Technical Discussion
Hey thanks for the quick patch! Unfortunately that's incorrect because there are more things than atlas in source/tools so you need to ignore that as well. For the mo generation I suppose we could use an extra python script to generate them? see source/tools/i18n for more info on how we generate things. I believe tinygettext is currently built statically with the game while atlas is built as a dll (as it is optionnal) Finally and apologize about this, we use phabricator and arcanists for code submissions See https://trac.wildfiregames.com/wiki/SubmittingPatches and https://trac.wildfiregames.com/wiki/Phabricator for more information on how to upload your code to code.wildfiregames.com -
Interesting, thanks for explaining it to me. What about setters ? I'm prudent about those things because I've seen compilers do weird stuff even for trivial things. Nowadays I run things through Godbolt.com I hope someday I can help you both work out your differences. I am somewhat of an idealist as you may have seen. EDIT2: Note the command above can also be run in non visual mode, so you only get the the cfixedvector stuff perf record 0ad/binaries/system/pyrogenesis \ -autostart="skirmishes/acropolis_bay_2p" \ -autostart-ai=1:petra \ -autostart-ai=2:petra \ -autostart-aidiff=1:5 \ -autostart-aidiff=2:5 \ -autostart-nonvisual \ -autostart-victory="conquest" EDIT3: Here is some extract as you can see isqrt64 is there (it's vanilla not your patch) 3,75% main libstdc++.so.6.0.28 [.] std::_Rb_tree_increment ◆ 3,33% main pyrogenesis [.] CComponentManager::BroadcastMessage ▒ 3,12% main pyrogenesis [.] CComponentManager::QueryInterface ▒ 2,30% main pyrogenesis [.] VertexPathfinder::ComputeShortPath ▒ 2,28% main pyrogenesis [.] CComponentManager::PostMessage ▒ 1,78% main pyrogenesis [.] CCmpRangeManager::PerformQuery ▒ 1,38% main libmozjs78-ps-release.so [.] js::AtomizeString ▒ 1,32% main libc-2.31.so [.] __memmove_avx_unaligned_erms ▒ 1,15% JS Helper libmozjs78-ps-release.so [.] js::jit::BacktrackingAllocator::tryAllocateRegister ▒ 1,13% main pyrogenesis [.] isqrt64 ▒ 1,00% main libmozjs78-ps-release.so [.] js::NativeSetProperty<(js::QualifiedBool)1> ▒ 0,93% main libc-2.31.so [.] _int_malloc ▒ 0,92% main pyrogenesis [.] CCmpPosition::HandleMessage ▒ 0,88% main libmozjs78-ps-release.so [.] js::jit::GetNativeDataPropertyPure<false> ▒ 0,86% main libc-2.31.so [.] __memset_avx2_erms ▒ 0,84% main libmozjs78-ps-release.so [.] JSRuntime::tracePersistentRoots ▒ 0,82% main pyrogenesis [.] CCmpObstructionManager::TestLine ▒ 0,79% main libmozjs78-ps-release.so [.] js::MapObject::has ▒ 0,78% main pyrogenesis [.] CCmpTerritoryManager::GetOwner ▒ 0,78% main pyrogenesis [.] CCmpRangeManager::LosUpdateHelperIncremental ▒ 0,75% main libmozjs78-ps-release.so [.] js::NativeObject::addDataPropertyInternal ▒ 0,68% main libmozjs78-ps-release.so [.] js::MapGCThingTyped<js::ApplyGCThingTyped<js::InternalBarrierMethods<JS::Value>::preBarrier(JS::Value const&):▒ 0,63% main libmozjs78-ps-release.so [.] js::NativeLookupOwnProperty<(js::AllowGC)1> ▒ 0,56% main pyrogenesis [.] CCmpRangeManager::ComputeLosVisibility ▒ 0,55% main pyrogenesis [.] LongPathfinder::HasJumpedVert ▒ 0,52% main pyrogenesis [.] FastSpatialSubdivision::GetInRange ▒ 0,51% main libmozjs78-ps-release.so [.] js::jit::GetNativeDataPropertyByValuePure<false> ▒ 0,51% main libmozjs78-ps-release.so [.] js::NativeObject::lookupPure ▒ 0,51% main libmozjs78-ps-release.so [.] JS::Zone::getOrCreateUniqueId ▒ 0,51% main pyrogenesis [.] CComponentManager::LookupEntityHandle ▒ 0,48% main libmozjs78-ps-release.so [.] js::MapObject::get ▒ 0,48% main libmozjs78-ps-release.so [.] js::NativeGetProperty ▒ 0,44% main libc-2.31.so [.] __memcmp_avx2_movbe ▒ 0,44% main libc-2.31.so [.] malloc ▒ 0,44% main pyrogenesis [.] CCmpRangeManager::UpdateVisibilityData
-
Well if you call a function pointer you need more time to resolve things no? Maybe it doesn't take more time in practise but it's still an extra step. Also if the setter assignation is non trivial it might affect optimizations. I suppose I need to compare assembly Maybe. I used the perf command on linux to check for such functions like this perf record 0ad/binaries/system/pyrogenesis \ -autostart="skirmishes/acropolis_bay_2p" \ -autostart-ai=1:petra \ -autostart-ai=2:petra \ -autostart-aidiff=1:5 \ -autostart-aidiff=2:5 \ -autostart-victory="conquest" then perf report You can see there which code gets the most called (doesn't mean it's slow just that it's called a lot) It's my strange sense of humor, I have heard a lot of things like this in the past ten years, and I hope you'll surprise me You can quote my comments by hovering over the text in my posts Glad to hear, I always try to help as much as I can. But you will soon be reaching my C++ limits, I'm by no mean an expert, and @wraitii and @vladislavbelov know so much more than I do. I only "fake it until I make it" which sadly can only go that far. I feel ashamed just writing it
-
@feneur can you lift his post limit? @chantsepl you should able to answer Langbart's pm anyway the post limit is just there to protect from spammer.
-
You're very likely using Fgod or Autociv which are not compartible as far as I am aware.
-
The point is your sqrt patch doesn't seem to improve performance which probably means the performance we get from not recomputing the length is lost because the "proper" usage of getter and setters. So maybe something is wrong there ? (I'm just making assumptions I didn't try) I guess an option would be to try first without the getters and setters and then without the optimization. Also langbart tested on Mac which might yield different results because we use SSE3 there (windows is stuck with SSE2) Looking forward to seeing it Promises Promises. You can just fork it on github you know using branches I don't particularly like the idea of spread efforts but one of the goals of 0 A D. is to have fun if that suits you better then I have nothing to say. I will continue to help if I can but you might soon reach my limits.
-
The reason there are both is this one. If you have a camera you don't care about precision cause it's not synchronised so we use floats. I guess that applies to most of the visuals. But units have rotations too. And those needs to be syncrhonised cause units need to face their targets to be able to shoot. So stuff in graphics/ will probably be floats while stuff in simulation2 will probably be fixed. Does that make sense ?
-
Hey DanW58, Nice to see you haven't given up! The errors you get seem to me like you are not sure with there is Fixed and Floats. As you may know the game must run the same on all machines, operating systems we support because all clients compute everything (google lockstep model) Since floating point calculation are not really precise and and can change from one machine to the next we cannot rely on them to be them hence why everything that needs to be synchronised uses CFixed instead of a normal float. I suppose that when you used your macros (which might be better as templates) you didn't make that distinction? Stuff that's serialized usually needs to be a CFixed because one wants the state to be exactly the same when loading a game for instance. The state is based on what's serialized so we can compare hashes with other players. Not really actually. To understand those graphs better you need to play with the Profiler2 UI in source/tools/profiler2/ and load those two jsonP files. The colors depend on the order files are loaded here I believe green is your patch and red is vanilla. The y axis is the time it took to compute a single frame.