Simulacra X: Update (CUDA/CTM)

well, my new "compatialbe" battery for my hp laptop finally arrived from hong kong a couple of days back so it's gonna be a linux install/set-up weekend. still not decided on which distro to install yet but i'm leaning towards vector linux.

simulacraX is still moving at a snail's pace. most of the low-level stuff is in place but not implemented (stuff such as the memory management, window management, timing... are all waiting on linux). the maths library is virtually done though. speaking of maths. i came across this just over a week ago. apparently nvidia along with their sworn rivals, amd/ati, are seriously making efforts to turn the GPU into a complete coprocessor by providing low-level access to their hardware and SDKs for development. basically there is nvidia's CUDA and amd/ati's CTM. CUDA provides a C-based tool chain for development. CTM on the other hand is much more open and low-level, allowing programmers access via assembly. IMO, this is some good shit as this allows programmers to write complex and computational algorithms for the hardware using C rather than using shaders (which are primarily for graphics algorithms). this means programmers can write libraries for stuff like AI on the GPU quite easily as well as physics (infact this is as good as having a programmable PPU). and with microsoft's vista up and about, GPUs will be invading computers near you and typically, developers will want to take advantage of these monster processors if they can help it.
well, i'm looking at how to take advantage of this for simulacraX - oh yeah! it's a bit tricky though, because the issue of platform-indepent code comes into play. these APIs are strictly for their respective hardware so logically the best way to go would be to use CTM, and implement a version of CUDA for the amd/ati cards but i have no assembly programming skills. besides a CUDA implementation is a big project on it's own i guess. with my C/C++ background, CUDA is much more easier for me to get into. i just downloaded both the CUDA programming guide and the CTM techincal reference manual... maybe i'll read them tommorrow... zzz

BTW, first we had a morpheme release party thursday and boy, did i get f**ked up soaking my head in multiple pints of kirin and hoegaarden. nasty stuff - i still haven't fully recovered.

Simulacra X: Update

yes, the project has kicked off but at a very slow pace. been quite busy with "real life" and work recently. but so far i've been working on the system and maths stuff and lots of ideas about the other stuff have been bouncing everywhere in my head. the project name has changed from "simulacra" to "simulacra x" only because i needed a cool second consonant to prefix my #defines, typedefs and class names. for example, my 3d vector class, now named SxVector3 is way cooler than SVector3 or SeVector3 (e = engine). also considering namespaces too. namespace Sx?
anyway, my major priority now is to install and set up a linux dev enviroment on my almost-3yr old laptop which hasn't been of much use recently. first, i have to buy a new battery for it, totally format and fdisk the whole hdd, then go through mess of installing/configuring a fast, bloat-free linux environment. it's been a since while i played with linux – dunno if my memory is still intact for the command line.

Simulacra: The Features

warning: this is lengthy, geeky post and will most likely contain typos, cos i am too lazy to proof-read.

ok, i’m gonna go through the proposed features of simulacra which are by no means definite. which ever way, this is gonna take a lot of time to complete considering i have a day job and also that i’m trying hard to have a life.
the engine is not commercial. i still have to figure which license i will be going with (LGPL?). the primary target platforms are windows and linux. the mac isn’t supported because i don’t have a mac, never used a mac, and i doubt i’ll be owning one ever. basically the subsystems of simulacra, which i will explain are: core, graphics, UI, input, sound, physics, character animation, AI, input, sound, tools.
the programming language of choice is the obvious C/C++, coupled with OOP principles. C# will be considered for tools but at this moment i’m not sure as to its status on linux machines. i’ve heard about the mono-project but that was a long time ago during my last days as a linux freak.

the core system
this is the basis of all game engines. the most frequently used routines will be defined here, platform-specific code will be encapsulated here. C++ features will be implemented and the maths library will be constructed.

low-level: this is the lowest level of the engine and will generally handle all platform-specific system level routines through encapsulation; stuff such as system time, window management, multi-threading? (nasty! by the time this engine will be finished, quad-core cpus will be cheap – screw intel) will be sorted out here. other commonly used routines for file I/O, memory management, and debugging utilities will also be implemented here.

mathematics: i always enjoy this bit (its easy anyway). any engine that deals with graphics and geometry must necessarily have a subsystem for mathematics. this system will consists of math routines for trigonometry, vectors, matrices, quaternions, planes, and lines. for graphics, a data structure for color will also be defined.

object system: taking tips from dave eberly’s book, 3d game engine architecture, with the amount of objects an engine has to manage, it is essential to have some sort of object management. this is a core set of automatic services that application writers can rely on such as names and unique identifiers for each object. also it will be an advantage to implement certain functionality that is inefficient in c++, such as a RTTI system, and also functionality that isn’t available in the c++ standard library such as shared pointers. functionality such as streaming will be considered. it’s not guaranteed that i will implement this system because i guess C++’s RTTI system will improve over time. anyway, i’ll see how boring or exciting it gets.

the graphics system
the big kahuha. this is usually what makes or breaks an engine. it’s what the graphics-crazy world looks at. well I’ll just say I’m not a graphics whore, I’d rather code physics or AI than do graphics so don’t expect much.

renderer (fixed function): i’ll be using the OpenGL library for rendering on both windows and linux. i might implement a DirectX9 renderer but that will much much later, probably at the end of the project. By the time I through with the engine, this again might be futile as the fixed-function pipeline is giving way to the programmable pipeline (GPU programming). the renderer will support font rendering, and rendering of basic 2D primitives such as lines, triangles, quads, and also 3D primitives such as cubes, cylinders, cones, etc.

