Today, I want to share some of the features I put into the engine, what it is currently capable of, and where it is going from here. As of the moment it’s nothing truly superbly impressive, however it is my own work and is not borrowing code from other places. In other words, it has been written from scratch.

Introducing Reason Engine

I created the engine because I noticed that, at least for me, MiniB3D had a few downfalls I could not live with for my game. While shadows are implemented in Klepto’s extended remix, they do not work with my models and it also does not work with my bloom technique.

So why not go the whole 5 yards and do everything? I learned quite a lot by doing this.

It’s important to understand that the engine utilizes a naming system. Everything you define has a name that, so I hope, should be easier to work with. No need for ints, IDs, or stuff like that. You don’t name your child “1″ or “56735678″ – do you?

The engine is far from complete – I just want to share how far I have gotten in recent weeks. I’ll update this post as the engine progresses.

Engineered for simplicity in use and horsepower under the hood, the engine features:

* Utilizes OpenGL, thus platform independent
* Naming-based system
* Built-in texture catalog that stores your textures
* Textures added are automatically mip-mapped
* Unlimited textures
* Unlimited models
* Unlimited soft-lights (8 hardware lights, as usual)
* Up to 16 cameras, one can switch between them at run-time
* Automatic shadow generation for lights
* Shadows bend around arbitrary geometry
* Adjustable shadow quality, even at run-time
* Built-in Frustum Culling to ensure rendering speed
* Built-in W-A-S-D movement, can be enabled with one line
* Built-in 2D emulation for elements such as images

If you are interested in seeing some actual coding with it and the engine perform live, in color, HD and in stereo, please have a look at my latest DevBlog video (bonus feature length!) that shows how it’s supposed to work.

So here are a few screenshots.

Showing a simple cube and an Orion Relay, both casting shadows

Depending on resolution, shadow quality can be adjusted at run-time

There is support for 1024x1024px shadow maps, if your graphic card can support it. The setting is called “Ultra”. Possible shadow quality depends on the vertical resolution the engine is running at. If you run at 1920×1080, the Ultra setting becomes available. Also bear in mind that the higher you go, it obviously requires more memory.

I put in a little function that shows you where the light is, and in what direction it is shining. It will draw a line on screen (for now! I’ll improve it) so that you know what’s happening.

RN_EnableLightDebugging set to True

As soon as light is created, shadows are automatically added to the model you define as main terrain/indoor part.

Therefore, they automatically bend around non-planar geometry. Automagically!

Shadows bend around arbitrary geometry

Oh uh, one more thing. I put in a few 2D functions as well. They are not based on Max2D or any module in BlitzMax. These are pure OpenGL calls, allowing you to display and, of course animate, 2D elements (images for now, text to come).

Images can be the usual suspects – bmp, jpg, png. Each of those can be given a certain transparency value, much like SetBlend ALPHABLEND and SetAlpha. Except that this is performed in OpenGL and ortho-projection.

Two images being displayed – one without additional setting, the second with 50% transparency

This is the current command set:

----------------------------
CREATE REASON APP
----------------------------

RN_CreateApp(name:String , w:Float , h:Float, fs=False, mt=False)

----------------------------
SHORT CUTS
----------------------------

RN_CreateCube(name:String, noshadow:Int = False)

----------------------------
MODEL CALLS AND PROPERTIES
----------------------------

RN_LoadModel(name:String, file:String)
RN_SetModelColor(name:String, r:Float, g:Float, b:Float)
RN_HideModel(name:String)
RN_ShowModel(name:String)
RN_PositionModel(name:String, x:Float, y:Float, z:Float)
RN_RotateModel(name:String, p:Float, y:Float, r:Float)
RN_SetModelTexture(name:String, texname:String)
RN_ScaleModel(name:String, scale:Float)
RN_ScaleModel3v(name:String, x:Float, y:Float, z:Float)
RN_SetModelIsMainTerrain(name:String, value:Int)
RN_SetModelAmbientAndDiffuse(name:String, r:Float, g:Float, b:Float, a:Float=255.0)
RN_SetModelSpecular(name:String, r:Float, g:Float, b:Float, a:Float)
RN_SetModelShininess(name:String, s:Float)
RN_SetModelPickable(name:String, value:Int)
RN_FlipNormals(name:String)
RN_ModelX:Float(name:String)
RN_ModelY:Float(name:String)
RN_ModelZ:Float(name:String)
RN_ModelWidth:Float(name:String)
RN_ModelHeight:Float(name:String)
RN_ModelLength:Float(name:String)

----------------------------
LIGHTS
----------------------------

RN_CreateLight(name:String)
RN_SetAmbientLight(r:Float=51.0, g:Float=51.0, b:Float=51.0)
RN_SetLightPosition(name:String, x:Float, y:Float, z:Float)
RN_SetLightColor(name:String, r:Float, g:Float, b:Float)
RN_SetLightSpecular(name:String, r:Float, g:Float, b:Float, a:Float=255)
RN_SetLightConeValues(name:String, wideradius:Float=70.0, focusradius:Float=60.0)
RN_SetLightDirection(name:String, p:Float, y:Float, z:Float)
RN_SetLightRange(name:String, range:Float)
RN_TurnOnLight(name:String)
RN_TurnOffLight(name:String)
RN_EnableLightDebugging(debug:Int)
RN_LightX:Float(name:String)
RN_LightY:Float(name:String)
RN_LightZ:Float(name:String)

