A long journey starting with a simple step...
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 :/
|
Quote:
Quote:
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. Quote:
Quote:
Quote:
Quote:
|
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. |
Quote:
Quote:
Quote:
|
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.
|
Quote:
|
Quote:
Where did Erv say that Quote:
|
Quote:
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
//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. Quote:
Quote:
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. Quote:
Quote:
//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. |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
//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. Quote:
Quote:
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. Quote:
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. Quote:
Most games that use HDR have that awful yellowish-pinkish color. Quote:
There was ATI sdk somewhere, but it was mostly DirectX/Windows related. Nvidia is better for OpenGL+Linux. Quote:
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. |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
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. |
All times are GMT -5. The time now is 09:10 PM. |