hyperion

Of course contributors are more of an investment than getting things done quickly. Experienced opensource coders are not the norm. But there is no need for hand holding either, which you tend to fall into all to quickly.

Just watched the video doing the testing, the obvious result if you throw a one pound stone it will best guns and slings. So we can conclude NO weapon is most powerful. Science the American John Doe way... Anyway, ancient slings were seriously dangerous, just needs quite some practice.

Trusting people to try their best is certainly good. Trusting people are born fully fledged coders and knowledgeable of the ins and outs of the project is bound to not work. The first thing about git is branches are very cheap, commits are very cheap. To test or review I don't need anything committed to master to reduce workload, so there is no need to commit anything to master either. At one point you will have to look at what was done either way, so commits to master can't reduce your workload only increase it unless you don't care about the master branch in the first place. Anyway good to run into such issues now, so you can ponder a workflow for in case of migration.

To used to to svn

Not easy to say without testing but sounds like it might be an improvement, the extra computational cost in most cases should be limited.

Propose an alternative algorithm to pick target. And as @Player of 0AD stated, some intelligent behaviors might well be costly, but could be cheaper than current on as well.

What about the obstruction? Can the enemy still build on top and it's about who starts building first? Could also deduct some resources, like the foundation already costs x% of the total or such.

What do you want to replace and why? Anyway, all I needed was to mogrify some assets and run fontbuilder using always colour in render options and have now a working replacement for nvtt, so no longer restricted to releases respectively already packed mods. Also created some tickets with compressonator to see if what we lack we can get in a future release. I used a somewhat brute method to get compressonator support, I'm sure @vladislavbelov had something more complete in mind For instance I don't offer modders dozen of options on how to treat their textures. For my layman eye they look better on average anyway. I'm not even sure what all those available tuning parameters are about, so everything default. So now I can build 0ad for windows from ground up using mingw, the only things missing are wseh and stackwalking for dumping crashes. Other than that it's fully functional as far as I can tell. If there are bugs they need first be found.

So a zip (ignoring the errors) was created and I ran 0ad with the "new" textures. Some font(s) got messed up, some of the textures auto resized to dimension 2 from 1 look like zebras but otherwise the textures seem of better quality, less washed out. Quality setting used 0.5 (0 lowest, 1 highest), maybe 1 looks even better, might just take forever to compress. Stumbled over another issue, some textures have png and dds in tree, the dds should probably be deleted in this case. binaries/data/mods/public/art/textures/skins/props/cape_hd_black.dds binaries/data/mods/public/art/textures/skins/props/kart_sail_2.dds binaries/data/mods/public/art/textures/skins/props/kart_sail_3.dds binaries/data/mods/public/art/textures/skins/gaia/tree_cypress_a.dds binaries/data/mods/public/art/textures/skins/props/kart_sail_1.dds binaries/data/mods/public/art/textures/skins/props/iber_sail_b.dds binaries/data/mods/public/art/textures/skins/gaia/farming_barley_harvest_a.dds binaries/data/mods/public/art/textures/skins/gaia/farming_wheat_harvest_a.dds binaries/data/mods/public/art/textures/skins/gaia/farming_wheat_harvest_b.dds binaries/data/mods/public/art/textures/terrain/types/desert_forestfloor_palms.dds binaries/data/mods/public/art/textures/skins/props/celt_prop_1.dds binaries/data/mods/public/art/textures/terrain/types/road_roman.dds binaries/data/mods/public/art/textures/skins/structural/rome_ram.dds binaries/data/mods/public/art/textures/skins/structural/kart_trireme.dds binaries/data/mods/public/art/textures/skins/structural/iber_struct.dds binaries/data/mods/public/art/textures/skins/structural/hele_trireme.dds binaries/data/mods/public/art/textures/skins/structural/hele_struct_b.dds binaries/data/mods/public/art/textures/skins/skeletal/pers_isp_e_1.dds binaries/data/mods/public/art/textures/skins/skeletal/rome_ijv_e.dds binaries/data/mods/public/art/textures/skins/skeletal/mace_bronzeshield_pikeman_a.dds binaries/data/mods/public/art/textures/skins/props/head/celt_caratacos.dds

So works on macos, could it be broken on linux only? Will try the update-workspace et al path. Not using mingw for my compressonator experiments. Also 0ad installed by package manager has the same issue. Compressonator is fine with those. Also compressonator is working as replacement already. The issue I face is I can't build public.zip due to skeleton xml files not being found / not readable for some reason. Candidates for issue are pyrogenesis, fcollada, libxml first and foremost. But thanks anyway.

Now it's compressed and my script will pick it up and convert to png so compressonator can open it. The script converts 16 bit png to 8 bit depth png resizes dimension 1 textures converts compressed dds to png All stuff that needs fixing in compressonator obviously, don't fancy working around this in 0ad proper. Still the corrupt dds should be replaced in svn, compressed or not. -- As for generating the public zip, tried with -mod=mod -mod=public, tried with replacing rdb fcollada with 0ad fcollada, tried with system installed pyrogenesis (pristine a25b, no changes by me), tried with mod-packer binary (source below). I always get those skeleton related errors. What am I missing? Btw., source/tools/dist/build-archives.sh doesn't add public either, what do you use to create the release tarball? #include "lib/os_path.h" #include "lib/timer.h" #include "ps/ArchiveBuilder.h" #include "ps/GameSetup/CmdLineArgs.h" #include "ps/XML/Xeromyces.h" #include <vector> void RestartEngine() {} bool g_GameRestarted = false; void QuitEngine() {} bool IsQuitRequested() { return false; } void StartAtlas() {} int main (int argc, const char* argv[]) { timer_Init(); CmdLineArgs args(argc, argv); OsPath mod(args.Get("input")); OsPath zip(args.Get("output")); OsPath cache(args.Get("cache")); CArchiveBuilder builder(mod, cache); std::vector<CStr> mods = args.GetMultiple("mod"); for (size_t i = 0; i < mods.size(); ++i) builder.AddBaseMod(OsPath(mods[i])); CXeromyces::Startup(); builder.Build(zip, args.Has("compress")); CXeromyces::Terminate(); return 0; }

Phew, not just me

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.