[59] Brasilian Skies

On Monday, I was told that I'm allowed to show multiple projects I work on instead of the single project I was showing at any given time, as it still counts as work.

I was running into problems with the NES and motivation was dropping quite quick, so I wanted to put more time into the other project I'm working on, which I'm making for a friend of mine. A lot of thinking has gone into it before I ever tried writing a line of code for it, and the writing for it effectively boils down to what happens if you write down every funny thing you and your friends say and think up for two years. It makes for writing styles and content like this:

A shining example of me and my friend's immature humor.

The document that I put all of this in is sitting at a little over 8000 words, so extrapolate these few examples to that amount in your head, I guess.

Anyway, I've tried this project about 4 times to varying success and failure, using different build systems, environment setups, libraries, and IDEs. This will be the 5th attempt.

This 5th attempt involves binding SDL and process heavy functions and the like as Lua functions, which I'd use as the main scripting language for the game.

I'd prefer it if the source code wasn't within the games release files, and since ".lua" can be edited like source code (especially this context, in which it literally is), I wanted a way to obfuscate it somehow.

I originally made a python script that walked through and encrypted the source .lua files and subdirectories recursively, but I ran into an issue. I realized that I'd need to make my own version of require() or dofile() that unencrypted the file at run time.

If I did do that, I'd want to bind it as a pure C function, but looking at the definition of require() in Lua's source code made me think otherwise.

Some of these functions might even be private or just macros, and I'm not about to reverse-engineer each one to find out, hoping that they're adequately commented.

The 2nd method of obfuscation would be to just pre-compile Lua code and save it to a file.

Lua is compiled at run time every time loadfile(fileName) (or load(codeString)) is called, so this would also save a bit of time loading the script.

So, using this method, Lua code that looks like this:

Can be compiled to look like this:

If it's incomprehensible to the average person, it's good enough for me.

Here's the lua code I use to run a pre-compiled file as a function:

I even recycled the bad encryption script that I was talking about earlier to use the "luac" utility, which does the whole pre-compiling thing:

I use this within a simple shell script that copies over current asset data to the game files before pre-compiling the Lua scripts to the same destination:

This shell script is run every time I start building for any of the two build targets, which are called "Debug" and "Release".

I did a few tests with Lua, but I'll show the last one I did.

I wanted to make and bind a C function as a Lua function, and I wanted to test how its call stack responds to a nested function, with the root call in lua, and the nested call going to a C function.

For this test, the C function to be bound is called "KIT_coolpow", which just takes two numbers, and returns the first number raised to the power of the second.

(Anything SDL can be ignored here, as it isn't doing much in this example.)

Below is the main.lua script the C counterpart loads and calls:

Finally, this is what the whole program outputs:

Also, as specified in KIT_coolpow(), it doesn't accept a negative 2nd argument.

So, by changing the power from 4 to -4...

The result looks like this instead:

To account for the stark differences in how C and Lua is structured, a virtual stack is used

which is part of why the bound C function looks kinda odd.

Well, that's it for this week.