Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Reggie-a

Doom on Chrombooks?

Recommended Posts

My old laptop is worn down to hell, and probably has a virus on it, plus the screen is cracked so I can't play doom on a better pc. So instead my Highschool has provided us with chromebooks. So my only access to Doom is through links to the flash shareware version. I just beat that, but I want to play the full thing. So Is there a way for me to run the full version of doom onto a chromebook?

Share this post


Link to post

You'll have to get a full Linux distribution running on it. From there, it should be simple.

Share this post


Link to post

Makes me wonder, is there a portable device i.e., a laptop or other thing that is ideal for playing Doom on? The desktop i own now is pretty weak but Doom runs terrifically on it. On most laptops I've used, Doom takes a while to boot up, and frame rates would get choppy on larger maps or with lots of active monsters at once. The thought of trying it on a chromebook crossed my mind but I've never met anyone who has owned one so the thought slowly drifted my mind.

Share this post


Link to post
40oz said:

Makes me wonder, is there a portable device i.e., a laptop or other thing that is ideal for playing Doom on? The desktop i own now is pretty weak but Doom runs terrifically on it. On most laptops I've used, Doom takes a while to boot up, and frame rates would get choppy on larger maps or with lots of active monsters at once. The thought of trying it on a chromebook crossed my mind but I've never met anyone who has owned one so the thought slowly drifted my mind.


Nvidia Shield Portable or any Android device with D-Touch is amazing. GZDOOM, PRBoom+, and Chocolate Doom in one. Runs mods perfectly. I like the shield portable cause it got actual controls, but you can buy a controller for android devices

Share this post


Link to post
40oz said:

Makes me wonder, is there a portable device i.e., a laptop or other thing that is ideal for playing Doom on? The desktop i own now is pretty weak but Doom runs terrifically on it. On most laptops I've used, Doom takes a while to boot up, and frame rates would get choppy on larger maps or with lots of active monsters at once. The thought of trying it on a chromebook crossed my mind but I've never met anyone who has owned one so the thought slowly drifted my mind.

Depends on if you need a mouse or not. If you can play with touch controls, D-Touch as mentioned is great!

Any modern medium price range laptop should play modern Doom ports at full 60fps, maybe cheaper ones, too, depends on the port and settings. prboom+ is the fastest modern port, you can try the software and the hardware renderer. If using the integrated keyboard is not a problem...

Share this post


Link to post

The only problem with D-Touch is how it was purposely set to OPL Synth rather than the intended midi which Doom was originally meant for.

Share this post


Link to post
Avoozl said:

The only problem with D-Touch is how it was purposely set to OPL Synth rather than the intended midi which Doom was originally meant for.

I think it doesn't support midi playback. There is some option to download a sound font for a software synth. It's several MBs so it's not included by default. It's not a matter of the coder's preference but a necessity.

Share this post


Link to post

Funnily enough, over the past few days I've been looking into doing a Emscripten (C->Javascript compiler) port of Chocolate Doom, mainly because I've been stuck with a Chromebook Pixel for the past week. Turns out to be a bit trickier than I hoped though, so don't get your hopes up.

Share this post


Link to post

Google for the advances for running a Linux based operating system on Chromebooks. If you are lucky or willing to test it you might be able to boot a system from a USB stick.

Share this post


Link to post
fraggle said:

Funnily enough, over the past few days I've been looking into doing a Emscripten (C->Javascript compiler) port of Chocolate Doom, mainly because I've been stuck with a Chromebook Pixel for the past week. Turns out to be a bit trickier than I hoped though, so don't get your hopes up.


Heh, I still remember that proof-of-concept port of linuxdoom v1.10 done in that way -if I remember correctly the platform's limitations, the main problems with making a true portable Doom, was that Emscripten pretty much required that programs were entirely self-contained (with hardcoded IWAD data etc., in the case of Doom).

The "compiler" also was more of a VM where a "flat" memory space was emulated, and C code was compiled to some sort of intermediate stack machine bytecode. Kinda like that older Internet C++ VM (which also had a port of Doom....anyone ever got this to work?!)

