A few days ago i found a job listing from an indie company who asked about XNA and C# development. While i didn't knew XNA, i had messed a bit with C# at the past and since i have a good grasp of game programming in general i decided to call them. It turned out that they were ok with me not knowing XNA or having much of C# experience because "since i knew C++ it would be easy to learn C#" and so we arranged for an interview a week later. However i thought that becoming familiar with XNA until then would be a good idea, so i downloaded Visual Studio 2010 Express and XNA Game Studio 4.0 (which is a very hard thing to find in Microsoft's site now that they try to promote Windows Phone 7), installed them and started playing with it.
I had tried VS 2010 Express before and i was familiar with it (mostly Visual C++), so nothing new there. About XNA i mostly expected something like Ogre, in that provides a core engine that you work with, but it actually came to be more like LWJGL which simply provides means to render stuff on screen, play sounds, handle input, etc. XNA is slightly more high level than LWJGL, though, since it mostly takes care of timing, initialization, resources and generally provides a very thin skeleton/framework to build on. Also API-wise while it is written on top of Direct3D, it doesn't really expose much of it (unlike LWJGL which provides the raw APIs it uses).
However it doesn't provide you with scene managers, renderers, collision/physics, GUI, etc - you have to wrote those yourself as (and if) needed. In general it is a lightweight API. Except one part: audio. I found the need to use their specialized audio tool (XACT) for anything more complicated than "play sound now" to be really awkward and i would prefer more programmable controls. Ok, not just awkward - i hated it. The idea is to separate the job of the programmer and the audio designer, which i suppose makes sense in larger teams, but for a small team or for doing something as simple as "play sound A as if it came from X, Y, Z" is really weird.
In any case, in that week i extended my Runtime World 3D world editor to load OBJ models, set models for user entities and create links between entities and made a small world with it:
Then i wrote a loader for Runtime World files in C# and used that with XNA to create a small demo over the week. The audio part bit me at the last moment since i had floating platforms which i wanted to emit a gas-y sound. While the other sounds were simple monophonic sounds played at slightly randomized pitch, i the platform's sound plaback had to be in 3D space (at the platform's location). After spending a few hours trying to figure out what the "proper" way is to do that, at the end i chickened out at the last moment (literaly minutes before i left my home to go to meet the people i taked with) and wrote the 3D audio code myself. Unfortunately the panning wasn't properly calculated and sometimes the platform sounds as if it comes from the opposite side.
The result of my effort to become comfortable with XNA is a little 3D platform game where you control a robot around:
At the end, i think that XNA is actually a nice API to play with. My major problem with it is that it is tied to the Windows platform and i prefer to use cross-platform tools. Also the dependencies are sad: a huge .NET runtime and a XNA runtime (although some recent popular indie games, like Terraria, are written in XNA and install it by default, so some players will probably already have those two). There are efforts to port XNA to Linux and Mac via Mono, but so far the progress isn't that good for 3D games (2D games seem to work fine though). Additionally even Microsoft seems to have abandoned XNA - it has been a long while since the last update, Windows 8 do not seem to support it in Metro and apparently the XNA-related posts in Shawn Hargreaves's blog have almost stopped. Of course this is just a rumor and even if it were true, XNA can be reimplemented and improved (people already do this to port games to Mono).
For a while i toyed with the idea of making something similar for a more open and cross-platform environment like FreePascal (which is natively compiled and very similar in relevant features to C#, so no external dependencies like a runtime - and in addition with Lazarus one can build tools too) or a Python module (i even started coding that for a while), but couldn't find something satisfactional. I didn't worked on it much, though, so i might revisit it later.
In a previous post i mentioned a method i came up, Occlusion Normals, for dynamic ambient-occlusion-like shading of static meshes. The demo i used there used a single model/mesh and did lighting in vertices. Also it was supposed to be used mostly for nearby lights.
In a recent post in the Indiegamer forums, a question was posted about using shadow maps (or other lighting methods) for the entire world for the sun. I thought that the Occlusion Normals method would work, with a slight modification to ignore the distance from the ray intersection point (the original method faded out the ray's contribution based on how far from the point we calculated normals for the intersection point was - after all, we didn't care about rays hitting stuff at the other side of the room).
Before i posted the message, i decided to try it out. So i modified my Runtime World 3D world editor's embedded lightmapper (in a new branch) to generate Occlusion Normal Maps which are basically lightmaps but with normals instead of colors. Also i modified the Java walker test that comes with the editor to use GLSL and wrote a phong shader that uses the method described in the article above. Basically, the shader does normal phong lighting with an extra couple of lines to fetch the normal (just a sampler call) and integrate it with the intensity of the light's contribution:
Here ocnormal is the occlusion normal at the point, lightnormal is the light's normal (we're talking about directional lights of infinite distance here), lfdot is the classic dot product between the light normal and the surface normal, odot is the dot product between the light normal and the occlusion normal and d is the strength of the light on the surface (1.0 is fully lit, 0.0 is not lit at all).
The result can be seen in the following video at YouTube:
and here are the occlusion normal maps as shown inside the editor (the editor simply displays them as lightmaps):
After a few years without a home, i finally found some time to put my 2005 game Nikwi Deluxe to some place where people outside of the Debian community can get it. Also i managed to make it compile under Mac OS X which required a few modifications.
Nikwi was my first commercial game but it never had any sales. It was released at a time where indie was almost equal to casual and platform games were scarce (yes, there was such a time :-P). After my Slashstone site went down, i never found some time to put my Nikwi Deluxe game anywhere else. People using Ubuntu or Debian could get it from the repositories, but Windows users had to look around for some archived downloads.
Today i was looking around my old PC's hard disk and found the code. So i decided to relicense it under zlib (from GPL) so it can be usable to other coders and put it on GitHub. Also i uploaded binaries for Windows, Linux (32bit and 64bit) and Mac OS X.
After ~7 months making (in a not really non-stop fashion) what i initially thought to not take more than one or two weeks, just a few minutes ago i uploaded the new version of Runtime World, my 3D world editor!
The site now contains versions for Linux (32bit and 64bit) and Mac OS X in addition to the Windows version. So, yeah, Runtime World can now be used by all three major desktop systems :-).
Ok, so what is new? Well, here is a (brief) list i posted in a couple of forums:
A multithreaded in-program lightmapper
Linux and Mac OS X support
Independently resizeable viewports
Java walker in the devkit (based on the She Loves You codebase)
Win32 and SDL-based viewer in the devkit
Solid rendering mode
Scripting via LIL (can also call scripts via the command-line which can be used for e.g. calculate light maps for a bunch of .rtw files and terminate - useful to let the computer do slow stuff over the night)
User entity support
Better user and developer documentation
A lot of bug fixes
A lot more things i don't remember
Here is also a collage of the screenshots from the site that i've made:
These last few days there have been a bunch of posts in Reddit's /r/programming subreddit about the Lua scripting language. As it usually happens, a lot of unrelated to the topic of the original post comments about Lua were posted in these posts. A common one was how easy it is for Lua to be embedded into C applications.
So i decided to show off about how easy is to embed LIL into C applications in just three easy steps.
Step 1: Have a program in C that you want to extend using scripting, preferably a program that you don't mind crashing at the middle of an important operation, like a Nuclear Reactor Controlling Program.
Step 2: Get this and this file from the LIL GitHub page. Ignore any mention of fixing crashing bugs in the logs, there are no crashing bugs.
Step 3: Write the following code to initialize a lil_t object which represents a LIL runtime:
lil_t lil = lil_new();
then write the following code to define a new function to expose in the program:
register the function with the LIL runtime so that scripts can call it:
lil_register(lil, "square", fnc_square);
execute some script code that uses the function so that all the above have a reason to be:
lil_free_value(lil_parse(lil, "print the square of 2 is [square 2]", 0, 0));
and destroy everything:
lil_free(lil);
Bonus: read the readme and the example REPL for more detailed information, especially if you do mind user scripts killing your program without it having a chance to react!
I hope that was as interesting to read as it was to write :-)
About a week ago i saw a post on Reddit about an article about HyperCard, a sort-of hybrid between a painting application (like MacPaint, which was made by the same author), simplistic database and hypermedia authoring tool. HyperCard uses a "stacks of cards" metaphor, based on the idea of a rolodex-like device that holds cards of a dynamic nature that contain links which perform actions, such as linking to another card, playing some sound or doing some calculation (the initial version of HyperCard before a scripting language was added - and before a public release was made - had only links between cards).
The article was a bit controversial because it had the premise that Steve Jobs disliked HyperCard and was against its philosophy, although that was proven wrong by the commenters on the Reddit post, noting how Steve Jobs had mentioned several times at the past how good HyperCard was (including a mention of a comment in Slashdot about the person who convinced him that Interface Builder was better). However personally i paid more attention to the pretty images in the article than the words surrounding them
Basically i had barely heard about HyperCard until a week ago.
And i liked what i saw. Immediately i searched around the web on information about HyperCard. For a supposedly popular program, there wasn't really that much information lying around. Most of it was blog posts from people reminiscing the good old times when Macintosh and HyperCard was all they were (with a couple of them mentioning how HyperCard crippled them because it was so good that they sticked with it and didn't looked how everything else was evolving so losing it was a cost to them) and dead sites with dead or dying links to other dead sites and stacks that haven't been updated since the 90s.
Also everywhere there was a comment box or editable section, there was someone from RunRev trying to promote LiveCode (which, used to be called Revolution and before that MetaCard - and all this renaming reminded me how Borland/Inprise/CodeGear/Embarcadero tried to get away from calling their products Pascal, first by renaming them to Delphi and later dropping the "Object Pascal" name from the language as if a tool by another name isn't still the same tool).
Anyway, among the stuff i've found there was an excellent (albeit a bit slow) introduction to HyperCard video from NOTACON 5.(a hacker conference that focuses more on the beauty, art and community of hacking - at least according to their Wikipedia page) by Drew Ivan and an episode of the computer show Computer Chronicles which featured HyperCard and with the guests Bill Atkinson and Dan Winkler (the author of HyperTalk, the scripting language that HyperCard used) presenting it. Also the WikiWikiWeb page on HyperCard was very helpful while trying to find information on HyperCard.
What i found was interesting. HyperCard was apparently used for the insanely popular game Myst (at least for the original Macintosh release), for keeping the inventory of the automobile company Renault, for a bunch of (non-game) programs published by the game publisher Activision, for a lot of educational multimedia titles and for many users it provided means for writing quick-and-dirty applications for their own personal use, like recipe lists, telephone books, etc. And like any easy to use visual authoring tool, there were a LOT of amateur (and sometimes, professional) games built with it. Also it was used a lot for quick prototyping of interfaces and programs, including at some point a "3D" interface that uses the three coordinates for sorting metadata. Even WikiWikiWeb which i mentioned above and was the father of the modern concept of wikis (such as Wikipedia) started as a HyperCard stack.
Apple itself had stopped the development of HyperCard in early 90s (a mid-90s demo that was presented was never finished) and so HyperCard wasn't only stuck in Macintosh systems, but also stuck in classic Macintosh systems. So one would expect that there will be at least one open source project to replicate what HyperCard offered.
And there are some HyperCard inspired projects, most notably PythonCard and xTalk (which is more of a hub for similar projects than a project itself). Unfortunately both of these two focus more on HyperTalk and ignore the visual aspect of HyperCard, which is what made HyperCard attractive and accessible in the first place. I can't say i find this surprising though given the general distaste that many open source (and some closed source) developers seem to have for visual tools (not just development tools, but developing visual tools and GUIs in general). There is also MacBird by Dave Winer, which actually does follow the HyperCard idea more faithfully than PythonCard and xTalk by providing a visual interface, but it is more a code dump of an abandoned project (there wasn't any updates since 2000 - that is 12 years ago for those who can do math) than a real alternative - and even if it was, it seems to be made for Mac OS 9 which as we all know, isn't exactly on the living side of things. Not that PythonCard looks much better (last release in 2006).
So, where are the modern open source HyperCards? One might say that there is no need for such a tool because The Web replaced it. To that i say bollocks (and balls and nuts and whatever else). While "The Web" is indeed more popular than HyperCard and it is based on the same concept of hyperlinking stuff around (like i did so many times so far), it lacks the ease of use for making things. Sure, for a user, it is about the same, but for an author as as different as it could be. And in HyperCard the user and the author was usually the same kind since making and viewing stuff in HyperCard were just two different modes of the same thing. No, it isn't the same. Even when using WYSIWYG web designing programs that try to do everything for you, like iWeb, there is a big difference in using and designing web pages.
And also there is the whole thing about the web having your files in some nebulous cloud instead of the safety of your local hard disk (assuming it is safe anyway). And we all know how safe are your data in the cloud.
Why would that be? Personally, i'll be a bit bad and say that this is just because most open source developers dislike working on visual programs - and some might even feel offended by working on visual development tools. We all know how much Visual Basic is loved, right?
Ok, that probably isn't the truth. After all there are hundreds of developers working on GNOME, Mono, MonoDevelop, KDE, KDevelop, Qt, Glade, etc and of course a lot of developers working on very visual development tools like Lazarus. Which means that actually i have no idea why there isn't any alternative (Gambas doesn't count, it is more of a VB clone and AFAIK doesn't work with Windows).
So basically i decided to take a stab in making something like HyperCard. Yes, the wall of text above was just to introduce my own take on the HyperCard cloning problem. Ladies and genlemen, i present you:
LILCard
(*thunderous applause*)
The originally chosen name is made up of LIL and Card, the former because instead of a HyperTalk-like language it uses my own LIL scripting language and the latter because most HyperCard clones seem to use "Card" at the end of their name - at least until the decide they do not want to be associated with it for some reason...
LILCard is open source and like almost every other piece of open source code i've written the last few years, it is released under the zlib license. It is written in FreePascal and Lazarus (an open source Delphi-like RAD GUI IDE tool which can be used to make applications for Windows, Linux, Mac OS X and possibly a bunch of others using native controls and stuff) and uses FPLIL, a FreePascal implementation of LIL. Also it uses a couple of other libraries i've written for FreePascal and Lazarus, namely ChunkIO for the extendable binary file format and LazHelp for the integrated help system.
I decided to use LIL because, well, i've made it and i think it is a nice little language. While it isn't exactly HyperTalk, i believe that it is (relatively) easy to read and simple to learn. LILCard has a simple introduction to LIL in its help site. Of course i could have used any other scripting language and anyone who feels so, is free to fork the project and replace LIL with something else. Almost all of LIL integration is in the scripting.pas unit, so this is the only part of the code that one would need to (partially) replace in order to bolt on his own favourite scripting language. FreePascal supports Lua out of the box and can use the Python DLL/shared object libraries directly.
I didn't really planned to use Lazarus initially (nor FreePascal - i used FreePascal because of Lazarus), but i wanted to be able to distribute a single executable file with everything inside without 3rd party requirements or runtimes in all platforms i wanted to support (Windows, Mac OS X and Linux) and i wanted to use native widgets where possible (GTK2 under Linux). So i would either reimplement the interface everywhere from scratch in C or use Lazarus.
And because of that, i chose Lazarus.
The development was relatively easy, if a bit mechanic at some parts. The biggest issue that influenced a bit LILCard's feature set (or lack thereof) was that i decided to use the native graphics API that Lazarus provides. The native graphics API is named that because it uses whatever the underlying widgetset provides for graphics and because Lazarus tries to be crossplatform and compatible (to various extents) with Delphi, the API is almost the same as the one used by Delphi since the mid 90s. That wouldn't be much of a problem (compatibility is awesome) if there wasn't a simple flaw: there is no API to work with the alpha channel. Or more precisely, there is no API to set the alpha for the current color.
Lazarus itself supports the alpha channel and alpha blending and all that stuff, it just doesn't expose it wherever you have to access colors. The reason is that due to its inheritance, Lazarus uses a type named TColor which is basically a 32bit value for 24bit color with a reserved 8bit part. The reserver 8bit part in Lazarus is used as a selector for special colors, like the default color for a button, window, etc. This is basically the same as in Delphi and because of that there is no room for an alpha channel.
Of course that doesn't mean that you can't do 2D graphics with full RGBA support in Lazarus. It just means that you cannot do it with the native API. FreePascal has the FCL-image package (part of the Free Component Library) which is a 2D graphics and imaging library (which Lazarus itself uses to load and save a variety of 2D image file formats) that fully supports RGBA colors and operations. The problem is that it supports them too much: it uses 16bit per channel and 64bit per color. This means that an image in FPimage needs twice the memory of an image in the native API (assuming full 32bit images - most images in the native API are 24bit images). And because FPimage favours compatibility and features over speed, it is much slower.
The biggest reason i decided to use the native API however was because i was familiar with it and because i could use fonts directly out of the box. With FPimage i would need to either use FreeType (and thus depend on some 3rd party library) or use the native API to draw the text in native bitmaps and pull them over to the FPimage bitmaps. Eventually if i want to properly support alpha blending, i'll need to use FPimage though (or write some custom leaner solution) and probably use that with OpenGL.
As a result of the lack of alpha blending support there is an important feature missing from LILCard that HyperCard had: the ability to draw on foreground cards. While LILCard allows you to draw on background cards, you cannot do that in foreground cards and thus you can't have scribbles or handwritten notes or signatures or whatever in foreground cards. Of course you can still have buttons and fields since those are drawn above the foreground image.
Talking about buttons and fields, the latter was a bit of a problem. Buttons are made using custom drawing code and LILCard's code is extendable enough so that new parts (controls/widgets) can be introduced fairly easy. But fields were more of a problem because i didn't really wanted to mess with text editing - and i'm not sure i could do it as good as the native text editing widgets of each platform do. To overcome this, fields are drawing themselves, but when a field is activated (focused/selected), a native widget for text editing with the same color, font, etc is placed where the field is so that the user can properly type text using the platform's conventions for text editing (and possible typing assistants - i'm not sure how Chinese input works for example). Lazarus has a key input event that provides UTF8 characters, so it might not be actually a problem, but i decided to play it safe for now. The experience isn't very polished because of the pop in/out of the text editing widget, but given the time i spent on it, i think it is ok.
Despite Lazarus and LCL being cross platform, there were a bunch of platform-specific issues. For example under Mac OS X/Carbon (LCL doesn't properly support Cocoa yet) the colors when creating a bitmap from memory had their red and blue components reversed. Also under Mac OS X/Carbon, some "preferred sizes" were not properly reported and because of that the controls were not properly positioned and needed some good ol' hardcoding. Under GTK2 the window frame wasn't taken in account when the main window size was set (but it was taken when the custom control used that size as the minimum size, so LCL does have support for it). Under Windows some events were fired in different order than the other platforms. And above all, only the Windows LCL backend implements the flood-fill algorithm (which is why the tool is invisible under Mac OS X and Linux).
Still with all the issues and the problems, i think that the positive aspects outweight the negative. Lazarus is a very fast tool to work with, the editor makes jumping around the codebase a breeze, the backends for the most part work fine and the whole framework (FCL/LCL) provides a ton of functionality. And with no weird external dependencies on DLLs and runtimes and without a crippled "managed" language - everything is fast native code .
The project is available since a couple of hours now (the time that it took me to write most of this blog post) in GitHub at https://github.com/badsector/lilcard. In the Downloads page you can find binaries (executables) for Windows, Linux (i386) and Mac OS X (32bit). As i originally wanted, the Windows and Linux binaries are self contained standalone programs: you download and run them as-is. The Mac OS X is just a DMG with a single application, but that is the normal case for all (proper) Mac OS X apps. Please note that i used UPX in the Windows and Linux executables to keep the size down (and have the downloads be small), so if your Windows antivirus complains, that is a false alarm. Although i've tried with Avast and Ad-Aware and they said nothing. So if yours does, go replace it :-P.
As a closing, here are two screencasts of me making a calculator and a telephone book in LILCard:
p.s. i forgot to mention that LILCard has an awesome embedded help system. Ok it isn't that awesome, it is just embedded in the program. That means that either you like it or not, you always have the documentation with LILCard.
With the GPU of my current PC being dead i used mostly my iMac the last few months. While Mac OS X is fine for most tasks, it sucks that almost all of my Steam library is unavailable. Also while i could work with the Mac/Carbon version of Lazarus and Runtime World, the truth is that the Lazarus Carbon backend is still in beta stage and won't see much improvement until after Lazarus 1.0 has been released. The Windows backend is currently much better.
And i want to make a new Runtime World release with the new lightmapper and other improvements. I mean, originally i planned to have this ready in a couple weeks and it took me almost five months :-P. And still no release. But while i plan on adding a bunch of new features soon, currently i am only going to do some cleanup on the existing features, the UI and update the documentation with the new stuff. I planned on rewriting the docs in LILArt so i can have them in both LazHelp and HTML formats, but i need to write the LILArt-to-LazHelp scripts first, which will take a bit of time.Since i already spent a lot of time on this version, i'm going to leave it for later. This way i can also improve LazHelp a bit.
So, i managed to fix the old Athlon64 i gave to my sister 3-4 years ago and recently she gave me back (the last year or so she uses exclusively a laptop). This is a machine i bought at late 2003, although it has been upgraded a bit since then to replace the single core Athlon64 with a dual core Athlon64 X2 and the GeForce FX 5950 Ultra was replaced with an ATI X1950 (which, IIRC, i bought at the time to play Bioshock - and i bought the card with the game at the same day :-P).
It isn't a speed demon, but it ain't bad. I haven't tried any modern-ish game, but i have a lot of oldies in my Steam account (and GOG) so i'll be fine :-).
Also, i started playing around with some new project:
This is just a mockup in Lazarus and may or may not have much of a future. After all, Runtime World's first version was four years ago and since that version there were at least two major rewrites from scratch (and maybe a couple minor rewrites i don't remember).
Well, i managed to finish my Ludum Dare 22 (a 48h gamedev compo) game just in time - 5 minutes before the deadline :-P. Also it probably is the first game i have finished since Rombo Rush. Although, obviously being made in only 48h, it lacks a bit on the polish department. And level design could be much better.
Anyway.
Here is the Ludum Dare database entry :-). If you have an an account and submitted a game, please vote (you can't vote if you haven't participated). Here are some screenshots:
So i just added user entities in Runtime World. Entities are defined using simple LIL scripts (ah, yes, i also added LIL scripting via FPLIL :-P) that look like this:
register-user-entity Player "Player Start" 40 70
register-user-entity Coin
register-user-entity Gun
The first parameter to register-user-entity is the name of the entity (what is stored in the world file), the second is the group (used by the interface only) and the rest is the size of the entity as it will appear in the program. If parameters are missing, some defaults are used. Currently not much else is exposed to the scripting runtime, but this is good enough for now. Later scripts will be able to define a static mesh to show, but for the moment only a box is shown to represent the entity in the world.
Here is how the entities look in the program:
I've also modified the Runtime World Walker i wrote in Java/LWJGL these days to load and render entities and add a bit of behavior to them. Here is a video with me walking around the map above with the Coin entities placed all over the place:
I just added a new rendering mode in Runtime World: Solid Mode! The button for this actually existed before that, but i used it for some debugging rendering that wasn't needed anymore :-P. So now the proper solid mode is available. Here is how it looks like:
It also looks like a nice non-photorealistic method to render game worlds :-P.
