It has been a while since I updated. Been a hectic February, life moves too fast and work is a pain at times. I had to pull an all nighter last Thursday to get a demo finished. I would normally have just asked for more time but this was my project and really my ass on the line. I wrote the research paper that was behind it, not really expecting the funding to come through and when it did, I got the work. I was very proud of the work I did but damn it was a struggle.
The project involved Lua, which I must say after working with Lua in both C and C# integration. I like C# much better. The .Net version of Lua integration is extremely easy to work with and the ability for C# to have attributes which can be put to use in registering exposed functions to Lua is a dream compared to working with Swig or writing your own function wrappers. I learned a lot though, about Lua and about C. I consider myself a good C programmer, a professional if you will, but there is never a shortage of things to learn. This project really stretched my expertise in DLL handling in windows in a C environment (not for Lua but still, I learned it because of this Lua project).
It is interesting to note that a DLL can be loaded into the program space more than once. Mind you this is generally not a good method of doing things, but sometimes a necessary evil. Care must be made though that DLLs are not loaded from multiple copies of the same DLL in the file system. All references to a DLL should be made on the same DLL file. If you do not you will give yourself problems because it will actually load two copies into program space and when you expect the DLL to have global variables that are maintained in the program space environment you will be rudely awakened to find that those global variables in your other DLL are in fact different than the ones you expect them to be.
Another interesting thing I picked up last week was the use of Lua userdata types. These data types are used to represent "objects" in Lua that are not considered one of the standard primitive types. These can be anything from C structs or pointers to C++, C#, or Java objects. It is basically just a pointer to memory in the Lua environment. The tricky things about these datatypes is that you can not create them in the Lua environment. You can only receive them from the main application. Thus the use of these data types are heavily reliant on the host application, functions that receive a pointer to something must be represented as a userdata type and not the primitive that it points to (if it is a pointer to a primitive of course). This obviously can cause some issues, especially when generating interfaces to pre-existing libraries. I found that Swig is not so good at handling this, so care had to be taken to fix some of my wrappings. Also, typedefs can be a cause of torment when dealing with Swig if the typedefs are not included in the header that is being "Swigged". The reason for this is that Swig thinks that these typedefs need to be represented as a userdata type which can cause problems when working with things like handles.
Finally, it should be mentioned that applications that use functions that have output parameters are also a very complicated issue when working with Lua. Lua has no concept of pass by reference. It only allows pass by value and as a result, any pointer passed to the function, when converted to a Lua wrap, is treated as a userdata type. Very inconvenient when Lua has a perfectly good multi-return mechanism built into the language. In fact this is so good that great care must be made to utilize it, unfortunately Swig once again fails at this because it does not know what is an input parameter and what is an output parameter. Now I don't know if I am just too thick skulled to know how to use Swig in all its faceted feature set, but I handled this by brute force modification of my generated Lua wrappings. I feel like modifying these wrappings not only gave me more control over what was being done in each function, but also provided better functionality and ensured that each function was being generated correctly. It took a bit more time but I was happier with the results, and I was able to fix all of the issues that possibly would have gone undetected for a few weeks, or months, or years, until those functions were used by a scripter.
Overall, I still love Lua, I think it is one of the best scripting languages out there. It is easy to use (on the scripting side of things) and not overly complicated to integrate. I was able to get scripts executing within a matter of two hours at the most, much can be said for that. The demo was a success and I am very excited to say that I was able to secure additional funding to continue my work. My managers were happy and thus I was happy. Glory day!
Oh and I beat Dante's Inferno this weekend... also a bonus, saw the anime for Dante's Inferno I was not impressed, more just a retelling of the game storyline. I think EA did a better job with Viceral when they made the Deadspace anime for that games release. It added something to the story that was not in the game. I also am not a fan of anime where they have a handful of different studios with different art styles writing different parts of one story. The change in art style confuses me, not that I am dumb, it just makes my eyes readjust to the changes in color pallets and the character movements. I hope to write a review on Dante's Inferno to finish up the trillogy of reviews (First Impression, First Look, and Overall review) but life is killer and I am super busy looking for a new job, planning my wedding, working at my current job, and working on side projects. As a result the blog always seems to fall to the back burner. Well... back to watching some anime before bed, and back to the grind tomorrow.
