hyperion

This one for nodjs Well, some 15 years ago javascript was slow as hell ... So no surprise we have different choices this days. As the simulation under current constraints needs to be single threaded javascript is an option. Again, I can only make an educated guess and you will have to consult specialist in this field but I think it might be well worth it.

Obviously something went wrong as https://gitlab.com/0ad/0ad-community-mod-a26/-/blob/main/community-mod/mod.json still says 0.26.2 <- @Stan` Anyway the list of commits you can see here https://gitlab.com/0ad/0ad-community-mod-a26/-/commits/main

Many messages probably originate in javascript and are consumed in javascript and so wouldn't have to leave javascript space at all. Maybe moving the dispatcher to javascript might be an option if expensive components can't be moved to c++. Just a guess but the cost of communication between c++ and javascript might outweigh the extra cost of using javascript. Maybe something like nodjs event emitter and libuv could be used as inspiration. This thread is a bit of a headache, first it looks like "let's sprinkle mutex in case we need it some day". Then it shifts to headless, which at it's easiest could be a null render backend and a driver (possibly some tcp socket protocol) and has nothing to do with threading per se. Then I see some hint of a server client setup where you don't send commands but state transitions or error corrections, which would possibly allow for much more aggressive parallelization. I'm lost at that point.

Plenty good enough to show the approach, thanks. Does the scaling at load time and I guess @vladislavbelov favorite is the randomized scaling to ensure there are no two same models. Reading between the lines I guess @vladislavbelov would want the scaling be done on the gpu tho. A good point brought up is how scale inheritance should be figured out as well.

There is zero additional overhead compared to using blender to scale the model, only less sources in the repo. Given the use cases in this thread there is no need to use the same model at different scale at the same time, but I see your concern that when you don't have to go through a lot of pain to scale a model "some random artist" will find it a good idea to have the same model be used at dozen scales at the same time.

So adding scale means we could deduplicate some assets? Well, you can generate different pmd/psa per scale, that's what I meant with build time / static scaling. Whether this is the most suitable way to go about it is another question. Not accessible

Not sure but I think opengl 2.1 is now a requirement, so hardware older than ~2005 won't do anymore but maybe it's just the drivers which are to old or incomplete.

There is no scaling via actor xml as of yet, right? As for the feature, I guess he wants to scale per entity (main actor and props alike), how to do it is up for debate. The main use of such a feature I see that one could model with a realistic scale or for example shrink the current ships for testing.

Guess adding scale wouldn't add any runtime cost as the models get converted to psa/pmd during build. Can't find a ticket on trac for it, so if you have use for this feature I suggest to open a bug.

Maybe "Player Placement": "AI: Petra Bot (hard, aggressive, ...)" would make more sense?

Scenarios are poor man campaigns from long ago, now that we have campaigns support they should be converted or deleted.

Well, as before, only Windows 7 and later are supported and they all have the same defaults for where to place app data.

Hand drawn icons are miles ahead of renders in terms of aesthetics.

All supported Windows versions have the same paths, at least by default.

The only way to get 64-bit support fast is to replace the 32-bit version, even that is probably more than a day of work, but more or less straight forward. What I did is cross compile 0ad which is somewhat troublesome, my changes are from replacing buildsystem, fixing deps or even replace them, fixing cross compile bugs and more. Reviewing means accept the changes and committing them. The developer on which shoulder this would likely fall is busy adding Vulkan support and still has font rendering on his plate which are in my opinion much more important. Also I prefer to wait for the git migration which is in the works. The takeaway from my work is that there is little in the way of a straight replacement, all else is somewhat cumbersome.

2000, xp, vista are all older than 7, so it's just Windows

Erm, Windows 7 SP something is the minimum requirement.

It doesn't work exactly well with random maps, also for me those pics only serve the purpose of looking good and to immediately recognize the map. Maybe some people are indeed interested in more info, but then a sample minimap render might be more useful and can be optionally viewable with some trigger.

Apparently the rational is in http://www.wildfiregames.com/forum/index.php?showtopic=1125 but it's private (gotta love proper documentation).

If it's one or the other, I much prefer the one the right, ie the current one.

Congratulations

There is git-svn which you can use to track the svn repo, maybe your gui client supports it, the svn repo you want is the one you linked. Svn also supports branches but it's a cludge. All github adds is a means to publicly share your changes which you probably do not need, people often get confused with git vs github.

Well, Microsoft drops support for 32 bit Windows in 2023, after that there is no longer a reason to have 32 bit pyrogenesis. The way windows is handled with prebuilt binaries in repo makes it less straightforward to offer both. The technical issues are mostly understood and not that hard to fix, just work.

The git repo is striped of the prebuilt windows executables, you need to use svn repo instead of git for those. Everyone else probably wants git tho.

You could install Linux into a virtual machine, then use it to build and run 0ad. If you don't do engine work just pull 0ad from svn which has recent binaries for Windows.