Indie As Hell

Blend it well - Skydome's contact point with Scene

Thu, 03 May 2012 01:17:00 +0700

From my previous post which I mentioned to write about a simple technique I implemented and used in parallel with fog rendering system in order to pull out every sense of what’s “right” out of the screen, so here we go.

The problem usually arises when there’re models or meshes placed on a large flat plane in which a skydome covers entirely of those. What’s matter is the plane or ground as it interfaces with skydome and produces unpleasant result as seen far away in sight. It’s too separated and cut off. The artifact is easier to be seen if there’s not enough objects to distract us from glancing at the line itself. See below.

The red arrows show what happens to be a problem which we’re trying to solve.

So I came across with a simple approach to make a skydome blended well with the scene interfacing with it.

I jotted down the idea on paper, and decided to share it below for some pleasure in seeing original writing.

The main point is at the center of the page. There might be a hard time to clearly see it so I rewrote it (somewhat) cleanly below.

We have a skydome covering all of the whole scene with its both side of edges may go deep down below and pass through the ground itself. To better blend the color along the line, it should not happen to be a sudden full 100% color from the skydome’s texture right away, but it should merely smooth out for better transition from normal scene to skydome.

Height is the estimated length to do linear color blending with fog color (or fixed color value). If y-position is outside this range, then we ignore it. Min is the position where skydome texture takes all the majority of the result blending color. Max is the position where fog color (or fixed color value) takes all the majority of the result blending color. So in between, we have a linear transition.

The following is a section of hlsl code inside an effect file.

...
// blend with scene
if(input.WorldPosition.y <  SKYDOME_LS_HEIGHT)
{
        float f = input.WorldPosition.y / SKYDOME_LS_HEIGHT;
        if(fogEnabled)
        {
                blendedColor = f * blendedColor + (1-f)*fogColor*ambientLight;
        }
        else
        {
                blendedColor = f * blendedColor + (1-f)*float4(1.0f, 1.0f, 1.0f, 1.0f)*ambientLight;
        }
}
...

Note here that SKYDOME_LS_HEIGHT is HEIGHT as explained above. f is a percentage describing how much skydome’s texture color will have majority in result blending color.

Whenever fog is enabled, then we blend skydome’s texture color with fog color. I also take a consideration on global light intensity percentage (0.0 - 1.0) or ambientLight here. As I use a value to represent the sunlight intensity at particular of time to simulate my day-night effect, so I must take it into account as well.

But when fog is not enabled, then I normally blend it with white color. White color is naturally used to give out a shading level of a target color in blending operation. In additional, I want to keep a sanity in color and not to mess it up. Using white will preserve the color coming from skydome’s texture.

This section of code should be added after a main color operation is carried out, but before alpha-channel color operation will be performed (to ensure we won’t mess up with alpha value). In fact, putting this code into a separate function is also a way to go, but as I want to reduce overhead, so I can live with that.

See the comparison between turning on/off of this technique while fog is enabled below (click on image for original resolution).

That’s it for now. Til next time.

Fog Fog Fog

Wed, 02 May 2012 00:37:00 +0700

Begin with story
I remembered back in a day that I’ve failed in adding fog in my new ground deferred shading. So I decided to pursue another route just for survival alternative, and that was particle fog.

The time passed, and someone popped up a need to fully take control of fog system. Then that thing heads back and bangs me to the code!

I have done fog in shading sense before. But that time with normal forward rendering technique. So it’s quite straight forward as merely no other big stuff to be considered and would block out the way. It should be something, I always think to myself, that I miss it out in that time. Finally, I go back to Castle Wolfenstein!!

In fact, it’s a same same approach that be done inside effect file with shading programming. I would guess that because I saw everything shaded into white, then I suddenly gave up.

Wait! What’s wrong with particle fog?

Particle system can be implemented in 2 major ways.

Triangle or Quad-based
Point sprite

My current particle system uses a 2nd approach.

The resource needed for point sprite to represent one particle is one vertice compared to another way which may need 3 or 4 vertices based on technique of implementation. So it’s ideal to have point sprite in place for particle system as number of particles surely will be high. But it comes into some costs as well.

Firstly, Point sprite will be scaled up/down based on the distance to the camera. Thus whenever we go closer and closer, the particle (or point sprite) will be really small so we won’t be able to see nice detail of the particle itself. Consider that a building catches on fire. Far away, you clearly see its effect and recognize that it’s fire. But when you come closer, particles get smaller and smaller til you see the house itself which seems like nothing has done anything to it.

Secondly, in fact both of the approaches, it’s harder to control behavior of particle system although you have a good tool to simulate the behaviors and it acts like that in the real simulation. I believe for most hands-on code in purity, if it’s not designed to be a tool, it will have to be manually adjusted in terms of particle’s position, number of particles, direction it goes, size, randomness stuff, etc.

It would conclude that I should stay away from point sprite (in case of fog effect), and use triangle / quad - based instead. Anyway, a better approach is to use shader. This way we gain all control for whenever to do shading, fog’s settings in terms of density or anything else, and the most importantly, it’s uniform on the whole screen buffer.

Side-note: Shawn Hargreaves stated in his post that point sprite won’t be supported in XNA 4.0. DirectX 10 and 11 will cut out its future from there as triangle / quad - baseds is proved to be as efficient and sometime better than point sprite approach.

Okay, here the things

Each individual entity has its own effect (or shader) file that describes how to render itself on screen. Surely, every of my shader files include one common include-file where inside has basic operations in both terms of transformation, and pixel shading that they can use and adapt up on to more specific operation.

Fog related variables lie inside that include-file. The following is HLSL language declares fog related variables as shared ones across all shader files as I want fog to be globally effect. Just set its settings once, then every single entity, every mesh in simulation will be rendered with consideration of fog shading.

// -- Fog properties --
// Linear Fog
shared float fogNear;
shared float fogFar;
shared float fogAltitudeScale;
shared float fogThinning;
// Exponential Fog
shared float fogDensity;
// Others
shared float4 fogColor;
shared bool fogEnabled;
shared int fogFormulae;	// 1 = LINEAR FOG, 2 = Exponential Fog, 3 = Exponential Fog ^ 2
shared const float E_CONST = 2.71828;

To be more elaborate on the above variables, I researched through the Internet and found this one. Its information dated back in time of DirectX 9, but the theory still holds. A notable graph comparison at the bottom is really nice and blowing benefit.

I decided to implement them all for 3 types of fog which are Linear, Exponential 1 and 2. That graph tells everything! Whenever you want any other behavior of fog, you compare them and choose what’s right for you.

// Linear Fog
float4 LinearFogPS(float4 color, float3 worldPosition)
{
    float d = length(worldPosition - cameraPosition);    
    float l = saturate((d - fogNear) / (fogFar - fogNear) / clamp(worldPosition.y / fogAltitudeScale + 1, 1, fogThinning));
    
    return lerp(color, fogColor, l);
}

