Simulating Laser: Line-Circle Intersection

Recently, I tried to apply a new kind of enemy which use laser. At first it seems so simple until I realise that laser-object intersection is not something that I know right away. The laser is a line and the object that I need to intersect, which is the player, is circle. So I need to figure out how to find an intersection point between a line and a circle.

Triangle Wars: Graphics and Gimmicks

Another 'major' update on the Triangle Wars. I'm not sure whether I'm bored with the black background, but I'm very pleased with the new grayish background. I also add dust path to make the game more 'glowing'. Another major redesign is the bullet is not a circle instead of an oval. It looks cuter (imo) :) I also add a health bar surrounding the player object instead of putting it on top of the screen.

Recently I struggled with sound, but no luck. I've tried SDL_mixer (which features is extremely limited) and OpenAL (which is not well-supported in OSX environment). Currently I'm trying to find another sound engine (gonna try FMOD).

I'm still looking an artist and sound engineer. Contact me if you're interested!

So here is the video of the last update. Watch it on directly on Vimeo for a higher resolution! It should be on HD (720p). I disabled the Player-Enemy collision since there's an error in circle-triangle collision. I'm currently working on it.

Triangle Wars: Font, GUI, and Lights

Greetings Human!

I spent the last week to create a 'decent' GUI. I already created a set of font, exported as TGA and add a few eye candy effect. I added the gloom effect and use a shuffling animation (inspired by Modern Warfare multiplayer intro at the beginning of the game). It uses automatic random generator so it's easy to add new text and automatically have it shuffled.

I also add light/gloom effect surrounding the enemy so the player can easily notice the enemy.

I also define 2 missions on the level: time based Survival and Elimination. On survival mode, the player has to survive at a certain time with one life. On elimination, the player has to destroy a predefined amount of enemy.

Next, I will focus on defining more types of level and fixing the GUI.

Here is the video for the latest update. The resolution is not in HD since I'm trying to see how the game would be on iPad. The GUI (especially the 'start' and 'option') is not final. I use the box to detect the hit, but it won't be there later on.

Triangle Wars: Enemies redefined

In this phase my focus is to fix the broken AI by implementing a simple Finite State Machine and redefining some enemies behavior. Currently there are four type of enemies: Fighters, Runners, Kamikazes and Effector.

Fighters is extremely slow but heavily armored. It shoots rockets which has a light damage but fast and follows player.  Runners is extremely fast when in running mode. It enters running mode when the player is close enough to the Runners. Kamikaze follows the player (slowly) and have massive damage. Once it close enough to the player, it armed itself for a few second and create a huge explosion with devastating damage. Effector is a static enemy. It slows the player if the player is inside its range.

I also add a 'lighting' effect to destroyed objects so it looks like there is an explosion. I did this by creating a shader that (re)draws the background grid nearby the explosion. It also colored the grid/background color to suit the explosion color.

Next phase: fonts, GUI and menu.

PS: Just noticed the disabled health system. That is intentional to make the testing easier.
PPS: Still looking for artist! ;)

Triangle Wars: Graphic and Camera

I'm back! After a few weeks of 'hibernating', I finally can start working on my game again.

This update focus on graphics and camera. I use bloom effect on every object. I do this by creating a 1 byte alpha texture and tell the GLSL to treat this as an alpha value. I also add a few artworks so it's easier to figure out which is what. For the camera, I move it closer to the object so the bloom effect is noticeable. I also add a new movement positions for the camera.

I also put a few animations on the equipment: rotating target for Decoy and radius-decreasing circle for Attractor.  It's not a breath-taking art system but good enough for a programmer ;) I'm still working on the Turret.

The next step is to modify the gameplay (AI, horizontal path) and polish the effects (particles). I decided to delay my work on sounds.

MYOGE 5: Equipments and SDL

I'm back with another update with my OS X mini game: Triangle Wars. I've been busy recently so the updates will be minor.

