Holy shit! They made the flash version of DOOM!!

[princec]

NIH syndrome.  We have met with Todd twice and I have spoken with John C on several occasions.  Making the tech is as much fun for them as making the games.

Even so from a biz POV it would have saved them maybe $100k in development time at least just making that wretched ActiveX plugin working. And it'd work on Mac and Linux which they have a soft spot for. Just plain daft! You should have paid them to use it!

Cas

[kappa]

Even so from a biz POV it would have saved them maybe $100k in development time at least just making that wretched ActiveX plugin working. And it'd work on Mac and Linux which they have a soft spot for. Just plain daft! You should have paid them to use it!

Cas

hmm I initially thought you meant they should have ported the C Quake 3 engine to Java (which wouldn't make much sense), but now I see why it could have made sense to use the java plugin (and probably still does for the Mac and Linux ports).

All they'd have to do was launch the c version of Quake 3, grab its window handle and stick it on the applet.

which would leave the problem of javascript communicating with the quake engine, which could probably be done with some jni.

They'd have to make java plugin 2 a requirement though if they'd want any form of stability.

looking at the horrid state of applets when they started the project, i don't blame them for going the custom plugin way.

[erikd]

While this automatic porting using Alchemy is certainly impressive, I can't say I'm much impressed with the end result.
It runs just awful here on my PC!

To me it feels more like novelty than something really worthwhile. I just can't help but think doing a 'real' port instead of automatic one would likely have led to a much better end result (at least on a proper Java VM anyway).

I also wonder if they'd port the code manually, how much more time that would have taken. I mean, how 'automatic' is this porting using alchemy anyway? Doesn't the Doom engine have some bits and bobs in ASM, and what about platform specific stuff?
I looked at the Doom source a long time ago, but if I remember the source correctly, I'd probably be able to translate it to java during a rainy weekend.

Games published by our own members! Check 'em out!

[Markus_Persson]

A looong time ago, I made a doom level renderer from scratch in java without looking at any source code:

http://www.theintraclinic.com/stark/play_large.html

[princec]

Haha yes but you don't count, being some sort of codtistic savant.

(Runs at 600fps here, blimey)

Cas

[appel]

A looong time ago, I made a doom level renderer from scratch in java without looking at any source code:

http://www.theintraclinic.com/stark/play_large.html

Runs much better than the Flash version, which is sluggish.

[gouessej]

Runs much better than the Flash version, which is sluggish.

I agree, Markus_Persson's version works quite smooth here.

[PeterB]

You never cease to amaze Markus! Well done!

[phu004]

A looong time ago, I made a doom level renderer from scratch in java without looking at any source code:
http://www.theintraclinic.com/stark/play_large.html

OMG My jaw just dropped once again!!!

[erikd]

A looong time ago, I made a doom level renderer from scratch in java without looking at any source code:

http://www.theintraclinic.com/stark/play_large.html

That one works great!
Which kind of proves my point that automatic code translation is nice, but can't beat proper coding by a good programmer. 

There have been a number of C->Java code translators for a long time, but that was never really a great success:
1) The end result is not really java code, but really 'translated C code'. Things that are optimal in C are not necessarily optimal in java, and you would typically program java in an OO way (which the resulting translated C-Java code of course is not).
2) Behaviour of C code largely depends on the underlying platform and compilers (endianness, type differences, things like that), so there might be subtle bugs that are hard to track down.

Games published by our own members! Check 'em out!

[Ranger]

And now they've made an Android Doom:  http://phandroid.com/2009/03/31/android-is-doomd/
As well as Quake for Android! http://www.youtube.com/watch?v=fH1Rd-T1rYM

[gouessej]

And now they've made an Android Doom:  http://phandroid.com/2009/03/31/android-is-doomd/
As well as Quake for Android! http://www.youtube.com/watch?v=fH1Rd-T1rYM

Thanks for the link.

[Catharsis]

>Exactly Kev.  People go nuts when Flash (10, mind you), does DOOM but noone thinks it's great when Java can do Q2/3?  Interesting.

I ported Auriga3D (A Q3 class engine) to Android in just over 2 days for my presentation at CodeCon a week ago or so.  I've ported Typhon to Android (http://typhon.egrsoftware.com) and 98% of the code for Auriga3D cross compiles with the desktop version. Typhon now supports JOGL, LWJGL, and Android OpenGL ES. You'll love this.. It only takes 13 class files specific to Android to have things up and running..

Regarding Auriga3D on Android, how I handle curved surfaces is the largest performance handicap as there is no LOD and the bezier patches are large (fine for desktop / not Android). FPS is 8-45 FPS for the untuned port of the Q3 renderer to Android. Culling out curved surfaces gives roughly 15-45 FPS.

I'll make another top level post about this.

Here is a "sketchy" video I made right after getting things to work.
http://www.youtube.com/watch?v=fokeI3Ynuc4