// Exponential Fog
float4 ExpoFogPS(float4 color, float3 worldPosition)
{
        float f = pow(E_CONST, length(worldPosition - cameraPosition) * fogDensity);
        f = 1.0 / f;
        return saturate(f * color + (1-f) * fogColor);
}

// Exponential 2 Fog
float4 Expo2FogPS(float4 color, float3 worldPosition)
{
        float f = pow(E_CONST, pow(length(worldPosition - cameraPosition) * fogDensity, 2));
        f = 1.0 / f;
        return saturate(f * color + (1-f) * fogColor);
}

saturate() is added for sane of color stability. Note f*color + (1-f)*fogColor that merely explains the essential of f by means of “how much should color should be seen after combined with fog color”. This is why Maths is so lovely in hidden message, it won’t directly speak in normal human language but instead purity of its own tradition.

fogFormulae will be a key for us as I will allow users or whoever uses my framework to be able to instantly change the method to calculate fog on-the-fly. Thus I wrote a handy function just to check for which way to calculate for fog. This function will be used across shader files.

float4 fogFormulaePS(float4 color, float3 worldPosition)
{
        if(fogFormulae == 1)
                return LinearFogPS(color, worldPosition);
        else if(fogFormulae == 2)
                return ExpoFogPS(color, worldPosition);
        else if(fogFormulae == 3)
                return Expo2FogPS(color, worldPosition);
        else
                return color;
}

This means that caller has a sole responsibility to send-in forFormulae value into shader file as well as other related fog variables. But as long as they don’t frequently change the fog setting, they just have to do it once and for all.

Now, we already set things up.

Just a side-note for myself, an include-file is going bigger and bigger. Once only pixel shader model (PS Model) version 2 is a way to go, but as things go bigger, I have to change it to version 3. This is a two-sword decision. It would cut users who use PS v2 capable graphics card, and target only for those who use PS v3 and above. Anyway, think it in a positive way, as my framework is bandwidth hunger, setting it to PS v3 will told the requirement for any system to run it in the first place. Misunderstand and self-thinking would not happen.

Now, it’saa bout time!

So it’s time to make use of the things we already set up previously. I excerpted the code inside airport’s shader file of pixel shader function to let you see how we take the code into a real production.