It was very difficult (or outright impossible) to "mix" the "C" part of the VM with calls to the "pure Javascript" one, e.g. to open a WAD file in the user's folder or use Javascript's libraries for some tasks such as accessing the net from the "C" part, at least without jumping through a lot of hoops.

I have no idea if those things have changed/improved in the meantime.

This was quite unlike e.g. Google's GWT, which also used cross-compilation trickery (from Java to JS, in that case), but still allowed a user to call (at least some) JS functions directly, through their Java code.

Share this post


Link to post
fraggle said:

Funnily enough, over the past few days I've been looking into doing a Emscripten (C->Javascript compiler) port of Chocolate Doom, mainly because I've been stuck with a Chromebook Pixel for the past week. Turns out to be a bit trickier than I hoped though, so don't get your hopes up.

There's already an Emscripten port of PrBoom available. So, it's definitely possible?

It would be fantastic to have a server that always provided the latest version of Freedoom running on an Emscripten version of Chocolate Doom.

Share this post


Link to post
Jonathan said:

There's already an Emscripten port of PrBoom available. So, it's definitely possible?

It would be fantastic to have a server that always provided the latest version of Freedoom running on an Emscripten version of Chocolate Doom.

Oh, awesome. I wasn't aware. And yes, that would be a lovely idea, though it would have to be FreeDM as the single player Freedoom IWADs aren't vanilla compatible. Though ideally if I do this port I'd like to have multiplayer via websockets; not sure how well that might work.

The port you've linked to looks like it's a fork; I'd really like the Emscripten port to be an integrated part of Chocolate Doom - a first class port just like the Windows, Mac and Linux versions that I test and ship already. In the best case it should just be a page on chocolate-doom.org that people can go to to play.

Maes said:

Heh, I still remember that proof-of-concept port of linuxdoom v1.10 done in that way -if I remember correctly the platform's limitations, the main problems with making a true portable Doom, was that Emscripten pretty much required that programs were entirely self-contained (with hardcoded IWAD data etc., in the case of Doom).

I don't have all the answers here because I've just started playing with it. But I think things are a lot better than you're describing here. Probably they've improved over time.

Ideally there should be some kind of built-in launcher analogous to the Mac OS X launcher to let the user "load in" their WAD files for play.

How the filesystem is implemented is an interesting question because in Javascript land you obviously have no direct access to the local FS. Emscripten gives several different options including IDBFS which lets you use the browser's persistent IndexedDB store. So theoretically it should be possible to "upload" your IWAD into your browser (though it's not actually being "uploaded" anywhere outside of your computer) and stored in the persistent filesystem so that you can come back and play without any tedious setup process.


The "compiler" also was more of a VM where a "flat" memory space was emulated, and C code was compiled to some sort of intermediate stack machine bytecode. Kinda like that older Internet C++ VM (which also had a port of Doom....anyone ever got this to work?!)

Emscripten is a proper transpiler and my understanding is that there is no bytecode. You can see this if you look at the generated code. Modern Javascript has typed arrays which make this quite efficient.


It was very difficult (or outright impossible) to "mix" the "C" part of the VM with calls to the "pure Javascript" one, e.g. to open a WAD file in the user's folder or use Javascript's libraries for some tasks such as accessing the net from the "C" part, at least without jumping through a lot of hoops.

This might be something that has improved over time. I've only looked at this briefly, but it has a system that allows you to interface with the Javascript world and doesn't look too bad. It also has this HTML5 interface that lets you access most of the stuff that's available in Javascript.

