[Help Wanted] "The First King" - FPS game. PRE-ALP

[Nadro]

Lightmap looks very interesting, but we can't add day and night with sun moving, so I think than lightmaps are good for Indoor style level. For Outdoor level I recommend Full Real-Time Lighting (Similar to "Doom 3"). One problem is shadow system because two are good: Mapping Shadow and Stencil Shadow, but what system is better...? For lighting You have to create new class eg:

Code: Select all

// Comments for Sun
class CLight
{
public:
int ID;
SColorf Diffuse; // Color from actual Sky subcolor (for night dark color, but for day white color etc.)
SColorf Ambient;
vector3df Position; // Move on Sky
float Radious; // For Sun, it isn't use
float ConstantAttenuation; // For Sun, it isn't use
float LinearAttenuation; // For Sun, it isn't use
float QuadraticAttenuation; // For Sun, it isn't use
};

Now You can send this information to Shader as float variable:) You can easy create standard Irrlicht T&L light with this values eg. if graphic card hasn't got support for Pixel Shader 2.0. I think than good system is only per shader lighting (user can ON/OFF it eg. If Your graphic card hasn't got Pixel Shader support).

[Halifax]

Tip from me: Never, ever post projects in pre-alpha stage.People will know what to expect and they won't be surpised....

Ivo: People like to see how things come along in the development process. Personally I like seeing games evolve.

Also I don't exactly know if you would want to switch to dynamic lighting over lightmapping. Dynamic lighting has severe limitations, and lightmapping still looks amazing if you do it right.

(I posted the Resistance: Fall of Man lighting post mortem earlier in this thread, and they used lightmapping all throughout the game.)

[BlindSide]

Yeah you can try dynamic shadows along with lightmaps.

Use the lightmaps for Ambient Occlusion style lighting, and use the shadow maps for shadows.

My X-Platform Shadow Wrapper supports lightmap materials, but it has fallin a bit out of disrepair, I may release an enhance demo soon, here is a shot:



PS: These are fully dynamic, as in moving.

[christianclavet]

Hi, Blindside and Nadro

Thanks, I'll surely check it out. Lighting and shading is a problem that concern the game now; because it an area that I'm not experienced at all. I appreciate all your recommendations and support. I have a way out, tought. I can do it like my level demo. But If I can, I would like to use shaders. And the game is using shaders, it will REQUIRE PS2.

Ivo Georgiev. I don't want to put this AFTER the game is completed. Because for one, this project is too big for one person alone. I want to show the developpement of the game while it's being developped so that others may join the team if they have some time.

I'll also want to give up the source so the IRRlicht community would be able to pick the game functions to use in their own projects. (In fact you can download the source now from the SVN on the sourceforge site)

JP is working hard now on making the AI and we decided that it would become a project in it's own. Because there isnt much AI engines all around. I'll clean up my camera code when it's working the way i'd like and once it's working fine. It will go in the snippet section of the forum BEFORE the game is completed and so for the IrrAI project.

If you want to download something to PLAY now. Download my level demo.

[Mirror]

just ran the game, very nice effort christian and i suppose the content making must be very tedious.

is the fountain empty ( as in no water ) or is it a shader problem ?

edit : impressed by the glass effect.

p.s. why the .exe asks for the dx3d9.dll. btw the irrlicht.dll is a recompiled version ?

[christianclavet]

just ran the game, very nice effort christian and i suppose the content making must be very tedious.

is the fountain empty ( as in no water ) or is it a shader problem ?

edit : impressed by the glass effect.

p.s. why the .exe asks for the dx3d9.dll. btw the irrlicht.dll is a recompiled version ?

Hi, Mirror.

Content making was not so tedious. All assets now are taken from my level demo. For the level demo; I had to take pictures of my reference models. But the modeling took about 2-3 week. Learning to program to make the demo work took me the longuest time. The level demo contained the Realistic Water Node. I did not needed the water to test.
I'm working on the "engine" right now to implement a full featured camera system so that it will work as most major FPS games perhaps push it further (I will not bet on that, but the objective is that at least the player could move like we do on a big FPS title (like FAR CRY, CALL OF DUTY, ETC)

For the glass effect there is a major problem with reflective surface with transparency (full reflective surface are ok). I've issued a BUG REPORT so that it will corrected once the DEV team have some time to look at it. If you go in front of some windows, and rotate the view, you'll see the problem (I think there is problem in the transformation matrix with the way the environnement reflection is mapped). The level permitted me to test and get more informations on the problem. This current level use only for now the IRRlicht default surfaces settings.

For the dx3d9.dll the IRRLICHT version was recompiled to support DirectX9, OPENGL, and the BurningVideo software driver. I will have to recompile it soon with the final release of 1.4. It's still using a 1.4Beta SVN (1039)