RenderGBufferPixelOutput RenderGBufferPS(RenderGBufferPixelInput input)
{
        RenderGBufferPixelOutput output;

        //Color
        //Lerping base and target texture
        //get color from baseTexture
        float4 baseColor = tex2D(baseSampler, input.TexCoords);
        //get color from targetTexture
        float4 targetColor = tex2D(targetSampler, input.TexCoords);

        //lerp from baseTexture to targetTexture (the dTime must be set properly)
        float4 blendedColor = lerp(baseColor, targetColor, dtTime);
        
        // fog
        if(fogEnabled)
                blendedColor = fogFormulaePS(blendedColor, input.WorldPosition);

        ...
        // do whatever you like here
        ...

Not to worry about why I do lerping here. I have 3 different weathers so there’s some chance that some parts of airport would do lerping from normal weather texture to snow weather texture.

Line to note is commented out with “// fog”. We just test it whether at the moment fog is enabled to apply or not, if so then we use our handy function to handle decision over calculating fog on each pixel whether it’s Linear, Exponential 1 or 2. We plug in the color, and its world position.

See the result

See the full gallery below of what the result may look like. I reserve the space to the next post for another simple technique I implemented in parallel to fog (as in my case) in order to make it looks much better along the edge of the ground map interfacing with skydome.

Til next time.

Goodies! Finished updating some enhancement to RealKo framework,...

Sun, 29 Apr 2012 19:53:00 +0700

Goodies!

Finished updating some enhancement to RealKo framework, and this for April.

DLAA and do it in post-processing

Tue, 24 Apr 2012 04:22:11 +0700

For a long time that I think to myself, the only way to add anti-aliasing ability into deferred shading renderer is to mess around among its steps which involve some kind of tedious tasks, rerouting and higher maths stuff. So I haven’t taken a look at this seriously until someone popped up this issue again and I have an enough gap to make it done. Then it’s time …

Anti-aliasing in normal rendering environment can be enabled via toggling a flag telling a hardware to do that for you. But when deferred shading is in place, that thing is not supported. You have to do it yourself.

The whole idea I started with is “how we can do this in post-processing”, if that’s possible at all? The fact that I don’t want to mess around among important steps of deferred shading to add another ability. If we could, do it outside the box separately is a good way to go. At least, if something happens we know where it comes from.

I found a starting point here. I remember I went back and forth with that link for several times. A reason that S.T.A.L.K.E.R was the very first to implement deferred shading already prove for a gogo that AA would be possible. Nonetheless, I don’t fully understand the code at the first read. It requires readers to assume something, and make something available before apply the code fully. Then I found this. A very interesting idea came from the guy in forum named “Styves”. He seemed to found or create a new adaptation of AA as post-processing technique for deferred shading which works quite well with jungle environment with lot of short edges showing on the screen. The basic idea is to calculate the difference between color space of pixels around the center (in pattern). Then form normal to represent the direction that should be for the that particular position of edge. Finally, get the color samples up again with the perturbation of texture coordinate from newly calculated “normal” representing each pixel, in order to sum them up and give out a final color. Unfortunately, this technique don’t work with my engine. It gave out not acceptable result, merely the same as NO AA.

Continued searching, and I found this one. Another technique called DLAA (DirectionaL Anti-Aliasing) which is used in Star Wars : Force Unleashed II. I personally think that the idea is similar for most of AA as post-processing here. The main differences come from how we approach to find edges, and additional specific steps. It may need more samples, with weird patterns, and some higher maths if need. I added DLAA as a post-processing into my RealKo engine, the result is decent. Much better than previously, things get a little bit more blurry but jaggy edges are gone. But in a certain angle, it can’t 100% solve the problem but just reduce it.

DLAA takes 2 passes. First pass is used to create edge representation image that will be used as input for the next pass.

In fact, the first pass just marked the edge of all pixel in the input image (which is the final combined with light resulting from deferred shading’s process). The clever portion of code which I liked the most is that it actually marks the edge for each pixel and stores that piece of information via alpha-channel of the input image itself. This cuts a need to temporary render target to hold a result from Pass 1. So we can draw the result direct to back buffer, and Pass 2 just continues using it as an input. Anyway, I don’t use this benefit as I may have to use a result from deferred shading again. So I won’t mess things up with it, and insist to create additional render target to hold the result.

Then it comes the second pass. This pass will operates on edge data produced from the first pass. It then measures for short edge, and (if need) long edge. It do several calculations to create data in order to get amount of blur to finally applies to result pixel.

Short note: Due to its several instructions required, SM (shader model) version 3 (at least) is needed. Thus it breaks my SM 2.0 for this ability especially.

See some shots below (click on image for original size).

As mentioned, I doubt that there always will be some certain angles that AA can’t solve? Please take a look at the first pair of screen shots. The position of camera is on the tower looking towards the runway in a far sight. We partially see some white swapping with gray color in both edge of runway, and it rather seems we can do something about this.

Anyway, anyhow, at least a decent AA already did it jobs here: Reducing jaggies.

Keep rolling …

Testing platform powered by #preprocessor

Sat, 21 Apr 2012 15:19:00 +0700

Early in the time of yesterday night, I decided to follow along with the challenge “On your own” situation of OpenGL graphics programming.

That was to create a pyramid with its sides rendered using TRIANGLE_FAN, and its bottom rendered using TRIANGLE_STRIP. Multiple vertex buffer or VBO can be used to accomplished with no limit in imagination or other implementations.

So it popped me up to enhance my own existing testing platform playing around with OpenGL to support additional (and separate) testing project.

For sure, if you invested your effort in creating code-base that much to ensure a solid ground to build up on then there’s no need to move away from that unless you have to. So that night, I come up with all-in-one testing platform which allows you (and me) to test your testing program without the time lost in creating a new project or re-add source files into it.

First thing first

Firstly, I started the whole OpenGL testing with only basics and general in mind. I have several testing demo in place.

It’s not a full feature run once then select which demo you want to see, but rather it compensates me times to push in developing each pure testing demo instead, so I stick to select it at the compile time by change a number in #define.

Some of testing demos make use of the existing demo, so there’s no need to write those code again but rather just add features into the existing one.

The original block was for TEST_SUBJECT #4, but as time goes on I also added TEST_SUBJECT #7 on top of #4. So whenever you run #7 you will see anti-aliasing feature enabled for #4.

Another alternative is to catch up keyboard event for particular key, then you can switch between enabling/disabling anti-aliasing feature of #4. Anyway, it’s not my purpose to involve keyboard event catching here, I would rather focus on pure rendering code direction.

Getting bigger

Now I need a separate project to better serve my another testing purpose. Instead of creating a new XCode project and re-do work you already have done previously, I rather add it to one place.

Basics is what I have at first, PyramidBasic is another I would like to spawn/separate the code for. Thus I organize the whole project with grouping folder here, finally the key part is main.cpp.

By the way, Haxek, a sub-project referenced from elsewhere, it’s my slowly in-progress OpenGL game library and is used to power testing demos.

By using the power of preprocessor you can get rid of unnecessary headers file you don’t want to include as they’re not part of the demo you will be running sooner or later.

Anyway, it depends on your system design as well. In main.cpp, you will have to create a right object from a right class (HaxekGame1 or PyramidBasic) in order to correctly hook up the game loop and make function calls to the right place. To solve this, just use preprocessor again.

The fact that game is a pointer to Haxek class; my base game class, and HaxekGame1 and PyramidBasic inherited it, and it exposes virtual functions for derived class to make use of them. This way, we can ensure that hooking up for game look and making function calls are correct and in a good shape.

What preprocessor does in the case of function createGame() above is that it wipes out unwanted code so that the compiler doesn’t have to look at it. For instance, I chose TNO = 2, then only header I (and compiler) will know and have knowledge about only comes from PyramidBasic.h, we don’t know anything about HaxekGame1. If preprocessor #if statement is not used here, and we use actual C/C++ if statement then things will get messy. Compiler won’t know about it and will generate error telling you HaxekGame1 is totally from nowhere.

In any case, yes, we can include all those headers and don’t touch anything with preprocessor. But by doing that, we have unnecessary code and may lost memory into places we have no chance to use. We can do better than that right ? Yes, we can.

What we got

This one when I set TNO = 1, TEST_SUBJECT = 15.

This one when I set TNO = 2.

This approach would serve you for a quick and robust testing platform without time lost in managing or dealing with IDE stuff. Yeah, keep coding …

Timing system. It's about my code!

Mon, 16 Apr 2012 21:50:00 +0700

This post responds to my previous post about timing system in game, and issues I met during testing.

I mentioned in that post about the issue of tearing / unsynced / jittering of the result graphics I met whenever running in full screen mode of GLFW application. In fact, the problem lies inside my timing system.

The root cause is that in fixed mode, I sent in a wrong elapsed time into update() and render() function. So they all behave in unstable way. The correct value should be fixed elapsed time says 16.67 ms for 60 fps instead I sent in a value in the same way of non-fixed mode.

Another cause that might hurt it more is about burst elapsed time in startup. The way I hooked up and initialized time (or clock) in my system needed to be in concern. The start time is initialized outside working loop and before the window is created or showed up. Thus the starting gap produces large elapsed time that will hurt the internal timing system at the end, and make it to behave wrongly.

Let see the code of my fixed and working game’s timing system.

/*
 ============
 Haxek::mainLoop
 ============
 */
void Haxek::mainLoop()
{
    // Timing
    clock_t cur_clock = clock();
    m_diffClock = cur_clock;
    m_diffClock = m_diffClock - m_frameClock;
    
    // Update frame clock
    m_frameClock = cur_clock;
    
    // Set time to elapsedTime
    float diff_secs =  m_diffClock * 1.0f / CLOCKS_PER_SEC;
    m_elapsedTime.secs = diff_secs;
    m_elapsedTime.ms = diff_secs * 1000.0f;
    
    m_fps.update(m_elapsedTime);
    
    if(!m_isFixedTimestepMode)
    {
        update(m_elapsedTime);
        if(m_elapsedTime.ms > m_target_fixed_timestep_ms)
        {
            m_isGameRunningSlowly = true;
            m_droppedFrames++;
            
            // Catch up
            update(m_elapsedTime);
        }
        else
        {
            m_isGameRunningSlowly = false;
            
            render(m_elapsedTime);
            postRender(m_elapsedTime);
            m_fps.incrementFrame();
        }
    }
    else {
        if(m_elapsedTime.ms > m_target_fixed_timestep_ms)
        {
            m_isGameRunningSlowly = true;
            m_droppedFrames++;
            
            // Catch up
            ElapsedTime fixedElapsedTime;
            fixedElapsedTime.secs = m_target_fixed_timestep_ms / 1000.0f;
            fixedElapsedTime.ms = m_target_fixed_timestep_ms;
            
            update(fixedElapsedTime);
        }
        else
        {
            m_isGameRunningSlowly = false;
            
            m_countingUpdateTime_ms += m_elapsedTime.ms;
            
            if(m_countingUpdateTime_ms > m_target_fixed_timestep_ms)
            {
                m_countingUpdateTime_ms -= m_target_fixed_timestep_ms;
                
                // fixed: major
                ElapsedTime fixedElapsedTime;
                fixedElapsedTime.secs = m_target_fixed_timestep_ms / 1000.0f;
                fixedElapsedTime.ms = m_target_fixed_timestep_ms;
                
                update(fixedElapsedTime);
                render(fixedElapsedTime);
                postRender(fixedElapsedTime);
                
                m_fps.incrementFrame();
            }
        }
    }
    
    // Post
    postMainLoop();
}

I designed it to be portable and be able to easily and flexibly integrate with many of open source windowing library out there. At the current stage, it works with GLUT, FreeGlut, and GLFW. Anyhow, the code above should be independent of any libraries we decide to use as it’s one of cores to game application.

In code

I will base the precision and granularity from clock() function. It returns ticks, and we need to convert it back to seconds, and millisecond as if we need to. In the process, we need at least 3 clocks to make fixed/non-fixed mode happen.

As well, I already mentioned that this inspired me much that let me keep what I’m doing here. I added a flag to indicate whether the game is running slowly as well as the amount of dropped frame for performance monitoring purpose. If the game is running slowly, we will drop a call to render() and catch it up by calling update(). In fact, we could do it even better by setting a maximum amount of dropped frame to be accepted. So if it exceeds the limit, we can then take some responding actions or warn users.

Note the code section at “// fixed: major” as well. That’s a piece that I missed it at the first go, so it produces unstable of rendering result.

A couple of places found in the code is a placeholder (function) for specifying callback function in the wrapper class or inherited class. So this function is as part of a core class.

60 FPS ? More or less ?

Mon, 16 Apr 2012 16:43:00 +0700

This is a continuing post for my OpenGL journey days.

With the fact that I’ve started with a bare-bone OpenGL then I have to hook other stuff manually. The first important stuff I need to pull it in is Windowing System.

Talk about Windowing System, there’re plenty rather several out there readying libraries to be linked with in no time. I started the whole things with GLUT, a plain simple yet old and non-active development since several years ago but already found itself in Mac OS X platform since several updates and it’s there and no more effort to download and brew thing again. So at least it guarantees to be a component which exists for wide (legacy and plain old) users and developers.

I came across using GLUT with no pain, and easily integrate it with my OpenGL testing platform in no time. It’s clean and fast readable and understandable. Not long that I progressed through the true understanding of the history of OpenGL and its way of working. The deprecation model, its compatibility and profiles pop up the need to properly create a correct OpenGL rendering context!

It’s totally different if you use OpenGL 2.1 or 3.0. You just jump into another boundary world with (maybe) no turning back. Apparently upon the pile of research over Internet about OpenGL and its deep technical jargon history. OpenGL on Mac OS X seems to be very lag in progress, and staying late after other major platforms like Windows, or even Linux. OpenGL 3.x, if I can remember it correctly, seems to be supported in Mac back in its platform updates version 10.7 in July 2011. Yes, not only we should wait for it but also driver and extension updates from ATI as it’s the main part of graphics card installed in Mac system. I understand the feeling of author of OpenGL Super Bible 5th Edition in which it came out in the time of Mac didn’t support OpenGL 3.x just yet.

For OpenGL context creation, developers need to specify which version and whether they need the code to be compatible with older version or plain-through forward compatible context. This is done with its context creation, and it’s the problem in using with GLUT.

GLUT offers no context creation setting. It forces developers to use what’s there automatically and compatibility in mind across all the platforms. I found this out when I wanted to know which OpenGL version it created for my testing application via glGetString(GL_VERSION) which returns 2.1 ATI-7.18.11. Darn, no way! With this set up, I can’t even test the code with 3.x. So I turn it around finding a more customizable windowing library.

It comes FreeGlut, a free version and open source alternative of GLUT. GLUT, in fact, is not an open source. Its license goes to Mark Kilgard. Any modified source code of the library must be shipped with the the product itself. It restricts some of limitation most developers won’t apply. Then I have my hands on FreeGlut. It turns out that FreeGlut is not friendly with Mac OS X at all. Its user-based not land in Mac platform but spread throughout Windows, and Linux/Unix. Only a very small percentage of Mac users use it. I decided to use this because it’s same same code to GLUT and its cleanness and approach in hooking function calls which I like the most but with additional ability to customized in OpenGL context creation!

At the time, its main website listed out 4 major stable packages to download. No pre-build available to download for Mac or any other platforms. So I have to manually compile and build it. Several failed attempts to compile and build come to desperate to find another solution. So I turn around again to another one, GLFW.

I successfully compiled and built GLFW and not much in effort to hook it up with my application. Everything is done but with one exception that my own timing system (implemented as part of testing OpenGL platform) doesn’t fully work out cleanly with GLFW.

To be more elaborate on timing system, I implemented it since my day one in testing OpenGL application. In game, we need not the ability to fully render all content of the game in full speed of 60 fps but it would be better to restrict it or even no limitation on fps at all. That comes with the topic of Fixed Timestep and Non-Fixed Timestep. I am inspired by the notion of fixed timestep back in a day I have worked with XNA. Its definition and simple explanation raises the need to provide both options of rendering approach and timing in game. In fixed mode (with ability for you to set a target fixed time as well), your game will try (for my implementation, it will restrict!) to render the game in X fps in which X is what you can set. Not all games on different platforms need to be capped at 60 fps. Consider a simple game with slow paced rendered on low-powered mobile device, just 25 or 30 fps can do a trick. Even web-based game which goes for 25 fps for flash styled. It has its own purpose so timing system is (at least to say) a major part in game application.

My experiment with GLFW only found an issue with my timing system. I found out that GLFW already capped the frame rate at its will automatically, so when I combine it with my timing system lied internally in game loop, the game will be double slow delayed in time! So things won’t get smooth out as it seems to be. I fixed it by disabling a fixed mode, and let GLFW does its work on that restriction alone. It works fine but somewhat raises a question. How can I set a target fps of the game to run with GLFW? I filed out a question here on a main soureforge.net site of the project. I expect someone would come and answer it.

In addition, I experimented with non-fixed mode as well. By setting glfwSwapInterval(0) which means to disable v-sync mode, the application is told to be relied on the capability of software or hardware as it goes, no more restriction here. Also with non-fixed mode is enabled in my timing system, the things run out as expected. The fps goes beyond 8000 which is similar to what I have tested with GLUT. This goes well with fixed-mode enabled on my timing system, now I can cap it to run says 30 fps or 60 fps at will. But that result only shows in window mode, whenever I go to full screen mode the polygon drew is tearing / unsynced / and jittering. I truthfully think that it’s because of v-sync is disabled by the result of calling to a mentioned function of GLFW. Another question raises again on how to prevent those effects with the software / hardware (graphics card) were already told to render the content as fast as possible with no restriction ? So I replied to my own earlier question and ask about this as well.

A bit to mention that during a laboring test with GLFW, I even went back and tried to find a way to compile FreeGlut. Indeed, I found one. Initially I don’t care even if it does only compile with not latest version but rather 2.6.0, just give it a go. After successfully compiled and built the libraries, then hooked up with my code in action, I feel disappoint immediately. Why? FreeGlut uses old X11 system to show up its window. I don’t like this as it needs to open up X11 agent program first before it can even run your program. That’s case bringing me back and forth and at best try to make GLFW works out!

For now, I will use GLFW at least for testing purpose with my OpenGL stuff for a long while. It has potential to be my integrated windowing system for yet to come a game product (hmm? hopefully). It offers flexible integration with callback and specific context creation. Also with non-to-mention, it breaks out the loop design (remember glutMainLoop()) and allows developers to hook up the function calls inside instead. At last, if I could find a solution to prevent those tearing / unsynced / jittering effect from uncapped rendering approach, I will definitely update here at my blog.

Updated

- See my updated post responding to the issues above.

Cease PongMaster, go wild with OpenGL

Wed, 11 Apr 2012 18:33:06 +0700

The fact that I have lost my interest over Pong Master, the game currently in my development.

That’s bad, to be honest, that I can’t finish in-progress project on iOS this time. Anyway I have another reason kicking in to put this down for quite some times before (maybe) heading back when it’s possible.

For a couple of weeks ago, I have continued working further for another addition of Airport model for RealKo and it’s as part for my continuing of its phase I development back in a couple of years ago. Not only that I can brush up my graphics programming, but also feel that I should switch to 3D in full engagement from now on or at least several months to come.

RealKo was developed with XNA (of course, it’s on top of DirectX). Sure it will be running only on Windows system. That’s not long ago when I have a plan to myself to port this stuff available on other platforms such as Mac OS X, Linux, or possible to include embed systems like mobile. So I started to look at OpenGL again. That also includes some personal interests watching & listening to detail of games, technology prediction, Id Software, and graphics programming from John Carmack. It totally blew me away!

Days passed with lots of research on OpenGL vs DirectX, OpenGL history, deprecation dilemma, OpenGL implemented in Wolf3D / Doom / Quake, portable code on various platforms including consoles. I feel that those things truthfully kick me to be in front of computer and keyboard with no need to even rest. Hah, that means I may drag my soul back once more.

To be more elaborate on OpenGL as why does it should be selected as a graphics API for from-scratch implementation or anything might be besides Id Software is Wolfire.

From now on, I will be revisiting a lot of technical stuff of graphics programming from vertex forming, texture mapping, shadowing, lighting, to more advanced topic like ray tracing or whatever may placed there in research (or white) paper. I will target to work on it with OpenGL 3.x-3.2 as it’s the best choice for me now and for preparation for the future to come. Intentionally, when it’s saturated in topics and enough in stable I plan to create a game framework based on that beast in order to use for my own in-house game development, possibly in a right time to come.

And for Pong Master, we may see each other again when the time is right, …, but not yet, not yet …

Re-submitted PongMaster for PlayBook

Fri, 06 Apr 2012 01:33:00 +0700

Since I’ve got an e-mail from BlackBerry app world dated back on 15 March stating below …

I just have a chance to start fixing it tonight.

As I have no real PlayBook device, so the successful test on simulator won’t guarantee anything. Back then I have posted asking for suggestion about this situation on http://cocos2d-x.org/boards/16/topics/9372?r=10035#message-10035 . I believe and thought to myself that the cause should be about custom .ttf file I used across scenes in the game. Although there’s a high chance that it’s the root cause of problem, but the same goes -> it won’t guarantee anything. Anyway, just roll a dice and see what’s happen!

PlayBook don’t support custom .ttf file. It probably has a fail-safe on simulator. Apparently, this is a trap that lures me to think my game should be okay if it runs on a real device.

Not at all. Rendering text font on simulator has not failed, it just returned back to normal vague font style. But if it runs on real device, the result goes the same way as stated in the e-mail above.

I have two choices to solve this.

Render a custom .ttf font with XCode, capture the screen, save it into an image file, and finally use it in the game on PlayBook.
Use normal installed font specified via font-face name such as “Time News Roman” or “Courier New”. See the list here.

I know my time is tight and font style is another story according to my purpose playing around with PlayBook here. So I go on with number 2.

In addition to that major fix, I also fixed a ball speed by adjusting a ball’s mass with the observation on a simulator.

By the way, my fellow rahulbolia who I met on this thread http://devblog.blackberry.com/2012/03/package-id-rejected-by-app-world/ about solving unsigned .bar but accidentally submitted to App World didn’t seem to get an e-mail asking about shipment address yet although his application was approved on 14 March and he already sent e-mail to ask them about it. If ones meet the same situation, you better check that link out.

Did this for you, Earth.

Sat, 31 Mar 2012 19:51:37 +0700

Did this for you, Earth.

Tank - Experimental Project back in Nov 2008

Mon, 26 Mar 2012 20:46:42 +0700

My mind is going to be miss-understood in myself, I can’t decide whether to post this kind of stuff (old stuff) Now or Dated back in time.

It’s kinda cheat in its own sense as a new post has gone through the blog without traces or even know about. That’s initially my pure sense without knowing that it’s actually true at the end.

So then I investigated whether the Dated back in time post will be seen in Archive / Search section ?

No sir ! I can’t find it, so the dilemma concluded and ended with the way I will select to post any Dated back in time in Now.

—- Let’s jump into a topic —-

Before I even give some explanations, visual comes first.

Tank is an experimental project I did back in November 2008 to test out accessing model’s structure, its manipulation & transformation and home-made physics for tank’s movement on the ground.

It’s a small world that you can experiment things you want.

Terrain was generated by height map with procedural approach, so we got a natural scene as you might perceive.

Tank model itself has some parts which we can interact and manipulate or transform (not only scale) with them.

Its turret can be rotated as well as its cannon which can be lifted up / down. I just need to know which axis to do the work.

From the experiment, I rendered 3 axises {Red, Blue, and Yellow} representing each part of the whole model in order to see whether it’s properly manipulated or transformed.

Well. As far as I concern, it did its job quite well.

Not only model I experimented with. The home-made simple physics for Tank’s movement on the ground can be done as well. It gave out more realistic when Tank moved on across the different level of ground, yes, you’re back in World War with this set up.

I’ve blended the test altogether and see if one effects another. You can see axises were slightly off, but that I believe it’s because of rendering code of those axis which need to be more accurate than what it was now.

Apart from those, we could do a little bit more by playing with camera, and modes which could be available for Tank’s driver.

Camera is such an important puzzle to look at in order to boost the feeling of how we could achieve the word “interesting”.

3 modes of camera were available

Normal
Followed-camera or fighting mode
Bird-eye-view

For the scene, it’s applied with simple shadow mapping (which in turns broken at the moment I found this project deep into sector of harddisk, I don’t have time to fix it now though).

Skydome was made into life by the approach of transitioning of cloud map over its mesh.

Fork / Clone / Download / … you name it

Well, well. I have made all source code available for anyone interested in those experiments. The code may not be optimized and may not represent the best I could offer as of now.

So just head to https://bitbucket.org/haxpor/tank/ or directly grab it at https://bitbucket.org/haxpor/tank.git or git@bitbucket.org:haxpor/tank.git.

Be sure to read license though. WTFPL is what the best I could tag it for. Anything can happen right ? ;)

