Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
roadworx

what's the strangest programming language or platform that a source port has been written in?

Recommended Posts

i've been curious about this for a while now. considering doom's source code is freely available, i was wondering if there've been people who took it upon themselves to port it to some programming language or obscure platform that you wouldn't really expect a source port to ever run on, just for shits and giggles. something like, idk, fortran lol

 

i know delphidoom is one of them, but what others are there?

Edited by roadworx

Share this post


Link to post
2 hours ago, jerk-o said:

 

That's just running in Virtualbox - bog-standard Doom written in C with extra steps.

 

The most exotic language I know of that Doom has been ported to is probably Java, with Mocha Doom. Maes goes into the difficulty he had translating the code from C here, and any translation to a language that's not in the same realm of C or Pascal is probably going to go through the same sorts of problems that he did, though likely a different flavor.

Share this post


Link to post

I mean, I hate to be that guy, especially since the author has tragically passed away (RIP), but that doesn't really count either because it's nowhere near complete. If it was, then I'd gladly accept it as one of the weirder languages used for a Doom port.

 

I think in general there's just not a lot of ports to non-C like languages because it's a lot of work for little gain. As a bored side project I've been considering doing a port to C#, but it's just following in the footsteps of Mocha Doom, with some additional conveniences that Java doesn't have. I think there's also been some attempts at porting it to Rust, which does implicate some architectural changes due to Rust's heavy focus on memory safety.

Share this post


Link to post

PyDoom wasn't Python for no reason, there was a lot of intent there. It's been a good four years at least so my memory is hazy, but I believe the intent was to leverage Python's ability to easily do plugin-type stuff? I tried finding the conversation I swear I had with her about the rationale but I couldn't find it.

Share this post


Link to post

I started a port to Crystal called CrDoom.  It's halfway working with an OpenGL renderer, coldet, and thinkers, but it has enough bugs that it isn't playable yet.  But hey, I can get through E1M1 just fine already if I ignore all the monsters and don't shoot*.  It had a software renderer, but it was buggy af, and I honestly prefer an OpenGL look anyway.  The code is based on Managed Doom, which is a port of Doom to C#.

I also wrote a level viewer for Doom in Common Lisp but it doesn't use much of the original code at all.  Just a bit of thinker code is ported, iirc.

Both are very low priority for me, and are just hobby projects, so I basically work on them whenever I'm in more of a programming mood than a mapping mood :-P

*because sometimes this causes the Doomguy to suicide :-P

Share this post


Link to post
2 hours ago, Remilia Scarlet said:

*because sometimes this causes the Doomguy to suicide :-P

 

"Is the mobj who fired me the one I should collide with? I think so!" -the projectile probably

 

I generally find the weirdest things for me is when Doom is loaded up on a toaster or something quirky like that.

Share this post


Link to post

I'd love to see Doom ported to Brainfuck, but I doubt that'll ever happen - or if its even possible? Sure would take a LOT of time... Not a programmer btw...

 

I know Brainfuck is just a goofy esoteric language, I don't actually think anybody's insane enough to try something like this. Its apparently turing complete though, so does that at least mean it would be possible theoretically? I'm naive to this stuff, but once I heard of this language, I immediately was curious if anybody has even tried making a VERY basic game w/ it. Doom would probably be far too hard of an endeavor to port, but maybe Pong? lol

Edited by Arrowhead

Share this post


Link to post

Someone should try making a source port using assembly.

Share this post


Link to post
1 hour ago, Arrowhead said:

I'd love to see Doom ported to Brainfuck, but I doubt that'll ever happen - or if its even possible?

it is definitely possible, but nobody will do it manually. the only way is to use some kind of compiler that will emit bf code instead of assembler for some CPU.

 

on-topic: Vavoom prolly counts too, because the whole playsim (including physics) is done with VavoomC. C++ code does only very low-level things, and most of it can be ported to VavoomC too, Janis simply didn't finished the porting. the whole idea of Vavoom was to move as much engine code as possible to VavoomC. not to be confused with GZDoom, where you can override many engine functions with ZScript, but they are still implemented with C++.

Share this post


Link to post
1 hour ago, Remilia Scarlet said:

Someone should port Doom to Forth.

hm. great idea. i wrote my own Forth system some time ago, and it definitely needs it's own Doom port!

Share this post


Link to post
11 hours ago, Remilia Scarlet said:

I started a port to Crystal called CrDoom.  It's halfway working with an OpenGL renderer, coldet, and thinkers, but it has enough bugs that it isn't playable yet.  But hey, I can get through E1M1 just fine already if I ignore all the monsters and don't shoot*.  It had a software renderer, but it was buggy af, and I honestly prefer an OpenGL look anyway.  The code is based on Managed Doom, which is a port of Doom to C#.

I also wrote a level viewer for Doom in Common Lisp but it doesn't use much of the original code at all.  Just a bit of thinker code is ported, iirc.

