While I will be focusing on inserting portraits for this post, the main topic I want taken away from it is different ways to automate similar processes throughout your work. Something common I hear is that inserting “assets” (generally graphical ones such as portraits, icons, animations, etc) in FEBuilder is easier and/or faster than with a buildfile. To that I want to say, it depends on what type of setup you are willing to use and the effort you’re willing to put in to adjust your strategy that focuses on things like ease of use, compile time, and so forth.
Take 1: The Basic Case
This is the most basic, barebones way you could insert a portrait. It works, and so it is mostly unchanged even from the days of works like VBA. Bundled with Event Assembler are a few external tools, one of which is PortraitFormatter. Feeding that a .png file using cmd will spit out a sequence of compiled binary files for the various aspects of the portrait. Specifying an output file will give all of those bundled as a single binary file instead. Using EA’s #incext directive, you can even feed PortraitFormatter the .png files from EA without having to interface with cmd at all.
Also included with the tools is the aptly named “Tool Helpers”, including a macro for use with PortraitFormatter:
#define setMugEntry(mugEntry, mugLocation, mouthX, mouthY, eyeX, eyeY)
So simply include the compiled binary of the portrait by giving the .png to PortraitFormatter via #incext, slap in the macro, fill out the inputs, and you’re done. Now repeat for every individual portrait you want to add. While #incext will speed up the initial setup, the weakness of that strategy is that the portrait binary will be recreated on every build, slowing down your build times - and the problem only exacerbates as more portraits are added to your project. In this case, only creating the binary files when needed seems to be the better choice, but this brings us back to the initial reason we wanted to use #incext in the first place: interfacing with cmd to call the program every time is cumbersome.
Take 2: “Make Hack Full” And Simple Batch Scripting
Since we don’t like having to use cmd manually, we recall an old friend - Make_Hack.cmd. We can use batch scripts to interface with cmd for us, and so we don’t have to go through the effort every time we want to run similar commands. Sounds great, so let’s do it. Here’s a simple script I cooked up in batch:
@echo off
if not exist dmp mkdir dmp
for /r %%f in (*.png) do ^
PortraitFormatter.exe "%%f" -o "dmp/%%~nf.dmp"
pause
This will compile all .png files in this and subdirectories and spew the output to a /dmp directory. Now we just need to run this everytime we make any updates to any portraits and they’ll all be updated. For the experienced buildfile users you may notice this operates very similarly to other programs run using “Make Hack Full” such as tmx2ea and c2ea. Indeed, this could be added to your “Full” build and run in the same manner directly from there. That way you only have one, longer build for when you update external assets, and your “regular” builds are kept shorter. This is good, but we can do better. What if we didn’t need to seperate the two at all? Well, technically there is always the option to just always run “Full” builds, but those builds are slow because they recompile all our assets. What if we could run a “Full” build, while only compiling assets when necessary, as opposed to just compiling all of them without regard? That way the time would still be fast, and we would compile our assets, without having to do them manually.
Take 3: The Makefile
Enter Make. Make is a smart building system, because it knows when components need to be updated. Indeed, it sounds like exactly what we were looking for. A Makefile is comprised of various “rules”. Each rule dictates how certain assets need to be compiled. Let’s check out a simple make rule:
# dmp to png rule
%.dmp: %.png
PortraitFormatter '$<' -o '$@'
This says we can make a dmp out of a png of the same filename by giving it to PortraitFormatter. In our case, the dmp file is the “target”, that is, what we want to compile, and the png is the “dependancy”, or what it is compiled from. By including this rule in our overall makefile, make will know how it needs to compile our png files into binaries, and what’s more, make itself knows which of those png files actually need to be compiled at all. Now we’ve reached a point where we don’t even have to worry about the dmp files at all, and make handles the entirety of the work of compiling them. Surely, it doesn’t get any better than that?
Take 4: Writing Your Own Code For Full Automation
But this is where we should reconsider our goal in the first place. Was it really just compiling the dmp files? Our manual work still involves including all the processed dmp files and filling in the information for the macro to insert them into the portrait table. But what’s to stop us from automating this aspect as well? If we write our own program to read off the dmp files, and analyze the corresponding png images, we could create our own script or program that writes the installer entirely for us. Adding a portrait could be as simple as naming the png file and dropping it in a folder.
The End?
And so we come back to my opener - the amount of work and complexity left to us is entirely dependant on the lengths we’re willing to go to remove it. Nothing is stopping you from being creative, or just continuing to do things the same way you always have. There are really no restrictions when it comes to your workflow, so do whatever works best for you, but most importantly, don’t believe that just because someone, or everyone else does something one way, that you should too. Happy hacking and stay safe.