Til next time.

Doodling - Pixeling - Animating, "FatRobot"

Tue, 20 Mar 2012 03:55:00 +0700

This is a 2nd day since I jumped into the world of pixel art as a need to teach my coding hard self to be able to create art stuff and put it into a game. As far as I can tell you, I fell hard loving it already !

This time, I decided to create a few frames animation of pixel art. The reason is plain simple. Game uses spritesheet, and animation is somewhat a core to game creation. This will let me know more about pixel art’s animation workflow and test exporting into spritesheet.

All things went well, although it consumed my time. A dancing robot you see above is a result, I would call it “FatRobot”.

So let me tell you a bit more about the starting point and the process I just did. It’s a pure sharing experience as I am no expert in art but nonetheless I strongly believe it will benefit someone for something at the end (as well for those who use Aseprite). Then read along …

Conceptualizing

It would be not much fuss if I start with a simple geometry and shape. The first I can think of is Robot. Then only a few conceptual drawings are made and I decided to go with it.

As this is a practice for pixel art animation, so I planned a head of time for each frame I will use for this dancing (kind of aerobics action). It consists of just 4 frames. A few, probably 3-4 is a go, much more than this is merely not need at all. I just don’t need it to be that much precise in movement.

Outlining

The common commands you will use most are “Line” - L, and “Pen tool” - B. As I use this tool more and more on day-to-day work, those shortkeys will automatically digested into your brain in no time !

