An offer to help

[XeryusTC]

A friend(known as Seniltai) and me have been working on an OS independant game engine (we call it Tezuka after Osamu Tezuka). It isn't finished yet but it can do a lot of stuff right now. The engine is now partially being rewriten because we wanted to split it up from the game core, some features don't work (good) anymore because of this.
The engine is mostly programmed by Seniltai, if you have any questions you can find us in #tros at irc.tweakers.net ([url=irc://irc.tweakers.net/#tros]mIRC users click here[/url], web based irc client). You can find the source at http://tros.xepo.nl/subversion, you can download it with a regular SVN client.
The engine will probably the best way to get the project on track again, you don't have to worry about the engine itself and can start working on the game .

The engine has the following implementations (there are many more to come):

• An advanced, fully skinable GUI.
  A terrain renderer, it needs to be partially reworked to fit with modular design
  A logging system which allows to save to multiple files in different formats.
  A far from finished object renderer, it renders objects but it needs A LOT of improvements and needs to handle more formats.
  A nearly finished sound engine, it is currently being reworked to use OpenAL.
  SDL support.
  Lua support.
  Raknet support, we use a custom Raknet version to disable some features that aren't needed and eat bandwidth.
  freetype support, also custom to gain a better performance.
  A package format that is based on bzip2.

EDIT: improvements on the sound engine

[Arathorn]

Is it 3d?

[XeryusTC]

Is it 3d?

Yes.

[Hyronymus]

This sounds very promising . Everything you sum up sounds good, I hope what the people with more knowlegde of coding think of it.

[iLess]

I looked at your source code. What types of games are you aiming for with your engine? The server is retreiving Information about the player from an MySQL Server. This is something for a MMOG. But It would be an overkill for our application. Everybody should be able to host a game without having to go through the trouble to install a MySQL server for that.
But having MySQL behind a masterserver for global player rankings or such, would be a cool thing to have. I didn't have much time to look at all your code though so i haven't checked the graphics stuff yet.

[XeryusTC]

I looked at your source code. What types of games are you aiming for with your engine? The server is retreiving Information about the player from an MySQL Server. This is something for a MMOG. But It would be an overkill for our application. Everybody should be able to host a game without having to go through the trouble to install a MySQL server for that.
But having MySQL behind a masterserver for global player rankings or such, would be a cool thing to have. I didn't have much time to look at all your code though so i haven't checked the graphics stuff yet.