----------------------------
TEXTURE CATALOG
----------------------------

RN_AddTexture(file:String, name:String)

----------------------------
COMMON PARAMETERS
----------------------------

RN_SetClearColor(r:Float , g:Float , b:Float) 
RN_SetBloomTo(bloom:Int)
RN_AntiAlias(value:Int)
RN_EnableWireframe(value:Int)
RN_SetShadowQualityTo(value:Int)

----------------------------
CAMERAS
----------------------------

RN_SwitchToCam(name:String)
RN_RenameCamera(currentName:String, newName:String)
RN_NewCamera(name:String, x:Float=0.0, y:Float=0.0, z:Float=0.0, rp:Float=0.0, ry:Float=0.0, rr:Float=0.0)
RN_PositionCamera(name:String, x:Float, y:Float, z:Float)
RN_RotateCamera(name:String, x:Float, y:Float, z:Float)

----------------------------
MAX 2D EMULATION
----------------------------

RN_Text(x:Int, y:Int, text:String)
RN_LoadImage(name:String, file:String)
RN_ReplaceImageFromFile(name:String, file:String)
RN_ReplaceImageWithImage(name:String, pixmap:TPixmap)
RN_RenameImage(current_name:String, new_name:String)
RN_ResizeImage(name:String, x:Int, y:Int)
RN_DrawImage(name:String, x, y)
RN_SetImagePosition(name:String, x:Int, y:Int)
RN_SetImageAlpha(name:String, alpha:Float)
RN_SetImageVisible(name:String, value:Int)

----------------------------
BUILT-IN CAM CONTROLS
----------------------------

RN_EnableWASDMovement(value:Int)
RN_SetCameraMovementSpeedTo(speed:Float)

----------------------------
RENDERING
----------------------------

RN_Render() 
RN_Render2D()

Obviously that expands as I progress with the engine.

Reason is going to be available in 3 flavors, one which is free. If you’re eager to try this out yourself, I’ll let you know when I have something ready for you.

I am currently building a Wiki for the engine, so as soon as it’s ready to show for the public, I can also tell you if you like.

That’s it for the moment. I hope you find this project a little interesting.

See you around. And thanks for reading.

If you’re not aware – I am working on my own online game for quite a while now. However, one thing has been quite a pain in the ass to do – and that’s shadows. So I’ll be talking about that particular subject today.

Producing real-time shadows is one hell of a thing to accomplish. Luckily in this day and age, there are a few ways to go about this. These are:

Shadow Mapping
Probably the most widely used technique of them all. The fast version is that you render from the light’s view, note depth values, render from real point of view, compare values, and determine which part is lit and what is in shadow. Sounds simple, it’s pretty difficult since you have to do something called Matrix Multiplication.

Volumetric Shadows aka Stencil Shadowing
This technique performs so-called Backface-Culling (find out which polygons can’t be seen by the camera), copies them, and extend them in a finite range, and make the overlaps visible with anything those “copies” hit. This usually produces pixel-perfect shadows – but it’s also very expensive to calculate.

After reading a lot about this shady (badum-tish) subject, I decided to go about it in a different way. I sat down and thought long and hard about a way that would sort of maybe meet both of them in the middle, or maybe use a new technique to do it.

I learned of a completely different technique, called Ray Tracing.

While super-easy to implement, even on easy scenes it can take quite a while to render the scene. There have been a few attempts at actual real time ray tracing, one of which can be seen here:

Now obviously that kind of setup and machine is a bit outrageous to aim for someone making a game. While this looks pretty good, pixel-perfect ray-tracing as seen in the video will remain in the domain of super-computing for now.

However, I came up with a way that utilizes a stripped down version of ray tracing, which is usable in today’s hardware. While it won’t produce super-mega-realistic shadows, or imagery, it does work as intended and produces accurate shadows with the help of light ray tracing.

I’ll outline the steps of the technique used, hopefully in a way that works for everyone.

1) Define a grid of a finite size, say 128 x 128 points. The higher this number, the higher the shadow detail – but also the more delay in ray tracing. You could think of this as the shadow map size.

2) Have a model in the size of exactly 1 x 1 unit compared to the grid, and place it at the start position (0 x 0 for example). Also, switch your view to the light’s position (IMPORTANT).

3) Start moving the model in one direction (horizontally or vertically, up to you), with the distance of 1 unit. Rendering is not required. You query whether or not the “scanner tile” can be seen from the light at its current location. When it hits the end of your plane, you move it back to 0 vertically and 1 unit horizontally, and again move it on that line to each place in the grid.

4) As you move the “scanner tile” on all possible locations on the grid, you mark down whether or not the tile was seen from a specific location. If for example a cube was blocking sight to the tile, that particular place has to be in shadow.