Titbits here for Aseprite, when you create a new file, the program will ask about resolution, color type, and background. What you enter here is the “Frame” width and height not the entire spritesheet going to be exported later in time. Instead we will modify and draw each frame via layer.

Another thing that it will ask is “Background” type. Mostly we will choose “Transparent” and this is a choice for me as well as cocos2d/cocos2d-x has no easy way (or at least to say not flexible) to mask the key color for transparency on the file for image. By choosing “Transparent” will reduce our work later on in code. So plan about this !

After things are all set, we will have an empty working space. You will see a crossing line in the background in which it indicates that it’s transparent (mask). Personally I really don’t like this distracting background while I’m doodling my robot so I then create another layer and paint the whole layer as white color (or black) just to give me some contrast before actually start draw. This will make me more focus on the subject !

*You create a new layer by pressing “N” (indicated as B on the lower right of the screen, if you click on the image it will direct you to the full quality image).

**And when we export, we just press “Tab” and disable the visibility of layer B, so the whole things are normal the same as we start creating this robot !

So recap here,

Layer A - just mask or transparent plane
Layer B - contrast plane in white or black
Layer C - the plane we will work on and do some drawing

Coloring & Shading

First before we go into coloring, we need to limit ourselves by select some colors to work with. As I’ve read from Derek Yu’s tutorial, we should focus on a few color (2-3 colors) for the whole work we create. For pixel art, more colors mean distracting.