When I tried compiling Chocolate Doom this weekend, these were the biggest problems I encountered:

  • Event-driven interface. This is a result of the fact that in the end it's JavaScript that's being run. Unlike in a normal C++ program where you typically write a loop that runs forever, JavaScript is event-driven, where code gets run in response to events (user clicking things, or timers, etc.). You can read a bit about it here but the summary is that it requires restructuring your code in terms of a function that gets run regularly, and that cannot contain any blocking function.

    My first try after compiling and running the setup tool led to my browser tab just freezing up as I wasn't aware of this.

  • Limited SDL interface. Emscripten helpfully includes its own "native" implementation of the LibSDL library, meaning that in theory, Chocolate Doom should just compile and run. In practice of course it's not that simple. The LibSDL implementation is actually a complete reimplementation of SDL's API rather than a port of SDL itself (see here).

    A few of the API functions used by Chocolate Doom appear to be missing, and what's there doesn't have feature parity with the "real" C SDL. For example, after compiling the setup tool and working around the infinite loop bug described above, I then just got a blank screen, because Emscripten's SDL doesn't support 8-bit surfaces. So it's going to need to be extended to add support for these things in order to get something that works. Ideally these should be patches that can be submitted back to the Emscripten project itself.
Despite these limitations, it's still a really cool project and I highly recommend taking a look at it. I was quite impressed at just how easy it is to get something up and running with it.

Share this post


Link to post
fraggle said:

Emscripten is a proper transpiler and my understanding is that there is no bytecode. You can see this if you look at the generated code.


Weird, because on the project's page it states it first thing, that Emscripten uses the bytecode output from a LLVM compiler (which is at the very heart of the toolchain) and "compiles" that into Javascript. So to begin with, it operates on a representation of your program that looks nothing like its source code.