renderer (programmable pipeline aka shaders): with vista coming out soon, ms will force the planet to upgrade the computers ensuring everyone has a decent GPU. Hence shaders support is necessary. this system will handle everything related to pixel and vertex shaders. the shader language of my choice is Cg since it is cross-platform across both OpenGL and DirectX. i do have some experience with both HLSL and GLSL and I just might support GLSL also, might.

renderer (raytracing/raycasting): a raytracer is something I’ve been looking forward to implementing. why? my former classmate had to implement one on a GPU and he seemed to have had fun doing it. and that’s what I want to do. a simple CPU and GPU raytracer.

special effects: nowadays, it’s kind of hard to draw the line between fixed and programmable pipelines as a lot of graphics effects are now implement in the GPU. I haven’t yet decided what and where I’m going to do what so the following is just a rough idea and it will change – i know. when it comes to shaders, it’s very much in the hands of the application writer and shader code is quite specific to the projects it’s used on. however I will provide a few basic sample shaders for different effects.
fixed function: texture loader, basic texture mapping, multi-textures, projected textures, bump mapping, environment mapping, planar reflections, planar shadows, lens flares, billboarding, particle systems, fog, water, fire, sky, terrains, foliage?
shaders: per-pixel/per-vertex lighting, basic texture mapping, multi-texturing, environment mapping, bump mapping, parallax mapping, water rendering, reflective mapping, refractive mapping, cel-shading, HDR lighting, deferred shading, fog.

meshes: will provide support for loading meshes of different open formats (such obj, md5, etc). tessellation will be supported too.

camera: yeah I’m looking forward to implementing a kick ass camera system. support for scripted camera behaviour will be included amongst other things such as frustum culling, camera effects (eg. depth of field), and many more.

scene graphs: not quite sure if this should be under graphics but i’ll try to make it as generic as possible. scene graph implementations will include octrees and BSP trees. i might consider ABTs if I can get my head around it. also, stuff like level of detail (LOD) will be implemented.

the UI system
writing a UI library is something i think would be interesting. i don’t believe it’s that hard though but yet i think i’m gonna be annoyed doing it as it’s more of an OOP problem that anything else. making a robust UI system would be a challenge. the UI system will support skins (easily configurable and loaded from XML files). or i could just use crazy eddie’s GUI system.

the input system
this is a relatively easy-to-implement subsystem of the game engine and will most likely be implemented using a third-party input library such as SDL's input system, especially useful for linux.

the sound system
just like the input system this is easy to implement and i will be using the FMOD sound libraries, which is quite popular in industry.

the physics system
writing a robust physics engine isn’t trivial at all. it’s a really complex system and i will be going the third-party way again and using PhysX. however since i enjoy physics programming, simulacra will provide support for rigid bodies and collision detection. soft-body physics will be considered but only as far as 2D soft bodies such as cloth physics.

the character animation system
no naturalmotion stuff here :). I hope to implement features such as keyframe animation, skeletal animation, inverse kinematics, mesh skinning and deformation. all these are old-school stuff compared to what naturalmotion is doing.

the AI system
now i have experience writing an AI engine, so this system should be more straight-forward than the others. AI engines, just like shaders, most of the time are game-specific. hence i will only provide agent-based, AI functions for navigation and decision making that are common to most genres.

navigation: this system controls agent movement. this consists of path-finding search algorithms such as A*, breath-first search. also included will be a steering behaviours library with behaviours such as evade, chase, flocking, path following, etc

decision making architectures: the architectures that will be implemented are: finite state machines (FSMs), scripted FSMs, fuzzy state machines (FuSM), rule-based AI, and goal-driven behaviour.

tools
scripting: at the moment, my decision is to use lua (until I look into gamemonkey) for scripting, and XML for file loading. There I will have to written a versatile lua scripting engine. I will mostly like be using TinyXML for XML parsing and will provide a wrapper for it (in case i might want to change XML parsers in the future).

editors: having editors would be swell but i’m afraid this part will be least looked into. i don't have much passion for tools (i.e. gui programming) but a map editor would be cool though.

as i progress with coding, i'll go much more into details about the implementation of the different components. i reckon this engine will take me at least 3 years to complete and that's just being optimistic.

Introducing the Simulacra Engine

i had mentioned in an earlier post that i hoped to start a game project soon. thing is i've been thinking hard about what kind of game i would like to develop and have tied it down to my favorite genres, fighting games and RPGs (even though like the average nigerian gamer, i've spent more hours on PES/winning eleven). RPGs are complex, and require a good solid story. unfortunately, story-telling is not a talent i possess. fighting games are basically divided into 2 types: classic 2D (think sf2 turbo) and modern 3D (think tekken). personally, i prefer the classic 2D games. games, like tekken (with complex animation and physics), don't impress me in terms of gameplay. also, i believe the 2D games are easier to code for than the 3D games. the biggest pain with developing 2D fighting games is that i'd require lots of 2D sprites for animation and i have no 2D art skill. finding skilled 2D artists to help for free is pretty hard these days. if you're reading this and you've got mad skillz, get at me.
anyway, games ultimately require engines and i have decided to write one from scratch which i've codenamed "simulacra". some argue that there are a lot of good free game engines like OGRE, and cheap commercial ones like torque that i could use so why bother. well, for fun i suppose, besides i need to get back more into low-level stuff. at naturalmotion, i write mainly high-level code and with my poor memory, my low-level knowledge is fading away. besides, i need something to do while i make up my mind on the type of game i'd like to develop :). game engines take shitloads of time to develop - luckily, i've got a good amount of re-usable code (nothing fantastic) from my past projects that should make things easy at the beginning.
now i have to go decide what features the simulacra engine will have.