Hello all,

I'll just jump right into it: I would like to create a high end FLOSS FPS graphics engine for the Linux OS. I have a few questions about it and I don't know where to possibly start so I'll just throw them here:
1) What program language to consider? C or C++? And why? Should I also learn other programming language(s)?
2) What and where do I have to start learning about everything but the programming languages?
3) Is OpenGL up to the task of new rasterising technologies? In other words; is OpenGL future-proof? Is it 'realisable'?
4) What other stuff is necessary? SDL?

I got too much free time on my hands. I know how crazy this idea sounds but I don't care. If John Carmack can do it than so do I. I consider myself intelligent enough for it. My motivation is creating momentum for Linux gaming in general.

Between C and C++ you want C++ - this will let you take advantage of object-oriented design, amongst other things. Opinion is usually divided over what to learn first, all the courses start the same but there is some merit to the idea of starting with C++ so you don't have to discard some of the paradigms you'll learn with regular C.

You start learning programming by getting a book and doing tutorials. But, as soon as you can, find a project in active development and play with it. You'll learn faster the sooner you start butting your head against a big chunk of code.

Remember - you may be doomed if you fail, but disappointed if you never try.

@Simon Bridge: Will C++ not be an considerable performance hit or is that just a myth? I already have the second edition of Bjarne Stroustrup's C++ book, but I am wondering if it is not better to learn C because of performce before I start learning this 1040 pages long book :/

Lua or Python, because they are prime candidates to be integrated into engine for scripting. Lua is easier to integrate, but offers less features.

You should learn about 3D math and graphics. www.opengl.org has a list of recommended reading ("red booK", "orange book", etc), which should cover everything. Also Francis Hill's "Copmuter Graphics Using OpenGL" should be a good book to read.
You should also learn what free engines are available right now. Most free fps games use Quake3 derivatives (for example, ioquake), but there is also saurbraten (which is really worth looking at), and probably few more engines. Sauerbraten is closest to what you can develop alone.

AFAIK there is no alternative to OpenGL on Linux. All 3D linux games use OpenGL. As for "future-proof", OpenGL standard is evolving, and in future there will be new versions.

Yes. Again - there will be little choice if you want your engine to be portable.

AFAIK John Carmack didn't do it alone.

It's a myth. You can get good performance when you know what you doing and without trying to do OOP in C. Also there are many FPS engines written in C++. Performance hits are programmer's fault, not language's.

I shall second everything ErV said here.
Particularly that last bit.

Remember, once you get a feel for how things are set out, start looking for a project - get the source and study that. See what needs to be done, and have a go submitting small patches. Brace yourself for critique - learn from it. Bear in mind that people submitting code instead of, or alongside, bug reports are very valuable.

I already started to learn everything on http://en.wikipedia.org/wiki/Portal:Computer_graphics. Are these good references for starters? Or would it be wise to start learning some place else?

I was think about something along the lines of making a basic, clean and fast, but also easily expendable engine and play catch up with the latest id tech engines later on. id tech engines are obsolete by the time they are released as GPL software Or should I start with learning the Quake 3 source code and expand on that? According Wikipedia id had almost completely rewritten the id tech 3 engine (porting it from C to C++) in order to create the tech 4 engine (Doom 3). Isn't the Sauerbraten engine just a cube engine? That's a joke compared to todays commercial engines.

I know that there is no alternative to OpenGL and because of that I wanted to know if I wouldn't be hitting a massive brick wall along the road. In other words; I wanted to know if it was even worth it to start making an engine for Linux. The reason I am asking this is because the Linux port of Doom 3 isn't applying some more advanced rendering techniques when I set it to ultra high. I was thinking that maybe there is no such functionality when using OpenGL.

Why not just save yourself a whole lot of man hours and use ogre. Generally an rendering/game engine evolves out of games you have previously made not really from scratch.

Ogre3D is OOP C++ and according to Erv that is a performance hit. Besides... isn't Ogre3D a little too complex and too "can be used for everything" rendering engine?

You had better tell that to the AAA game studios then. What language and paradigm do you think they use?
Where did Erv say that

I was making a mistake: I thought he had said OOP in C++. Sorry Erv

I can't help you here. I learned basic math many years ago, and it was based on "demo.design.faq". This is very old info, and I do not know english translation of that.