5) Now that you know what is in shadow and what is not, you can begin shading the scene. How you do it is ultimately up to you – I use simple two-dimensional GL_QUADS at those locations. I also take the distance of the tile to the light into account, and apply an alpha value to it relative to its position to the light, giving the effect of shadows fading out the further they are from the light.

It works like this:

Here are a few screenshots of the technique in action.

And to close this off, I’m showing the technique on video and explain it in simpler terms, if you’re interested.

Until the next worklog.

It’s been quiet around here these days. That mostly has to do with the fact, that for once, I really want to finish a project I start. I have had the idea in itself for quite a while now – I always wanted to somehow convey my idea of a possible future scenario. The game is called “Orion’s Gate”, and takes place 500 years in the future in a fictional dwarf galaxy.

Orion’s Gate

The whole thing is meant to be a MMO-RTS – Massive Multiplayer Online Real Time Strategy game. It has gotten to a point at which I am able to present a few things. As of now, the game itself is not complete, but fundamental things are working – such as database connection, verify player credentials, establishing a session, retrieving character data.

I don’t want to give away too much of the game itself as of the moment – I like to keep the suspense. Rest assured that it is 3D, and is going to be available for Windows, Mac OS X and Linux flavors.

The three races from left to right are:

Orion Federation -
The only democracy in the Orion galaxy, and defenders of values the humans believe to be the most important: freedom, independence, and equal rights for everyone. A variety of people from all walks of life have lead the Federation, which lead to commended diversity – even by other races. Technologically, humans are only second to the Reticuli, and somewhat equal to the Midori.

Reticuli Triumvirate -
Wisdom, science, and enlightenment are pursued by the Reticuli above all else. They are the oldest race in the galaxy, but also face a greater challenge – possible extinction due to genetic degeneration. This has forced the Reticuli to go a different way and to develop new technology and acquire anything alien that may yet help their survival – which is probably the main reason for this ancient race to be in the galaxy.

Midori Regime -
A rough, straight-to-the-point society. Centuries of slavery and oppression have lead the Midori to rebuild their society through force and military might, which is why these people seek to control the galaxy, and will do what is necessary without remorse, and won’t stop for no one. Politically speaking they are a dictatorship, their mentality has shifted toward a territorial and capitalistic mindset.

As you can see, we have three very different colors here. I’m dying to find out how this will turn out between people once the game goes live.

It is written in BlitzMax – which I would like to think of a distant relative of Objective-C. It is extremely flexible, object-oriented, and not interpreted (meaning no virtual machine or the like). It has its own compiler and runs directly on the chip. The beauty of it is, that it is primarily aimed in making games – so pretty much all graphic operations are hardware-accelerated.

If you so desire, you can also create normal GUI applications and combine hardware-accelerated graphics in it. This is highly useful for 3D-modeling applications, or scientific purposes. The module, MaxGUI, comes with the package.

BlitzMax, among other tools, is developed by BlitzResearch and has been in constant development for over 10 years – and is still ongoing.

Corona UI

The user interface for this one is a very vital part. For the purposes of the game, I purchased a library called ifsoGUI. In effect, it’s a UI module through which you can rapidly create in-game user interfaces that can have pretty much all of the known elements such as buttons, labels, text boxes, images, and so on and so forth. The specialty of this one is that it is fully skinnable – and can change themes on the fly.

However in order to make it work I did make some changes to the source code, and there are going to be many more. I’ll be implementing some of my stuff I did earlier for MarcOS – it should be easy to port. Things such as “iconification” of a window and something I’d like to call MenuShelf. More on that another time.

Another thing I put in is something I’d like to call Corona Viewer. It can be called with a command line switch and is mostly a development tool for themes. With it you can have a look at how a theme will look without actually entering the game. Useful for when people want to test themes before they share them with the community.

Server API

When the server is running, it will write information about its status, among other things, in periodical values, into XML files. These XML files and thus the server data is accessible from the outside. You can then go in with any tool you like, parse the data, and display it in any way you like.

This XML shows the server status, and number of players.

One more thing… Reticulum Engine

The game is 3D, obviously. In the past weeks I have mostly been busy creating an engine for the game. I am calling it Reticulum. The engine is based on a module for BlitzMax, named MiniB3D. The module, in essence, wraps OpenGL into BlitzMax. I have already made hacks and extensions to that module in order to make it do what it can do now.

Multi-Mesh technique

The models in the game are really comprised of multiple meshes, that are loaded separetely – but kept together in an model object in memory. This also enables me to switch states of a model as needed – for example a Relay is only active for a short time. I can then switch parts of the model for something different, or textures of that part, or… you get the point. That also is just about the only way to go in MiniB3D if you want quality meshes.

The Geometry Of Shadows

Probably the biggest break-through I had in development so far, was that I have been able to figure out how to cast good looking shadows, in real-time. I don’t want to into too much detail – it all has to do with something called shadow mapping.

Believe your eyes. This is the Reticulum Engine casting shadows.

DevBlogs

If you’re interested, here are all of the things I discussed in action.

And here is a written version where I also keep up about the progress:

Orion’s DevBlog

Watch this space:
orions-gate.com

Until next time.