[fpc-pascal] DOOM game for FPC

[L505]

I got Doom to compile with freepascal and run. But I'm not exactly a gamer.

Someone else maybe want to take on the source code and improve it?

[L505]

Post by L505
I got Doom to compile with freepascal and run. But I'm not exactly a gamer.
Someone else maybe want to take on the source code and improve it?

Here is the

Information link:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Doom-To-Freepascal

Direct Download link:
http://z505.com/pascal/games/DoomToFreepascal.zip

I talked to Jimmy and we are going to make it one single project (maybe throw in some
IFDEF's for freepascal..)

Also, this project will help solve some Delphi incompatibilities with freepascal in
Delphi mode. I came across a few (but not many!).


--
L505

[Felipe Monteiro de Carvalho]

Post by L505
I got Doom to compile with freepascal and run. But I'm not exactly a gamer.
Someone else maybe want to take on the source code and improve it?
_______________________________________________
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Hello,

You manually converted c code from doom to pascal and made it compile?

Where can one find the source code?

In what licence Doom is? If you need hosting space and doom is free
software maybe you could use Source-forge. There is the lazarus code
and components repository project.

Maybe you could add a link to the Wiki? Lazarus wiki at least has a
"Projects" section.

thanks,
--
Felipe Monteiro de Carvalho

[Elio Cuevas Gómez]

Post by Felipe Monteiro de Carvalho
Hello,
You manually converted c code from doom to pascal and made it compile?
Where can one find the source code?
In what licence Doom is? If you need hosting space and doom is free
software maybe you could use Source-forge. There is the lazarus code
and components repository project.

IIRC Doom is GPL'ed, but the translation doesn't have to be.

[L505]

Post by Felipe Monteiro de Carvalho
Hello,
You manually converted c code from doom to pascal and made it compile?

Jimmy did the work, I just ported it to run on freepascal. It's all in the ReadMe.txt
file :-). Jimmy ported all the C code to Delphi, and I saw his post on Pascal Game
Development website. I'm not exactly a gamer, but I decided to run it through the
freepascal compiler just for fun.

Post by Felipe Monteiro de Carvalho
Where can one find the source code?

The C code?

ID Software (the maker's of doom) released Doom source code... There are even
versions of Doom that run on linux, AFAIR.

Problem is, the game runs really slow on freepascal and the walls "jump into your
face".
Could someone please confirm that the walls are rammed into your face, when you play
the game? It could just be my video card, but I think that is optimistic.

I'm sure this project will help us optimize the freepascal compiler. It could be that
this Doom code has some "bad code" in it, and that Delphi optimizes "bad code" better
than freepascal?

The other problem is the keyboard is really "sticky". You have to hold down the keys
longer in the freepascal version than the Delphi one.

If I had Atttention Deficit disorder, I'd think of running over to Quake 2 and try
compiling it.. but alas... now it's back to Syn text editor work ;-)

--
L505

[Kornel Kisielewicz]

Post by L505
I got Doom to compile with freepascal and run. But I'm not exactly a gamer.
Someone else maybe want to take on the source code and improve it?

This is amazing!
Anyway, I took a peek, and by the look of it I have two suspicions for
that graphics mess:

1. Floating Point operations.
2. Floating point comparition.

I'm not much of a gamer, but a Doom fan :-P. I even made a freepascal
Doom Roguelike game :-P.

[L505]

Post by Kornel Kisielewicz
Anyway, I took a peek, and by the look of it I have two suspicions for
1. Floating Point operations.
2. Floating point comparition.
I'm not much of a gamer, but a Doom fan :-P. I even made a freepascal
Doom Roguelike game :-P.

So you think Delphi optimizes these operations significantly?
So you did see walls and bricks rammed into your face when you played too?
It's not just my video card?

How about the keyboard? Was it sticky and slow? As if you had molasses on it?

[Kornel Kisielewicz]

Post by L505

Post by Kornel Kisielewicz
Anyway, I took a peek, and by the look of it I have two suspicions for
1. Floating Point operations.
2. Floating point comparition.
I'm not much of a gamer, but a Doom fan :-P. I even made a freepascal
Doom Roguelike game :-P.

So you think Delphi optimizes these operations significantly?

No, I think that the error is in the BSP building algorithm. Original
C-source probably used some float-model-specific optimizations, the guy
who ported it to Delphi converted them to delphi-float-model-specific
results, and while porting to FPC those things got broken. I know that
in the "old-days" there were several machine-wise tricks on floats that
were used for BSP trees, and I imagine that could be the main source of
the problem.

Post by L505
So you did see walls and bricks rammed into your face when you played too?

Yes.

Post by L505
It's not just my video card?

No :-). Or both of ours :-D.