I think that "basic & clean" is incompatible "with easily expandable".

There were several conversions of quake, for example, tenebrae which added per-pixel lighting and shadows. Those engines can be converted and upgraded, but it is up to you to decide if this worth the try.

I think you should take a look at quake 3 conversion instead (ioquake, for example). Quake 3 code isn't easy to read.

Honestly, you should play it, try its' level editor and see yourself.
//personal opinion follows
Saurbraten is closest to what you possible can do alone without a team. Engine incorporates advanced lighting, post processing, it is easily extendable (using scripting, custom-written shaders, and so on). I think it is 75 percent finished commercial engine. Make more details, fix some bugs, increase texture resolution, change shaders to more heavy stuff, change lighting model to realistic lighting, and you will get very good engine. It has source code and it is easier to use for learning than quake 3.
I also like elegant idea behind the engine.

Also you won't make commercial-quality game (without army of artists) alone if you will keep using standard techniques. If you will invent something new, non-standard and interesting (for example - generators for levels, monsters, textures, which will reduce amount of required work), then you will have some chances. Good example of interesting approach is kkreiger, but, unfortunately, its' source code is not available.

Yes, it is worth it. Besides, there is always commercial Mac OS, and there DirectX is also unsupported. I also think that OpenGL is easier to learn and use and with it you will create something much faster.

Which techniques exactly?
Doom 3 uses OpenGL on all platforms. It (I mean Doom 3) is also fairly old by now, so there is no hdr (which I hate anyway, because it makes everything yellow) or similar effects. If you want to be sure if "opengl supports that", then download and check nvidia sdk. Half of examples there made for opengl, and many of them compile on linux without modifications. Also by the time you'll have something working, there will be probably newer OpenGL standard.

I said that C++ is not a performance hit.

Yes it is too complex.
//personal opinion
This is what you will get if you will start making generalized easily-extendable engine without clear goal in mind. To succesfully write an engine, you should concentrate on narrow easy-to-define task. Once it is done, you can start adding features.

No-no-no!... I don't plan to have this entire dynamic loading plugin framework crap! Rendering is turning a mathematical, three dimensional scene into a two dimensional frame, right? So you have these processes of computing textures, shaders, lightning effects, etc, right? Well if you make all of these processes functions, you'll have a top-to-bottom list of processes that are processed from top to bottom, which make up the renderer. What I mean is that I could easily expand the renderer by inserting more processes/functions into that list.

Do you mean the style in which the code was written or the structure of the entire source code?


The idea is to create the engine first Making a complete game is something I'll be considdering in the future. I will however create at least something (one level maybe) with all the ideas that I've came up with during daydreaming about making my own game even since I was about the age of four

I have thought about that too in the past. Stuff like: randomly create a tree for x amount of times. Then have a tool in which you will have a topdown view where you can say: Some vegetation here and there, absolutely not there, create a bit if high here and a large valley there but not steeper than 45 degrees because I have to create a road over there, etc.

I don't remember as I played it back when the Linux client came out for. All I know was that there was no difference between normal, high and ultra high settings. Tried it with both ATI and nVidia hardware.