I added 3 equipments (or secondary weapon) that the player can use: Mini Turret, Attractor, and Decoy. Mini turret shoots enemy, Attractor pulls nearby enemies and bullets, and Decoy acts as a target when an Enemy is looking for a target. 

I also converted the program from GLUT to SDL. Thanks to Me and Mark for the XCode template. However I have problem with performance when I use SDL compared to GLUT. The frame per second is still smooth, but the input (mouse and keyboard) is less responsive. I will look through this problem . 

And another minor update is the particles. Just a minor particle-bounce update, You'll notice on the video.

My next update would be adding the sound, and make some pixels. Anyway, any artist would like to join? ;)

MYOGE Part 4: Weapons Defined

Back again with the MYOGE series. On this phase, I focus on the weapons definition of my game. Currently I have 3 weapons: Gatling Gun, Explosive and Spray.

Gatling Gun focuses on long range shot with high rate of fire, good for attacking a single enemy. Explosive bullet explode at the end of its lifetime, gives damage to nearby enemy. Spray Gun has a short range but devastating damage to nearby enemy.

I also put an upgrade lines on the weapons. At level 10, gatling gun shoots multiple bullet while explosives explode twice.

I also redefine some effects on the scene.  I use a line based effect for the explosion. It looks prettier than the point based but it doesn't match the theme of the game. It looks weird. But I'll decide later.

The next step would be converting the windowing system to SLD instead of GLUT. I had a few troubles with GLUT limitations and it's impossible to use this library for the next step.

MYOGE part 3: Effects

Ola. New progress on Make Your Own Game Engine series. The progress mostly fixed the redundancy loops, hence enhancing the performance. I also added some particle effects. It's still in the rough version. But I like the random generator. The next progress would focus on adding more levels so its actually playable ;)

Meawhile, here is the HD version of my game. I hope you'll like it.

MYOGE part 2: Memory Management and Stuffs

So here we go again with the very development process of Make Your Own Game Engine. haha! The progress mostly dealing with memory allocation which I'm pretty sure by now is leak-safe ;) I changed my engine object management from std::vector to a simple array.

There are also some changes on the gameplay: allowing player to use mouse to point the shooting direction instead of manually using buttons so rotate the direction. It took a while for me to figure out how to convert from screen space to world space. I finally use FBO for this problem. See my previous post for more details.

I also tweaked the camera so it has a floaty feeling making it less rigid. Thanks to Rob for the old tutorials ;)

Multitexture FBO in OS X

It's been a while since I put my code in here, thanks to the internet bandwidth around here *sigh*. So here we are, geeking around with graphic source code, and it got nothing to do with Jake Gyllenhaal! *dry joke*. I'm using the oldest Macbook Pro: Core Duo @ 2.0GHz (yup, the 32 bit one), 2 GB Memory, ATI X1600, running OS X 10.6.

M.Y.O.G.E: Make Your Own Game Engine, Part Uno!

Well, finally I have time to develop my own game engine. It's a 2D game engine, but I chose to use 3D vectors for each position/measurement just in case I can develop it to 3D (crossing fingers). Here is the first milestone:

Thesis: Pre-computed Surface Radiance Transfer

Title: Pre-computed Surface Radiance Transfer

Examiner: Jonas Unger

Complete version of the thesis can be downloaded here.

Abstract:

Rendering a complex global illumination scene requires an extensive computational resource. It is hard to achieve a real time rendering of a complex object using explicit 3D information. To tackle this obstacle, many techniques have been introduced to close the gap between complex 3D scene and real time rendering. One of the proposed solutions is using an image-based rendering technique. Image-based rendering is a method to achieve the desired image by referencing the sampled image as a source.

This thesis will focus on a mix between image-based rendering and geometry-based rendering. Instead of rendering directly using a global illumination method, we use a set of image, which are captured during the offline rendering. We call the first process as light transport pre-calculation process. These images then treated as a texture and will be attached to the polygon during the online rendering process.This will split the burden of processing power by using the power of memory. Since the pre-rendered data could be huge, it is also important to discuss a compression method that can be applied in GPU architecture and fast enough to be rendered as a real time.