“Take Mario character as an example.”
I digested this from Derek Yu’s tutorial.

I chose to shine out only 3 colors “Red”, “Blue”, and “Flesh”.

But …

not just select some color as a main, we probably need other colors to support or to do gradient as well. So it’s a better idea to create our own palette.

The way to create a palette in Aseprite is as follows.

Create a new file with arbitrary resolution.
Use “Line” to isolate each color.
Paint each vertical block with desire color.
Click “View”->”Palette Editor”.
Click on “+” symbol and click “save”.
Choose format of image file.
Done, you have your palette in a formet that compatible with Aseprite program.

In fact, there’re number of possible ways to do this as per your own taste. From the image you see above, I listed out the possible colors I will use and limit myself to them (soft limit, as along the way I broke the rules and add more color later !). The benefit of limiting in this way will keep you focus, and not be overwhelming by so many color to choose from appearing in the left-side palette.

You may question that by limiting the colors going to be used. Will it reduce the file size of image as well ? No, as the color type you choose from the start will already determine it.

Then we load the palette to work with our main workspace by open up “Palette Editor” and “load” it with our file saved earlier.

Then you’re free to engage in coloring.

When you’re done with coloring, then you go for shading to enhance the result of your work.

Shading consists of the following.

Normal shading
Take a sun’s direction into account and add darker color on top of your colored block.
Soft shadows
These are areas that indirectly lit. Or say, a second shade with lighter color than the previous one. This will give more realistic especially on curved surfaces.
Highlights
Areas that are directly hit by the sun, highlights will occur.

Please note that my work doesn’t have highlights as when I added, it looks strange so I decided to cut it out.

Selective Outlining

A near to finish work. But if we perform this step by eliminate some outline out from our drawing. It will look more realistic and all parts blend together better. Be sure to look the result from the actual size not the zoomed size to judge what’s good for.

At last

Finally, just brush up your work add some more detail. See if anything is missing or feel right/not right. At last, what you’ve done in a past (probably) couple hours will pay out at the end.

By doing all of these, I believe that I found a reason why indie game developers or solo game developers out there are so tie to pixel art. Because it’s the least cost to engage and require not much of learning curve. As well, its pixelated and retro look are quite attractive for game developers to come by and use this technique to create graphics putting into use in their game in no time. In addition, as not all game developers will have their own artists to help them create images as they need, so this way will help themselves out walking by their own legs !

After finished the past 2 days with pixel art discovery and hard but fun practicing, I strongly believe now that I can feed my own game with art resource and the boring times won’t be easily pop up as when I’m exhaust or bored on something (code or art) I can switch endlessly between the two and maintain my own motivation and energy for doing game projects.

Good night !

Yeah ! I’m sure who knew me will be a little bit of...

Mon, 19 Mar 2012 01:01:00 +0700

Yeah !

I’m sure who knew me will be a little bit of surprise of why I did this art my self. The reason is that I need some art in my game and I can’t wait ! ha hah

The most comfortable for me is “Pixel Art” and this one is a real start into this world even it’s just a practicing.

Some time before I tried all by myself, and thought all alone that my approaches are not standard (kind of) and mostly I used feeling with unpolished result. So it’s time I decided to take a look at some guides over the Internet. Fortunately I’ve found a tutorial on notable steps doing pixel art from Derek Yu. I found him in TigSource as a reference to indie games he did.

Instead of using Photoshop, I use Aseprite. Now, as far as I can tell you, I fall in love with it !

Enjoy my humble “Muddy Dragon” for the time being.

Continuing "Pong Master"

Sat, 17 Mar 2012 22:40:58 +0700

Time to focus on creating this game more and more.

Today, I have a chance to meet my sister coming back from Oman to visit me. I knew and planned about this, so a latest build was loaded up in my iPad and took out the playing test with my sister.

There’s a chance for this game to be fun. It eventually needs more features, and enhancement in terms of touching and gesture interactions. As time goes by, hopefully the issues won’t be too large.

Peace …