Post by L505
How about the keyboard? Was it sticky and slow? As if you had molasses on it?

Yes.

I wonder how much work would it be porting this code to JEDI-SDL...
Hell, I might even give it a try... tough it seems useless, for there
would be no gain for anyone from that -- we already have several supreme
Doom-clones... :-]

[Vinzent Hoefler]

Post by Kornel Kisielewicz
No, I think that the error is in the BSP building algorithm.

The BSP-trees are built beforehand. I don't see how this would affect
game performance unless the built BSP-tree is heavily unoptimized.

Post by Kornel Kisielewicz
Original
C-source probably used some float-model-specific optimizations, the
guy who ported it to Delphi converted them to
delphi-float-model-specific results, and while porting to FPC those
things got broken. I know that in the "old-days" there were several
machine-wise tricks on floats that were used for BSP trees, and I
imagine that could be the main source of the problem.

The original Doom didn't use floating point at all. Back in the "old
days" (meaning: 486 at best) it was far too slow (no pipeline and all).
Maybe the conversion now uses floats, but the original code definitely
didn't. Quake was the first of Id's games to rely heavily on floating
point usage (and IIRC also a lot of hand-optimized assembly to get
those through the pipeline fast enough).


Vinzent.

[L505]

I'm not an expert in game programming.. so I don't know much about BSP. But the
keyboard runs at least 4 times as slow, and I still don't see why the game would be
any different on the same code base. The keyboard running 4 times as slow shouldn't
be related to BSP, so there are other issues too, than just graphics.

The FPC team always requested a real world example of the same code in freepascal
running several times slower than in delphi. Now optimally, I hope it is simply a
"bad code" issue in which delphi cleans up more than FPC.

Jimmy is going to look into the FPC code too. But at least we have a real world, in
practise example of where Delphi may (or may not, if this is bad code) be several
times faster than freepascal.

[Jonas Maebe]

Post by L505
The FPC team always requested a real world example of the same code in freepascal
running several times slower than in delphi. Now optimally, I hope it is simply a
"bad code" issue in which delphi cleans up more than FPC.

Keyboard handling is not something which is cpu-bound in any way, so
I doubt that is caused by a code generation issue.


Jonas

[L505]

Post by Jonas Maebe
Keyboard handling is not something which is cpu-bound in any way, so
I doubt that is caused by a code generation issue.

Only think I could think of is if maybe there are some non-standard loops running
waiting for the keyboard, that are sucking up CPU, it is weird ..

[Florian Klaempfl]

Post by L505
I'm not an expert in game programming.. so I don't know much about BSP. But the
keyboard runs at least 4 times as slow, and I still don't see why the game would be
any different on the same code base. The keyboard running 4 times as slow shouldn't
be related to BSP, so there are other issues too, than just graphics.
The FPC team always requested a real world example of the same code in freepascal
running several times slower than in delphi. Now optimally, I hope it is simply a
"bad code" issue in which delphi cleans up more than FPC.
Jimmy is going to look into the FPC code too. But at least we have a real world, in
practise example of where Delphi may (or may not, if this is bad code) be several
times faster than freepascal.

Such issues has usually nothing to do with good/bad code generation.

[L505]

Post by Florian Klaempfl
Such issues has usually nothing to do with good/bad code generation.

I meant bad code by the author/creator... not the compiler :)

Sometimes delphi has been known to clean up bad loops that people create, and speed
them up..

[L505]

Post by L505

Post by Jonas Maebe
Keyboard handling is not something which is cpu-bound in any way, so
I doubt that is caused by a code generation issue.

Only think I could think of is if maybe there are some non-standard loops running
waiting for the keyboard, that are sucking up CPU, it is weird ..

There are quite a bit of keyboard code snips...

"// Respond to keyboard input events,
// intercept cheats. "

And there is also a unit called "unit i_input;" which does a lot of keyboard
translation/input

Something like that might be checking too often or not often enough for keyboard
input - I won't be able to look into it for a while. Jimmy might find something too.