A clean opengl source port ?

[FireFish]

Hello doom tech-heads i have a problem which i cant seem to find an answer to. For some time now i have been searching far and wide to find a super clean code-base of doom / doom 2 in the likes of prboom+ without added extras like linedefs, things, and MBF by example. To phrase it at its most simplest a direct doom engine to opengl with no additions.

The problem would be having it work on modern windows, and i already attempted to clean prboom / + but my patience ran out. Any guide or help to get such a thing would be appreciated.

If people are interested i could post some ideas i have but for which i fail the patience to implement

[Graf Zahl]

I doubt you will find anything if PrBoom doesn't suit your needs.

The GL parts of all other hardware accelerated ports are significantly more complex than what PrBoom has to offer.

Few developers who are interested in hardware accelerated rendering care about strict vanilla feature support.

[FireFish]

Well it is not about the strict vanilla rendering in opengl, it is more about features like Mans best friend and others additions into the code base that bloat it up for me. High res, and raised limits are absolutely no problem at all.

original linedefs, original things, no added scripting, no MBF, etc...
it actually surprised me that no such thing seemed to exist.

Well i might as well garbage bin this idea, and go for prboom and fidle with it once in a while... It kind of killed my drive to actually do something with the engine / game design.

[Graf Zahl]

FireFish said:

it actually surprised me that no such thing seemed to exist.

As I said, those with an interest in hardware rendering have a tendency to go 'more modern' with their feature sets. And since the compatibility of PrBoom is extremely good there's really no need for something simpler, it can already do everything that's needed.

[Doom_user]

GLBoom-plus with the "default compatibility level" set to "Doom/2 v1.9" and the "sector light mode" set to "shaders". That's as close to a clean opengl source port as you can get.

[FireFish]

Thank you for the attempt to help, but i was referring to the code base and not to the execution after being compiled.

[Quasar]

This is digging way back into the annals of Doom community history, but it's probably the only shot you have at what you're looking for:

http://sourceforge.net/projects/gldoom/

glDoom was the original GL port of DOOM. The source code was thought to be lost from 1998 until 2011 and then somebody turned up with a copy of it.

This is one of the first generation ports and as far as I know, it is minimally modified in the way of meeting its particular goals, and for portability to Windows. I don't guarantee it's exactly what you want or that it works to any satisfactory extent though :P

[Graf Zahl]

I don't think the GL code in there is particularly useful. The game related code may be sufficiently unaltered but as a whole this is way too rough if it's in the same state as the last version of it that I ever used.

[Gez]

http://doomwiki.org/wiki/glDoom

If you don't like having extra features, you can always remove them from GLBoom+. It's a lot easier to cut out stuff than to create a new GL rendering engine; and you can take advantage of PrBoom+'s compatibility code to quickly find most of the code that you can remove.

Alternatively, try to transplant the renderer from GLBoom+ to Chocolate Doom or something.

[Quasar]

Graf Zahl said:

I don't think the GL code in there is particularly useful. The game related code may be sufficiently unaltered but as a whole this is way too rough if it's in the same state as the last version of it that I ever used.

Well aside from that and DoomGL, which I don't know the state of at all, there aren't really any other options. Doom 3D was Direct3D, and as Kaiser found, also in need of a more-or-less ground-up rewriting.

The options for what he's asking for are all fixer-uppers. By making said request I get the impression that he's looking for a code base to work on though so, if he wants work, he'll have plenty of it.

[FireFish]

Interesting, yet now i am starting to cringe at the idea. :)

Thinking about the age of GLdoom it might need extreme amounts of updating beyond my patience
to work on a hobby idea which would use the doom engine, As my fear with ancient Gl is based around OPENGL its fast transition
to one hundred percent shader based rendering and deprecating the old school functions would mean
this could end up non functional way to fast.

It seems i was hoping for something i might never find without having
to dedicate many hours and grinding trough the source code, for a meager conceptual idea for a simplistic game using the doom code base in a way that it would be stand alone and without clutter, instead of a mod.

And yes i am one of those people who since childhood dreamed of game creation, has thousands of ideas, but never seems to find the perfect ways of creating them...

[VGA]

There are source ports like zdoom that have had decades of development effort put into them. What do you want to create that is impossible in that?

[FireFish]

It is not about something being impossible to do in any existing engine based upon the doom code, it is about me wanting to know if by any chance there would be an absolutely clean doom engine port without anything added except a modernized rendering system, (and the usually logical mouse look extra.)

I absolutely can not stand or tolerate in any way everything which could be totally unnecessary or irrelevant inside of an engine / code-base which i would use to create a game, or even experiment with in private. Call it odd or crazy but i can not stand it... i do not need MBF mixed mixed with 100 linedef actions topped by a script interpreter, supplemented by code hacks hiding where they load the engine its own resource wads while adding 200 new sector specials, etc...

But still, at least i have gotten some useful answers out of doomworld yet again. if i ever come as far as comparing
I might look at what ID software did to PRBOOM to make DOOM-IOS,
maybe i could find something usefull here once i actualy do it, which i doubt would be more then a direct port of prboom.... :(

https://github.com/id-Software/DOOM-iOS/tree/master/code/prboom

[fraggle]

Prboom includes a GL renderer. It's probably easiest to just go through and rip out all the stuff you don't need. Arguably the Boom code is much cleaner than the original Doom sources anyway: it's vastly cleaned up and sanitised.

You complain about hundreds of extra linedef types etc. but what Boom actually provides is generalised linedef and sector types. If you're making a totally new game and want something simple it might even make more sense to strip out the original Doom linedef types.

I can understand not liking the prboom+ compatibility hacks as they complicate things a lot. I suggest using straight prboom, possibly an older version from before they were incorporated. The original prboom code was much closer to the original boom code and much cleaner.

[andrewj]

FireFish said:

I absolutely can not stand or tolerate in any way everything which could be totally unnecessary or irrelevant inside of an engine / code-base which i would use to create a game, or even experiment with in private. Call it odd or crazy but i can not stand it... i do not need MBF mixed mixed with 100 linedef actions topped by a script interpreter, supplemented by code hacks hiding where they load the engine its own resource wads while adding 200 new sector specials, etc...

I can understand where you are coming from. Recently I made a project and chose PrBoom as the basis, and found it a fairly unpleasant code-base to work with, riddled with all that demo compatibility stuff which I did not need for my project, and code files where the formatting is so inconsistent that I needed to reformat it just to make it readable. Not a fan of Killough's terse lisp-like style either.

That said, you're gonna be hard-pressed to find any open-sourced game engine that has nice clean code, especially one with only the features you care about and nothing else. Quake has its fair share of hacky shit going on. The original Cube engine is quite minimal, but the code also has a minimally-commented terse style making it hard to understand.