Keyword:

Pre-computed Surface Radiance Transfer, Global Illumination, BRDF, Image Based Modeling and Rendering, Real Time Rendering, GPU Programming, GLSL.

Pre-calculated Light Transport:

The idea of the implementation is to render pre-calculated data instead of calculating value during rendering process. Since we are dealing with a 3D scene, the data that is going to be captured is the distribution of reflected radiance at every point on the surface. The rendering method used in this program is similar to any ray tracing method available. But instead of casting ray from the camera to find pixel-to-point relation, we loop through every texel of the texture to find texel-to-point relation.

Mapping Texel to Point

Now that we know how to find the corresponding point from a texel, we can start making the set of textures for each object. We built a hemisphere surrounding the corresponding point, and find the amount of radiance reflected to each angle (represendted with spherical coordinate value) on the hemisphere.

Hemisphere to represent any possible viewing angle

The spherical coordinate value of each angle is then converted into a single value by a predefined formula. We keep the texture as a 3D texture file. OpenGL’s 3D texture has width, height, and depth. . The width and depth will define u and vof our texure. We will use the single index sphIndex as the depth of the texture.

3D texture as a multi texture file

we use linear piecewise interpolation to compress the data and color indexing to reduce the bit to represents the color.

Pre-calculated Rendering:

The main task in the rendering process is to determine which texel to be shown on the screen. 3D texture has 3 component; x, y, and z. The value of x and y represent a point on the scene. The z value represents an outgoing radiance based on a camera position. The main idea of the rendering process is to find the proper z value of each point based on the camera position on the scene. We can compute the index by finding the spherical position of the camera based on the point we want to render.

The engine of the renderer is written in GLSL. Most part of the engine is in its fragment shader.

Result:

Sample 3D Scene to be rendered using our method

Total Polygon: 906

Total Uncompressed Pre-calculated Data: 1,2 GB

Total Compressed Data: 204 GB

Render Rate: 2-3 FPS

SFX: Houdini Tutorial

So in my last year of studying at my master degree, I took this SFX Course, or usually called Special Effects Tips and Tricks. It was total fun to have an experienced SFX person teaching in the class, knowing tips and tricks in real SFX industry, end much more. I also had a Houdini Tutorial, not from the artist point of view, but from programmer point of view. I was skeptical with houdini before I took this course but now I am considering to replace my PC just to play with this one.

This is the first video for the first tutorial. The task is to create a particle attractor, combined with some query and variables. So as you can see the video, the particle is not manually moved to the destination. We set the source here, the destination there, and voila. Its amazing :)

The second one is more like a physic contest. We make a pyramid and throw some balls to it. Nothing that fancy. Whats amazing is the whole scene is created using phyton, without accessing GUI at all. The point of this lab is to teach us the basic of phyton in Houdini.

I am a Maya user but I think I am considering to move to Houdini. Although the Modeling tools is not work as good as Maya, but the node concept is super awesome. It is easy to understand what happened on the screen, and, one of my favorite way to do things, to do trial and error by changing values a lot. Something that I dying to see in Maya.

Credits to my teammates, Kostas and Stefan.

Portfolio listed for viewing pleasure ;)

If you find my portfolio to much to scroll you can go to my profile page where you can find it listed neatly. Its easier to navigate my portfolio through that page. Plus you can find more information about me through that page.

Experiment: MultiLight

I am always curious about light. Amongst all OpenGL code, it is the light that held me the most. So I decide to do a lighting demo. Referencing from an application in Paul's Project, I made my own scene for the light. This is the screenshot of the program.

You can see the video here.

As you might know, OpenGL supports 8 lights only. This is a trouble when you are trying to create more than 8, which is common. One way to trick this is to render each frame multiple times, using 8 light per render, and then blend it into a buffer. In my program, I used 60 light, so I render the frame 8 times, 7 with 8 lights and the last one with 4 lights.

If you try to build the scene, be cautious that you might get white color a lot. 60 lights is a lot of lights, might results a total white color. Try to reduce the attenuation or maybe the number of the light.

