Writting a doom-like game

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?
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.

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 :slight_smile:

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

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
systems.

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
painters algorithm.

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 :slight_smile:

That is a good way to really learn how it works. But, from experience, I
can tell you that it takes a long time.

	Bob PendletonOn Tue, 2005-01-04 at 11:21 -0300, J Inacio wrote:

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
http://www.libsdl.org/mailman/listinfo/sdl

Does anyone here have a good advice?

Well - I do have a copy of the doom-source at home - the following to
say:

  • Most things they did back than were necessary back than but are not
    necessary today.
    To learn how to code the old way is not bad but IMHO wasted time
    because you will still have to learn the current ways of programming
    and if you learn those you will sooner or later understand the old
    ones.
    In short - redundancy :slight_smile:

  • Seeing the doom code is good if you want to learn some (old) dirty
    tricks. Can be helpfull some time but you will need some understanding
    of what they do first.

  • You say you code Java - well - let’s hope that’s not the only
    language because a jump from Java to assembler (which doom is written
    in) is a - let’s say - HUGE leap. If Java is the only language you know
    you should learn C (or C++, but C is better (IMHO) if you want to head
    that way) first before hitting assembler.

  • It may be handy to know how to write a complete renderer (rasterizer,
    etc.) but that’s all. You don’t actually want to write a renderer
    (believe me :slight_smile: you want to create 3D graphics (at least I did - and I
    had the same idea you have ;).
    In short - get a book about the basics (e.g. Peter Shirley -
    Fundamentals of Computer Graphics) that will give you all the
    understanding you need in much less time.
    Furthermore IF you want to learn from doom you have to understand all
    the optimizing they did and that can get really hard if you don’t know
    the basics which the doom code will NOT tell you (like I already
    mentioned ;).

  • If you did it anyway and wrote your own renderer you will sooner or
    later discard it and turn to OpenGL or DirectX. Why? Those libraries
    stick around here a long time, meaning many people put lot of work in
    it, meaning those libraries will be better than anything you will end
    up with in the same time. And - after all - if you want to write games
    you need to know one of those libraries anyway.

Ergo - what I would recommend:

  • If you don’t know C - learn it. If you learned C - switch over to
    C++, maybe have a (short) look on assembler (comes handy some times).

  • Get a book about 3D basics (e.g. Shirley). If you feel like you want
    to code a few parts of it - do that one-by-one.

  • After that get yourself a few OpenGL tutorials (e.g.
    nehe.gamedev.net) and play around with those to see how OpenGL handles
    the basics you just learned. You will see - you only need a fraction of
    the basics you learned and happily not many of the complicated ones.

  • And - if you still don’t have enough - get yourself the book “Real
    Time Rendering” - that covers nearly every topic in computer graphics.

But after all - that’s only my opinion - the rest is up to you :slight_smile:

Arne

Well, this kind of stuff would definitely still be useful in the PDA and
cellphone programming realms (where small screens, lack of OpenGL / accel 3D
graphics, and no FPU are still the standard ;^) )

-bill!On Tue, Jan 04, 2005 at 09:22:15AM -0600, Bob Pendleton wrote:

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.

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.

Well, this kind of stuff would definitely still be useful in the PDA and
cellphone programming realms (where small screens, lack of OpenGL / accel 3D
graphics, and no FPU are still the standard ;^) )

Yeah… for how long? The first phones with 3D acceleration are for sale
now. The turn over time on cell phones isn’t very long. So, by the time
a newbie learns enough about 3D programming to develop a game, the need
for the skills will be gone. :slight_smile: Seriously, in 5 years will there be any
phones or PDAs for sale that don’t have 3D acceleration? How about 3
years from now?

I looking forward to the first time I see someone playing a stereo video
game using two cell phones or PDAs strapped into a steriopticon
displaying the left and right images on the left and right device. Of
course, it will use something like 802.11g for synchronization and for
multiplayer communications.

Of course, the game would be based on SDL, otherwise this would be a
very off topic post!

	How Cool Would That Be?

		Bob PendletonOn Tue, 2005-01-04 at 11:46 -0800, Bill Kendrick wrote:

On Tue, Jan 04, 2005 at 09:22:15AM -0600, Bob Pendleton wrote:

-bill!


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Huh? DOOM was mostly written in C. It used to contain some small bits of
assembler code in the original DOS version, but it was all ported to straight
C in the Linux version (which is what was open sourced). The DOS assembly
code is included in the source archive (in README.asm), but only for historic
purposes.On January 4, 2005 1308, m7174389-1 wrote:

  • You say you code Java - well - let’s hope that’s not the only
    language because a jump from Java to assembler (which doom is written
    in) is a - let’s say - HUGE leap. If Java is the only language you know
    you should learn C (or C++, but C is better (IMHO) if you want to head
    that way) first before hitting assembler.

check out opengl es
http://www.khronos.org/On Tue, 4 Jan 2005 18:37:17 -0500, Simon Roby wrote:

On January 4, 2005 1308, m7174389-1 wrote:

  • You say you code Java - well - let’s hope that’s not the only
    language because a jump from Java to assembler (which doom is written
    in) is a - let’s say - HUGE leap. If Java is the only language you know
    you should learn C (or C++, but C is better (IMHO) if you want to head
    that way) first before hitting assembler.

Huh? DOOM was mostly written in C. It used to contain some small bits of
assembler code in the original DOS version, but it was all ported to straight
C in the Linux version (which is what was open sourced). The DOS assembly
code is included in the source archive (in README.asm), but only for historic
purposes.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Antoine W. Solomon Jr.

— m7174389-1 escreveu:

Well, C was my first programming language, C++ my
second and Java was the last I learned (3 years ago).
(the thing I most love in programming is pointers and
pointers of pointers).
I used to write pascal and delphi code (wich I hate),
visual basic code (wich I hate even more than delphi).
I wrote some asm inline codes, but it was 8 years
ago.
I have to apologise, I had take doom too “easy”.
Maybe I should have said “Wolfenstein 3d”.
I just want to play with some matrices using SDL for
page flipping and things like that.
The reason why I can not use OpenGL * for now *, is
that, my SiS 740 agp card is only 3d accelerator under
windows, and I do not even use windows anymore (I am a
Slackware fan …) - I think I am not the only one on
the world wich have a pcchips motherboard (I will get
a MSI motherboard and everything will be different :slight_smile:
)

I was thinking about that for fun, only.
Sorry if I looked like I thought I was a master C
programmer.
I know that I looked like I was trying to show
myself, but I was just trying to get some fun :slight_smile:
And I think I still have too much time, I am only 22
now :wink:

A special sorry for Bob Pendleton, I think I made him
angry someway.> > Does anyone here have a good advice?

