• Advertisement
Sign in to follow this  
  • entries
    27
  • comments
    25
  • views
    6334

Entries in this blog

Life is ironic

How come the more you learn, the more you realize that you are not an expert?

I mean... if you think you know how something works in the beginning and then really dive into it, you always end up thinking "how could I say that I knew something about this before I learned all this?".

You define that you know everything about for example a programming language and environment after having worked with it several years. Then you get into a series of problems that cause you to open your books again searching for a solution, and wow(!)... you learn something new. After several problem solving tasks you have learned so many new things that you just laugh out loud when you think back on the time when you thought you knew everything.

Isn't this ironic? Doesn't the process of learning ever end [rolleyes]? Are humans constructed to learn all their lifes about everything and everybody? I think so. Why else would the term "science" exist?
The last few days I've been trying to solve some major problems with my old design. One of these is the fact that you were limited to 4 simultaneous collisions per object and the collision detection shader was always run 4 times the number of objects. Now I have a new solution in which an object can have an arbitrary number of simultaneous collisions and no irrelevant pixels will be processed. My current best solution still has broad-phase collision detection on the CPU, which requires a read-back of the position texture (128x128 32-bit FP). However, the alternative would be either to test every object against every other one, which is a REAL performance killer!!! I tried to find a way to do broad-phase CD on the GPU, but always ended up with expensive or impossible-to-implement-on-GPU algorithms [totally]. I've not given up on this yet, but will put it on ice until everything else is done so I don't get stuck...

This evening, I also created a simple scripting system so that I can define all textures and passes in a text file and not have to hardcode them in the program. This will really simplify testing of different configurations and it will not be such a pain in the *ss to test a configuration anymore...

Now it's 2 a clock in the morning and I think I have to go to sleep so I don't kill myself working [smile].

Good night!
I have completed a quick case study of an existing physics engine (ODE). This gave me a better overview of how a physics system works. Up til now I knew how the details worked but not how they might work together in an engine. I got some things to think about now regarding how to make my GPU system more useful for more than just a dumb rigid body simulation (one of the main requirements for the project is the ability to communicate with other systems like AI and animation also running on the GPU*).

