search

GoomiiV2 / Rampancy

A new level editor for the Halo games based on a CSG/Brush workflow, similar to Source/Quake level editing.
MIT License
36 stars 1 forks source link

No tag-to-xml command like in Halo 1 #16

Open GoomiiV2 opened 2 years ago

GoomiiV2 commented 2 years ago

No print-tag-to-xml like Halo 1. need to write to a file and then read back It would streamline just being able to parse the standard output instead of writing to a file to read back in.

The other issue would still be the relatively slow start up time of tool to run a command, I'm not sure much can be done there in most cases as i expect its some tag index building or such.

But it means if i want to export all the shaders to Unity thats about 3k invoking of tool, even with doing in batches of 10 or 20 process at a time it can take a while.

ATM I work around this but scaning the tag file and looking for a hex pattern to pull out the tag paths for the texture slots I need, then checking the template string for if its transparent etc. Its not great if I want to make more accurate Unity shader versions of Halos shaders, but it works well enough for now and is faster than xml, to file, read parse for 3k ish mats (to xml was taking about 5 mins, this is less than a second.

kornman00 commented 2 years ago

Won't make the next release, too many other changes tied to this and other related code, but should be available in the major release after the next one

I'm not sure how "slow" export-tag-to-xml is for you, as there's no tag index building for that command. When testing a new print-tag-to-xml command, both tool and tool_fast execute in 1.8s-2.2s on lord_hood.biped (granted, a very light tag). A little over 40% of that time is in vprintf though (which is why they both have roughly the same run time).

It is worth noting that tool disables buffering at startup, like

    //  set to no buffering
    setbuf(stdout, NULL);
    setbuf(stderr, NULL);

which may have some performance impact

Testing (still using lord hood) with that code commented out, the hit ends up getting shifted from vprintf to memset_repmovs and more consistently 2.0s-2.2s. So the performance impact of no buffering may be for the better, would require more exhaustive testing with larger/complex tags to figure out what is the most optimal, but right now I have no plans to do more around this.

kornman00 commented 2 years ago

Should be able to close this now