This time with Yangon International Airport

Sat, 17 Mar 2012 20:45:51 +0700

Now it’s back with support of Yangon International Airport !

I implemented RealKo Engine back in 2 years ago as part of a freelance job during University. Briefly the goal of this engine is to render airport model plus some features to use in training of officers in traffic control simulation.

For Yangon airport model, it’s still in early phase rather than final version but the point is that I’m glad that the engine itself can prove to support multiple or custom made airport models. It used to render Suvarnabhumi Airport as a first model before, and now with another.

moosader: rootstudio: I was poking around on The Independent...

Fri, 16 Mar 2012 00:03:22 +0700

moosader:

rootstudio:

I was poking around on The Independent Gaming Source (which I haven’t done in like forever) and noticed they have a new feature… The TIGForum Image Crawler programmed by Daid. Basically it trawls the TIGSource’s forums for all manner of gaming/poly/pixel images for you to drink in with your eyeballs and more than lives up to it’s caveat…

WARNING: Using this tool might waste many hours of your life. Do not forget to eat and sleep!

Good for inspiration~!

Surely I will waste a ton with this !

PlayBook's Package ID mismatch after failing to submit a signed app

Thu, 15 Mar 2012 12:48:35 +0700

Frustrated at first when just got to know later I’ve failed to sign the application before submitting to App World.

They sent me back two links on how to resolve the issue.

http://devblog.blackberry.com/2012/03/package-id-rejected-by-app-world/
http://supportforums.blackberry.com/t5/Testing-and-Deployment/How-to-sign-your-BAR-file-from-the-command-line/ta-p/944647

And yeah, it works but took some time to figure out this and that.

When I re-submit it again, I got the very top result picture. It stated that my application’s package id is mismatch with the original one submitted. The fact that you’re fail to sign your application in the first time, and re-submit it again will not gonna make both package id be the same. Fortunately I found the solution (hopefully) here.

Briefly I need to shoot an e-mail telling BlackBerry PlayBook offer Support about my case (most guys out there faced this case, so don’t worry), and in the mean time just submit a new application to App World again with the hope that they will still give you a free device :/

Nonetheless even the case seems to close, testing house reported back “When tapped the game it’s closed by itself” and it’s faster than my issue e-mail seem to be replied. Yes, it’s the fact that I don’t have a real device to test, so even it works on Simulator it may not on the real device.

I have to continue figuring it out …

A panorama shot of my room. Just have enough feeling recently...

Tue, 13 Mar 2012 01:36:00 +0700

A panorama shot of my room.

Just have enough feeling recently after read a post here. Then I believe I should share mine as well, it’s no faulty on anything.

I has set this room up since about a week ago. Two main working environments for Mac and Windows side. Of course, currently I invest on cross-platform and open source game framework in which I can work on both side, nonetheless working on one will give more flexible on certain tasks and things relating to specific platform.

At first, a humble netbook beside my rightmost PC used to serve as a gateway for that PC to connect to Internet as its WiFi adapter is broken and malfunction. But now, a new adapter was brought in and replace its temporary survival functionality.

Apart from those, Roland TD-4KX, V-Drum Series is my beast on relaxing state and calm down my mind. It’s placed near iMac as I can plugged and hook up via Garage Band to record my play.

The last stuff is reading side, several books I have collected since several years ago, most of them are un-finished in reading, some of them are finish.

I don’t think there’s a better place than home. Don’t you think ?

3 days spent on Dynamic Content Building Tool

Fri, 09 Mar 2012 17:19:00 +0700

I have spent the past 3 days on creating a tool used to build XNA content dynamically. In fact, this is a extended tool based on my creation of RealKo framework. Back in that time the framework ties to configuration of XNA content (model and xml config files) at compile time, so when users have a new model they need to render in the engine, they have no choice as they need to recompile things up and run it again.

This’s probably not a good approach of flexibility. So it’s time for me to revive things up creating a tool used in this circumstance.

(… and yeah, I just find a time swapping from my Pong Master project to this, and after this post is finished I’ll back on route.)

Dynamic Content Building with XNA

What’s the approach I will use here ?

I will let users select an arbitrary model file (mainly focus on .fbx file) to load, then the tool will render it with Deferred shading technique in the program. In fact, it’s not quite fully deferred shading as although your rendering pipeline supports that but with the simple set up of directional lights coming from all 4 ways in 3d space. So it seems everything seems bright. This is a limit as if a timeframe to develop such a tool is not much, and users want just a visual aspect with no fancy so this set up is a fast way to come up with.

Take a consideration into point lights, or spot light targeting at some areas not all area. Deferred shading would be perfectly beautiful for that. If time to creating a customization and set up of different light source is there, then this will leverage rendering pipeline and visualization even further.

So back to the point. It seems like simple enough to just let users select a model file. Unfortunately as I discover that the basic framework cannot identify and automatic discover diffuse texture mapping to each mesh of the model. Although the artist already attached the diffuse texture for each mesh back in 3d tool, and export it nicely. Yes, the information is there in export file (as I examine it via normal text editor, the export file is in ascii format so it would be great to let artist exports it in this format for your ease in debugging) but the framework only can discover only one and the first diffuse texture assigned to any mesh of the whole model. Please note for the case prior I used BasicEffect to read the texture out. I’m not sure whether there’s some ways to do.

So I solved it with another approach by using configuration file to define which mesh maps to which texture. In this way, you can use ful textureset as they are diffuse texutre, normal texture, and specular texture if they are any and available to use. That would be a great choice of rendering in terms of this technique (of course even better with the customization of light source).

In order to know which mesh is mapping to which texture. There’s a need to also export model’s structure. This method goes inside the model for each mesh, and print out its mesh index, bone index, or even do other calculations such as how big of the model, its radius, and number of polygons. Even more complicate ways to implement this is via ContentImporter or ContentProcessor in which these two I don’t go with it with this project. For the case I used, only load a new model and process it manually from the interfaces provided to access of Model class. It’s quite simple enough not to goes so complex.

With the information of model’s structure, users can take a look at the output file and see targeted mesh for its mesh index then go back to text editor to create an xml file that will be used for loading into a program later on.

The following is the sample of the xml file described a model being load.

<?xml version="1.0" encoding="utf-8" ?>
<Model>
    <Name>Ship 1</Name>
        <FilePath>ship1.fbx</FilePath>
        <Scale>1.0</Scale>
        <Meshes>
                <Mesh>
                        <Index>0</Index>
                        <BoneIndex>-1</BoneIndex>
                        <Textures>
                                <Diffuse>ship1_c.tga</Diffuse>
                                <Normal>null</Normal>
                                <Specular>null</Specular>
                        </Textures>
                </Mesh>
        </Meshes>
</Model>