Yes I hate it when HDR is not implemented correctly! Some studios just implemented it for the sake of having it. For example in Gears of War it is used even though the entire game takes place in a dark, cloudy world. Valve seemed to be the only one who got it right: only the sun has HDR, but when you are going into a dark place (let's say a cave) everything is dark for a few seconds until your 'eyes' get used to it, but when you'r used to the dark and you go outside the entire world is HDR'ed, untill you get used to that for a few seconds and then the entire HDR goes away.

I have an ATI card now. ATI HDRadeon 4870 X2 to be precise. (offtopic) Everything from from watching DVD's in a full compositing OpenGL DE (KDE 4.2) to playing ET:QW and Warsow in 64 bit works like a charm with the latest proprietary ATI driver. (/offtopic)

That's exactly what I want to do. I am currently learning the principles of everything related to a game engine and constantly narrowing things down; ray tracing, ray casting and volumetric rendering... no I am going with rasterisation. Lightning techniques... these are old, these are too heavy... penumbra in shadows in shadow maps is coming to id tech 5, ah that's realisable, ok so I'll take that, etc. The idea of large worlds instead of levels is also appealing to me and not having to deal with a limited set of textures in the memory but streaming a 20GB texture from the HDD is also cool but a huge performance hit. But wait... fast SSD's are on the rise, ok so this is also realisable at the end of 2009. Ok let's 'steal' that from id tech 5 too. But first of all I have to do the basic stuff before even dreaming of that but it will all be part of my goal. Narrow stuff down and work my ass off :P

Not quite. Modern game uses shading languages to define shadings.
//opinion
Sometimes programmer decides to make "an extensible material/shader system" which allows to make any material, complicated lighting effects and custom shaders that are supposed to work on any hardware ever created with several hardware compatibility levels. This often looks plain awful and incredibly complicates engine, and makes engine faulty.
Another standard problems of all beginners - they think only about cool features and technologies, and never try to do game as a whole. They sink in features and fail to do complete game because of all modern stuff.

Quake 3 is written in C. Source is big, code is quite difficult to read and there is little documentation. That is all I can say. Feel free to download quake source from ftp of ID software. That is why I recommend to look for adaptation or saurbraten source.

//opinion
I think that creating engine for a game is easier than making engine without a game, because you have better goals, when you are trying to make a game. You really should start with idea you can imagine.

There are a lot of differences. Main feature Doom 3 uses is "automatic hardware" detection, which will show a lot.
To adapt to hardware, Doom 3 might:
1) disable specular
2) downscale textures
3) disable dynamic lighting from projectiles.
4) disable shadows.
5) Disable postprocessing (blur when you are hit) and refractive surfaces (glass).
All those features were considerable performance hits. Also, for example, texture downscaling and disabling light from projectilves happens completely silently. You can find out if those options are enabled only in doom 3 configuration file.

I think that most studios implemented it only for having it.
Most games that use HDR have that awful yellowish-pinkish color.

If your card supports OpenGL 1.5 or OpenGL 2.0, many demos should work.
There was ATI sdk somewhere, but it was mostly DirectX/Windows related. Nvidia is better for OpenGL+Linux.

//opinion
No offence, but this is a nice way to sink in the features without ever finishing the idea. I was through that before.
For beginning, try to do something that looks like Quake 1, at least, but will work and can be quickly finished. Once you have finished product or prototype, you can add all advanced lighting stuff.

Is this done through OpenGL?

Ok. Yes I've already started reading the Quake 3 renderer code, but I think I'll go with the Cube Engine 2 (saurbraten engine)


I was already thinking about making some kind of space shooter, inspired by the coolness of Quake 2, which is the only shooter I stil replay after all these years.

I hate auto detection as it always gets it wrong.

I bought an ATI card because AMD released documentation and because recent nVidia cards cope with manufacturing problems. I refuse to buy defective products.

Add modern graphics on top of outdated rendering techniques?

I meant that they have some good code freely available in sdk (examples, and so one, and not all of them are nvidia-dependant), and some useful libraries, like nvtristrip. Also (not sure if that is good or bad) their glsl compiler is less picky than the one used on ATI. As for their manufacturing problems - they aren't my concern right now, because I'm happy with my card.

Yes.
Besides there are already conversions of Quake 1 engine to newer technologies. Modern graphics are not that different from "outdated" ones. Besides I meant to use opengl without shaders (so quake 2 would be better example), which will allow to build prototype quicker.
If you won't be able to do game which looks like Q1, you won't be able to create anything that looks better.
Differences in rendering sequence are minor. The only thing you should prepare yourself to is that you might have to render scene or parts of the scene more than once and possibly from multiple points of view (which means that occlusion culling part should be flexible enough to allow that). That is the only thing that matters. Once you have working prototype with old-style lighting, you can easily move it to multi-pass per-pixel lighting, because it all comes to finding objects and lights that affect them (even in old-style lighting, because limits on number of lights are pretty strict even on fixed-function pipeline), determining visible (and/or lit) faces in the level geometry, and so on. And besides dynamic lighting (and setting shaders) the rest is identical - you have scene graph, you determine what is visible, what lights affects it, and you render it, and in many cases you can still use same functions for setting matrices. In my opinion, in the end it all (even rendering) comes to collision detection, and it hasn't changed much.