That doesn't mean that the generated code will be unreadable/obfuscated (though a deployment build is likely to be so, for efficiency purposes), but it will look nothing like e.g. a manual transcription of a C/C++ (or even Java) program to Javascript, e.g. a simple "Hello World" type of program with some numerical computations thrown in. By looking at the generated source code, you probably won't be able to understand it any more than you would understand x86 assembly (unless you're an x86 assembly guru, heh)

I would be surprised if it wasn't so, actually: you can't expect an automated tool to use the same methods an experienced human coder would use (e.g. how would you proceed if you were to port Doom into native JS by hand?), and put thinking into it. The "simplest" workaround, used by all "X to Javascript" compilers is to bypass language semantics completely (including Javascript's ones) and simulate a "neutral" VM environment (usually emulating a simple stack-based machine, with a flatly addressable memory space, which allows for a C-like heap/stack emulation).

As for the rest, it really seems they added better HTML5 integration, and it's possible to bridge the two worlds (the Emscripten VM and the host machine/web) to some extent.

However, filesystem limitations still seem to be exactly as I described, unless the linked documentation is out of date.

Share this post


Link to post
Maes said:

Weird, because on the project's page it states it first thing, that Emscripten uses the bytecode output from a LLVM compiler (which is at the very heart of the toolchain) and "compiles" that into Javascript.

Sure, it's based on LLVM, but that's just an intermediate representation you're referring to. Actually, it's more properly referred to as "Bitcode" rather than Bytecode, but the name isn't really that important :) I suggest you look more closely at that Bitcode representation though (ie. the intermediate "assembly" style representation). While it superficially resembles assembly/machine code, there are actually some fundamental differences to what you'd see with real assembly/machine code, most notably the fact that all registers have to be in SSA form.

In the end, the point I was making was that the end result - the JavaScript that runs in your browser - is not any kind of virtual machine or emulation of one. The fact that it goes through the intermediate LLVM representation is kind of inconsequential, just like if you compile something with Clang for example, the compiled program that it outputs is not running in or emulating a virtual machine either.

Maes said:

That doesn't mean that the generated code will be unreadable/obfuscated (though a deployment build is likely to be so, for efficiency purposes), but it will look nothing like e.g. a manual transcription of a C/C++ (or even Java) program to Javascript, e.g. a simple "Hello World" type of program with some numerical computations thrown in. By looking at the generated source code, you probably won't be able to understand it any more than you would understand x86 assembly (unless you're an x86 assembly guru, heh)


Yeah, sure, but does it matter? I don't think so.

Out of curiosity I decided to take a look at the generated code. Here's an example of a small function from something I was compiling:

static void drawsphere_point(GLfloat x, GLfloat y, GLfloat z)
{
        glNormal3f(x, y, z);
        glVertex3f(x, y, z);
}
This is the equivalent generated code:
function _drawsphere_point($x,$y,$z) {
 $x = +$x;
 $y = +$y;
 $z = +$z;
 var $0 = 0.0, $1 = 0.0, $2 = 0.0, $3 = 0.0, $4 = 0.0, $5 = 0.0, $x$addr = 0.0, $y$addr = 0.0, $z$addr = 0.0, label = 0, sp = 0;
 sp = STACKTOP;
 STACKTOP = STACKTOP + 16|0; if ((STACKTOP|0) >= (STACK_MAX|0)) abort();
 $x$addr = $x;
 $y$addr = $y;
 $z$addr = $z;
 $0 = $x$addr;
 $1 = $y$addr;
 $2 = $z$addr;
 _glNormal3f((+$0),(+$1),(+$2));
 $3 = $x$addr;
 $4 = $y$addr;
 $5 = $z$addr;
 _glVertex3f((+$3),(+$4),(+$5));
 STACKTOP = sp;return;
}
As you can see, there's a lot of boilerplate in there. Most of it looks like it is asm.js annotations (the redundant-looking $x = +$x; stuff, the redundant variables, etc.). There's also a bunch of C call stack-related stuff - I guess Emscripten has to deal with the fact that in C it's possible to create pointers to stack variables, which isn't really possible in JavaScript.

The only real hints of the LLVM Bitcode are the $0, $1 etc. variables. Those might just be there because I compiled with no optimization, I'm not sure. Higher optimization levels apply minification and I wouldn't be surprised if those variables just disappear. Regardless, I would expect modern JavaScript interpreters to eliminate them anyway.


As for the rest, it really seems they added better HTML5 integration, and it's possible to bridge the two worlds (the Emscripten VM and the host machine/web) to some extent.

However, filesystem limitations still seem to be exactly as I described, unless the linked documentation is out of date.

Well, the limitation you described ("open a WAD file in the user's folder") is really a fundamental limitation of the fact that you're using JavaScript, which is deliberately heavily sandboxed. It would be a pretty huge security hole if it were possible to just read random files from the user's system just by tricking them to visit a particular website. So Emscripten is working with those limitations, but it looks like it's doing a pretty good job of providing something nominally useful with what's available.

That said, the original discussion here was about Doom on Chrome OS, which does have a notion of "apps" that you can install in your browser. For example, I have a Secure Shell app installed that lets me log into other machines from my Chromebook. Theoretically it may be possible to make a Chocolate Doom app as well, essentially a wrapper around the Emscripten-compiled code. And it looks like Chrome OS has an API that allows filesystem access. So it may be worth creating an app just to make that experience smoother.

Initially I'd prefer to focus on something that just works as a normal webpage though. Having a Chrome app is a nice afterthought and probably not a huge amount of work.

Share this post


Link to post
FireFish said:

Google for the advances for running a Linux based operating system on Chromebooks. If you are lucky or willing to test it you might be able to boot a system from a USB stick.

Chocolate Doom and PrBoom+ runs fine on my bootable USB stick, using the latest stable version of Puppy Linux (6.0 "TahrPup").

There : http://puppylinux.org/main/Download%20Latest%20Release.htm

To create an USB bootable key, I use Linux Live USB Creator (a windows program).

Share this post


Link to post

Just to close the sidetrack conversation on my side, in the end Emscripten is not really different in its approach from tools like GWT or JSIL.

The "transcompilation" done by those tools is completely different than the one performed by older language converter tools such as f2c or PTOC, whose stated purpose is to produce human readable and maintanable code in the target language, and use as many native language facilities as possible, if available, ideally producing a 1:1 equivalence. Pretty much like a human would convert between languages by hand.

For F2C, that would be exemplified by translating Fortran's WRITE and PRINT statements directly to printf or sprintf, appropriately, without attempting to emulate a completely different runtime environment at the source code level.

Then again, if you're trying to get around the limitations of Javascript, your best bet is to work your way around the language, an approach which has a lot of apparent success. The real question is if what is running in the end can truly be considered a "Javascript port" of the original code (what would a conventional manual conversion be, then?)

Then again, for all I know, this indirect approach may be not only infinitely more flexible (by abstracting all JS away from the developer) but also more efficient in all senses.

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
×