At this point, we could have a config file being compiled as a XNA content. That is to say both config file along with model file and its texture files are in region of XNA content. If so they are in need to be built at compile time with Visual Studio. This is not an option here. So instead I just normally read an xml config file via normal I/O provided in .net framework. The flexible class I used is XmlDocument. If you take a look at it, you will see how flexible to work with nodes, tags, and its value in xml file rather than messing up with serialization and parsing through the entire xml file. The great thing about XmlDocument class is that, it allows developers to access the target value in chain just like.

node.GetElementsByTagName(“Book”)[“Author”][“Name”][“FirstName”]

And that’s it about the approach I used to create this simple humble tool.

Things to note, erros to note

MSBuilder is a core builder used to compile content into .xnb in runtime. It’s different from ContentManager as appears in the Game1 class of normal XNA game project. MSBuilder is at another region different of ContentManager, so when you call Load() via MSBuilder it actually does on a temporary directory. A little bit more about it is that, the stable and safe version that has worked since XNA version 3.0 is MSBuilder version 2 which consists of the following

Microsoft.Build.BuildEngine - version 2
Microsoft.Build.Framework - version 2

It has 2 versions which are 2, and 3.5. Mostly when you add their reference into a project, the default one is version 3.5, and when compile the project and run, things go error and error stating something weird. So we better stick to version 2.0.

There’s also a file called App.Config used as a trick to bind reference conflict for Build.Framework. Its content is as follows.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="3.5.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>  
</configuration>

If you download your base project from somewhere to further develop on such as from App Hub, and found out that you found an error. This might be one of the cause. Please check if this file is exist in your project.

Another big chunk lies inside ContentBuilder class which provided by Microsoft for convenient in development involving with content builder. The things to note about this file is firstly the version of XNA to build against. If you switch to another version of XNA, make sure to change this line to match XNA version.

        // What importers or processors should we load?
        const string xnaVersion = ", Version=3.0.0.0, PublicKeyToken=6d5c3888ef60e27d";

If you build your own custom Importer/Processor, and you found an error stating that the system cannot find your custom content class while it’s reading, then you might not include the reference of those content class to your main project just yet.

*From above, there’s a high chance that you will create another library project just to hold your content information and be referenced by other projects in development. For my case, once I tried, I have at least 4 projects to hook.

XNA game project
Winform project
ContentShared (just to hold content information, it’s XNA library project.)
Inside, it will be a data class and a ContentTypeReader class corresponding for each data class.
ContentPipeline
Inside, it will be ContentTypeWriter class to write data out into .xnb file.

So ContentShared project is a central of data information for your content.

To note, I use XNA game project instead of implement a rendering inside winform application. If I do that, I have to mess up with GameTime, the controls and things will got messy. I found the solution on how to hook up render each frame of XNA project into a picture to draw on PictureBox control on winform. It requires about 10 lines of code, and it works like a charm, please check it here.

So back to reference things. You may need to try to add a reference to make the ContentBuilder knows via code by doing the following.

1.) Add a direct code into pipelineAssemblies at the very first of the code in ContentBuilder class.

        static string[] pipelineAssemblies =
        {
            "Microsoft.Xna.Framework.Content.Pipeline.FBXImporter" + xnaVersion,
            "Microsoft.Xna.Framework.Content.Pipeline.XImporter" + xnaVersion,
            "Microsoft.Xna.Framework.Content.Pipeline.TextureImporter" + xnaVersion,
            "Microsoft.Xna.Framework.Content.Pipeline.EffectImporter" + xnaVersion,
            "E:/somepath_base/somepath_sub/bin/Debug/ContentShared.dll"
        };

But note that this is not so elegant as it’s fixed. A better is to determine the current working directory via Path class and get into a correct directory.

Sample Screenshot

…

I guess that’s all about what I would like to say.

Happy coding and hacking !

Pong Master - Progress

Mon, 05 Mar 2012 10:32:00 +0700

I’m quite happy with my progress over this small game I have made so far.

Now, it’s modified to be in universal application in which I inserted the adaptive content scaling into the game. Please don’t be too amazed with that word, may be I’m not sure which word to use :P

void Utility::SetUp() { 
// get the current device's window size 
CCSize winSize = CCDirector::sharedDirector()->getWinSizeInPixels(); 
// precompute values (must call this after CCDirector is created) 
_precomputed_adaptedContentScaleFactor = fminf(winSize.width / 1024, winSize.height / 768); 
// set device active use 
if(winSize.width == 480) 
    _deviceActiveUse = DEVICE_IPODIPHONE_3; 
else if(winSize.width == 960) 
    _deviceActiveUse = DEVICE_IPHONE_4; 
else if(winSize.width == 1024) 
    _deviceActiveUse = DEVICE_IPAD; }

See SetUp() function above, it’s not that elegant that I use the very basic method to detect which device currently runs the game. Yes, you may use macros or any functions specific to platform you’re developing for. But this approach works, and I tested it on iPhone (simulator) and iPad (simulator / device). Anyway please note that, I use cocos2d-x here.

I learned about the formule from reading in this link http://www.cocos2d-x.org/projects/cocos2d-x/wiki/How_does_cocos2d-x_support_multi-resolution.

So by knowing which device users’ using, then I route things up and multiply the scale factor to values that needed to be scaled especially in positioning code. So I made this game once and give it a little effort on modifying a positioning / scaling code for objects appeared in the game.

See iPhone version below (captured from Simulator).

One interesting piece of information from my testing is that whenever you modified the size of sprite then its physics properties you hooked up with Box2d may needed to be adapted as well. The ball is the case. As original, its size is bigger and one fixed value of density is fixed as well. But then you resized the ball (to smaller) then it’s previous value of density mapped to the sprite is too low, and it makes the ball moves really fast !

Again with a benefit to detect which device is running, I can set different values of density to a ball for different device running it. See snippet code excerpted from this project below.

 
// Create shape definition and add to body 
b2FixtureDef ballShapeDef; 
ballShapeDef.shape = &circle; 
// ** selective depends on device active use 
// set density depends on device active use (affecting physics properties) 
int deviceActiveUse = Utility::Instance().GetDeviceActiveUse(); 
if(deviceActiveUse == DEVICE_IPAD) 
{ 
   ballShapeDef.density = 1.0f; 
} 
else if(deviceActiveUse == DEVICE_IPODIPHONE_3) 
{ 
   ballShapeDef.density = 10.0f; 
} 
else if(deviceActiveUse == DEVICE_IPHONE_4) 
{ 
   ballShapeDef.density = 5.0f; 
} 
ballShapeDef.friction = 0.0f; 
ballShapeDef.restitution = 1.0f;

I will be thinking what’s more to be added into a game, what’s I’m missing now and then. More to be come.

{Edited}

Fixed that actually my code has a flaw, changed CCDirector::sharedDirector()->getWinSize() to CCDirector::sharedDirector()->getWinSizeInPixels()
This will take into account retina enabled for both iPhone 4 and new iPad as well.
You can find more information about this at http://www.cocos2d-x.org/boards/7/topics/4025?r=9559 .