[SDL] Linux, OpenGl, VBO and SDL?
cu at cg.tuwien.ac.at
Thu Jan 20 09:01:10 PST 2005
On Tue, 2005-01-04 at 11:21 -0300, J Inacio wrote:
> Hi there.
> I am thinking about start writting a doom clone,
> using only 2d things (like doom was made), without
> opengl, just algebra and C.
> Does anyone here have a good advice?
Good advise? It is up to you to decide if it is "good" advise. But,
advise, I have plenty!
I usually tell people not to do what you are about to do. I do that
because they want to write a game, but want to be able to claim they are
as macho as the old time game programmers. But, it seems clear that you
want to do this project so that you can learn how graphics are done at
the lowest level. That is a goal that is worth pursuing.
OTOH, many of the skills you will gain from doing it aren't that
valuable. Learning how to draw a 3d texture mapped polygon from scratch
is not that much use in todays world. Learning how to concatenate a
transformation matrix is worth while and you have to learn to do it
whether you use OpenGL or not. Learning how to do scene level polygon
culling is worthwhile, but you will have to learn that whether you use
OpenGL or not.
There are a lot of things that were done in DOOM that are not worth
doing now. For example, DOOM used fixed point arithmetic, but modern
processors (486DX and above) do floating point math very well, so there
is no need to deal with fixed point arithmetic. DOOM was written for a
VGA display and used a tweaked display mode to get access to the frame
buffer and to do multi-buffering. You can't do that (or at least you
don't want to do it) on modern operating systems. DOOM was written for
an 8 bit display so palette management was very important. In a world of
32 bit video cards palette management just isn't worth the time.
On a slightly different topic, you say you want to do this using only 2d
things. I think you don't understand that even DOOM was a full 3D
system. It drew to a normal frame buffer, just like OpenGL. The
difference is that we didn't have 3D hardware acceleration in those
ancient days. Even Carmack switched to 3D accelerated hardware as soon
as it was available because he wanted to write games, not 3D rendering
I would suggest that you not try to write a full game using all software
techniques. I would suggest that you write a simple 3D package and
experiment with it. Then look at scene level culling. Then spend a lot
of time on 3D techniques. My next suggestion may seem more than a little
bit strange, but here it is. When you build you 3D pipeline, do all the
transformations and even clipping in software. But, use OpenGL, in 2D
mode, to do the actual drawing and page flipping. Then as you develop
your system compare it to OpenGL. This will help you get a deep
understanding of why OpenGL does the things it does.
Thing most people forget is that a system like OpenGL represents the
distilled wisdom and knowledge of a couple of generations of graphic
programmers and graphic hardware designers. You can learn an awful lot
by getting to where you understand why they did it like that.
> I am thinking about it as a way to learn about the
> basis of a 3d game (the raw basis).
> I will give a look at the doom source when I arrive
> home, for some ideas. I know I will have to deal with
> matrices and matrices.
Matrices are a a very small part of it. The key part of DOOM is the BSP
tree based polygon culling system that is used to implement a fast
> I know, there is a lot, really a lot of this things
> that I want to write already written, by really good
> programmers, but the fun, I think, is to write it
> myself :)
That is a good way to really learn how it works. But, from experience, I
can tell you that it takes a long time.
> J Inácio Ferrarini
> Part-time J2EE / J2SE programmer
> Extreme Tecnologia
> Salvador - Bahia - Brazil
> Yahoo! Acesso Grátis - Instale o discador do Yahoo! agora. http://br.acesso.yahoo.com/ - Internet rápida e grátis
> SDL mailing list
> SDL at libsdl.org
More information about the SDL