Once the camera is fully usuable and cleaned up, the next step is implementing shader to support Normal maps, specular maps, some shading and lighting technique. Perhaps also some nice postprocess shader effects. The priority is for having the normal/specular maps and lighting working. (Others are more like candy... Nice but If not there I won't miss them that much)

[Mirror]

some feedback.

probably you have noticed it already but here it goes : when the camera is turned towards some locations, the moving speed ( as well as fps ) drops dramatically. i suppose because of many polygons from the underground tube

[dlangdev]

nadro,

what you said about the sun moving and changing the atmosphere sounds cool.

i have found a sample demo exactly what you said, though i need more time learning how to do it in my demo projects.

let me know if you're going to work on atmosphere shading. i'd like to spend some time learning it.

there are several papers documenting how light scatters when it hits the atmosphere, it also contains scattering in fog and clouds.

so yeah, it's definitely interesting trying to work out a fast alogrithm just for that.

[christianclavet]

some feedback.

probably you have noticed it already but here it goes : when the camera is turned towards some locations, the moving speed ( as well as fps ) drops dramatically. i suppose because of many polygons from the underground tube

Hi, Mirror.

Yes. This is because of the basic culling of IRRlicht. It doesnt do occlusion culling (Perhaps IRRlicht 2.0?). There is mostly the Frustum view culling now. I've checked for this and there are lots of methods for doing culling for different types of situation (You could search the forum about occlusion AND culling) Hope, the developper found a good and efficient culling method someday.

Right now the solution is to have your level in "parts" and hide theses parts manually and design your level so culling will be optimized. I was assuming that Occlusion culling were done by the engine when I made the demo and was wrong.

One thing I could do, (thinking about it now. is to try a collision with the wall(code from collision demo), calculate the distace from the camera to the wall and change the FAR value of the view FRUSTUM of the camera. But I think it will not be good for all situations. (perhaps do a distance*2 and see how it goes). I'm working on my camera right now. So it will not be worked (the idea) for a while.

[Mirror]

here is one solution i came up with last night with this problem. Let's call O the Outdoor meshes, D the indoor ( Dungeon ) meshes, and finally let's call C a connecting mesh ( connects O and D ). More specifically we will split C in two parts, C1 and C2. C1 is the entrance near O and C2 the entrance near D. C ( C1+C2 ) will be designed in such a way that when the player is in C1, he cannot view D, and when he is in C2, he cannot view O. So you will do a simple check :

- if player is in O or C1, the game will render : O,C1,C2
- if player is in C2 or D, the game will render : C1,C2,D

in this way at any given time, you will never have to render both D and O ( large meshes ).

ps1. The simpler design for C would be a U or Z form with C1 being the left side of U or the lower part of Z.

ps2. this way can be used for even more meshes thus improving performance alot.

[christianclavet]

Mirror, that would work, but how about doing that for 40 different levels? I think it's good if you have few levels. Anyway, checking for this will start surely when "optimizing" the engine, so in the last phase (levels are completely modeled).

Hi, I've updated my source and uploaded it at sourceforge today.

I started separating the functions into files so the code will be easier to understand (For whom who'd like to take some component out of it)

I'll be starting creating a way of building multiple kind of camera controllers(camera rigs)

The user will have to create a std camera, then choose and apply the chosen rig to control it.

The current rig, is using only the camera right now. Other rigs that I would like to create:

- Current camera rig:
Operate the same way as the FPS one. But there are speed variables for actions and those can be changed at runtime. Will have some boolean to activate/deactivate some functions.

- 2 points camera rig: Will have the same feature plus:
- The motion will be applied to a specified node
- The rotation of the mouse will be applied to the camera (camera will be parented to a defined node.
New possible features of this rig:
- Sin/Cos movement of the camera to simulate walk
- Real zoom feature (will have to block camera with collision so it's won't look behind walls) (perhaps will let the user put another collision response animator on the camera for this)
- Creation of a 3rd person type camera (Will allow the use of Collision response animator on the specified node and the camera would rotate and move freely.
- The "defined node" will be created as a "empty node" as a default parameter, but can be changed. So a animated mesh (car, character) could be defined as the "specified node"

Also I'm still figuring out for a tilt feature that will base itself on the current UPVECTOR, will store it, Will do the proper manipulation of it for Tilt actions (take the current upvector, check the current directional vector of the camera, then do a proper tilt left or right (could be fun to have a front and back tilt), and once the action completed will restore the UPvector. A more advanced approach would be to have a spring based tilt. That will account on the velocity of the camera to tilt it. (Could be great for car games and/or FPS)

[Halifax]

Wow that sounds like quite some work christian. Keep it up man, you are doing great justice with all these camera rigs.

[Mirror]

christian, what do you mean by 'if you have many lvls?' for every 'dungeon' mesh you will build a mapping of O/C1/C2/D and just make the checks. in this way you will just render only one dungeon and one connector link mesh nothing else, huge performance

[BlindSide]

Most games, like HalfLife, use this technique extensively. Its just the basic concept of "Make an area where you can't see around the corner the next level or the previous level and do your loading there".

Something like a corridor with an S curve is useful, its pretty simple to do and not much to ask per level.

[lostclimategames]

look up binary space partitioning.