Tuesday, June 9, 2009

Introducing Snagle

A little over a week ago I officially posted snagle , my new 2d/3d engine. Since then I've made quite a bit of progress.

So far the Engine features:

Common Math:
  • 2d Vector
  • 3d Vector
  • 4x4 Matrix
Graphics:
  • Vertex Buffers
  • Vertex Formats
  • Sprites
  • Textures
  • Colors
System:
  • Window setup
  • Keyboard and Mouse Input
  • Timers
I feel it is a good platform to expand upon and the basic foundation is done for the most part. Some things that I feel are needed to make the foundation done are:
  • State Management
  • Resource Management
  • Content System
Once those three features are done then it's only a mater of focusing on common features that most games will use. The biggest issue I have is that I don't know what people want, so I have been focusing on what I would like to see. The biggest reason for this blog post is to get feedback on what people think and shape the direction of it's future.

At this point I want to finish up some of things listed above before I spread the word about the engine too much however I encourage people to look at the wiki, browse through the source code and give feedback. The code is well document and is very presentable, if you don't agree let me know. Sending me feature requests, comments on my code, and general questions about the engine would be quite helpful. I hope to hear some feedback.

Sunday, May 31, 2009

Change of plans

Sometime when developing you come across an unexpected twist and new motivations. My latest "twist" is that for all intensive purpose the server part of my program is being put on hold. Trying to justify this with myself was hard because I feel that my only complete projects were ones I was forced to develop on the job. The new project I'm working on has several goals which I believe are more realistic then a "generic" mmo server.

Some of you may know about my 2d engine tutorial series on gpwiki.org . Since it has been released I've continued to get emails about it, more specifically how to compile/use the code rather than design. The whole purpose of those tutorials was to give people an idea of how to structure an engine rather than something to use. Some people have requested feature enchantments and others want to know when the next version is coming out. About a year ago I started on a new version of the engine. After awhile I was too busy at work and life in general and forgot about then abandoned it.

Since creating that project I've done a lot more engine design and coding and feel like it can be done better. Some of the bigger issues in my mind is that it uses immediate mode in OpenGL, which is slow and generally not that great to work with compared to VBOs and VAOs. The engine also isn't well documented nor structured in a consistent way and worst of all it carries some of my bad habits of using Get/Set in front of things where it isn't need and hungarian notation for private variables. I did delete the project but then the next day I decided that I will leave it up as a code sample and change the front page and license to reflect it's status.

So why the new engine? Besides the things listed in the last paragraph, I'm becoming more interested in modern graphics programming and 3D in general. I've done 3D and even a 3D engine for my current job however I haven't messed with modern features much such as VBOs, VAOs, shaders, FBOs which seem to be all the rage these days. Another big pushing factor for a new engine is to back-port what I do to my companies engine to make my life easier. Since my company is a startup I can really push the direct that the engine goes quite easily. The last point about the new engine is that it doesn't meaning that I have to give up the mmo idea, it just means I'm switching work from the server to the client. I still plan on making the server in scala as I feel it's suited well for that task but I also feel that C++ is better suited for the client (lack of game related libraries on java/scala).

Right now I've been working on the engine in my free time during the last week, I've put about ~15 hours into the project and feel it's coming along rather nicely. So far I've implemented input (keyboard, mouse), windowing, some math (vector2 & 3), vertex buffer formats, textures and vertex buffers. So far I feel that the VBO related stuff is the most interesting.

Right now the formats I support are:
  1. VertexNormalTexture
  2. VertexTexture
  3. VertexNormalColor
  4. VertexColor
They seem to be the common formats out there and if needed you can always plug-in your own formats if you want a custom one.

Here is the code for the vertex buffer:

/*
* File: vertexBuffer.hpp
* Author: Sean Chapel
*
* Created on May 30, 2009, 7:56 PM
* Copyright 2009 Seoushi Games. All rights reserved.
*/


#ifndef _VERTEXBUFFER_HPP
#define _VERTEXBUFFER_HPP


#include "vertexFormats.hpp"
#include "resource.hpp"
#include
#include "types.hpp"
#include "platform.hpp"


namespace k2e
{



/**
* A vertex buffer object that stores a fixed size of elements
*/

template <class T>
class VertexBuffer : public Resource
{

public:

/**
* A default constructor
*/

VertexBuffer()
{
}

/**
* A constructor with the number of elements and thier types
* @param numElements the number of elements to store
* @param type the type of vertex buffer
*/

VertexBuffer(unsigned int numElements)
{
SetSize(numElements);
}


/**
* Default destructor
*/

~VertexBuffer()
{
Dispose();
}

/**
* Sets the number of elements for the VBO
* @param numElements the number of elements to store
*/

void SetSize(unsigned int numElements)
{
buffer.clear();
buffer.reserve(numElements);
}

/**
* Adds an element
* @param v the element to add
*/

void AddElement(const T &element)
{
buffer.push_back(element);
}


/**
* Generates the buffer for use
*/

void Generate()
{
if(buffer.size() == 0)
{
return;
}

Dispose();

glGenBuffers( 1, &glId );
glBindBuffer( GL_ARRAY_BUFFER_ARB, glId );

glBufferData(GL_ARRAY_BUFFER_ARB,
buffer.size() * sizeof(buffer[0]),
&buffer[0], GL_STATIC_DRAW_ARB);

glUnmapBuffer( GL_ARRAY_BUFFER_ARB );
glBindBuffer( GL_ARRAY_BUFFER_ARB, 0 );

isResourceLoaded = true;
}


/**
* binds the buffer for use
*/

void Bind()
{
glBindBuffer(GL_ARRAY_BUFFER_ARB, glId);

T::SetupDraw();
}


/**
* Unbinds the buffer
*/

void Unbind()
{
T::TeardownDraw();
}


/**
* Implements the resource's dispose method
*/

virtual void Dispose()
{
if(isResourceLoaded)
{
glDeleteBuffers(1, &glId);
isResourceLoaded = false;
}
}

private:

u32 glId;
std::vector buffer;
};


} /* k2e */