This program was built using XCode under Mac OS X Snow Leopard. Using GLUT for windowing and no extension required.

Update:

This is the better version of the multilight demo. I decrease the light number to 24 so the light is noticeable. Putting too many light will only make a tendency of white color as result of adding the light color. Since the light is dividable by 8, no last loop modification is needed.

Also note that the program run smoothly in approximately 60 FPS. The jaggy experience in the movie caused by a bad free screen recording.

Experiment: CG Wave

Based on a tutorial from Nehe Gamedev: Building a wave using Cg Toolkit by NVidia. The wave is using sin value, moving through time, but in current version, I haven't apply time difference calculation, so the speed of the wave is quite random according to current idle process.

The object from the main program is a 64x64 flat grid. Using Cg is like using GLSL, only this one is more friendly to programmer, since we treat the Cg itself as an object instead of a file.

I cant capture the program as a movie file, my trial of SnapPro has ended :p and the quicktime capture screen option uses too many performance. Stay tune for a better version of the capture.

Global Illumination: Raytracing

Finally, my own Cornell Box :)

This is the result from one of my program to complete a Global Illumination Course. Using a Ray Tracing, I render the famous Cornell Box. Its still under development, need tweaking here and there but I am very satisfied that my weekend is not wasted at all :) Lots of reference here and there though.

Image Width/Height: 1024/768

Sample Point: 400

Objects: 1 Light Source, 3 Spheres, 5 Walls

Rendered using Macbook Pro Core Duo 2.0 GHz, 2 Gigs DDR2.

Rendered approximately in 2 hours.

All objects represented Sphere, a very neat idea by Kevin Beason. The wall and the light are spheres with large radius so they look flat. Its great because finding Ray-to-Sphere intersection is quite easy. My next step is going to implement other shape, and of course, tweaking here and there to increase performance.

Experiment: Shadow Mapping

This is an experiment for a research I did in one of my course. I took a paper about an enhanced algorithm to create a 'proper' shadow mapping, reference can be found here. So I did an experiment doing a shadow mapping from scratch, try to understand how a basic traditional technique of shadow mapping can be done. I enhanced my program to do a shadow mapping feature. I hasn't done yet but its getting somewhere indeed :)

Artificial Intelligence: SWAMP

Once upon a time, when my mind is full of imagination, and Lord of the Ring is still kick ass, when Total War series are permanently installed at my PC, I make a program called Simulated Warfare Application for Military Purpose or SWAMP. Please... don't comment on the name :P

Its my last project done by my group for an artificial intelligence course at 2004. The basic idea is to create a turn based strategy. I am so proud in this project since I think the idea is quite original, either because I did not play much back then or its just that original ;) After a few moment, Rome:Total War was launched and it has the same basic idea that I implement in this game. I am so happy since its like the best game implementing 'my idea'

Here are the screenshot:

you can find the video here.

I used minimax for the AI, in short human explanation, the computer considers human players at his/her best and find the best solution for that. The program was built using Java with the help of Netbeans. The graphic is not that fancy since I dont have much time. You can see more explanation about the gameplay from the video or the info of the video.

Special credits to my teammate.

Real Time Rendering: Multithreaded Programming

As the last project for my Real Time rendering course, I make a program which contain many aspects of graphic programming such as shaders programming (per vertex using GLSL), collision detection (uniform grid detection) and simple particles.

You can see the video here, bad quality in sound division, but thats what I could come up :)

Its full of experiment, I love the spring effect in the third person camera, and I spend lots of time to have such side view camera (notice the effect when the object is reaching the most left or most right). It was fun, its the best course I had and going to do lots and lots of experiment in this area (hopefully implementing it in game).

As you might notice from the video, the frame rate does not drop even after lots and lots of particles. There are lots of trick I did to keep the frame rate high and I must say its full of grin when seeing the tricks is working properly ;)

This project built from scratch using OpenGL, Glut Library, under OS X using XCode IDE.