Well - I do have a copy of the doom-source at home -
the following to
say:

  • Most things they did back than were necessary back
    than but are not
    necessary today.
    To learn how to code the old way is not bad but IMHO
    wasted time
    because you will still have to learn the current
    ways of programming
    and if you learn those you will sooner or later
    understand the old
    ones.
    In short - redundancy :slight_smile:

  • Seeing the doom code is good if you want to learn
    some (old) dirty
    tricks. Can be helpfull some time but you will need
    some understanding
    of what they do first.

  • You say you code Java - well - let’s hope that’s
    not the only
    language because a jump from Java to assembler
    (which doom is written
    in) is a - let’s say - HUGE leap. If Java is the
    only language you know
    you should learn C (or C++, but C is better (IMHO)
    if you want to head
    that way) first before hitting assembler.

  • It may be handy to know how to write a complete
    renderer (rasterizer,
    etc.) but that’s all. You don’t actually want to
    write a renderer
    (believe me :slight_smile: you want to create 3D graphics (at
    least I did - and I
    had the same idea you have ;).
    In short - get a book about the basics (e.g. Peter
    Shirley -
    Fundamentals of Computer Graphics) that will give
    you all the
    understanding you need in much less time.
    Furthermore IF you want to learn from doom you have
    to understand all
    the optimizing they did and that can get really hard
    if you don’t know
    the basics which the doom code will NOT tell you
    (like I already
    mentioned ;).

  • If you did it anyway and wrote your own renderer
    you will sooner or
    later discard it and turn to OpenGL or DirectX. Why?
    Those libraries
    stick around here a long time, meaning many people
    put lot of work in
    it, meaning those libraries will be better than
    anything you will end
    up with in the same time. And - after all - if you
    want to write games
    you need to know one of those libraries anyway.

Ergo - what I would recommend:

  • If you don’t know C - learn it. If you learned C -
    switch over to
    C++, maybe have a (short) look on assembler (comes
    handy some times).

  • Get a book about 3D basics (e.g. Shirley). If you
    feel like you want
    to code a few parts of it - do that one-by-one.

  • After that get yourself a few OpenGL tutorials
    (e.g.
    nehe.gamedev.net) and play around with those to see
    how OpenGL handles
    the basics you just learned. You will see - you only
    need a fraction of
    the basics you learned and happily not many of the
    complicated ones.

  • And - if you still don’t have enough - get
    yourself the book “Real
    Time Rendering” - that covers nearly every topic in
    computer graphics.

But after all - that’s only my opinion - the rest is
up to you :slight_smile:

Arne


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Yahoo! Acesso Gr?tis - Instale o discador do Yahoo! agora. http://br.acesso.yahoo.com/ - Internet r?pida e gr?tis

A special sorry for Bob Pendleton, I think I made him
angry someway.

I doubt it. Bob is a great guy that just hates seeing people wasting
their time :slight_smile:

Saludos desde Uruguay,

--Gabriel

— m7174389-1 escreveu:

Well, C was my first programming language, C++ my
second and Java was the last I learned (3 years ago).
(the thing I most love in programming is pointers and
pointers of pointers).
I used to write pascal and delphi code (wich I hate),
visual basic code (wich I hate even more than delphi).
I wrote some asm inline codes, but it was 8 years
ago.
I have to apologise, I had take doom too “easy”.
Maybe I should have said “Wolfenstein 3d”.
I just want to play with some matrices using SDL for
page flipping and things like that.
The reason why I can not use OpenGL * for now *, is
that, my SiS 740 agp card is only 3d accelerator under
windows, and I do not even use windows anymore (I am a
Slackware fan …) - I think I am not the only one on
the world wich have a pcchips motherboard (I will get
a MSI motherboard and everything will be different :slight_smile:
)

I was thinking about that for fun, only.
Sorry if I looked like I thought I was a master C
programmer.
I know that I looked like I was trying to show
myself, but I was just trying to get some fun :slight_smile:
And I think I still have too much time, I am only 22
now :wink:

A special sorry for Bob Pendleton, I think I made him
angry someway.

No, not at all. I was not angry at all. I think what you are talking
about makes a lot of sense. It is a good way to learn about 3D graphics
at the lowest level.

It is very easy to ascribe emotions to the content of an email that are
not there. This is especially easy when the two people come from
different cultures or speak different native languages.

BTW, my code for polyfonts
(http://gameprogrammer.com/polyfonts/polyfonts.html) includes a software
line drawer and a software polygon renderer including clipping. It would
be a good place to start. And the article at
http://gameprogrammer.com/6-text.html is one I wrote about doing texture
mapping. It is very old. I did a lot of the original work on a 386 about
12 years ago and is based on fixed point arithmetic. So, the code may be
a bit hard to follow.

Also, the VOGLE library at http://www.wumpus.com.au/eric/ is a good,
though confusing, software rendering library that does every thing you
want to do. Studying it can be very helpful. It was to me.

	Bob PendletonOn Tue, 2005-01-04 at 21:52 -0300, J Inacio wrote:

Does anyone here have a good advice?

Well - I do have a copy of the doom-source at home -
the following to
say:

  • Most things they did back than were necessary back
    than but are not
    necessary today.
    To learn how to code the old way is not bad but IMHO
    wasted time
    because you will still have to learn the current
    ways of programming
    and if you learn those you will sooner or later
    understand the old
    ones.
    In short - redundancy :slight_smile:

  • Seeing the doom code is good if you want to learn
    some (old) dirty
    tricks. Can be helpfull some time but you will need
    some understanding
    of what they do first.

  • You say you code Java - well - let’s hope that’s
    not the only
    language because a jump from Java to assembler
    (which doom is written
    in) is a - let’s say - HUGE leap. If Java is the
    only language you know
    you should learn C (or C++, but C is better (IMHO)
    if you want to head
    that way) first before hitting assembler.

  • It may be handy to know how to write a complete
    renderer (rasterizer,
    etc.) but that’s all. You don’t actually want to
    write a renderer
    (believe me :slight_smile: you want to create 3D graphics (at
    least I did - and I
    had the same idea you have ;).
    In short - get a book about the basics (e.g. Peter
    Shirley -
    Fundamentals of Computer Graphics) that will give
    you all the
    understanding you need in much less time.
    Furthermore IF you want to learn from doom you have
    to understand all
    the optimizing they did and that can get really hard
    if you don’t know
    the basics which the doom code will NOT tell you
    (like I already
    mentioned ;).

  • If you did it anyway and wrote your own renderer
    you will sooner or
    later discard it and turn to OpenGL or DirectX. Why?
    Those libraries
    stick around here a long time, meaning many people
    put lot of work in
    it, meaning those libraries will be better than
    anything you will end
    up with in the same time. And - after all - if you
    want to write games
    you need to know one of those libraries anyway.

Ergo - what I would recommend:

  • If you don’t know C - learn it. If you learned C -
    switch over to
    C++, maybe have a (short) look on assembler (comes
    handy some times).

  • Get a book about 3D basics (e.g. Shirley). If you
    feel like you want
    to code a few parts of it - do that one-by-one.

  • After that get yourself a few OpenGL tutorials
    (e.g.
    nehe.gamedev.net) and play around with those to see
    how OpenGL handles
    the basics you just learned. You will see - you only
    need a fraction of
    the basics you learned and happily not many of the
    complicated ones.

  • And - if you still don’t have enough - get
    yourself the book “Real
    Time Rendering” - that covers nearly every topic in
    computer graphics.

But after all - that’s only my opinion - the rest is
up to you :slight_smile:

Arne


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


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
http://www.libsdl.org/mailman/listinfo/sdl

In any case, were goes the details of a book describing
just that.

I already mailed Inacio about this, but I am posting
here because someone else might be interested.

NetWarriors In C : Pogramming 3D Multi-Player Games In C
Joe Gradecki
John Wiley & Sons
ISBN: 0471110647

http://www.wiley.com/legacy/compbooks/catalog/11064-7.htm

But this is really an old book, from around 97.
It targets MS-DOS and most of the techniques described
there are outdated.

The author did a new version in C++, called
NetWarriors In C++ : Pogramming 3D Multi-Player Games In C++

As far as I know it is the same book but updated for Windows 95/C++
and using GDI. But I haven’t read this one.

If we time travel back to 1997, I can say that it is a good
book on the subject. But nowadays, I don’t know how much it
can help you.

Cheers,
Paulo

Quoting J Inacio :> — m7174389-1 escreveu:

Well, C was my first programming language, C++ my
second and Java was the last I learned (3 years ago).
(the thing I most love in programming is pointers and
pointers of pointers).
I used to write pascal and delphi code (wich I hate),
visual basic code (wich I hate even more than delphi).
I wrote some asm inline codes, but it was 8 years
ago.
I have to apologise, I had take doom too “easy”.
Maybe I should have said “Wolfenstein 3d”.
I just want to play with some matrices using SDL for
page flipping and things like that.
The reason why I can not use OpenGL * for now *, is
that, my SiS 740 agp card is only 3d accelerator under
windows, and I do not even use windows anymore (I am a
Slackware fan …) - I think I am not the only one on
the world wich have a pcchips motherboard (I will get
a MSI motherboard and everything will be different :slight_smile:
)

I was thinking about that for fun, only.
Sorry if I looked like I thought I was a master C
programmer.
I know that I looked like I was trying to show
myself, but I was just trying to get some fun :slight_smile:
And I think I still have too much time, I am only 22
now :wink:

A special sorry for Bob Pendleton, I think I made him
angry someway.

Does anyone here have a good advice?

Well - I do have a copy of the doom-source at home -
the following to
say:

  • Most things they did back than were necessary back
    than but are not
    necessary today.
    To learn how to code the old way is not bad but IMHO
    wasted time
    because you will still have to learn the current
    ways of programming
    and if you learn those you will sooner or later
    understand the old
    ones.
    In short - redundancy :slight_smile:

  • Seeing the doom code is good if you want to learn
    some (old) dirty
    tricks. Can be helpfull some time but you will need
    some understanding
    of what they do first.

  • You say you code Java - well - let’s hope that’s
    not the only
    language because a jump from Java to assembler
    (which doom is written
    in) is a - let’s say - HUGE leap. If Java is the
    only language you know
    you should learn C (or C++, but C is better (IMHO)
    if you want to head
    that way) first before hitting assembler.

  • It may be handy to know how to write a complete
    renderer (rasterizer,
    etc.) but that’s all. You don’t actually want to
    write a renderer
    (believe me :slight_smile: you want to create 3D graphics (at
    least I did - and I
    had the same idea you have ;).
    In short - get a book about the basics (e.g. Peter
    Shirley -
    Fundamentals of Computer Graphics) that will give
    you all the
    understanding you need in much less time.
    Furthermore IF you want to learn from doom you have
    to understand all
    the optimizing they did and that can get really hard
    if you don’t know
    the basics which the doom code will NOT tell you
    (like I already
    mentioned ;).

  • If you did it anyway and wrote your own renderer
    you will sooner or
    later discard it and turn to OpenGL or DirectX. Why?
    Those libraries
    stick around here a long time, meaning many people
    put lot of work in
    it, meaning those libraries will be better than
    anything you will end
    up with in the same time. And - after all - if you
    want to write games
    you need to know one of those libraries anyway.

Ergo - what I would recommend:

  • If you don’t know C - learn it. If you learned C -
    switch over to
    C++, maybe have a (short) look on assembler (comes
    handy some times).

  • Get a book about 3D basics (e.g. Shirley). If you
    feel like you want
    to code a few parts of it - do that one-by-one.

  • After that get yourself a few OpenGL tutorials
    (e.g.
    nehe.gamedev.net) and play around with those to see
    how OpenGL handles
    the basics you just learned. You will see - you only
    need a fraction of
    the basics you learned and happily not many of the
    complicated ones.

  • And - if you still don’t have enough - get
    yourself the book “Real
    Time Rendering” - that covers nearly every topic in
    computer graphics.

But after all - that’s only my opinion - the rest is
up to you :slight_smile:

Arne


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


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
http://www.libsdl.org/mailman/listinfo/sdl


This message was sent using IMP, the Internet Messaging Program.

sdl-bounces+leiradella=bigfoot.com at libsdl.org wrote:

In any case, were goes the details of a book describing
just that.

I already mailed Inacio about this, but I am posting
here because someone else might be interested.

NetWarriors In C : Pogramming 3D Multi-Player Games In C
Joe Gradecki
John Wiley & Sons
ISBN: 0471110647

http://www.wiley.com/legacy/compbooks/catalog/11064-7.htm

PCGPE (http://brand107.home.comcast.net/pc-gpe/) has some articles that
describe algorithms used in Doom:

. BSP Trees and Painter’s Algorithm
. Texture Mapping
. Doom Techniques

Cheers,

Andre de Leiradella

There are still some niches where fixed point is valuable. Whenever you need
to store some vector that is supposed to have equally distributed precision
across its entire range, and you’re not doing seriously heavy math with
this vector, you might want to consider fixed point.

In one 3D environment, I was reaching the range limits of the 32 bit float.
Well, not exactly the range limit, but once you’re too far from 0 (i.e. the
world origin), the precision got so bad that round-off errors in simulation
were unacceptable. There were two choices: Use double, which takes twice
the memory, or store the actual coordinates as 32 bit fixed point. I chose
the latter, and it works perfectly fine. Note that I still use float during
the actual simulation, but that works out fine because during the
simulation, only small (difference) vectors will be used.

To give a more well-known real-life example, Half-Life sends player
coordinates as fixed point across the network. This is obviously done in
order to save space while guarantueeing that the precision at which player
coordinates are transferred is everywhere the same.

cu,
Nicolai
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050108/4092f884/attachment.pgpOn Tuesday 04 January 2005 16:22, Bob Pendleton wrote:

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.

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.

There are still some niches where fixed point is valuable. Whenever you need
to store some vector that is supposed to have equally distributed precision
across its entire range, and you’re not doing seriously heavy math with
this vector, you might want to consider fixed point.

In one 3D environment, I was reaching the range limits of the 32 bit float.
Well, not exactly the range limit, but once you’re too far from 0 (i.e. the
world origin), the precision got so bad that round-off errors in simulation
were unacceptable. There were two choices: Use double, which takes twice
the memory, or store the actual coordinates as 32 bit fixed point. I chose
the latter, and it works perfectly fine. Note that I still use float during
the actual simulation, but that works out fine because during the
simulation, only small (difference) vectors will be used.

To give a more well-known real-life example, Half-Life sends player
coordinates as fixed point across the network. This is obviously done in
order to save space while guarantueeing that the precision at which player
coordinates are transferred is everywhere the same.

Yes, in a completely different context than the one I was talking about
fixed point still has a place. But, you wouldn’t seriously suggest that
he write and entire rendering pipeline based on fixed point arithmetic,
would you?

		Bob PendletonOn Sat, 2005-01-08 at 17:53 +0100, Nicolai Haehnle wrote:

On Tuesday 04 January 2005 16:22, Bob Pendleton wrote:

cu,
Nicolai


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl