Post news Report RSS Truepaints New Engine Update

Hey, This news post is about the new engine and progress thats going on with it. I'm currently just working collision detection, and just pluging in the old OpenAL code(sound). Then I want to get the game code back in and have a workable copy of truepaint before I start to work on the rendering

Posted by on

User Posted Image

Hey,

This news post is about the new engine and progress thats going on with it. I'm currently just working collision detection, and just pluging in the old OpenAL code(sound). Then I want to get the game code back in and have a workable copy of truepaint before I start to work on the rendering code.

This is a pic of the new engine rendering doom 3 ccode.
Img359.imageshack.us

Engine managers are in except for the collision system, these include the filesystem, network manager, rendering front backend etc.

The engine is still an OpenGL engine. Basically OpenGL and DirectX give programmers direct access to hardware, and an interface to interact with the kernal so we don't have to write specfic code for ALL the different hardware there is. OpenGL is for graphics and directx encumposes everything. OpenGL is alot more extendable then Direct3D( the 3D drawing portion of DirectX), way in the future when I add support for the Geforce 8 OpenGl 3.0 we wouldn't have to re-wirte as much as we would if we converted from DirectX 9 to DirectX 10(pretty much would need a entire new renderer), and it would only work on vista. OpenGL 3.0 is faster then DirectX 10 and it will work on an XP computer. We are still using DirectX 9.0 for input and sound(through OpenAL), which is standard.

I added faster memcpy and memset support that are take advantage of the MMX technology. Memcpy copies memory from one data area to another, and memset fills memory with a value. This implementation is about 50% faster then Quake 3's and way way faster then the standard C implementation. Right now this is a windows only implementation I'm sure if the mac or linux compiles compiles this code nicelly. It cut down about 6% memory consumption in the current build so far. Chances are if you have a intel or amd processor over 1.0ghz it has support for MMX. As of now the game requires MMX.

Al ot of the math code and classes are in now. The msg_t class that creates bit messages for the network system is still C based and looks like shit thats kind of bugging me.

The lower level network code that deals directlly with WinSock is copied directlly from Quake 3, as well as some of the game code for player movement code, but ported over to c++. This moved over to the physics portion of the engine.

We are also using a faster version of std::vector which dynamically creates and stores memory, jmList is faster because it uses the new memcpy function, and it doesn't have all the debug code and extra stuff we don't need in std::vector.

When we do get the rendering code we will be using asm shaders, instead of the higher up shading language. Except all the shaders will programed in a higher up CG lanauge and then compiled with the NVIDIA CG Compiler. This adds two things. Gives us more security over our GPU programs(programs that are sent to the graphics card that control all vertex animations and fragment(pixel) shaders), and it allows the programmer to properly debug code, since GLSL has alot of driver implementation problems, were as if its compiled to its lowest form you know whats being sent to the graphics card.

Using GPU programs in a non fixed function pipeline gives us full control over each texel on the screen to pretty much do what ever we can imagine. The limit is based on vertex count, and the size of the fragment program, and thats based on the speed and processing power of the GPU. Current GPU's are NOT PROCESSORS they are specfically designed for rendering purposes only, even though you can offset things such as the physics code to the GPU. We add support for per-pixel lighting, bump mapping, post process effects such as bloom, and reflections based on cube maps.

Im staying with OpenAL instead of writing a entire new sound system using DirectSound. This will make it easier on us for portability when later we have to port our code over to mac and linux. The old mac/linux lower level code should when ported over work nicelly inside of the engine. The system code will have to be changed for mac and linux and wrote from scratch.

Ill post more information later, as the engine evolves and if things change.

Peace
Justin Truepaint programming GOD!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: