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

because it is an old school programming style, software higly optimized 3d engine.

technically it is also possible because it may not use a lot of external API

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.

I have never done action script by myself. How hard would it be to make game such as Pac man in flash
compare with java?

It’s easier.

(I work as a game developer, making games in Actionscript (flash), Java and C++)

It works horible slow for me ;).

[quote]It works horible slow for me
[/quote]
yeah I noticed that it take 37 ~ 50% of my cpu all the time,
(E8400 2 X 3.0ghz)
I wonder if they can make port Quake code
into flash and maintain the playable frame rate.

Who knows but it would be probably more cpu demanding than the most recent fps games, and that doesn’t make to much sense to me :P.

Btw i don’t know what is so cool about quake live. It needs its own browser plugin doesn’t it?

I upgraded my Flash and played this, seems ok, but seems very sluggish. Maybe Flash can’t handle even this sprite 3d.

[quote]Btw i don’t know what is so cool about quake live. It needs its own browser plugin doesn’t it?
[/quote]
Yes. I am sure no matter how many plugins it is required by quakelive, ppl will just install them.

Java is used to compile another action script toolkit, Flex, so maybe they use it similarly here?

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 :slight_smile:

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.

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.

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

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

(Runs at 600fps here, blimey)

Cas :slight_smile:

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

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

You never cease to amaze Markus! Well done! :wink:

[quote]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
[/quote]
OMG My jaw just dropped once again!!!

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

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.