(17-10-2015, 08:21 AM)Fendoroid Wrote:
(17-10-2015, 06:46 AM)queueRAM Wrote: Can you explain specifically what frustrated you about the patching process? I want to improve it so it is more friendly to new users.
Well, Windows does not provide a tool for applying diff patches. Thus, I had to install a utility that replicates the GNU patch tool. But now I'm considering to install mingw and msys, to get full GNU integration under Windows. I've did that some years ago, but at the time I was such like a newbie programmer, and have done a disaster (something like installing a bunch of compilers). Then I think that installing msys before using n64split could be a good idea, so you can use the same commands on both platforms, or just use the patch command under Windows.
Oh, yes, I don't inlcude a copy of GNU patch! I should do that in the future to make the examples easier to test. By the way, I also struggle with msys and mingw on Windows. I have found better support for unix utilities under cygwin, but even then it is very difficult to build portable programs.
(17-10-2015, 08:21 AM)Fendoroid Wrote: Also, after some testing under Windows, I found some issues. Maybe some info could be useful to you:
- when I run the command "make clean", all build files are deleted but sm64.map. Is the program supposed to do that?
- This bug is more tricky: I replace a texture through copy and substitution, in the textures folder and then build the ROM. Then, in game appears the older texture. In order to get things right, I have to open the texture file, save it and then build the ROM. Maybe the make process was not aware of the file substitution and thus used the old data from gen/bin folder instead from the textures one (you know the builder better than me, I don't know if actually things go like this).
Much appreciated! The "make clean" doesn't remove "sm64.map" but it should. I will fix this in the next version.
I have experienced the texture problem you are having as well. 'make' is looking at the timestamps of files to determine what to rebuild. Unfortunately, Windows does not update the modified timestamp of a file that is copied, so it retains the timestamp of the file from it's original location. Under unix, a 'cp source dest' will update the modification time of the 'dest' file to the current time so 'make' would pick it up. The only workaround I found is forcing Windows to update the modification time like you are doing or using "copy /b filename +,," to update the timestamp (which is the closest I can find to 'touch').
(17-10-2015, 08:21 AM)Fendoroid Wrote: PS: I also have built under VS2015 the splitter from source, with pain. lol, I had to change the names of every dependency library in the linker input settings, but after all, it is an alpha project.
Wow, that is impressive! Are you using the cmake files to generate the VS project files or did you create your own? I use cmake to generate mine and have a local directory where I've built all the dependencies. I want to simplify this process so it is easier to build and contribute to, so let me know if you have suggestions.