Both are very low priority for me, and are just hobby projects, so I basically work on them whenever I'm in more of a programming mood than a mapping mood :-P

*because sometimes this causes the Doomguy to suicide :-P

Honestly i like the concept of CrDoom. Managed Doom being a streamlined bare bones port with a few nifty things like DeHacked support, and  your CrDoom having a basic OpenGL renderer to have hardware acceleration going on.

 

What OGL version are you targetting by the way?

 

I like it, and i love to test it if there ever is a playable build coming out.

3 hours ago, ketmar said:

hm. great idea. i wrote my own Forth system some time ago, and it definitely needs it's own Doom port!

More and more i hear good old KB1 who also made his own systems. Thing is, his port has not seen the light of day and your's is all about lighting. ;)

Share this post


Link to post

I'd say for the uninitiated C is already a pretty strange programming language.

Share this post


Link to post
4 hours ago, Redneckerz said:

More and more i hear good old KB1 who also made his own systems.

i love to do things from the scratch when i can. or take some old piece of software and gradually rewrite it to something comletely different.

 

4 hours ago, Redneckerz said:

and your's is all about lighting.

lighting is just a side effect of the ongoing architectural changes. but it is hard to impress people with "i rewrote alot of code, but you'll never see the difference, because there shouldn't be any", so i had to invent some ways to force people noticing my efforts.

 

also, UrForth is there and can be downloaded. and i actually used it to write some utilities. ;-)

 

p.s.: still no dedicated k8vavoom doomwiki page? i disappoint.

Share this post


Link to post
8 hours ago, Redneckerz said:

 

What OGL version are you targetting by the way? 

2.2. I have an odd fascination with old-school OpenGL.

Share this post


Link to post
5 hours ago, ketmar said:

i love to do things from the scratch when i can. or take some old piece of software and gradually rewrite it to something comletely different.

Atleast you don't tease us. :P

5 hours ago, ketmar said:

 

lighting is just a side effect of the ongoing architectural changes. but it is hard to impress people with "i rewrote alot of code, but you'll never see the difference, because there shouldn't be any", so i had to invent some ways to force people noticing my efforts.

 

also, UrForth is there and can be downloaded. and i actually used it to write some utilities. ;-)

What were those utils about?

5 hours ago, ketmar said:

p.s.: still no dedicated k8vavoom doomwiki page? i disappoint.

Oh you hush :P PsyDoom also does not have one yet. Remind me this for next week.

1 hour ago, Remilia Scarlet said:

2.2. I have an odd fascination with old-school OpenGL.

If you mean 2.1 then count me in, because that's what my garbage PC' supports. :P

Share this post


Link to post
9 minutes ago, Redneckerz said:

If you mean 2.1 then count me in, because that's what my garbage PC' supports. :P

Yes, 2.1 lol.  I dunno why I keep writing 2.2 lately.  That happened yesterday on my Discord server, too.  But yeah, I was in the same position, where I had a machine that couldn't do higher than that (and 2.1 support was flaky as it was).  My plan is to focus more on incremental and experimental mapping features than a cool looking OpenGL renderer anyway, so there's no reason I should leave out people using old hardware (on purpose or for whatever reason), regardless of their number.  But first, I gotta get the base game playable :-P

 

I have a large mapping project for k8 in the works right now, but I'll probably get back to CrDoom for a while by summer, as well as hopefully finally releasing the tools I've written for Doom engine games.

More on topic: didn't someone port Doom to run in UEFI recently?  Still written in C, but that's an unusual platform to target.

Share this post


Link to post

In terms of sheer unsuitability of platform for game, I think Doom for the Super NES would be the winner.

 

Its CPU runs at 3.58MHz, has only 128KiB of general-purpose RAM, and its video unit is optimized for flat sprites animating against flat sprite backgrounds.

 

The unsuitability ran so deep that a second support chip had to be included on the cartridge itself to speed up 3D rendering and make the game playable. Even that runs at a max speed of 21 MHz.

Share this post


Link to post
27 minutes ago, JadingTsunami said:

The unsuitability ran so deep that a second support chip had to be included on the cartridge itself to speed up 3D rendering and make the game playable. Even that runs at a max speed of 21 MHz.

Heh.....running all of that shit on the cartridge is nothing more than a miracle.

Share this post


Link to post

Has anyone ported Doom to TempleOS yet? HolyC only half counts since it’s just a really weird adaptation of C but TempleOS is fucking weird enough by itself that this would be a pretty interesting project

 

if I have infinite time someday I might brush up on my C a bit, learn the ins and outs of Doom and TempleOS and approach this myself, but for now I’ll just idly throw the idea into the æther

 

oh yes and if anybody wants a really maddening programming challenge, try coding for the Atari 2600 

Share this post


Link to post
3 minutes ago, StupidBunny said:

oh yes and if anybody wants a really maddening programming challenge, try coding for the Atari 2600 

