hyperion

Guess I write and archive builder frontend which doesn't expect anything to be installed already. Thanks for clarifying. nvtt didn't chock either. Maybe best effort to recover from broken file headers or so. Maybe someone else on linux can chime in as to what the file command reports for them for metal_desert_small_a.dds. Maybe export as dds and I see if it's fixed for me. (Where did you get a working gimp-dds plugin from, thought that was long dead)

@vladislavbelov Investigated mipmaps framework uses min(w,h) insted of max(w,h) for mipmap min size / count while generating framework always sets DDSD_MIPMAPCOUNT != 0 (1 for no mipmap) already compressed dds need processing or pyrogenesis will chock due to not supported texture format. Converted them to png so I can feed them to compressonator. Also tex_dds.cpp only accepts DXT1 DXT3 DXT5, so no BC5 for normal maps, using BC3 instead. @Stan` Found out what's wrong with metal_desert_small_a.dds, file reports DOS/MBR boot sector, so obviously corrupt dds file. Might want to remove or replace it. Now that I have textures that can be processed with compressonator and pass sanity checks, a few questions wrt packaging: The problem with -mod=mod is you need to have mod already installed where pyrogenesis can find it, doing this during build is not possible, as you are only about to install it. Would have to fix archive build. Can't find the purpose of -md=public in source nor any documentation what it should do, can you elaborate? To build the public.zip I need public mod loaded? Typo or real?

@vladislavbelov, thanks. All those formats which are the same are confusing when getting into it at first. So let's see if I got it right, bc1-5 only for 0ad for now, dxt1 -> bc1, dxt3 -> bc2, dxt5 ->bc3, ati2 -> bc5 Some of my progress: Did resize png of size 1xsomething to 2xsomething and no longer see segfaults. When starting 0ad it fails at tex_dds.cpp:562, looks like mipmap is problematic. Built framework with mingw, only needed minor changes. So no issues from that angle.

git grep "grass b soft dirt 50" binaries/data/mods/public/art/terrains/grass/grass b soft dirt 50.xml:<?xml version="1.0" encoding="utf-8"?> <terrain> <textures> <texture name="baseTex" file="types/grass b soft dirt 50.dds"/> </textures> <material>terrain_base.xml</material> </terrain> binaries/data/mods/public/maps/random/ngorongoro.js:// ["dirta","savanna_wash_a","savanna_dirt_b","savanna_riparian_bank","savanna_grass_b","grass b soft dirt 50","grass1_spring","grass_field","grass1_spring","savanna_grass_a_wetseason","savanna_grass_b_wetseason","savanna_grass_a","new_savanna_grass_a","new_savanna_grass_b","new_savanna_grass_c","steppe_grass_dirt_66","peat_temp"];

Edit: double post, the forum seems buggy. Anyway let's use this to post for some questions. @Stan` @vladislavbelov What I'm actually interested is some enlightenment wrt. already compressed dds and DXTn vs BCn I have little clue about that topic, I read somewhere use BC7 always except BC5 for normal maps today. Is that reasonable? How new needs hardware be to accept that. What can be used in 0ad? Also somewhere I picked up closest equivalent DXT1 -> BC1, DXT3 -> BC2, DXT5 -> BC3 What do you want to do with the pre-compressed dds? I read DXT has low quality for size compare to BCn.

As it segfaults it's a bug anyway, if it's an intended limitation I'd expect an assert. I wouldn't "fix" them yet, might also be due to not being square or some other unexpected criterion. Will dig a bit into it later. Is a funny one as well. References would need to be updated too ofc. git grep "sunny 1" binaries/data/mods/public/maps/random/unknown.js: setSkySet(pickRandom(["cirrus", "cumulus", "sunny", "sunny 1", "mountainous", "stratus"])); binaries/data/mods/public/maps/scenarios/fast_oasis.xml: <SkySet>sunny 1</SkySet> binaries/data/mods/public/maps/skirmishes/corinthian_isthmus_2p.xml: <SkySet>sunny 1</SkySet> binaries/data/mods/public/maps/skirmishes/temperate_roadway_2p.xml: <SkySet>sunny 1</SkySet> Not hard but a bit of work. Might be an easy "first patch" for someone if you can't be bothered.