* The project is a part of an investigation of using hardware instancing to draw agents with physics, animations and simple AI (group movement and decision trees).
Came across this article (written by Jeff Plummer) by chance yesterday while I was browsing through Ogre tutorials to learn Ogre. It treats a somewhat different architecture for putting together a game from subsystems such as graphics, physics, AI, sound etc. For people like me -- who have at *least* basic knowledge in most major areas of game subsystems/engines but no real experience of putting together a full game -- it is easy enough to use one single engine in an application (like when creating a graphics demo you don't use AI for example). But when you have an application rendering a scene and want to turn it into a game you get stuck!!! Where are you going to add that extra code? How to organize it? This is where you should have thought twice in the beginning regarding the architecture that defines how different subsystems work together. Jeff describes a very easy-to-implement, easy-to-extend and easy-to-upgrade architecture. I found his idea interesting and started a design and implementation of it today in my spare time (I did some major changes compared to his prototype).

What I want the most of all for Fortia right now is to start development of the Game itself. So I think I'm going to move over to use engines created by other people (Ogre, ODE etc) for use in Fortia as well as Jeff's architecture. It will speed up the development significally compared to having to reinvent the wheel [smile] (especially since the team is very small). I learned a lot working on FortiaEngine and it has already served as a significant portion of my portfolio, but I have to be realistic if I want to get the game done!!! It also helped me understand Ogre and Nebula in just a few days!

I just want to finish this topic with a tip to all people working on their own game:

Consider reading the article and move to use finished libraries/engines!

For me this took years to understand and I'm sure I'm not the only one! Like a big group among game programmers I have had the ambition to code most things myself! If you're not in this group you're lucky! [smile]

Til' later!
Came across this article (written by Jeff Plummer) by chance yesterday while I was browsing through Ogre tutorials to learn Ogre. It treats a somewhat different architecture for putting together a game from subsystems such as graphics, physics, AI, sound etc. For people like me -- who have at *least* basic knowledge in most major areas of game subsystems/engines but no real experience of putting together a full game -- it is easy enough to use one single engine in an application (like when creating a graphics demo you don't use AI for example). But when you have an application rendering a scene and want to turn it into a game you get stuck!!! Where are you going to add that extra code? How to organize it? This is where you should have thought twice in the beginning regarding the architecture that defines how different subsystems work together. Jeff describes a very easy-to-implement, easy-to-extend and easy-to-upgrade architecture. I found his idea interesting and started a design and implementation of it today in my spare time (I did some major changes compared to his prototype).

What I want the most of all for Fortia right now is to start development of the Game itself. So I think I'm going to move over to use engines created by other people (Ogre, ODE etc) for use in Fortia as well as Jeff's architecture. It will speed up the development significally compared to having to reinvent the wheel [smile] (especially since the team is very small). I learned a lot working on FortiaEngine and it has already served as a significant portion of my portfolio, but I have to be realistic if I want to get the game done!!! It also helped me understand Ogre and Nebula in just a few days!

I just want to finish this topic with a tip to all people working on their own game:

Consider reading the article and moving to use finished libraries/engines!

For me this took years to understand and I'm sure I'm not the only one! Like a big group among game programmers I have had the ambition to code most things myself! If you're not in this group you're lucky! [smile]

Til' later!
(Finally, after having been sick for more than a week I'm back and ready to work.)

I have a lot to do on GPUPhysics now so i think that will be the center of attention for i while when creating the collision detection on the GPU. It's the hardest bit of all and I'm not as sure of that solution as of the integration shader i've written earlier. In short: it's a wild-card and can be done in a day or in two weaks, who knows? I also had some problems getting a test system up and running because it took too much time with basic stuff and hardly kept me motivated.

Conference

I just came home from Stockholm where I was at the "ATI Nordic Technical Day" (thursday). This was a conference where ATI, Microsoft, AMD and Havok worked together and held different presentations for Game Developers. I'm glad I went there because it resulted in an employment interview with the Swedish game development company Avalanche (just released the game Just Cause). But I didn't have a chance to work anything... just conference and party... [smile]. And now I will have to put together some demos to send to Avalanche...
After some thinking I decided to join zEROx on his RPG project Elium. So I'm kind of freezing the development of my engine for a while. It would not be the first time [smile]. As a hobby programmer you have the choice to do what you like, at least with projects on which you are the only developer and don't have deadlines! That's life!

But I'm going to finish the chess game now because it's such a small project (more like a demo...) and I almost got the network done by now. Didn't work on it today though because I tried to get the Nebula Device 2 Engine (the one that is used in the project I'm to join) to work on my computer. Really nasty process!!! And no tutorials or samples... but will have to learn from the existing game code.
Ok... so I have some time over here. I think I will do some things on FortiaEngine now (I like to switch my projects when I get tired of the one I'm doing...). I think an introduction of the game Fortia for which I write the engine is in place...

****************************************************************************

"-- You cannot see anything but light. Suddenly you realize that you are inside a deep mist or cloud and figures start to appear in it. Figures whose likes you never saw before, figures with a God-like appearence! They seem to be in a state of panick and look like they search for something. You are then transported into some kind of cave under ground and monsters are all around you, but... don't seem to know you're there?! They are celebrating! You see their leader holding up something, but you cannot see what it is. Everything gets dark. You hear people scream and the sound of soldiers fighting in war. But a calm voice seems to come from a point close to you... --

You wake up and realize everything was just a dream. But something inside you has changed, and when you look up you see a priest standing next to your bed. Things start to get strange when he tells you that he wants to teleport you to Fortia, the Gods' Reach...

Fortia will be a roleplaying game in 3D where your main quest consists of getting back the stolen item to return peace and as well as solve the mystery of how it landed in the wrong hands. You can do this two ways: By becoming a priest and fight openly or by becoming a spy and fight in secret. But to be able to do the main quest you will need to gain experience by adventuring. This is done by exploring the world, doing quests and fight any enemies you may encounter..."

****************************************************************************
I've now completed coding and designing (and coding again [smile]) my simple network system. It kinda' exceeded my expectations of what I thought I would be able to do when struggling though my first network code yesterday.

Here are some examples of how it works...

First: It's a client-server model application, and as an example, suppose we have the users "Mimi","Peter","Dan" and "Robbie" logged on (you are logged on whenever your chess game is in network mode). Here's an image...



The example continues with the connection of a new user...



To be mentioned is that the server will keep track of all logged in users in two lists: one containing all users and one containing those that are not currently playing.

Now how does game handling work?

We now have the current setup:



and Dan wants to play with Mimi...



NOTE: the show setup images contain information on other actions as well (messages in red text to the right)

As you can see the server is a kind of lobby... but handles chess draw transfers as well (chess play data is not much (4 bytes per draw) and is only transfered each 1-5 minutes or so per game).

I'm a bit amased that I as a beginner was able to put this together... it's just like I thought before I started: Network code isn't going to be much to work for a chess app...
Really don't know if I have the energy to write anything. It's so hot in here because the computer was on all day [flaming]. It will probably just be crap that I write, so don't take it seriously...

After looking a little bit in the at DirectPlay in the DirectX docs I decided NOT to use it. I don't know how they do these documentations. How are they thinking? I mean, if you're a beginner in a field you don't understand a sh*t and you don't even want to read it. I find the docs on Direct3D valuable, but that's because I've got experience (I didn't understand them either in the beginning...).

Went for using standard socket programming instead. I think it will suit my needs well and I now got a client and server up and running [smile]. Maybe I'll deal with DirectPlay another time when the need is greater and I have more time for it, but then I'll do it the "go and by a book on the subject and read it" way, and not the "check out directx docs and tutorials" way...

But it's fine for now. Tomorrow I will try to implement the network for the chess game, possibly extending it cause now my server only accepts one connection, but I want to have a lobbylike server so it will need to list all clients and let them play against each other.
Ok. Now I've finished rewriting all old stuff (human-human game logic) and stripping out all graphics code to create a separate ChessClasses DLL. The old program had chess logic and graphics code mixed up so it took a while to extract the essential parts. Personally I find a library more attractive, so that you could just add different user interfaces as you like...

Now to the next step: Network play!
I don't think the network code will be too complicated, but for me, who has never been programming network appz before, it's a new field to learn. But as always... extract the essential from the masses and you will learn quickly! (A nice motto, isn't it? [smile])

Here we go...

ChessGame: new project

Started to rewrite an old project during my free time today. It's a chess game that was originally implemented as a human-human game in 3D using DirectX8. I'm now to rewrite it to include network play and AI (at different levels). Also the user interface will be a LOT better, and the game will look more beautiful with my new (since then) skills in 3D graphics programming [lol].

If anyone would like to have a look at the old game, here's some screenshots:

MENU:


GAME:


As you can see, there's no user interface in the game, and the graphics are rather boring. That's what I want to fix...

The old game can be downloaded here (about 7,2 Mb), if you want to try it...

Anyway:
Finished the move determination rules today.

Bedtime...
Now I've created one of the shaders: the shader for integration of the state variables (position,rotation,velocities) for a rigid body. The code can be found here. It currently does not support collisions, but as a first goal I want to get a simulation to run without them...

An unsolved problem is that I have to be able to disable physics on an agent (approximated by a rigid body) if it reaches an equilibrium. Then AI and player control would take by. I'm not quite sure of the conditions for equilibrium and would need to adjust them when testing later. Currently I only test if linear and angular velocity are below a certain threshold value. But I'm not sure that will work as I want it to.

Physics on a body could be re-activated by the collision shader (if colliding) as well as both activated and de-activated by the user (programmer).

REMARK: Didn't test the shader. Have to complete user interface first before creating a demo.
Found this post written by MikeWW here.

Quote:

Hi,

Basically you get the error because the compiler does not have the same level of intuition that we do when we look at the code. As far as the compiler is concerned the if/else-if block that sets stf may not actually result in stf being set.

As an aside I would recommend an alternate way of doing this anyway:

* Use a single texture to hold all 6 faces packed together somehow.
* Create a static lookup cubemap that maps the incoming 3D vector to the UV coord of the point in the faces texture.

As long as you use point sampling for both lookups everything should work out OK.

This way not only do you only need to render to one rendertarget for the light instead of 6, but you also replace a whole load of ugly math and sampler array lookup with a texture read which can be a win in some cases.

Hope this helps,

Mike.


Guess it would help! Mike: You saved me! rating ++... (I can see you're from Sweden as well...)

Why is it that life always seems so much easier in the morning [lol]?
Today I began implementing the shaders for GPUPhysics and discovered a lot of limitations that were sooo annoying.

For example the fact that you cannot have a sampler array that you index with a variable. I was totally counting on that (and it's very important to get it working), but as it seems I will have to find a way around the problem. Any tips would be greatly appreciated. Currently I'm doing it this way as a walk-around (compiling with ps_3_0, HLSL):


//...
//tex_shapes is an array of 10 samplerCUBEs
int a = anything;
for(int i=0;i<10;i++)
{
if(i==a)
lala = texCUBE(tex_shapes,texcoord);
}
//...






But this generates a LOT of assembly code [sad]... there's got to be a better way! I want to have the appropriate indices stored in a texture and look them up (rounded to integers).

Another way I thought of is using 6 volume textures that have 10 layers. Each of these volume textures would be a set representing one cube side. Then I would do some kind of fake cube-texture lookup using a depth texture coordinate instead of an index to access the right layer. This would actually be good in the sence that I could have more than 10 layars if I like to (the number of 10 was chosen due to 16 textures limitation on Shader Model 3). But the problem is, that I don't know how to do this fake cube texture lookup.
To simplify the case: Imagine we have only 6 2D textures representing the sides of a cube map. How could I do a "cubemap lookup" using these instead of a real cubemap? I guess that's the problem of tomorrow, now I'm going to bed...

[dead]
As I wrote yesterday, the design image for GPUPhysics was to be accompanied by a "design document" describing the different stages. Well, it's out there now (here). It's rather long, about 9 pages, but if anyone is interested, it's there... Updated the image as well.

Going to continue the framework implementation now.

GPURigidBody: A skeleton

Today I've been putting together a directx skeleton to use for my GPURigidBody project. It gives a developer interface to the engine and creates all resources and stuff. I'm not using my engine (FortiaEngine) for this because GPURigidBody is to be integrated with another project later on. I'm going to put up a little design sheet showing the main "pipeline" of the system on my homepage (later today). It's preliminary, but I like to put things out on the web, it's like a progress monitor and it keeps me motivated [smile]... Also it makes it easy for my supervisor to watch on my progress cause I'm working from home.

/Fortia (with a broken toe since sunday [sad])

Old things

I just went through really old programs that I wrote som years ago. It's funny doing that. You notice how much you learned since then.

Anyway, found a little 2D game (snake-like) that was all finished and could run on my 64-bit system although compiled 2002. I think I'm going to put it in the Showcase (beacause I really want to post SOMETHING to see how it works). It's just a little program but there are more of the like in the showcase so I figure I'll not make a total fool of myself posting it...

Have other things I could post as well, but I'm having trouble finding the right dll-s for all that old stuff. I was using allegro at the time, but now I'm using DirectX.
Sign in to follow this  
  • Advertisement