#endif /* _VERTEXBUFFER_HPP */




If you noticed, every method is commented in doxygen format. It takes a lot long to code when adding all the comments up front but it also means that everything is documented as it progresses so people can actually use the code. All of my code so far has been commented like this and I feel it makes the code much nicer to work with and it makes me think of design before implementing something. When making my code I first design out all of the header file and make sure I'm not forgetting something then I'll comment the header then code. I find this method good pratice but it is more time consuming, fortunatly I don't have to hit crazy deadlines with this code.

Anyways about the code itself, you will notice it's templated which is something the kore2engine made little use of even though there are places that could definatly use it. It's also defined as a resource which means that I can easily have it managed by a resource manager (that's a topic for another blog post however).

Lets take a look at one of the texture formats that plug into the vertex buffer.


struct VertexTexture
{
/**
* A constructor that initializes all components
* @param position the verts position
* @param textureCoords the verts texture coordinatess
*/

VertexTexture(Vector3 position, Vector2 textureCoords)
{
this->position = position;
this->textureCoords = textureCoords;
}


/**
* Used for setuping up drawing with this format used by VertexBuffers
*/

static void SetupDraw()
{
int size = sizeof(Vector3) + sizeof(Vector2);

glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

glVertexPointer(3, GL_FLOAT, size, (char*)NULL + 0);
glTexCoordPointer(2, GL_FLOAT, size, (char*)NULL + sizeof(Vector3));
}


/**
* Used for tearing down drawing with this format used by VertexBuffers
*/

static void TeardownDraw()
{
glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
}


Vector3 position; /**<>
Vector2 textureCoords; /**<>
};


Nothing really too interesting, but it just goes to show how easy it is to make your own format.

So lets show some vertex buffers in use, in a simple application I'm using to test functionality and develop with I needed a hexagon grid. Here is the code to generate and draw a hexagon in a vbo.


HexGeometry::HexGeometry(float radius)
{
vbo.SetSize(8);

vbo.AddElement( k2e::VertexTexture(k2e::Vector3(0.0f, 0.0f, 0.0f),
k2e::Vector2(124.0f / 256.0f, 112.0f / 256.0f)));
vbo.AddElement( k2e::VertexTexture(k2e::Vector3(-radius/2.0f, radius, 0.0f),
k2e::Vector2(67.0f / 256.0f, 8.0f / 256.0f)));
vbo.AddElement( k2e::VertexTexture(k2e::Vector3(radius/2.0f, radius, 0.0f),
k2e::Vector2(189.0f / 256.0f, 8.0f / 256.0f)));
vbo.AddElement( k2e::VertexTexture(k2e::Vector3(radius, 0.0f, 0.0f),
k2e::Vector2(249.0f / 256.0f, 112.0f / 256.0f)));
vbo.AddElement( k2e::VertexTexture(k2e::Vector3(radius/2.0f, -radius, 0.0f),
k2e::Vector2(189.0f / 256.0f, 218.0f / 256.0f)));
vbo.AddElement( k2e::VertexTexture(k2e::Vector3(-radius/2.0f, -radius, 0.0f),
k2e::Vector2(67.0f / 256.0f, 218.0f / 256.0f)));
vbo.AddElement( k2e::VertexTexture(k2e::Vector3(-radius, 0.0f, 0.0f),
k2e::Vector2(7.0f / 256.0f, 112.0f / 256.0f)));
vbo.AddElement( k2e::VertexTexture(k2e::Vector3(-radius/2.0f, radius, 0.0f),
k2e::Vector2(67.0f / 256.0f, 8.0f / 256.0f)));

vbo.Generate();
}

HexGeometry::~HexGeometry()
{
}

void HexGeometry::Draw()
{
vbo.Bind();

glDrawArrays(GL_TRIANGLE_FAN, 0, 8);

vbo.Unbind();
}


The engine I wrote for my company would have been atleast three time as long because in that engine I decided to separate each component into their own buffer and force using an index array even if they were in order like above. Also at the moment that engine can only use GL_TRIANGLES, which made it easier to implement and use but less efficient along longer to setup. Overall I think this is pretty nice. Here is a screen shot from my test app with a grid of hexagons drawn with the above code.



Next time I'm unsure of what I will share and talk about, perhaps the resource manager would be a nice next step or possibly 2d graphics (My test app needs a gui).

Also I'm sorry about the code formating, since html ignores whitespace it makes it a pain to mess with. I've been using http://quickhighlighter.com/ and it looks great on their servers but this blog seems to mess it up for whatever reason, if someone has an idea on how to fix this let me know. Soon enough I'll publish all my code somewhere and I can just give links to a well formated html version.

Thursday, May 14, 2009

A Simple Server in Scala

Surprisingly enough there isn't much information regarding using sockets, scala and actors together. I figured that something like this would be quite wide spread however I found it straight forward to create. I took my knowledge of actors and then followed some sample code for Java sockets.

Right now all the server does is listen for connections and print out what clients send to it, nothing special. There are some downsides to the way I'm doing things. The actor class by default spawns it's own thread which can get ugly fast however it is easy enough to convert over to coroutine like behavior. The reason I haven't done this yet is because I'm not using select to see if there is data so waiting for one receive or in this case line would block the whole thread and that wouldn't be nice. Anyways here is my code.


  1. package stdServer
  2.  
  3. import java.io._
  4. import java.net.{InetAddress,ServerSocket,Socket,SocketException}
  5. import scala.actors.Actor
  6. import scala.actors.Actor._
  7.  
  8.  
  9. object Server
  10. {
  11.   def main(args : Array[String])
  12.   {
  13.     val port = 6669
  14.    
  15.     try
  16.     {
  17.         val listener = new ServerSocket(port)
  18.         var numClients = 1
  19.  
  20.         println("Listening on port " + port)
  21.        
  22.         while (true)
  23.         {
  24.             new ClientHandler(listener.accept(), numClients).start()
  25.             numClients += 1
  26.         }
  27.  
  28.         listener.close()
  29.     }
  30.     catch
  31.     {
  32.         case e: IOException =>
  33.             System.err.println("Could not listen on port: " + port + ".")
  34.             System.exit(-1)
  35.     }
  36.  
  37.   }
  38.  
  39. }
  40.  
  41.  
  42. class ClientHandler(socket : Socket, clientId : Int) extends Actor
  43. {
  44.   def act
  45.   {
  46.     try
  47.     {
  48.         val out = new PrintWriter(socket.getOutputStream(), true)
  49.         val in = new BufferedReader( new InputStreamReader(socket.getInputStream()))
  50.      
  51.         print("Client connected from " + socket.getInetAddress() + ":" + socket.getPort)
  52.         println(" assigning id " + clientId)
  53.      
  54.         var inputLine = in.readLine()
  55.         while (inputLine != null)
  56.         {  
  57.             println(clientId + ") " + inputLine)
  58.        
  59.             inputLine = in.readLine()
  60.         }
  61.  
  62.         socket.close()
  63.      
  64.         println("Client " + clientId + " quit")
  65.     }
  66.     catch
  67.     {
  68.         case e: SocketException =>
  69.             System.err.println(e)
  70.      
  71.         case e: IOException =>
  72.             System.err.println(e.printStackTrace())
  73.          
  74.         case e =>
  75.             System.err.println("Unknown error " + e)
  76.     }
  77.   }
  78. }
  79.  
  80.  


One of things I like about this code is that it shows off mixing Java code with Scala. If you haven't noticed it fits right in and you can't really tell that there is Java embedded.


I also wrote a version of this code with Scala's remote actors however it seems limiting. When I tried to connect to telnet and typed something my server instantly crashed with an out of memory error. I'm guessing that remote actors only can only talk to each other which means that I would have to learn the protocol that it is using and mimic it in my client thats not written in Scala and then hope no one tried to use telnet on it. I'd rather just use normal TCP/IP sockets and know that it will work with pretty much anything.

Well thats it for now, next time I hope to have an non-blocking version of this code with concurrent actors and perhaps some basic functionality.

Tuesday, May 12, 2009

Prototyping the MMO

So five days or so have gone by since I last posted on the MMO server development. Like (almost) all personal projects things are going slow but some progress has been made. I started making a server in python and using telnet for testing. I got as far as having multiple clients being able to connect, clients sending a user name/password (simple text strings) and the server telling the client if the authentication was correct by using a text file as my database. It worked well enough even though the sockets were blocking and synchronous, I didn't really care about scalability nor performance as it was just a prototype.

Being the language nazi I am, I found python not to my liking. First I will state some of the things I do like just to be fair.
  1. Indentation instead of brackets.
  2. No semicolons at the end of lines.
  3. Very feature rich set of common functions/tasks.
  4. No compile times.
  5. An interactive console (I miss this in most languages ever since I started playing with lisp/scheme).
  6. Good documentation and beginners guide.
So now for the things I didn't like.
  1. Classes are littered with self because they aren't real classes but rather namespaces.
  2. Global variables have nasty names __init__, __main__ for example.
  3. The state of flux between 2.5, 2.6 and 3.0. Most libraries are still only usable with 2.5 and then some of the bigger ones work with 2.6 but 3.0 is "virtually" unsupported which is shame.
  4. Lack of type annotations when wanted, for example I would love to be able to require that functions only accept and return certain types. This is just a drawback of dynamic languages for the most part however.
  5. Spaces and not tabs. Why people prefer spaces over tabs alludes me, tabs allow you to move around faster with the arrow keys and allow you to setup your preferred spacing. Mixing tabs and spaces is silly however as it will never look right between different computers. (let the religious wars begin)
Now most of these "cons" are just my opinion and I could probably live with them however #3 really annoys me. Once I got up my simple server I wanted a graphical interface for logging on my server and I decided to use wxWidgets except it only supports 2.5 and 2.6 (sort of). The reason I said sort of is because it actually doesn't work on 2.6 on windows because of some gui dll conflict, at least thats what google had to say. It ended up crashing anytime I moved my mouse over a very simple window. Hopefully this will be fixed in the future but it really makes me wonder about the state of python on windows in general. Windows seems to be a second class citizen in general when it comes to programming languages that are either open source or non-mainstream.

I decided to not take the risk and I started writing equivalent programs in other languages. I made a server in C# with async sockets and I really just didn't like the feel of it. I also made a version in C++ and boost.asio which I liked better than the C# version but I know that C++ will just lead to headaches later on and isn't a good prototyping language. Not being satisfied with either solutions I decided to re-look at some of the languages I skimmed over for one reason or another. In conclusion Scala is my next choice for prototyping a server with.

I looked over some of the beginning docs and I liked what I saw so I picked up "Programming in Scala". So far I'm only at chapter 7 however I really like the way the book is written and how material is presented. Most computer science or tech books bore the crap out of me but for whatever reason I like PinS. So what drove me to taking a look at Scala?
  1. The mix of function, imperative and object oriented paradigms.
  2. Having an actors library for concurrent processes in the same thread.
  3. Statically typed with type inference and the option to declare types if you want.
  4. Runs on the JVM and mixes well with Java (cross-platform goodness).
  5. Short concise programs, much like python is compared to C like languages
  6. The syntax is extensible and makes DSLs easy to create
  7. A familiar syntax without many odd operator symbols for everything.
In feel like Scala is mostly related to OCaml however with an object system that people actually use, mixed with Haskell except without forcing you to be purely functional and odd syntax choices. Of course it gets its influences from other languages as well.


Next time I hope to be able to post some code and my experiences with Scala.

Monday, May 4, 2009

New Project

So I haven't updated my blog in awhile, I'll talk a little bit about languages I've been messing with then I'll move into my new pet project.

Haskell was the last language I posted about and pretty much nothing has changed in my mind about it. It is a neat language and I hope to use it more some day however monads have really turned me off for the moment. Why have monads turned me away? Well it's actually quite simple, being a game programmer in C like languages I'm use to state and monads just makes it either more difficult, painful or ugly compared to the "C" way of doing it. There is always functional reactive programing which is suppose to be the new "cool thing" for programming in Haskell however I just don't feel like learning them as the concept is quite academic (like a lot of things in Haskell) and not really proven for game development yet. So to conclude I like Haskell as a language and it brings on some neat ideas however for game programming I'm having a hard time accepting it.

After I looked at Haskell I stumbled upon factor. Factor is a neat stack based language derived from Forth. I really liked how simple it was, push stuff on the stack then push a function that read the previous stack items and put the result on the stack. It seemed a lot like functional programming but a bit different. I really loved the idea of an image based programming language, basically what that means is that the programming language, libraries and programs are contained in an image file. What this means to the user is that it's very simple to import/include other modules as the programming language knows about everything in it's image. It also makes it painless to add new modules to the image, no need to worry about system paths and the such. As I worked with the language I just couldn't get my brain trained to think in the way factor wants you to (basically backwards or postfix). Because the language is stack based it depends what is already on the stack meaning you really don't pass arguments to a function it just reads from the stack. Also it reads the variables on the stack from back to front meaning it seems backwards in that way as well "push 3; push 4; +"(pseudo code). you would think that this translates to "3 + 4" if it was converted to infix but it's really "4 + 3". This seemed to cause me pain when coding, it made comprehending the code harder. I thought it would get better with time but I gave it a week of coding in my spare time and I felt no better than when I started. Curiously I looked around about factor and according to other blogs some guys had been programming in it for over a year and still are having the same problem I am. I decided that I will look at the language at another time.

Given all the languages I've looked at I got somewhat burnt out on looking for something to replace C, I decided I'd rather just make something. I decided up front that I wanted to make something that deals with networking as I haven't explored that area like I have graphics, sound and general game programming. Networking is becoming more and more important for game developers, it's getting harder to sell single player games and not having much experience with it I feel lacking.

So what did I decide on? I decided I want to design an mmo server. I'm unsure how far I will get with this but I do know I will take away some good knowledge from it. Right now I'm in the planning stages, designing protocols, server layouts and road maps/feature lists on how I will develop it. If your interested in this then I'm keeping all the information at my site here. Being a game programmer and having used C/C++ extensively, I naturally decided to use C++ for my language of choice without really considering my options. Upon doing research I came across Eve Online and surprisingly they use (stackless) python of all languages, this really surprised me because of how slow it is compared to C and how it had to handle tens of thousands of connections at a time (I believe peak is arround 50-60k players all on the same world). Also while I heard of python before I hadn't heard of stackless python. Apparently stackless is a modification to regular python for continuations, coroutines and talking between coroutines.

Now I saw why Eve could handle so many players at once. Still I wasn't exactly convinced python was the right choice so I started looking at other languages like erlang, boo, scala, clojure and even C#. I'm sure all those languages would work for an mmo server as well but besides from C# those are relatively obscure programming languages and if I ever wanted help (on the project, not in general) I probably shouldn't choose them. I then looked into the state of mono on the mac as that is my work machine and if it didn't work well at home and work then I didn't want to use it. I have to say mono has matured quite a bit since I last looked at it (over a year ago) however monodevelop still lacks a debugger and the coroutines that were recently hacked in were a hack that only mono has (.net doesn't support them) and the memory usage was almost double that of stackless python. So I've come to the conclusion that stackless python while it may not be the end result it will be good enough for prototyping and if I really need speed I can always extend with C.

I also must thank Richard Tew (for his posts on gamedev), the Eve Online developers (for their video presentations and developers blog) and lastly the other peoples that responded to my thread at Gamedev.net for helping me come to my conclusions on the subject so far.

In conclusion I've started work designing an MMO server/client and hope to have something to show for it in a couple of months. Lastly I've decided to start using twitter again for the sole purpose of letting people know about my latest developments on the MMO and this blog. You can follow me as Sean Chapel if your interested.

Sunday, March 22, 2009

Response to Reddit

So my blog got posted to reddit not too long ago and I got some comments from there and a few on my blog as well. I would like to take a few minutes to respond to a few comments then continue on like normal.
The silliest comment I got was that "he is trying to learn Haskell by installing an IDE", while I did talk about both learning Haskell and installing the Leksah IDE I didn't give any hint to learning by installing an IDE. If you want to know how I've been learning then skip down to the next section.

The other posts were mostly about how either I had given up on scheme from lack of an IDE or saying I didn't need an IDE. I can agree I don't need an IDE however I like them and this being my hobby language (nothing in the foreseeable future will replace C at work) I would like to have one. The main reason I'm not looking to into scheme anymore isn't because of a lack of a good IDE anyways, it's the lack of community and not enough program structure (parenthesis get hard to read quite fast).

There were also a few posts about my emacs comment. Yeap I did make it a little flame prone but all I really said was that emacs isn't for me and I don't see how other can get along with such primitive tools. The command line is great for some things but as an editor/IDE it's not very well suited for the task.

Learning Haskell

I have been reading the "Real World Haskell" online book and am currently on chapter 4 (been taking it slow in my free time). So far I really like the book, most things are easy to understand and laid out well but for those that aren't the comments do help. I quite like the idea of a comment system for continuous improvement of the book, it gives the author feedback on things that they didn't think about and those who read the book a better understanding when they get lost. There are a few places in the book where I feel it jumps too much or the exercises are either using something that hasn't been covered (ex: importing modules took a bit) or have an abstract concept that most people don't deal with (ex: convex hulls). Overall I feel like I am learning a lot of fun new stuff and most of the content so far as been great.

On another note, I have decided what I will be making in the meantime as a learning/test program. A simple bug tracker application is what I plan on writing. The first iteration will just be design and a simple command-line utility for adding and querying bugs and then from there I could branch out to databases and/or a gui.

Tuesday, March 17, 2009

Haskell

So I've been messing with scheme for little while now and I have a few things to report. Gambit-C and Chicken Scheme are quite fast, fast enough for real time games or any other application I want to develop. Of course that probably isn't news to anyone who uses either of those implementations of scheme. The C FFI on both is quite easy to use, which is nice. The biggest thing that the language is lacking is a good IDE, sure there is emacs if your twisted, like to memorize a bunch of commands and work with an odd interface made for computers before windowing systems were invented but I don't fit into that group. There are some real IDE's as well, such as schemeide and theschemeway however both are based on eclipse and I had issues getting both running. I wasn't really impressed by either of them however. The last ide if you can call it that, is Dr Scheme with PLT scheme, it's ok but quite slow compared to the implementations I preferred and I didn't really like it very much.

That being said there is nothing wrong with scheme however the community support is somewhat lacking. The irc channel (#scheme on freenode) while there are quite a bit of people there, many are away and no one really says much of anything (common in irc I guess). I did say a few things in the channel and the people are generally nice and helpful and pointed out quite a few resources for learning.

In Comes Haskell

The lack of a good ide and community support have lead me searching for something new again. Through out my looking for languages haskell has popped up quite a bit. I joined the haskell irc channel just to see what happens there and to my surprise it's quite busy most the time (busy enough that I don't want to read all the chatting that goes on). The next thing I looked at is an IDE, there are quite a few out there although most of them seem dead. The last thing that really won me over is the great amount of packages that are easy to install.


The IDE that looked the best to me was leksah. It is fairly new but looks to have a good feature list and is in active development. The installation was a bit of an issue on ubuntu 8.10 because they tend to use older packages. GHC, the main compiler for haskell, was only 6.8.x in ubuntu and the current is 6.10. Unfortunately ghc 6.10 requires a newer version of glib than ubuntu has as well and if you have ever tried to update glib on linux you know what a pain it can be. Anyways I decided to switch to OpenSuse 11.1, it's packages are more up to date than ubuntu's and is easy to install/maintain. Once up and running with opensuse I only ran into one issue with getting leksah running and it was my fault for not looking hard enough for a manual/install guide. For others who want to install leksah, here is a simple install guide (thanks to J├╝rgen for the help).

Open up the package manager and install the following packages:
  • glib-devel
  • gtksourceview2-devel
  • make
  • gcc
  • g++
  • ghc
Next you want to install cabal-install
wget http://www.haskell.org/cabal/release/cabal-install-0.6.2/cabal-install-0.6.2.tar.gz
tar -xvjpf cabal-install-0.6.2.tar.gz
cd cabal-install-0.6.2
./bootstrap

Now you need to install gtkhs
wget http://downloads.sourceforge.net/gtk2hs/gtk2hs-0.10.0.tar.gz
tar -xvjpf gtk2hs-0.10.0.tar.gz
cd gtk2hs-0.10.0.tar.gz
./configure
make
sudo make install

Make sure that gtksourceview2, glib and gtk all say "yes" after you do "./configure", otherwise you have missed installing one or more of the packages above.

The last thing you will want to do is add cabal to your path. My ~/.bash_profile looks like this:
PATH=$PATH:/home/sean/.cabal/bin
export PATH

If you change your path you will have to restart X to make it apply automatically or you can type
source ~/.bash_profile
each time you open a new terminal until you get a chance to restart X.

Finally we are ready to install leksah.
cabal update
cabal install leksah
Once you are done, just type "leksah" to run it.

I'm still playing with the IDE and it seems good so far but it looks like you have to make your own cabal package before you get started working on something and some of the dialogs seem a bit rough or I don't know what they are looking for exactly. I'm going to look over the manual and see how I like it.


To summarize a bit, I'm trying out new things again and Haskell seem to be the most mainstream functional language out there at the moment with quite a bit of support and community.

Saturday, March 14, 2009

Small Update

I've mostly been busy with work, perhaps I will talk about that a bit. At my work I develop iPhone games, for the most part I like it. The iPhone is a good platform for development not because of the SDK or the IDE but because it is an embedded device that feels like programming for a computer. What I mean by that is that your not really limited like most consoles, you have tons of ram (128mb), you have language choices (c, c++, obj-c), the processor is pretty fast (620mhz arm?), it has a floating point unit (good for 3d), has 3d hardware acceleration supported by OpenGL ES, it also has OpenAL. So overall it feel like I'm just programming for an older computer. The best part about this is that the device is standardized meaning that you can tune your program for the hardware and know it's going to run the same on everything.

So what am I doing at work? I can't give out specifics however I have developed two projects and updated a third (only been there three weeks). Recently however I've been moved off making games and focusing on making an engine since unity has quite a few issues (random hickups, large application sizes and overall buggy experiance). So far I've done some nifty things and learned quite a bit. The biggest hurdle right now is 3d, while I have dabbled in it quite a bit I usualy only use OpenGL for 2d. Luckly I know the math and general ideas, I am just lacking the experiance and some of the common "gotchas". So far I have a nice scene graph system going, 3d static models and 3d skeletal animations (I think thats quite good for a week of work).

My first approach to making the engine was in C++. I somewhat like C++ even tho it's not a very modern language. It allows me to access the machine directly for performance when needed, class/namespaces are decent for organization (although my thoughts on these change quite a bit), it has a good standard library and boost adds most everything else missing from the STL. For these reasons I wanted to go with C++ however, I ended up going with straight C.

Why straight C? C is more portable and it has been requested of me to make it portable in case we decided to branch out to other platforms. C doesn't suffer as much of a performance hit as C++, sure you can use C in C++ however it takes away from the point of C++ being a higher level language and you can't enforce people not to use virtual class, inheritance and other things that are slow and common in modern C++. Also like I've said C is more portable, gcc is good but it's not on all platforms. I've worked on other embedded devices which claim to have a C++ compiler but all they really add are classes and many things are either different or broken between compilers. The last reason I have for using C is the ability to use another language for the main game code and C for the base engine (yes scheme is on my mind), it seems there are quite a few languages that can compile to C, use C libs and many scripting languages work better/more supported with C.

Anyways enough of the flamewar, hopefully this should be enough to hold people over until I get more time to play with scheme.

Wednesday, March 11, 2009

SDL fun

So I've been playing a little bit with the SDL egg for chicken scheme. Most of the commands are pretty much the same except they replace underscores with hyphens, everything is lower case and camlHump notation is split up by hyphens. There were a few things that were different however, like in the case of SDL_pollEvent(SDL_Event* e), it follows standard scheme notation and uses a bang "(sdl-poll-event! event)". Overall it was easy to find what I wanted by looking at the SDL API docs from libsdl.org. For the functions I knew the name in C and could not find in the egg, I either loaded up my program in "csi" (the scheme interpreter) and guessed or opened the sdl.so that chicken created and searched for parts of the function name.

I can't say that writing this code in scheme is any easier than writing it in C, however I also haven't gotten to anything complex yet. Anyways here is the code I wrote.

(use sdl)

;; makes the screen to draw on
(define (make-screen width height)
(sdl-set-video-mode width
height 0
(+ SDL_HWSURFACE
SDL_HWPALETTE
SDL_DOUBLEBUF)))


;; makes a rectangle that is the size of the surface
(define (rect-from-surface surface)
(make-sdl-rect 0
0
(sdl-surface-width surface)
(sdl-surface-height surface)))


;; draws a surface onto another surface given an x and y
(define (draw-surface src dst x y)
(sdl-blit-surface src
(rect-from-surface src)
dst
(make-sdl-rect x y 0 0)))


;; handles a game event, returns false if the user wants to quit
(define (handle-event event)
(define event-type (sdl-event-type event))

(cond
((= event-type SDL_QUIT) #f)
((= event-type SDL_KEYDOWN) #f)
(else #t)))


;; starts up the demo and doesn't quit until a key is pressed or the window is closed
(define (run-demo)
(define ryu (img-load "ryu.png"))
(define event (make-sdl-event))
(define screen (make-screen 1024 768))

;; draws the ryu sprite and then flips it to the main screen
(define (draw screen)
(begin
(draw-surface ryu screen 200 100)
(sdl-flip screen)))

;; polls all events
(define (update)
(if (sdl-poll-event! event)
(if (handle-event event)
(update)
0)
(begin
(draw screen)
(update))))

;; start the main loop and clean up afterwards
(begin (update)
(sdl-free-surface ryu)
(sdl-quit)))

(run-demo)



I tried to make it a bit more functional than just throwing everything in a big (begin ) statement but since drawing graphics requires side effects its not an easy thing to do. If you can't follow the code, all it is doing is loading up a picture of Ryu (guy from street fighter) and drawing it to the screen, upon pressing a keyboard key or the window close button the program exits.

When making this application I did most of the things I wanted from "csi" then pasted them into scite for the things that worked. This interactive level of development was nice however it is probably not possible anymore the way I am doing things. Since the update loop is being called infinitively many times until the program is quiting it won't reach the top level for more input. I have a few ideas of getting around this but none of them are really ideal, the best one being an in-game console that would act like csi. Another more complicated idea is to have a client/server architecture and the game would evaluate the code sent to it in a que like fashion.

The last thing I tried was to compile the code. The chicken scheme compiler is "csc" and it works much in the same way as gcc does. To compile the code all I has to do was "csc sdlDemo.scm" and it spit out "sdlDemo" which is a binary executable with no dependency on chicken. I do love the compiler, most notably it knows what libraries you have used so you don't have to tell it what to link to. The program runs just fine and the executable is only 25k (a lot less than I expected). I haven't tried doing any performance tests on the program but from looking at it in "top" (tells cpu and memory usage of all running programs) it looks to be about what I expected.

So far, so good. Nothing really new came from scheme but I didn't have to do as much memory management as a C version, I didn't have to deal with pointers and I feel the code is more concise and easier to follow. So now my goals are to start some work with OpenGL, look into what OOP means in scheme and see how multiple source files work together.

Tuesday, March 10, 2009

Found Something, maybe

For a long time I've been searching for a language to replace C/C++ for the majority of my development but I've never stuck to one language for every long. There was always something I would find out about the language after messing around with it for a bit that I knew would get in my way later on in development. Personally I was looking for something that compiled to native code for speed, low memory overhead, portability to embedded devices and most of all easy compatibility with C so I can use good libraries/APIs like OpenGL and OpenAL or rewrite some of the slow parts of my code in C if needed. OCaml almost fit this bill but I just couldn't get over the weird syntax and I keep running into issues with it on OS X.

Now, while I have used scheme before, mostly while I was at the university (PLT/ Dr Scheme), I always thought of it as a learning language and nobody used it or could use it for real world coding. The more I dug into finding a new language, scheme kept popping up every now and then so I decided to take a closer look. To my surprise there were quite a few other implementations I didn't know about, of those were Gambit-C and Chicken Scheme that stood out to me. The main drawing factor was that they both compiled to C, could call native C easily and could be called from C.

I first started with Gambit-C as I found benchmarks that said it was the fastest one of the two, I don't know if those benchmarks were biased or still held true for the current releases but I figured it was worth a shot. I started messing around with Gambit-C and it was quite fun but when I decided that I wanted to give some game programming a shot I noticed that there were very few libraries and support in general. I decided to investigate Chicken Scheme to see if it was any better, I found out it has its own package manager with tons of "eggs" (what they call a package). Of those packages people had already created interfaces for SDL, OpenGL, OpenAL and a ton more of things I found useful. Needless to say I switched over to Chicken Scheme, it seemed to have more support and at the very least I could use all the existing packages.

The one thing about scheme that somewhat bothers me right now is the syntax. There are tons of parenthesis but I understand why because of S-expressions and I think I will learn to tolerate it (after all I did get use to OCaml). I'm tired of language hopping for now so I decided that I will at the very least write a game or two in it and see where it takes me. I've also decided that I want to semi-document things. I haven't decided what exactly that means but at the very least I plan on throwing together some tutorial-esque posts with some source code to go along with it. I'll say this right now however, I know I'm not a good scheme/functional programmer (yet) so if you see something weird or I'm over complicating things, I probably am (feel free to point it out to me).


Setting up your Environment

I've decided to use Ubuntu Linux for development. My main reason are:
  • Package management is easier than windows for development.
  • The windows command line sucks and many scheme implementations use the command line for normal tasks.
  • My vista installation doesn't like OpenGL (yes I have the latest amd/ati drivers)
  • I miss alt-f2 to run a program by name

In other words, personal preference :). If your following along on windows I highly suggest you either get cygwin or msys and friends up and running on your system, it will make things a lot easier.


Installing Chicken Scheme

The latest version in 8.10 is 2.5-1 which is extremely old, the current stable release as of right now is 3.4 . The semi-good news is the next version of Ubuntu will have a more updated version 3.2.7-2 which is more acceptable but not ideal. I installed these packages on 8.10 without any issues. You can grab all the files needed through launchpad (just get the .deb files on these pages:

(for amd64 processors x86-64)
amd64 - libchicken3/3.2.7-2
amd64 - libchicken-dev/3.2.7-2
amd64 - chicken-bin/3.2.7-2

(for i386 processors x86)
i386 - libchicken3/3.2.7-2
i386 - libchicken-dev/3.2.7-2
i386 - chicken-bin/3.2.7-2

Make sure to install them in the order listed, if you don't then it will complain about a missing dependency.

Next feel free to try out chicken scheme, I made a simple little fib program (seems to be the "standard" example for lisps).

(define (fib x)
(define (fib-helper x y)
(if (= x 0)
y
(fib-helper (- x 1) (* x y))))
(fib-helper x 1))

(print (fib 5))


Save off to a file named something like "schemeTest.scm". Now open up the command line and navigate to where you saved the file and type "csi schemeTest.scm" or whatever you named the file. You should see it print out something like this:

sean@sean-linux:~/programming$ csi schemeTest.scm

CHICKEN
(c)2008 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 3.2.7 - linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables applyhook hostpcre ]
compiled 2008-11-05 on debian (Linux)

; loading schemeTest.scm ...
120
#;1>


Pressing ctrl-d will exit out of the interactive console.

Hopefully everything will be working now. Next I want to install SDL and OpenGL for game development. Through synaptic/the package manager install libSDL-dev libSDL_image-dev libSDL_net-dev libSDL_gfx-dev libSDL_mixer-dev . Once those are done installing open up a command line and login as root ("sudo su"). type "chicken-setup sdl" then "chicken-setup opengl". If you get errors then usually it will say something to the effect of "couldn't find header file 'sdl.h' ", that means you should search in synaptic and install the -dev version of the file needed (however you shouldn't run into any errors).

The last thing that I recommend is a decent editor for your source code. There are a few choices out there, emacs seems to be the preferred environment however I don't feel like learning all the commands of emacs and I want more of UI based editor. I decided to go with scite, it's quite simple but it has all I need, syntax highlighting, code folding, parenthesis highlighter and auto indentation. Once you have everything setup you should be good to go for development.

While I don't plan to teach scheme, I do think it's a good idea to show some example code and hopefully people can follow along. If you don't know scheme at all I recommend visiting here and get a brief overview. Another good resource is http://mitpress.mit.edu/sicp/ , it is an online book with exercises to test your knowledge.

On a closing note, I doubt that I will be posting back to back like this again. The main reason for the fast post is because I had this post in mind when starting my blog. The last post was mainly just an introduction and a repost of something I had written previously that related to this post. I hope to keep this updated somewhat regularly but I'm making no promises.

The Ramblings Begin

Since this is my first post and I assume no one knows who I am, so a little introduction seems necessary. I am Sean Chapel a professional game programmer. I've been a programmer for about a decade now and have been creating games for about 3-4 year with the last two years being a professional. I've programmed for Windows, Mac, Linux, Nintendo DS and the iPhone. That should be enough of an introduction to know where I am coming from. For my first post I figured I would take something older from my site that will lead me into my new series of posts.


The Search for Something New

Originally posted on December 14, 2008.


Ever since I became familiar with programming in C/C++ I've been searching for a new language and unfortunately nothing has stood out as a "replacement". Among the languages I've learned or looked at are Ruby, C#, Obj-C, Java, OCaml, F# and Scheme/Lisp. I really like the idea of functional languages, they offer a lot of power and are aimed more at how to do things rather than dealing with syntax or language features. Of the language I've messed with Ruby, OCaml, Obj-C and C# stood out for various reasons.

Before I go into deal about the languages perhaps I should tell what I want to do with programming. Being a professional/(and hobbist) game developer (recently released "My Japanese Coach" and "My Chinese Coach" for the DS) I am looking for something for game development. Requirements are that it allows some sort of 3d API(OpenGL?), 3d Sound API (OpenAL?), Windowing, input and be fast enough for decent game without too much hacking. The most important thing I value is that the language is cross-platform (Win/Lin/Mac), the reason being is that I use all three and it increases my target audience.


Ruby

Ruby I knew was going to be slow from reading about it and I was right but it's a good little language. I ended up using gosu which was nice but awkward at times. I liked Ruby quite a bit besides it's sometime odd syntax and even ended up making a meteors clone in it (only took 2 hours :) ). The short development time was mostly due to Ruby having a lot of functionality in little code, the big core library was nice as well. Ruby was also easy to follow and learn. I will consider Ruby in the future for scripting but as far as games goes it was just too slow unless I was to use the foreign function interface with C libs for most of the code which defeats the purpose.


OCaml

OCaml I had heard quite a bit about and that it had roughly the speed of C/C++. OCaml defiantly has some odd syntax and it does turn me off but it was easy to learn and follow. For OCaml I used ocamlgl and ocamlsdl, they worked well on windows and Linux but getting ocamlsdl to play nicely with OS X was a pain because of the way SDL works (read more in my OCaml articles). The biggest thing about OCaml for me was that it was my first real functional language but also allowed imperative style. I caught on to functional programming quite quick and really liked it but I ended up using imperative programming more as game programming requires a lot of state and data manipulation. One of the things that I liked and later came to dislike is that you didn't have to give types to things because they were statically typed by inference. The problem that OCaml has is that it differentiates number types int/float/etc , so if you were going to add an int to a float you would have to cast the int to a float then use the special float addition operator "+." . In the end I still sort of like OCaml despite it's short comings but I didn't really see anything special about it and the lack of true threads makes it not very future proof.


C#

Everyone has heard of C# and I've used it for a lot of things myself before considering it as a game programming language. The syntax is nice although can be quite wordy at times. I tried using the TAO libraries and also XNA. TAO was nice but hard to setup on the mac (I'm seeing a trend here :) ), it was also just a straight port to C# with little to no syntactical sugar. Nothing really special with TAO but then again it's just a wrapper for some C libs. XNA was a new world for me as I haven't done any directx programming before. Just looking at C++ games in DirectX is enough to make any programmer barf. I'm not saying DirectX isn't powerful but all that com cruft is quite off putting. More on topic, XNA was easy to use and get things going and the content pipeline was quite nice. The biggest thing about XNA that put me off is the lack of control. In XNA you inherit from a GameApplication class which is monolithic and you ended up passing graphic device reference to everything, not my idea of well planned out or nice to use. In the end I still like C# but it's lack of decent cross-platform ability is what keeps me from using it. I know some will say that there is mono but mono is slower and it's not easy to distribute on the mac nor easy to setup all the libs on any platform.


Obj-C

Currently I am using Obj-C at work on iPhone games. Obj-C is my opinion is the C++ of mac development, everyone uses it and is though of as the standard. Obj-C isn't bad, it reminded me a lot of C++ and it's libraries are quite extensive. It has some odd syntax and it took me awhile to overcome that but it's not bad to me anymore. One of the things that bothers me is that the libraries while there is a lot of them they aren't easy to remember. I'm constantly looking up NSString and NSDictionary to remember what the name of a function is exactly and I've been working with Obj-C exclusively for about fours months at work. Luckily XCode's built in documentation view is quite nice, if it wasn't for that then I would be very frustated with Obj-C. Obj-C fails in the way that it is not cross-platform. Obj-C will compile with gcc on windows and Linux however all the libraries even including the string class are OS X only. There is an alternative called GNUStep but it's not quite the same and is lacking a lot of functionality that is on the OS X platform. Obj-C seem to me like a alternative version of C++ with some nice things added and others taken away.


So.. Nothing has Changed

So while I use Obj-C at work, I am still using C++ at home for my hobby work. SFML, DevIl, OpenGL, OpenAL and wxWidgets are my preferred libraries and are all easy to use and cross-platform without hassle. I would really like to find a new language to replace C++ as there are a lot of things that I'd like to see changed about it and functional programming still interests me. In conclusion I haven't found anything to replace C++ for my hobby development but I've learned quite a few languages and while I may not use them for game development I'm sure I will come back to some of them for something else later on.

I realize that this posting might make some people want to point out that I didn't try XXX or I'm giving something an unfair rap. This is probably true and feel free to point it out but I don't think you will change my opinions too much.