Files with spaces: binaries/data/mods/public/art/terrains/cliff/cliff volcanic coarse.xml binaries/data/mods/public/art/terrains/cliff/cliff volcanic ground.xml binaries/data/mods/public/art/terrains/cliff/cliff volcanic light.xml binaries/data/mods/public/art/terrains/grass/grass b soft dirt 50.xml binaries/data/mods/public/art/terrains/snow/path a.xml binaries/data/mods/public/art/terrains/snow/snow 50.xml binaries/data/mods/public/art/terrains/snow/snow forest.xml binaries/data/mods/public/art/terrains/snow/snow grass 100.xml binaries/data/mods/public/art/terrains/snow/snow grass 2.xml binaries/data/mods/public/art/terrains/snow/snow grass 75.xml binaries/data/mods/public/art/terrains/snow/snow rocks.xml binaries/data/mods/public/art/terrains/snow/snow rough.xml binaries/data/mods/public/art/terrains/special/light blue.xml binaries/data/mods/public/art/terrains/special/neon green.xml binaries/data/mods/public/art/textures/skies/sunny 1 binaries/data/mods/public/art/textures/skies/sunny 1/back.dds binaries/data/mods/public/art/textures/skies/sunny 1/front.dds binaries/data/mods/public/art/textures/skies/sunny 1/left.dds binaries/data/mods/public/art/textures/skies/sunny 1/right.dds binaries/data/mods/public/art/textures/skies/sunny 1/top.dds binaries/data/mods/public/art/textures/skies/sunset 1 binaries/data/mods/public/art/textures/skies/sunset 1/back.dds binaries/data/mods/public/art/textures/skies/sunset 1/front.dds binaries/data/mods/public/art/textures/skies/sunset 1/left.dds binaries/data/mods/public/art/textures/skies/sunset 1/right.dds binaries/data/mods/public/art/textures/skies/sunset 1/top.dds binaries/data/mods/public/art/textures/skies/sunset 2 binaries/data/mods/public/art/textures/skies/sunset 2/back.dds binaries/data/mods/public/art/textures/skies/sunset 2/front.dds binaries/data/mods/public/art/textures/skies/sunset 2/left.dds binaries/data/mods/public/art/textures/skies/sunset 2/right.dds binaries/data/mods/public/art/textures/skies/sunset 2/top.dds binaries/data/mods/public/art/textures/skins/props/helmet/hele_phrygian_mask_02_silver - copia.png binaries/data/mods/public/art/textures/terrain/types/cliff volcanic coarse.dds binaries/data/mods/public/art/textures/terrain/types/cliff volcanic ground.dds binaries/data/mods/public/art/textures/terrain/types/cliff volcanic light.dds binaries/data/mods/public/art/textures/terrain/types/grass b soft dirt 50.dds binaries/data/mods/public/art/textures/terrain/types/light blue.png binaries/data/mods/public/art/textures/terrain/types/neon green.png binaries/data/mods/public/art/textures/terrain/types/path a.dds binaries/data/mods/public/art/textures/terrain/types/snow 50.dds binaries/data/mods/public/art/textures/terrain/types/snow forest.dds binaries/data/mods/public/art/textures/terrain/types/snow grass 100.dds binaries/data/mods/public/art/textures/terrain/types/snow grass 2.dds binaries/data/mods/public/art/textures/terrain/types/snow grass 2_norm.png binaries/data/mods/public/art/textures/terrain/types/snow grass 2_spec.png binaries/data/mods/public/art/textures/terrain/types/snow grass 75.dds binaries/data/mods/public/art/textures/terrain/types/snow rocks.dds binaries/data/mods/public/art/textures/terrain/types/snow rough.dds binaries/data/mods/public/art/textures/ui/session/icons/mappreview/Barcania (3).png binaries/data/mods/public/art/textures/ui/session/icons/mappreview/Sandbox - Carthaginians.png binaries/data/mods/public/art/textures/ui/session/icons/mappreview/Sandbox - Iberians.png binaries/data/mods/public/art/textures/ui/session/icons/mappreview/The Persian Gates.png binaries/data/mods/public/art/textures/ui/session/icons/mappreview/Tropical Island.png libraries/source/fcollada/src/FCollada/Pre-requisites and License.rtf pngs with 1 x dimension binaries/data/mods/public/art/textures/ui/loading/progressbar/progressbar_middle.png binaries/data/mods/public/art/textures/ui/session/icons/capture_bar.png binaries/data/mods/public/art/textures/ui/session/icons/experience_fg.png binaries/data/mods/public/art/textures/ui/session/icons/health_bg.png binaries/data/mods/public/art/textures/ui/session/icons/health_fg.png binaries/data/mods/public/art/textures/ui/session/icons/pack_bg.png binaries/data/mods/public/art/textures/ui/session/icons/pack_fg.png binaries/data/mods/public/art/textures/ui/session/icons/stamina_fg.png binaries/data/mods/public/art/textures/ui/session/icons/supply_bg.png binaries/data/mods/public/art/textures/ui/session/icons/supply_fg.png binaries/data/mods/public/art/textures/ui/session/icons/upgrade_bg.png binaries/data/mods/public/art/textures/ui/session/icons/upgrade_fg.png binaries/data/mods/public/art/textures/ui/session/panel_shader_top_edge.png Collada files. So while generating the public mod (pyrogenesis --archivebuild=public/ --archievebuild-output=public.zip) output like the following is expected? ERROR: art/animation/biped/rider/cavalry/spearman/idle_shield_relax_shoulder_02.dae: Assertion not satisfied (line 393): failed requirement "recognised skeleton structure" Haven't looked into it yet. Just noticed those lines scrolling by

