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?

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,

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!).

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

L505 wrote

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.

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.

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 ;-)

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?

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.

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

Yes.

It's not just my video card?

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

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... :-]

Kornel Kisielewicz wrote

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.

The original Doom didn't use floating 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.

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.

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

Jonas

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

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.

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