Jump to content

Don't Starve Mod Tools Github Repo


Cheerio

Recommended Posts

I'll check it out. You ok with me porting it to windows as well? I'd rather support only one tool :-)

Sure. Porting it to Windows would be very simple, since I wrote it having cross-platformness in mind. I just didn't specifically bother with Windows because there was already an official tool for it, as well as Matt's tools.

There's very little OS-specific stuff, and everything's localized. Firstly, there's this portion of code in ktech.cpp:

	if(output_path.length() > 0) {		if(isDirectory(output_path)) {			size_t i = output_path.find_last_not_of('/');			if(i != string::npos) {				output_path.erase(i + 1);			}			output_path += "/";		}		else {			// Assume we can write to it and that the extension			// shouldn't be added.			has_extension = true;		}	}
where the tweaking amounts to using '\\' in the Windows case (better yet, in Windows one should use output_path.find_last_not_of("/\\") for the check, and "\\" for the appending). The rest is all encapsulated in wrapper functions, all placed in the file ktech_fs.cpp. Put precisely, these functions are

bool KTech::isDirectory(const std::string& path)
which returns whether a path corresponds to a directory and

void KTech::filepathSplit(const std::string& path, std::string& dir, std::string& notdir)
which splits path into directory and non-directory components.

ktech's only external dependency* is ImageMagick, which has precompiled releases (for Visual Studio projects) both as a static and as a dynamic library. One of the nice things about using ImageMagick as a backend is that image operations are usually GPU-accelerated (through OpenCL), and if not are at least automagically parallelized across CPU cores. ;P

The GitHub repo is at https://github.com/nsimplex/ktech.

* It also uses the Squish library fot DXT compression and one header file from Boost (for endianness detection), but those are bundled in source form, and Squish is statically linked to it.

Link to comment
Share on other sites

  • Developer

Sure. Porting it to Windows would be very simple, since I wrote it having cross-platformness in mind. I just didn't specifically bother with Windows because there was already an official tool for it, as well as Matt's tools.

There's very little OS-specific stuff, and everything's localized. Firstly, there's this portion of code in ktech.cpp:

	if(output_path.length() > 0) {		if(isDirectory(output_path)) {			size_t i = output_path.find_last_not_of('/');			if(i != string::npos) {				output_path.erase(i + 1);			}			output_path += "/";		}		else {			// Assume we can write to it and that the extension			// shouldn't be added.			has_extension = true;		}	}
where the tweaking amounts to using '\\' in the Windows case (better yet, in Windows one should use output_path.find_last_not_of("/\\") for the check, and "\\" for the appending). The rest is all encapsulated in wrapper functions, all placed in the file ktech_fs.cpp. Put precisely, these functions are

bool KTech::isDirectory(const std::string& path)
which returns whether a path corresponds to a directory and

void KTech::filepathSplit(const std::string& path, std::string& dir, std::string& notdir)
which splits path into directory and non-directory components.

ktech's only external dependency* is ImageMagick, which has precompiled releases (for Visual Studio projects) both as a static and as a dynamic library. One of the nice things about using ImageMagick as a backend is that image operations are usually GPU-accelerated (through OpenCL), and if not are at least automagically parallelized across CPU cores. ;P

The GitHub repo is at https://github.com/nsimplex/ktech.

* It also uses the Squish library fot DXT compression and one header file from Boost (for endianness detection), but those are bundled in source form, and Squish is statically linked to it.

 

We use squish as well :).  

Link to comment
Share on other sites

@Cheerio

I ported all the mod tools to Linux and Mac.

However, the tools depend on the "klei" Python module, which appears to be a compiled C package (likely in the mod_tools/exported directory). Since its source code is not available, I can't do anything about it. Moreover, since pretty much everything depends on it (since it handles the dispatching of texture conversion and other things, like atlasing), I could only do very limited testing, since nothing can go all the way due to the missing dependency. However, everything seems to be in order. Let me know if I broke any windows (but I don't believe I did, I was careful :razz:).

I submitted a pull request at GitHub.

EDIT: Oh, and I replaced the pkg/cmn/mod_tools.zip archive with its unzipped contents. Since I had to tweak a couple of the Python scripts (just to replace backslashes in strings with forward ones), and since once the "klei" module thing gets sorted out they'll need some further tweaking (since some call ".bat" files), I found it best to place them under revision control, which is not possible with a big zip file containing all of them.

EDIT 2: The Windows binaries are successfully compiled from Linux using MinGW. The mod tools should be compilable for any OS from any OS.


@JoeW, since @Cheerio seems to have unsummoned himself, could you relay this message to him, possibly when he gets back from vacation?

Link to comment
Share on other sites

  • Developer

@Cheerio

I ported all the mod tools to Linux and Mac.

However, the tools depend on the "klei" Python module, which appears to be a compiled C package (likely in the mod_tools/exported directory). Since its source code is not available, I can't do anything about it. Moreover, since pretty much everything depends on it (since it handles the dispatching of texture conversion and other things, like atlasing), I could only do very limited testing, since nothing can go all the way due to the missing dependency. However, everything seems to be in order. Let me know if I broke any windows (but I don't believe I did, I was careful :razz:).

I submitted a pull request at GitHub.

EDIT: Oh, and I replaced the pkg/cmn/mod_tools.zip archive with its unzipped contents. Since I had to tweak a couple of the Python scripts (just to replace backslashes in strings with forward ones), and since once the "klei" module thing gets sorted out they'll need some further tweaking (since some call ".bat" files), I found it best to place them under revision control, which is not possible with a big zip file containing all of them.

EDIT 2: The Windows binaries are successfully compiled from Linux using MinGW. The mod tools should be compilable for any OS from any OS.


@JoeW, since @Cheerio seems to have unsummoned himself, could you relay this message to him, possibly when he gets back from vacation?

I'll check out the pull request once I get back from vacation and get access to a 'real' computer.  

 

However I don't think the klei module has any compiled component.  If you check the windows python package under the site-packages folder there should be a klei subfolder.  I didn't get around to putting those python files into a common place for all os.

Link to comment
Share on other sites

However I don't think the klei module has any compiled component.  If you check the windows python package under the site-packages folder there should be a klei subfolder.  I didn't get around to putting those python files into a common place for all os.

That explains it. I didn't figure you'd put your custom package in the Python distribution bundled in (which I assumed was the default one). Using that information, I finished the porting. This is @Malacath's wand mod (auto)compiled from Linux (both the inventory image and the Spriter build):

wand_out.zip

Under Unix, the mod tools are currently operating under the following assumptions:

  • The user has Python 2.7 installed (but if there's any Python 2 version, it tries to run the tools anyway).
  • The user has the Python Image library installed.
  • The user has ktech installed.
As the last point highlights, I haven't bundled ktech (I'm still waiting on your opinion on the matter), though it is being used as an external dependency.

Besides the backslash-plagued paths, there were a few other issues on the Python side. One of them was that the zipped build was made with its contents having 0 permissions, i.e. not even the user who created them had read permissions, which I found out is an issue with the Python ZipLib library itself (under Unix), and whose solution simply has no official documentation. Nevertheless, that's all fixed, but since quite a few scripts took some tweaking I split the Python code base into common ("cmn"), Windows ("win32") and Unix ("unix"), which are merged according to the target OS by the premake4.lua script (I left them in unzipped form, to ease revision control as well as the merging process when building the tools). I tried to keep as much as possible in "cmn", and reverted the Windows scripts to their original form, only changing the Unix ones (and the zipanim.py scripts in "cmn", but that was just to replace Windows paths with cross-platform ones, using os.path.join()).

There's only one detail in the way of integrating ktech: TextureConverter can receive more than one input file (with just one output), separated by semicolons. I could implement that in ktech, but I need to know what's its operational semantic. They seem to be the precomputed mipmaps of the texture, is that really (and always) it? If so, how does the presence of more than input interact with the "generate-mipmaps" command-line flag, is it just ignored in this case, or if it were absent would only the first file be used (as the primary and only mipmap)? In the current Unix version, I'm simply ignoring the additional mipmaps (or whatever they are), and letting ktech itself generate the mipmaps using a Lanczos filter. For complete API correspondence, I also need to implement specifying a fixed width or height as a command line option, but that's straightforward (and doesn't seem to be actually used by the mod tools).

EDIT: On that last paragraph, nevermind: I hadn't noticed the TextureConverter sources were bundled in. The behaviour of the semicolon is exactly what I suspected: it separates mipmaps, and when there's more than one file the mipmap generation flag is simply ignored. By the way, TextureConverter uses TCLAP for command line parsing, just like ktech. (:

Link to comment
Share on other sites

@Cheerio

I made some general improvements (see the commit history) and changed the mod tools (and the proj/ files) to be built in a ./build subdirectory instead of an external ../ds_mod_tools_out, since the idea of a project interfering with files outside of its folder wasn't really appealing to me. I added a .gitignore file to the project to ensure git won't track any files inside build/ (except for the build/ folder itself with a single empty .gitignore file inside of it). Even a 'git add --all .' at the base repo directory is safe.

Link to comment
Share on other sites

@Cheerio

I updated ktech to be fully compatible with the Mod Tools. The extended usage is as follows:

$ ktech --help

Usage: ktech [OPTION]... [--] <input-file[,...]> [output-path]Options for TEX input:    -Q,  --quality  <0-100>         Quality used when converting TEX to PNG/JPEG/etc. Higher values result         in less compression (and thus a bigger file size). Defaults to 100.    -i,  --info         Prints information for a given TEX file instead of converting it.Options for TEX output:    -c,  --compression  <dxt1|dxt3|dxt5|rgb|rgba>         Compression type for TEX creation. Defaults to dxt5.    -f,  --filter  <lanczos|blackman|hann|hamming|catrom|bicubic|box>         Resizing filter used for mipmap generation. Defaults to lanczos.    -t,  --type  <1d|2d|3d|cube>         Target texture type. Defaults to 2d.    --no-premultiply         Don't premultiply alpha.    --no-mipmaps         Don't generate mipmaps.Other options:    --width  <pixels>         Fixed width to be used for the output. Without a height, preserves         ratio.    --height  <pixels>         Fixed height to be used for the output. Without a width, preserves         ratio.    -v,  --verbose  (accepted multiple times)         Increases output verbosity.    -q,  --quiet         Disables text output. Overrides the verbosity value.    --version         Displays version information and exits.    -h,  --help         Displays usage information and exits.    --,  --ignore_rest         Ignores the rest of the labeled arguments following this flag.If input-file is a TEX image, it is converted to a non-TEX format (defaultingto PNG). Otherwise, it is converted to TEX. The format of input-file isinferred from its binary contents (its magic number).If output-path is not given, then it is taken as input-file stripped from itsdirectory part and with its extension replaced by `.png' (thus placing it inthe current directory). If output-path is a directory, this same rule applies,but the resulting file is placed in it instead. If output-path is given and isnot a directory, the format of the output file is inferred from its extension.If more than one input file is given (separated by commas), they are assumedto be a precomputed mipmap chain (this use scenario is mostly relevant forautomated processing). This should only be used for TEX output.If output path contains the string '%02d', then for TEX input all itsmipmaps will be exported in a sequence of images by replacing '%02d' withthe number of the mipmap (counting from zero).

I also reused some portability code I wrote for the Mod Tools to make it completely cross-platform. The only remaining consideration is the building process. The dependencies TCLAP and ImageMagick are shipped with a dual build system: autoconf for Unix and Visual Studio project files for Windows. Squish uses a simple makefile or CMake, and currently I'm wrapping the former through autoconf. So if ktech is to be integrated, building it for Windows could also resort to maintaining VS project files in parallel, but that might be somewhat of a hassle. A premake build could be used, though its lack of feature checking capabilities are a handicap. Ideally, it should be built for Windows through autoconf as well, using MinGW instead of VS. ImageMagick has a MinGW binary release, in fact. But I'm still waiting for your opinion on whether to integrate ktech or port TextureConverter.

p.s.: I'm using commas instead of semicolons to separate input files due to considerations for command line usage under Unix. Since Unix shells interpret semicolons as a special character (separating statements, as in C), semicolons would make command-line usage by humans awkward (and could raise issues on automated processing without proper quoting).

EDIT: By inspecting the wand_out.zip archive I uploaded before, you may notice there was a bug on my end causing the intermediate folder created in the mod's exported subdirectory to be called wand.scml instead of wand. The thing is I am only considering a period to delimit a file extension if (besides being the last period in the path) it comes after the last path separator. Buuuut... I wasn't accounting for paths without any path separators :razz:, which made the extension not be removed in that case. This is now fixed.

Link to comment
Share on other sites

ktech for Windows (cross-compiled from Linux, with MinGW):

ktech-win32.zip

The executable is fairly large (~36MB uncompressed) because I statically linked every possible dependency, even the standard C and C++ libraries (which account for a big chunk of its size). This could probably be improved, but I barely know anything about linking and packaging programs for Windows: treat this as proof of concept that ktech works under Windows.

Link to comment
Share on other sites

@Cheerio

I created a cmake branch in the ktech repo, using CMake instead of the Autotools. CMake is a cross-platform building solution which generates native building files like premake, but is much more feature rich, allowing me to translate the previous build system to it.

I also caved in and installed Windows, as well as Visual Studio 2010 (Professional, free student 24 month license). The CMake project successfully compiled under VS2010:

ktech-win32.zip

I bundled the required DLLs, except for the VS2010 runtime.

The above binary also works under Linux (and likely Mac) under the Wine compatibility layer (though of course native builds should be used), provided the VS2010 runtime has been installed.

p.s.: Neither this zip or the MinGW one I posted before include the ImageMagick license (unlike the source zip). So they shouldn't be considered proper releases.


EDIT: I give up trying to figure out how VS works. I was trying to compile the mod tools under VS2010, and it says modtoollib successfully compiled, but nothing is placed in ..\win32\mod_tools. In particular, the other projects fail because modtoollib isn't being found. The output directory is being correctly set in proj\modtoollib.vcxproj, and the object files are properly being built/placed in proj/obj/{debug,release}. I don't know enough about VS to figure out what's going on.

EDIT 2: ktech is not properly identifying when a path is a directory under Windows. I need to fix that.

Link to comment
Share on other sites

The scml compiler in my fork of the mod tools now properly computes bounding boxes (on a per frame basis).


@squeek

What defines the bounding box of a frame are its parameters "x", "y", "w" and "h" (in the intermediate animation.xml file created by the scml compiler). To properly compute them, one must look at every element (i.e., animation symbol) in the frame and, using the pivot/dimensions in the build.xml file and the transformation matrix/translation vector of the animation frame element, determine the minimum and maximum x and y coordinates taken by that animation symbol in that frame (you're applying a matrix and a translation to a rectangle, and then checking its projections over the coordinates axes). Then the "x" attribute of the frame should be the least of the minimum x coordinates of each element in the frame (i.e., it is the globally minimum x coordinate, over all symbols in the frame), and the "w" attribute should be the greatest of the maximum x coordinates minus the global minimum "x" computed before. The same holds for the "y" and "h" attributes. In other words, you're first applying the transformations and translations to each animation symbol in the frame, and then checking the projections of the whole frame over the coordinate axes.

Before fixing the mod tools themselves, I tested my idea by writing a proof of concept script in Lua, which I attach below if you'd like to take a look:

klickable.zip

It takes as parameters the build.xml and animation.xml files generated by the scml compiler (as placed in the temporary .zip inside the project folder within exported/) and prints to standard output the fixed animation.xml (build.xml doesn't need any changing). It's a bit hard to use because it require first running the scml compiler to generate the zip with these files, unzip it, fix animation.xml, rezip it and then run the export.py script directly to carry on with the final part of the build/anim compilation. Since it is just a proof of concept script, I didn't expect it to be directly used, but if you really want to you may check how to call export.py by reading the log of the mod tools.

The reason why for simple static objects you got a proper bounding box by achieving a 0 value "m_tx" and "m_ty" is because the "x" and "y" attributes of the frame were always set to 0, so the bounding box wasn't translated (therefore, if the animation symbol also wasn't translated the positions would coincide). Also, for static (or almost static) objects the transformation matrix is the identity (or very close to it), so taking care of the translation was sufficient.


@Malacath

I already mentioned you in the U&A forums, but I'd like to restate this here: if you ever come back to these lands, I'd love to fix the bounding box of the Weeping Willow.

Link to comment
Share on other sites

Edit: guess I forgot mentioning I'm talking about @simplex version not the original
 
So tried building master on VS2013, I ran into a few things. Apparently va_copy() and realpath() don't exist on msvc++, and for some reason the output of premake did not generate links to actual source files (now.. wether its premake or vs2013 that ate them somehow when converting i dont know, I just put them back in without double checking)
 
The next issue, and that's not just issue with your fork but with the original too, is that python shipped with it requires dlls that it does not ship with. I have fixed that by pulling the installation from standalone modtools (where it is full) but... im not sure if i replaced one too many things since I'm getting 'cannot find file' on textureconverter calls from image_build. Haven't really checked why.

Link to comment
Share on other sites

So tried building master on VS2013, I ran into a few things. Apparently va_copy() and realpath() don't exist on msvc++ [...]

Thanks for the tip. I just pushed a fix removing the use of realpath under MSVC (since it was just under Unix that the way paths are handled is problematic for relative paths) and defining an alternative to va_copy for MSVC (I hadn't realized va_copy is in the C99 standard, which MSVC notoriously does not support).

[...] and for some reason the output of premake did not generate links to actual source files (now.. wether its premake or vs2013 that ate them somehow when converting i dont know, I just put them back in without double checking)

I'm aware of this issue (check two posts above yours). The project files generated by premake look alright to me under visual inspection, but for some reason the projects are simply not being linked. I was hoping Cheerio (or someone with non-zero experience with MSVC) would help with this issue when he got back, but since he never did this remained an open issue. If you figure out what the issue is, do let me know (or submit a fix). Did you manage to compile it somehow, such as via MinGW or Cygwin?

 

The next issue, and that's not just issue with your fork but with the original too, is that python shipped with it requires dlls that it does not ship with. I have fixed that by pulling the installation from standalone modtools (where it is full) but... im not sure if i replaced one too many things since I'm getting 'cannot find file' on textureconverter calls from image_build. Haven't really checked why.

For Windows, you should be able to replace the entire Python27 directory (ds_mod_tools/build/win32/mod_tools/buildtools/windows/Python27) with the one shipped via Steam. Let me know if issues remain after doing this.

Link to comment
Share on other sites

Well, I've been mostly  a java coder for too long, and I used to avoid tying myself to Microsoft anyway, going the alternative path (SDL, QT, OpenGL instead of mfc/dx etc) so I'm not the best person for config issues. I could just run through one of gnu ports, I had VC installed and I thought why not at least try, and then i got interrupted with other stuff so i did not actually run it through anything else.

 

I'm aware of this issue (check two posts above yours). The project files generated by premake look alright to me under visual inspection, but for some reason the projects are simply not being linked. I was hoping Cheerio (or someone with non-zero experience with MSVC) would help with this issue when he got back, but since he never did this remained an open issue. If you figure out what the issue is, do let me know (or submit a fix). Did you manage to compile it somehow, such as via MinGW or Cygwin?

 

comparing the .vcxproj of premake that doesn't work and one that does told me that it was missing the links to source files, and projects were empty when i tried to open them. I just hacked the missing lines into the .vcxproj files, as I'm not sure what exactly premake does, but it might tell you something - apologies if I'm just stating the obvious

 

e.g.

  <ItemGroup>
    <ClInclude Include="..\..\src\lib\modtoollib\modtool.h" />
  </ItemGroup>
  <ItemGroup>
    <ClCompile Include="..\..\src\lib\modtoollib\modtool.cpp">
    </ClCompile>
  </ItemGroup>

 

made the project actually load everything it should, before that it was empty/not building anything. Similar for others.

 

 

For Windows, you should be able to replace the entire Python27 directory (ds_mod_tools/build/win32/mod_tools/buildtools/windows/Python27) with the one shipped via Steam. Let me know if issues remain after doing this.

 

I thought standalone was same as steam.. I'll try again.

 

I pulled the new code,

#ifdef !defined(_MSC_VER)

 

was throwing me errors so i did just

 

#ifndef _MSC_VER

 

It built afterwards, I'll see if it actually works in a bit..

Link to comment
Share on other sites

comparing the .vcxproj of premake that doesn't work and one that does told me that it was missing the links to source files, and projects were empty when i tried to open them. I just hacked the missing lines into the .vcxproj files, as I'm not sure what exactly premake does, but it might tell you something - apologies if I'm just stating the obvious

 

e.g.

  <ItemGroup>

    <ClInclude Include="..\..\src\lib\modtoollib\modtool.h" />

  </ItemGroup>

  <ItemGroup>

    <ClCompile Include="..\..\src\lib\modtoollib\modtool.cpp">

    </ClCompile>

  </ItemGroup>

 

made the project actually load everything it should, before that it was empty/not building anything. Similar for others.

You're not stating the obvious, as I have absolutely zero experience with msvc. Premake is a (Lua-configurable) tool for generating build files under several platforms (usually for more than one build system in each). I'll have to figure out why it's failing at msvc, while in general it's working. Thanks for the tip, that'll surely help.

I thought standalone was same as steam.. I'll try again.

It's supposed to be, but it might be out of date. One way or another, it should have all that's needed on the Python side. If you still get an error, please post them here.

I pulled the new code,

#ifdef !defined(_MSC_VER)

 

was throwing me errors so i did just

 

#ifndef _MSC_VER

 

It built afterwards, I'll see if it actually works in a bit..

Sorry about that, this was a typo. It was supposed to state "#if !defined(_MSC_VER)", though "#ifndef _MSC_VER" is equivalent to it. I pushed the fix to the typo.

Let me know if it works for you (or if not, which errors you received).

Link to comment
Share on other sites

hmm i think there is an issue with premake on windows overall, i set target as gmake and tried to put that through mingw, ended up with that ending up empty too... so I checked diff again but with gmake target and got the same result as with vc pretty much, this time OBJECTS were empty just as compile includes were above^

 

My wild guess would be that there is some path in premake.lua that windows is not recognizing properly

 

And I hate doing this but... realpath doesn't exist on mingw either :p

Link to comment
Share on other sites

And I hate doing this but... realpath doesn't exist on mingw either :razz:

*sigh*

Apparently in Windows the roughly equivalent function is called _fullpath(). But anyway, I just disabled it on all Windows compilation, since as I mentioned it is only under Unix that this is necessary.

Link to comment
Share on other sites

@simplex

 

The reason of image_build failing turned to be the most trivial one - build\win32\mod_tools\tools was missing the whole bin folder, I guess 1 more thing premake failed to do.

 

The next thing is kinda weird, for some reason you can't put the command name under quotes in run(string...), but you can directly in cmd prompt. So I had to remove the quotes in png/scml main functions or it would throw invalid blah blah - might be mingw thing, since i did not try the orig in vs itself, but I doubt it. Being lazy, I just removed quotes, since there are no spaces in dir structures anyway, 

 sprintf( command_line, "%s \"%s\" \"%s\"" ....etc..)

 

there's probably a better option..

 

Another thing to note, when you're making temp dirs, you throw errors if they can't be created... which just so happens to be every time but the first (directory already exists), imo it should not force me to clean temp dirs every time i run autocompiler, but I assume it just acts differently on linux anyway, since windows throws error on it the very first time you try to run it regardless.

 

The last thing, that is confuses me to no ends, is MAX_PATH. It is #defined on windows api level (WinDef.h), then there's

const int MAX_PATH = 65536;

in SCML.cpp which is logically crashing mingw compiler... why is it not crashing msvc is beyond me... ms preprocessor working in weird ways I guess...

 

After hacking through the above, I got both mingw and msvc to compile, rebuilt a bunch of my files with both, seemed to be working fine.

Link to comment
Share on other sites

The reason of image_build failing turned to be the most trivial one - build\win32\mod_tools\tools was missing the whole bin folder, I guess 1 more thing premake failed to do.

Y-yeah... premake... its entirely its fault, that's the only explanation...

The mod_tools/tools/bin directory was being misplaced in mod_tools/bin. I misplaced in (within pkg/) when organizing what goes where in which OS (and didn't notice it, since Windows is the only platform which actually uses the bin dir).

 

The next thing is kinda weird, for some reason you can't put the command name under quotes in run(string...), but you can directly in cmd prompt. So I had to remove the quotes in png/scml main functions or it would throw invalid blah blah - might be mingw thing, since i did not try the orig in vs itself, but I doubt it. Being lazy, I just removed quotes, since there are no spaces in dir structures anyway, 

 sprintf( command_line, "%s \"%s\" \"%s\"" ....etc..)

 

there's probably a better option..

Oh, I did not know that. As you mentioned, it works directly in cmd.exe (and in shortcuts), so it's very strange that it doesn't work in a system() call.

 

Another thing to note, when you're making temp dirs, you throw errors if they can't be created... which just so happens to be every time but the first (directory already exists), imo it should not force me to clean temp dirs every time i run autocompiler, but I assume it just acts differently on linux anyway, since windows throws error on it the very first time you try to run it regardless.

It does act differently on Linux because on Linux and Mac I made mkdir use a flag (the "-p" flag) which suppresses errors if the target directory already exists, precisely for the reason you mentioned. I kept the Windows version as is because that's how Klei's original branch did (see create_temp_dir()), so I assumed it was working correctly :razz:.

Which flag do you pass to Windows' mkdir to suppress this kind of error?

 

The last thing, that is confuses me to no ends, is MAX_PATH. It is #defined on windows api level (WinDef.h), then there's

const int MAX_PATH = 65536;

in SCML.cpp which is logically crashing mingw compiler... why is it not crashing msvc is beyond me... ms preprocessor working in weird ways I guess...

 

After hacking through the above, I got both mingw and msvc to compile, rebuilt a bunch of my files with both, seemed to be working fine.

This confuses me to no end as well. This is also something that comes from Klei's repo. What's strange here is that scml-pp is ts own third party project which Klei embedded in the project. And the original file has no such thing. Nor that "<algorithm>" import. I have no idea why that was put there, it serves no purpose.

Anyway, thanks for hacking it until it worked. I fixed all the above issues, except the error on temp dir creation.

Link to comment
Share on other sites

It does act differently on Linux because on Linux and Mac I made mkdir use a flag (the "-p" flag) which suppresses errors if the target directory already exists, precisely for the reason you mentioned. I kept the Windows version as is because that's how Klei's original branch did (see create_temp_dir()), so I assumed it was working correctly :razz:.

Which flag do you pass to Windows' mkdir to suppress this kind of error?

 

 

To tell you the truth I didn't, i disabled error check :p It did not bother me enough to write if(exists) stuff, and quick google did not give me any useful alternative to mkdir that supposedly does not take any options..

 

Klei left MKDIR to throw 'directory already exist' because for them it was just a warning that does not crash - its annoying spam in console but that's all (and it does not happen in steam/standalone binary builds... just in github build... for my added annoyance). But it is when you put the error check (that caught !=0 because it indeed is not successful call)  that it started actually breaking things, exit(-1) killed all the fun.

Link to comment
Share on other sites

To tell you the truth I didn't, i disabled error check :razz: It did not bother me enough to write if(exists) stuff, and quick google did not give me any useful alternative to mkdir that supposedly does not take any options..

 

Klei left MKDIR to throw 'directory already exist' because for them it was just a warning that does not crash - its annoying spam in console but that's all (and it does not happen in steam/standalone binary builds... just in github build... for my added annoyance). But it is when you put the error check (that caught !=0 because it indeed is not successful call)  that it started actually breaking things, exit(-1) killed all the fun.

I removed the system() calls to mkdir altogether. Klei was doing it that way and I kept it, but I never liked the idea of system() calls for things that can be done natively in the language. Now directories are being created by the program itself, without failing if it already exists (but failing if other errors occur when attempting to create the directory).

Link to comment
Share on other sites

I removed the system() calls to mkdir altogether. Klei was doing it that way and I kept it, but I never liked the idea of system() calls for things that can be done natively in the language. Now directories are being created by the program itself, without failing if it already exists (but failing if other errors occur when attempting to create the directory).

 

Yeah definitely, Klei "design patterns". Did a clean clone, you still have quotes around python command in png sources, aside from that vs seems fine now.

 

I do have another issue/question tho, are you actually using strsafe from anywhere? Because mingw does not have it, I just moved it into vs specific part and built like that... and mingw is still working fine without it as far as I can tell.

Link to comment
Share on other sites

Yeah definitely, Klei "design patterns". Did a clean clone, you still have quotes around python command in png sources, aside from that vs seems fine now.

Just removed the quotes from png/main.cpp. Thanks for helping get my fork compiling under Windows, I really appreciate it.

 

I do have another issue/question tho, are you actually using strsafe from anywhere? Because mingw does not have it, I just moved it into vs specific part and built like that... and mingw is still working fine without it as far as I can tell.

I put it there because I'm using native calls from the win32 API to determine whether a path is a directory. I wasn't sure it was necessary, but since I'm not familiar with the win32 API I put it there just in case. Since by what you posted it looks like it's not necessary (and actually harmful outside visual studio), I (just now) made the include MSVC-specific.

Link to comment
Share on other sites

@simplex

 

I think the issue with premake was that solution() part is being ran through lua interpreter, which on its own deals with OS-specific slashes, and catfile(..) added backward slashes, confusing it and making it not grab source files at all. Assuming the logic is same on other Os's, there should be no issue with putting just forward slashes there.

solution('mod_tools')	configurations { "debug", "release" }	location ( catfile(props.outdir, "proj") )	flags { "Symbols", "NoRTTI", "NoEditAndContinue", "NoExceptions", "NoPCH" }	includedirs { "lib", "../lib" }  	targetdir ( props.skuoutdir )	definesMacros { PYTHONDIR = props.pythondir }    configuration { "debug" }        definesMacros { "DEBUG", "_CRT_SECURE_NO_WARNINGS" }   	configuration { "release" }        definesMacros { "RELEASE", "_CRT_SECURE_NO_WARNINGS" }        flags { "Optimize" }	   for k, app in pairs(apps) do		   	project(app)			kind "ConsoleApp"			language "C++"   	   	      	files { "app/"..app.."/**.h", "app/"..app.."/**.hpp","app/"..app.."/**.cpp" }	 	      	for lib, settings in pairs(libs) do	      		links{ lib }	      	end	end	for lib, settings in pairs(libs) do		   	project(lib)			kind "StaticLib"			language "C++"   	   	      	files { "lib/"..lib.."/**.h", "lib/"..lib.."/**.hpp", "lib/"..lib.."/**.cpp" }	      	if settings.include_lib then	      		includedirs { "lib/"..lib }	      	end	end

I am aware that location() and target() are using backward slashes on original file and here as well and they still work... but they clearly cause some issues on other places of solution def.

 

Anyway with that fix, it is fully compatible with windows building solutions, obviously setting gmake instead of vs for mingw-compatible generation (obviously not a notice to you but someone else that might be stumbling onto these posts that might be unaware of it)

 

Edit: wah indentation in that code block ends up messed up, stupid forums

Link to comment
Share on other sites

@simplex

 

I think the issue with premake was that solution() part is being ran through lua interpreter, which on its own deals with OS-specific slashes, and catfile(..) added backward slashes, confusing it and making it not grab source files at all. Assuming the logic is same on other Os's, there should be no issue with putting just forward slashes there.

I am aware that location() and target() are using backward slashes on original file and here as well and they still work... but they clearly cause some issues on other places of solution def.

 

Anyway with that fix, it is fully compatible with windows building solutions, obviously setting gmake instead of vs for mingw-compatible generation (obviously not a notice to you but someone else that might be stumbling onto these posts that might be unaware of it)

Thanks for picking up on that! And replacing the catfile() calls there with direct forward slashes is certainly no issue under Linux and Mac, since forward slashes are the native directory separators on these platforms.

I just pushed your fix, together with a couple general improvements (proper computation of pivots, putting them in build.bin instead of anim.bin and proper handling of spins for interpolating angles).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...