@Stan` quick tested the mingw build, two issues I built libcurl with openssl instead of winssl support, so modio didn't work, fixed. The alt tab issue remains in sdl 2.0.16, can't reproduce in wine --- So did run the mod packaging with rdb fcollada and compressonator and made some findings. a) Following files can't be opened in cmp_framework: Microsoft DirectDraw Surface (DDS): 16 x 16, compressed using DXT1 Microsoft DirectDraw Surface (DDS): 128 x 128, compressed using DXT3 Microsoft DirectDraw Surface (DDS): 512 x 512, compressed using DXT5 PNG image data, 1024 x 1024, 16-bit/color RGB, non-interlaced PNG image data, 1024 x 1024, 16-bit grayscale, non-interlaced Quite some assets in dds format are obviously already compressed. Not sure using nvtt/compressonator to process them doesn't result in loss of quality. dds not yet compressed open fine. Compressonator obviously doesn't like 16 bit png neither. b) Then a dozen or so *.dds have spaces in their path/file name! Not a real problem, just made writing a script removing the above a bit more awkward. Would still be nice to clean them up. c) There are png of dimension 1xsomething, they cause segfaults, compressonator probably requires dimension at least 2 d) craps out when generating mipmap for metal_desert_small_a.dds e) some dae: skeleton structure not recognized with rdb fcollada, do you remember if you changed something? (getting Assertion not satisfied (line 393): failed requirement "recognised skeleton structure") Assets not matching a)-e) seem fine.

Well, the current binary looks in /usr/share for ro data, reusing the native install. Sure can do a build intended for windows, but guess has to wait for tomorrow. Currently hacking in compressor support and about putting things off for the day. What I have so far: build of core compressor and framework libs (linux only) Some hack of TextureConverter using framework which passes test_TextureManager and actually produces dds. only producing BCn dds, if DXTn or ATI2n are really required somewhere down the road I have to figure out how to get support for those, doesn't look trivial tho. The build system is somewhat of a mess, they claim they are working on it, so things should improve. quite some features in TextureConverter dropped for now. diff is some 450 lines. So probably 20% there already.

40 fps sounds substantial. IFF built with 32 bit support, which requires 32 bit builds of deps as well, so I disabled it. Not wine's fault

I meant the native linux build, haven't ever tested the 32 bit msvc build offered for download as I don't have wine32 laying around. Should probably do that some time. As a rule of thumb, a 64 bit build is faster but requires more ram (compiler can use more instructions, registers etc but types may be larger), how much of a difference it makes only testing can tell. But I don't care about that in the first place. The performance issues can't be fixed even if it's twice as fast as the hogs aren't linear. The point of a mingw port is a) to build everything from ground up easily and b) cross compile support. As for the effort, well, it's still reasonable with the roughly 40h I spent on it so far. This includes things like learning premake and lua (which I then abandoned) as well as reading Microsoft documentation.

You made me check the ebuild for 25b # Build bundled NVTT # nvtt is abandoned upstream and 0ad has forked it and added fixes. # Use their copy. bug #768930 if use nvtt ; then cd libraries/source/nvtt || die elog "Building bundled NVTT (bug #768930)" JOBS="-j$(makeopts_jobs)" ./build.sh || die "Failed to build bundled NVTT" cd "${S}" || die fi Didn't know compressonator, but gives a good first impression: maintained by AMD has standalone libs for integration. has cli and gui tools for artists.

The author claims it wont link. The reason I don't want to invest time into nvtt is not the difficulty in porting (well hard to tell upfront). First reason is nvtt is dead, then latest release and master is broken, else Gentoo wouldn't use the 0ad bundled copy. 0ad or some devs at least have the intention to move away from nvtt. Lastly, the in tree copy is a typical 0ad mess. Import the code and do some random changes in the same commit, then carry some patches in a separate directory which may or more likely may not apply to pristine sources, then forget about them and change the sources directly again, formatting included. @wraitii did a good job with spidermonky, if not for storing the tarball in svn I'd label it close to perfect . Well, I look into compressonator, even if just to figure out it doesn't work.

So, the issues with replays was istream seekg being broken for text input with mingw (magically eating crlf as lf and so offsets are off), works when set to binary. @vladislavbelov @wraitii, The optimizer somehow breaks profiler2 in mingw, and I noticed profiler2 initialization is racy with native Linux build as well, couldn't figure out where it goes wrong so far (thou gcc bug less likely than 0ad bug). Replacing profiler2 with a stub and we have optimizations with mingw and no race with test in Linux; and basically the same execution speed in wine as a native build. @vladislavbelov, do you have a suggestion for a replacement of nvtt? Might look into it if there is a path forward. Otherwise I have to stick to releases and use the 0ad-data tarball.

git-format-patch / git-send-email and then use git-am Commit access isn't that important with git, Linus is the only committer for Linux Also easy to add back if desired. But better they push their changes to their own public repo and someone doing commits on a regular basis pulls from them (DVCS).

They also rebuild the engine for java script changes and stuff that isn't intended to be committed. A lot be cut if you wanted. Remaining known issues are optimizer breaking the build and texture conversion (nvtt), then polishing. For me it's a major reason not to contribute as it doesn't respect author and only knows committer. If you are lucky enough there is a patch by: in the message and if less there is a concern stating it (the latter I consider unacceptable). There is no need to move to github or even git to accept pull request, just devs willing to do review there and apply the patches. The only reason to migrate to github is lack of infra and infra personal.

It certainly isn't trivial. Whether to and where to split pyrogenesis and 0ad, strip build artifacts or tarballs from history, to exclude external libs etc are questions which need answers. Well, I'd start with the infra. Setup test.git.wfg.com. Add some test repos, setup hooks wanted, like maybe fast-forward only or run linter/CI for example, reports like mail and what not and try to break it. Play with gitweb, trac and if you want something github alike maybe gitlab and try to break it. Then document the setup you like best (and wait for it to get shot at from all sides ). In the meantime others can think about the actual conversion of the repo.

Only loading order matters. Mods are loaded from top to bottom in the enabled mod section.

Just recently looked at arcanist and thought it's trouble. Then came across https://gitlab.haskell.org/ghc/ghc/-/wikis/why-not-phabricator and have to say the section "one year of arc on #ghc" is a hilarious read. Not going to use it ever. I think facebook took over maintenance of phab, not sure what their plans are yet. Guess little short term implications for wfg but a possible switch would be a good opportunity to migrate to git as well.

Little had to be changed in cmake to get it working with mingw as well, have scenario and actor editor working now. Returning a fixed duration for replay length makes them work otherwise. So the only big issue now is not being able to generate mods, respectively being able to run in svn, which is blocked by nvtt not liking mingw at all.

But that probably also means older versions don't do fancy stuff which break user experience if the setting is not recognized. Are there any reported cases of green stripes bug for older versions?

See project_add_manifest() in premake5.lua. There are also plenty of pragma linker comments ignored by mingw and some specific function calls that could be replaced. Don't remember them offhand. They are sometimes even commented with do not really work. premake isn't that bad until your use-case outgrows it. Not really familiar with meson. Also me thinks the 0ad code is organized as-is mostly to fit premake, where it should be the other way around.

It seems all it takes is to play a different map than the one and only mainland with low size. Valid reason for blocking expansion is the distance between civ centers and possibly high cost. Also people do expand by means of planting structures at the border, some times house chains to cross half the map. Also some snowballing is needed or the game won't ever end. Me think snowballing isn't excessive in 0ad.

Thanks for the long answer. That has some issues with macOS and its sdk If you want to build on an old mac what is the issue with installing a more recent compiler? Just treat it like any other dep. I'd like to help with that. Seemed a bit annoying with premake The manifest is an xml file, guess there should be a fancy gui on windows to generate it. Then you simply include it in the rc file and the resource compiler will do the right thing. Is somewhat orthogonal to what you do with your patch. https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests in the rc file add: IDR_RT_MANIFEST1 RT_MANIFEST "pyrogenesis.exe.manifest" done. The minimalist one I use for mingw to replicate what I call the linker hack: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <dependency> <dependentAssembly> <assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> </assembly> But there is a lot that can be set like dpi awareness etc, then people don't have to set properties to work around green stripes I suspect A lot of maintainers are annoyed that. 10 years later still stuck with premake ...

Some time passed and I thought I post an update on the status, haven't given up just got sidetracked: Fixed the user.cfg issue mentioned earlier but found one with replays (can't rewind to start of line). Fixed spidermonkey for mingw64-runtime >= 9.0.0 Found out where the debug info got lost. Premake has a very hidden feature to add -s to the linker options unless you explicitly enable debugging within the premake script! Got fed up with premake enough to write a cmake script. Can even package mods . Probably only works for Linux right now. Most of wdbg restored. Missing stackwalker might not be easily fixable due to dwarf vs pdb? Anyway low priority. wseh might be doable as mingw 64 bit unlike 32 bit actually uses seh, have to investigate further. collada only used during caching/building mods (lack of nvtt prevented me from even trying) and so I only noticed during cmake porting that some more work might be needed than originally thought. To conclude, a 64 bit port seems quite doable, the issues I ran into are mostly due to using mingw instead of msvc. Next steps: use cmake with mingw try building atlas find out what's wrong with replays Current wishlist for A26: Drop nvtt for something else rather earlier than later, not gonna fix it, I have no clue what an appropriate replacement could be. Seems to be not that much work once you know the replacement and are somewhat familiar with texture conversion in 0ad. Only use <thread> instead of pthread and win threads. 80% of the work seems updating mongoose. use std:filesystem instead of custom implementation and sometimes boost. Use a proper pyrogenesis.exe.manifest instead of those code and linker tricks which seem to tell windows to run in win98 compat mode. Might fix some issues users see currently.