Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
90 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Getting data from a file.

So far, we've been entering in all the lua code by hand. This is great, if you want to type your script over and over again. This is novel for about 5 seconds. So, how do we go about getting data from a file? Well, two solutions present themselves. So the question remains … how can we persist this data?

It's really very simple, much like everything we've seen so far in lua. Lua has a function, lua_dofile() that essentially processes the contents of a file. Wow, that makes life really interesting. So, if I was to add that to the current source code, I could get my application to execute a script whenever it runs. Essentially,

#include <stdio.h>
extern "C"
 #include <lua.h>
 #include <lualib.h>
int main(int argc, char* argv[ ])
   lua_State* luaVM = lua_open(0);
   if (NULL == luaVM)
      printf("Error Initializing lua\n");
      return -1;
   // initialize lua standard library functions
   printf("Simple Functional lua interpreter\n");
   printf("Based on lua version 4.0.1\n");
   printf("Enter lua commands. type 'exit<enter>' to exit\n");
   lua_dofile(luaVM, "./startup.lua");
   return 0;

Which moves us to the next bit … what does "startup.lua" look like? Well, it looks like this:

-- Simple lua script
-- comments indicated with a '--'
a = 5;
b = 10;
c = a + b;
print ("5+10=" .. c);

What do we end up getting for results? Simply put:

As you can see, this is staying relatively simple. But, if you look, you can see a couple of problems with this analogy.

First and foremost, we now are exposing all of our source code for anything that we are building. This may not be a smart idea, since it's essentially exposing the functionality of the game (ie: the game logic) to everyone in a readily available format. Again, this might not be desirable. So, how to correct this deficiency? We compile our scripts.

You should be scratching your heads at this point. "Ash", you say, "wasn't the whole point of this exercise to avoid having to compile anything"? Well, yes, it is. But this compilation doesn't have to be done during the development process. You can leave your code in source format and compile it when you need to. In a second, you are going to see that in our application, there will be zero repercussions in doing this.

In the source workspace that I've included, I've also included to additional projects: lua and luac.

Lua is the interpreter that comes with the tarball distributed by the lua organization. Luac is a bytecode compiler. This essentially compiles the lua source into a format that is not human readable. It's also a bit faster. Not lots, but a little.

So, I'm going to take that script I just created, compile it into a bytecode compiled script, and use it in the exact same application, with the only change being the name of the file it loads. When you run luac, this is what you get:

OK. So, if we want to, we should be able to compile the last file we had, "startup.lua" into "startup.lub" using the following:

Luac –o startup.lub startup.lua

I've moved the file startup.lua into the same directory as luac.exe, but if I added it to a directory on my path, I could run this executable anywhere. Anyway, here's the result:

And at the very bottom, you see startup.lua and startup.lub. Open both up in a text editor, and you'll see that the lua file is textual and the lub file is binary.

I'd like to take a second and point out that the extensions given to these files is purely up to the developer. Lua itself doesn't care what you call them.

Page 5

  Page 1
  Page 2
  Page 3
  Page 4
  Page 5
  Page 6

  Source code
  Printable version
  Discuss this article