The part of the engine is in the directory trosengine (if you want to compile you also need everything in depsource).
The source you looked at is for our MMORPG that is based on our engine, TE probably doesn't need this server, but it could make use of an edited version of trosmaster (aka Belial). Belial now only supports clustering of servers and administrator logins (the administrator program is in trosserver/src/administrator and requeres Qt, as do the other tools).
Belial also has support for threading, we did this because I (I'm the main server developer) wanted to experiment with threading .

We were also thinking about putting the MySQL in the engine, along with some modular design to allow the use of other databases but this needs some good thoughts and is probably going to have the same implementation as CHash and CHashMD5 (more info about this is in our doxygen).

[charlieg]

Don't put MySQL in the engine... use SQLite instead! That's much more palettable.

[aarona]

Try as I may, I can't get it to compile! (It took me an hour to compile "depsource")
Would you be able to present some screenshots, or some pre-compiled Win32 executables?

[XeryusTC]

Try as I may, I can't get it to compile! (It took me an hour to compile "depsource")
Would you be able to present some screenshots, or some pre-compiled Win32 executables?

What can't you get to compile? I had some problems with compiling libOgg and libVorbis myself, you should just fiddle around with the configure file abit (disabling SDL helped), and you should download the OpenAL SDK as we use it (and those libs too IIRC), it even had a file in it that neither me or the other dev on the project could get to work.
I also don't know if everything is compilable with MSVC since I use MinGW.

And for the screenshots, there almost nothing to show, exept from our servers, the login screen of the client and a far from finished server manage application.

You can find the executables here, place the files in the corresponding bin directories.

Edit:
The master server (aka Belial, as it is know in our doxygen) is mostly running on xepo.nl too, you can access it here on the default port (which you can find in the master.cfg file).
Edit 2:
You can always find us at [url=irc://irc.tweakers.net/tros]IRC[/url].

[aarona]

What can't you get to compile? I had some problems with compiling libOgg and libVorbis myself, you should just fiddle around with the configure file abit (disabling SDL helped), and you should download the OpenAL SDK as we use it (and those libs too IIRC), it even had a file in it that neither me or the other dev on the project could get to work.

I had troubles with libVorbis, it didn't seem to find all the necessary files so I had to manually edit each include line and include the directory information. This also occurs with libLua, although this can be fixed by including the appropriate directory into the compilers directory list.

I also don't know if everything is compilable with MSVC since I use MinGW.

I'm using MinGW+Code::Blocks (which seem to be able to load VC++ project files.)

Which makes me wonder why the following code is not liked...(or anything else containing TROSAPI. Is there a #define error or something?)

Code: Select all

TROSAPI const char* EncryptString(HASH_TYPES Method, const char *String);

With the following error...

Code: Select all

error: expected constructor, destructor, or type conversion before '(' token

I dunno why it wouldnt like

Code: Select all

#define TROSAPI _declspec(dllexport)

There are also OpenGL errors.
The following definitions in OpenGL.h (the one in your include directory) cause errors.
PFNGL*
such as
PFNGLBINDBUFFERARBPROC xBindBufferARB;

Commenting these out doesn't help too much, but I did see the

Code: Select all

\deprecated The Subsystem system is not in effect anymore. Global classes are now handled on the application self.

Do you have any suggestions?

[XeryusTC]

What can't you get to compile? I had some problems with compiling libOgg and libVorbis myself, you should just fiddle around with the configure file abit (disabling SDL helped), and you should download the OpenAL SDK as we use it (and those libs too IIRC), it even had a file in it that neither me or the other dev on the project could get to work.

I had troubles with libVorbis, it didn't seem to find all the necessary files so I had to manually edit each include line and include the directory information. This also occurs with libLua, although this can be fixed by including the appropriate directory into the compilers directory list.

libVorbis should be used with the supplied configure file, which takes a while to get it correct for compiling, you also had to compile libOgg first IIRC. The paths in the Lua Makefile have been set correctly and should have compiled without errors so I don't know what happened there.

I also don't know if everything is compilable with MSVC since I use MinGW.

I'm using MinGW+Code::Blocks (which seem to be able to load VC++ project files.)

Which makes me wonder why the following code is not liked...(or anything else containing TROSAPI. Is there a #define error or something?)

Code: Select all

TROSAPI const char* EncryptString(HASH_TYPES Method, const char *String);

With the following error...

Code: Select all

error: expected constructor, destructor, or type conversion before '(' token

I dunno why it wouldnt like

Code: Select all

#define TROSAPI _declspec(dllexport)

That is because _declspec(dllexport) is something MSVC uses to create shared libraries and MinGW doesn't support it in this way, we don't have shared support for MinGW yet so it should use the empty define (look in PreProcessor.h).

There are also OpenGL errors.
The following definitions in OpenGL.h (the one in your include directory) cause errors.
PFNGL*
such as
PFNGLBINDBUFFERARBPROC xBindBufferARB;

Commenting these out doesn't help too much, but I did see the

Code: Select all

\deprecated The Subsystem system is not in effect anymore. Global classes are now handled on the application self.

Do you have any suggestions?

You'll probably need the NVidia GL headers, I don't know where to download them now so I'll have to ask the other dev, which isn't around right now and he won't be around for the next few hours .

[Seniltai]

Seniltai's here! First post Oh well, I figured more people who want to try TRoS have troubles, so I made a guide which explains in detail how to compile TRoS Engine.

The URL is http://tros.xepo.nl/tros/forum/index.ph ... .msg37#new.

You said that you work with MinGW + Code::Blocks, which loads .vcproj files, but there's no way that's going to work. Why? Because of the simple reason that MinGW works the same as linux, and using the .vcproj file lets it compile the visual studio C++ optimized code (which obviously doesn't work on MinGW). If it's possible to compile makefiles with Code::Blocks, then it should be possible, but I can't really help you with that

The code that you noted:

Code: Select all

#define TROSAPI _declspec(dllexport)

has been replaced, as shared libraries in MSVC++ gave me a lot of headaches (unexplainable stack forks, long story), as the compiler of MSVC++ 8 is very bugged and now just compiles TRoS as a static library and in debug mode (when oh when does microsoft release a service pack, please?).

Compiling TRoS with MinGW and MSYS is probably your best bet to get it working, and contact me at ultilink [at] hotmail.com when I need to start the servers for you, or you still need some more help. (they're not running 24/7 yet as they aren't stable enough for that.)

Hope this helped,
Seniltai =)

[aarona]

Okay well I've given up on compiling it!

It's been rather frustrating...
I think I'll stick to the binaries for now which I can get to work...

Before I spend any more of my time/sanity trying to compile this thing, I would like to ask a few questions.

My questions are
- How might this be used for Transport Empire?
- Is it possible to show this "Terrain Renderer", it doesn't seem to be immediatley obvious where it is currently being implemented in. (After all, this is, in my opinion the most important part of any graphics engine for TE)

I'm not blaming you guys for my failings in being able to compile your project. I would very much like to see where your project leads to, and hope some aspects could be used sucessfully in TE. If it looks sufficiently promising then I'll be sure to try again

[Seniltai]

Hehe, that you can't find the terrain renderer is a roger, because it's still not implemented in TRoS Engine Reloaded. It's actually the fourth remake of our engine (and this time we got it just like we wanted.) The terrain renderer was actually part of TRoS Engine 3, and was already very nice. The new one is going to be much nicer, and will have support for vertex and pixel shaders too, so the speed will be even higher. In a few weeks i'm going to rewrite the terrain renderer, and when it's finished, I won't hesitate to post some screenies here

EDIT: Some technical details about the terrain renderer, it's going to attempt to use two major shader effects, one called vertex displacement mapping, implemented in the vertex shader (geforce 7x minimum, shader model 3.0), and one called texture splatting by blending texture coordinates with a pixel shader to render 3 or more textures where previously only one could be done in one pass (shader model 1.1 minimal, Geforce 3 Ti or higher (excluding the Geforce 4 MX, which is actually a overclocked geforce 2). I don't know much about the ATi Cards, but when the shader model is sufficient, it should run it flawlessly like a NVIDIA card.

For the collision detection I'm using Axis-Aligned bounding boxes on terrain chunks, which accellerates the rendering significantly, with a setting to change the size per chunk, so you can set in the options if you want to let the CPU compute more, to save some GPU time, or vice versa.

The terrain renderer will load 8 bit targa files, which can be edited by TRoS Creator in the future, to create maps. (They are compressed in a .pka file, which is actually a modified version of bzip2 (same algorithm, other indexing system).

Seniltai,
Lead TRoS Engine programmer.

[XeryusTC]

Isn't the terrain renderer still in the engine or did you delete it already?

And for the shader support, we are going to create fallbacks that allow older video cards to do something too, but the load will probably be shifted to the CPU.

[Seniltai]

Never implemented actually, it's weakness was that it was dependant on the lScape engine, which was pretty much outdated, for example it still used VAR and NVFences, which can now be done with a global solution called VBO (Vertex Buffer Objects). I do still know all the theory, so it will be a piece of cake to rebuild it again, and it will be a lot more efficient, as I now know where to look for.

[aarona]

EDIT: Some technical details about the terrain renderer, it's going to attempt to use two major shader effects, one called vertex displacement mapping, implemented in the vertex shader (geforce 7x minimum, shader model 3.0), and one called texture splatting by blending texture coordinates with a pixel shader to render 3 or more textures where previously only one could be done in one pass (shader model 1.1 minimal, Geforce 3 Ti or higher (excluding the Geforce 4 MX, which is actually a overclocked geforce 2). I don't know much about the ATi Cards, but when the shader model is sufficient, it should run it flawlessly like a NVIDIA card.

Your making me drool!

What type of LOD/culling mechanism are you planning on using, ROAM, SOAR, or something more specific to this purpose? Using texture splatting by blending is a good idea. Are you also going to include fallbacks in case people cannot support the extra features which might not be standard?

How will Keyboad and Mouse event be handled? You have mentioned mouse/terrain collision, what else is on offer? Is it going to be a full terrain/game engine, or just the terrain part of it?

(Also, it would be good to include the .DLL and .a files in the release, just in case I can't compile it )

[XeryusTC]

What type of LOD/culling mechanism are you planning on using, ROAM, SOAR, or something more specific to this purpose? Using texture splatting by blending is a good idea. Are you also going to include fallbacks in case people cannot support the extra features which might not be standard?

We're currently using frustum culling, this makes sure that your graphics card will only render polygons that are visible in your screen. And we're going to implement fallbacks, I'm running on a Geforce 4 MX myself so we have to implement them otherwise I can't run it.

How will Keyboad and Mouse event be handled? You have mentioned mouse/terrain collision, what else is on offer? Is it going to be a full terrain/game engine, or just the terrain part of it?

We are using the SDL system, we let the engine handle some parts of it (like some GUI stuff), but it will mostly be handled on the "client" application.

[Seniltai]

Let me collaborate on that. It uses frustum culling, but, as 3d cards are very powerful at the moment, and the group with slower 3d cards is getting smaller, it's a good bet to do the most things at the GPU. Although, we will support fallbacks at the CPU. The amount of detail will be simple to set, so that you can scale it down to work on slower cards, and theoretically, it should even work at a NViDIA RIVA TNT2, although it's not designed to be. However that requires some serious sacrifices to detail, but that's not more than logical.

What type of LOD/culling mechanism are you planning on using, ROAM, SOAR, or something more specific to this purpose?

LOD is pretty much outdated nowadays, at least on terrains, as 3d cards like the Geforce 4 TI can handle 50.000 polygons with ease (depending on how it is transfered). There will be a dedicated vertex storage system, which also handles texturing (shaders/fixed function) and a simple collision detection (OBB-Frustum). It's not the most efficient algorithm, but it's very fast, and lightweight, so the balance will be shifted more to the GPU to do the processing, testing of the previous terrain renderer proved that it was pretty efficient, even with 4 passes (to do the texture splatting the manual way). For example, the terrain renderer will spit out the chunks it generates from the heightmap, and it will be loaded in the GPU (if it fits in memory, fully handled by ARB_vertex_buffer_object, which automatically puts it in system mem if it doesn't fit), and the vertex system will automatically generate a object bounding box. For every chunk you give a shading chain, which can include fixed functions and/or shaders (multi-passing shaders will also be possible). And in the frame, everything will be computed and rendered by the vertex system with one single call. Later on it can be more perfected by adding more functions, but that's the basic idea.

Using texture splatting by blending is a good idea. Are you also going to include fallbacks in case people cannot support the extra features which might not be standard?

Ofcourse, else we wouldn't be able to support geforce 3 and up, only geforce 7xxx class cards , this will be also be handled by the vertex system, using the shaderchain. The idea is that you put a shaderchain in a shaderchain, and specify that it's a fallback chain. It automatically removes the shaders which are inferior, and unsupported, so that the best case will be selected for your card.

How will Keyboard and Mouse event be handled?

We are using the SDL system, we let the engine handle some parts of it (like some GUI stuff), but it will mostly be handled on the "client" application.

That's correct. TRoS Engine includes a wrapper to access the SDL library in a way which is only necessary for TRoS. It's currently implemented in CSDLWrap, which includes a few functions to create a window, and automatically allocate a GL context to it, so that cross-platforming will be easy.

As for the mouse and keyboard, SDL works with SDL_EVENTS, http://docs.mandragor.org/files/Common_ ... event.html for a full description of everything that is being spit out, and the link between SDL events and TRoS is made with bool CSDLWrap::PollEvent (SDL_Event *event), which returns true if there is a new event, and puts the event in the preallocated SDL_Event you specify. So everything of SDL is accessible to you.

You have mentioned mouse/terrain collision, what else is on offer? Is it going to be a full terrain/game engine, or just the terrain part of it?

The engine will be primarily designed for a complete game (TRoS Client/Server/Mainserver), but you could even make scientific 2D/3D applications, or anything you wish. (TRoS Creator is using TRoS Engine too, ofcourse, which is actually a application to help every application that uses the TRoS Engine.)

Hope this informed you well enough,
Seniltai.

[aarona]

How is the engine going?
I can't access the web site anymore.