I heard that 6502 assembly is one of the harder things to program in - not to mention the EXTREMELY limited memory!!

And yes, a temple OS port of Doom would be an incredible project - I'm assuming it would use temple OS's extremely limited color palette, right? That would look ... interesting...

 

Here's my Hong Kong 'light-sixer', unrelated to the topic at hand, just couldn't resist. I was actually really a bit annoyed when I learned that the Atari 2600 'version' of Doom was a hoax, lol.


 

Spoiler

 

821788339_20210406_1634371.jpg.c2ccdb287dcf0a39a492f7e3c77679f9.jpg


 

Yes, I know my cord habits are horrific haha

Share this post


Link to post
18 hours ago, Arrowhead said:

Here's my Hong Kong 'light-sixer', unrelated to the topic at hand, just couldn't resist. I was actually really a bit annoyed when I learned that the Atari 2600 'version' of Doom was a hoax, lol.

 

 

It's majestic omg

6502 assembly itself isn't that hard, at least I don't think...although there's a lot of instructions that are a little more quirky than their usual descriptions would imply, and there's a lot you can (or sometimes have to) do to manipulate the processor register, instruction stack, memory etc. in ways that feel really hacky.  Being limited to 128 bytes of RAM and 4000 bytes of ROM is also shitty but in a way can be a valuable learning experience in how it makes you think really hard about code optimization--you are simultaneously having to balance and optimize storage, memory, and execution time. 

 

The thing that makes the Atari really a nightmare to program for is mostly the TIA, and the lack of a framebuffer, which means that the CPU is basically racing the laser on the CRT at all times.  You have to run a timer tracking how long the overscan period is, so that you can get all of you gameplay logic calculated during the short time that the screen isn't drawing anything, and then the real misery begins when you get to the actual frame and you have to time the position of the laser with how long it takes to execute each machine instruction.  And I'm not even going to begin expounding on how the TIA registers work, but they're also a total mindfuck counterintuitive to how any sane person would think game programming and sprite drawing should work.

 

It's honestly pretty fun, in a masochistic sort of way

Edited by StupidBunny

Share this post


Link to post
1 minute ago, StupidBunny said:

The thing that makes the Atari really a nightmare to program for is mostly the TIA, and the lack of a framebuffer, which means that the CPU is basically racing the laser on the CRT at all times.

 

It's honestly pretty fun, in a masochistic sort of way

You ever read 'Racing the Beam'? Your racing the laser comment reminded me of it. Great book on all the quirks and misery involved in the 2600 coding process. Also, the stuff that the Atari community can make w/ homebrew now, is CRAZY. But I digress, don't want to clutter up the thread w/ Atari nonsense haha :)

Share this post


Link to post
41 minutes ago, StupidBunny said:

The thing that makes the Atari really a nightmare to program for is mostly the TIA, and the lack of a framebuffer, which means that the CPU is basically racing the laser on the CRT at all times.  You have to run a timer tracking how long the overscan period is, so that you can get all of you gameplay logic calculated during the short time that the screen isn't drawing anything, and then the real misery begins when you get to the actual frame and you have to time the position of the laser with how long it takes to execute each machine instruction.  And I'm not even going to begin expounding on how the TIA registers work, but they're also a total mindfuck counterintuitive to how any sane person would think game programming and sprite drawing should work.

 

It's honestly pretty fun, in a masochistic sort of way

??????

 

who in their right mind thought that was a good idea, wtf?? i'm assuming there's some reason for it being like that, like ram being ridiculously expensive at the time or something (update: did some research and found out that is indeed the reason), but jfc that sounds horrendous

Share this post


Link to post
11 hours ago, Redneckerz said:

Atleast you don't tease us. :P

of course i do! with moving 3d polyobjects, for example. with screenshots of shadowmaps before. and so on.

 

11 hours ago, Redneckerz said:

What were those utils about?

ah, mostly small things for my own use. data converters, viewers for some binary formats, and so on. oh, you just reminded me that i need to write "inflate" implementation.

 

11 hours ago, Redneckerz said:

Remind me this for next week.

i'll try. if i won't worget about it. ;-)

 

to stay on-topic: there are implementations of doom-like engines in QuickBASIC and Roblox. i think it counts too.

Share this post


Link to post

Well there's Terminal Doom, which lets you play classic Doom in Doom 3. Instead of playing Super Turbo Turkey Puncher 3 like a normal person.

 

DH-acc lets you compile C code into ACS bytecode, so theoretically you could replicate Terminal Doom and play vanilla Doom inside a level for an advanced port. (No way it would work within vanilla Hexen, sorry.)

Share this post


Link to post

Not exactly a source port... but Iota is a LLVM bytecode -> Common Lisp transpiler.  Some of its examples include PrBoom and Quake.  I remember messing with this once when I was trying out an obscure experimental operating system called Mezzano, also written in Lisp.

Not the original Doom, but there's a WIP port to Ada for Doom 3.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×