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

Every beginning is painful...[ A Doomworld first]

Recommended Posts

...but as far as I'm concerned, this is officially the first rendering EVER produced by a complete port of the Doom's engine into Java, posted on DW just minutes after being produced, on 8 October 2010, 00:23 local time, Greece:



After fixing colormaps a bit, here are the results (tried with a test level):



Sure, STARK produced renders way before mochadoom, but that was a rewrite of the engine, while this is just the actual Doom source code ported to Java as faithfully as possible to the original. Also, the Mocha Doom project has now officially reached farther than DoomCott or Stark did: once the rendering is fixed and player input implemented, it will be conceptually complete and ready to be studied by others. A side effect of doing a non-C port was being forced to document the engine much more extensively, and thus the code is full with very detailed in-depth comments about how stuff is supposed to work.

CUrrently it's running from within a "jury rig" kind of setup that barely allows it to load the level and do the drawing and there are still a lot of broken thing, but just being able to see that screenshot meant that all fixed point and angle arithmetic works correctly, as does scaling, column-based rendering and even colormaps/lightmaps.

With patience....the goal will be reached.

Share this post


Link to post

This is great stuff, maybe when this goes finished, people can port it into the J2ME platform and fnally will be possible to play Doom on a non S60 cellphone.

Sorry for my bad english

Share this post


Link to post
AlektorophobiA said:

This is great stuff, maybe when this goes finished, people can port it into the J2ME platform and fnally will be possible to play Doom on a non S60 cellphone.



Do you have any idea how crappy J2ME is? On most phones the function to copy a memory bitmap to the screen barely allows 10fps, and that's the one function you need to make Doom's software renderer work. And that doesn't even start to factor in the serious memory limitations on these devices.

Sorry, but that platform is just not good enough. The only ones where there's a chance are those with decent native programming capabilities.

Share this post


Link to post
Graf Zahl said:

Do you have any idea how crappy J2ME is? On most phones the function to copy a memory bitmap to the screen barely allows 10fps, and that's the one function you need to make Doom's software renderer work. And that doesn't even start to factor in the serious memory limitations on these devices.

Sorry, but that platform is just not good enough. The only ones where there's a chance are those with decent native programming capabilities.

Sorry about that, but i suposed that Doom maybe can run on a J2ME platform because of Wolf RPG and Doom II RPG have engines that looks like the Doom one, i don't know much about this.

Share this post


Link to post

The software renderer as it is would stand no chance because after creating each frame you'd have to get it to the video hardware of the phone - and that step is extremely inefficient. The only chance you got would be to use system drawing routines only. But then you'd have to rewrite the renderer to actually use the system's features.

It's not that the phones are too weak (even though many are) but that the way the renderer works can't be done efficiently on most devices.

Share this post


Link to post

And in fact I never said a word about mobile devices -my implementation depends on the full feature set of the current JVMs and wouldn't work on many older releases older than v1.5, let alone mobile ones.

As of now, the renderer works in a way that's very close to the original C - putting bytes on an array that's mapped to the screen, and that array is almost directly mapped to video memory thanks to a hack that works in major OSes, which allowed me to get near native performance for pure LFB blits.

Java MIDP however only allows you to use drawing primitives or even pre-made images without direct screen buffer control unless they properly implemented Java2D/Java3D by now. I recall seeing some 3D titles with graphics better than the Doom RPG e.g Alpha Sector 3D that worked OK on an old Ericsson K750i, so I don't exclude that a port may be possible -the logic would stay mostly intact, if a way to draw on a raw byte buffer can be provided.

In any case, I will release Mocha Doom more as a "stepping stone" for any and all future non-C source ports. From then on, anyone can add Boom source port features, turn it into Javascript or C# or even MIDP/J2ME.

Share this post


Link to post
Maes said:

if a way to draw on a raw byte buffer can be provided.



You can get a raw 32 bit RGB buffer - but transferring that to the screen is way too slow on most devices. We can thank Sun for that because their reference implementation of that function is abysmally bad and from the looks of it most J2ME implementors just copied it with all its slowness.

Share this post


Link to post

That can indeed be an issue if MIDP/J2ME doesn't do a silent binding of BufferedImage backing arrays to video memory -it does so in desktop Javas, that's why I got those insane fps metrics.

If anything, I take there can be major differences between MIDP implementations on different phones -anything but the most basic or cleverly coded Java games can claim total compatibility on EVERY cell phone. But 30 fps screen updates + 3D software processing behind them don't seem technically impossible.

Share this post


Link to post

Depends on the phone. I've been developing stuff for J2ME for years now and I'm still waiting for the phone that does not have some crippling limits. Some are fast but have a ridiculously small heap, others have no memory issues but some stuff can't be used because it's either broken or just not fast enough. There's always something that keeps the phones from being good.

I much prefer the more modern platforms like Android. Far less problems to develop for.

Share this post


Link to post

Seconded. I would much prefer scaling down to Android, iPhone or even DS before I touched platforms like J2ME. Would be an interesting fork though.

Share this post


Link to post

The Android does have a -quite controversial- port of Doom, but Java is only used for the bootstrapping interface, the actual code is just a C library linked and called through Android's equivalent of JNI. So strictly speaking, that's not actual "development" in Android's API but merely wrapping something else. Just sayin' ;-)

Still, that didn't prevent it from being featured in well-known book about Android gaming, but I'd take it with a pinch of salt. It demonstrates how well it's possible to wrap native code, rather than how powerful the Android API is for this sort of task.

Share this post


Link to post

Still better than a platform that doesn't allow you to do anything. But that's not what I was talking about. Even in pure Java Android is still loads better than any J2ME device.

Share this post


Link to post

I actually got stuff to move today (about 500 fps when navigating a vanilla level on a P4) but I will only release an interactive demo when it's stable enough (patch drawing and clipping bombs under certain angles, too de-buggy in presentation). After I get it stable enough for a reference release I'll think more about speed :-p

Share this post


Link to post

BRAVO! I would love to show this to my old java teacher after you're done with it. What you're doing he said couldn't be done(tm) 8)

Share this post


Link to post
Csonicgo said:

BRAVO! I would love to show this to my old java teacher after you're done with it. What you're doing he said couldn't be done(tm) 8)


It most certaintly can -I'm struggling more with my own errors/misadaptations at this moment, since I already solved many of the hairier and "impossible" things about the code. Rendering works, fixed arithmetic works, unmarshalling Doom's Java-unfriendly binary data works too -now it's more a matter of ironing out mistakes and providing an interface for the user.

For now, I'm struggling with a bunch of HOMs and anisotropies due to errors in the renderer -_-

Share this post


Link to post

This is absolutely fantastic work. Great job!

Couple of questions...

  • What license are you going to be releasing this with? GPL or the DSL?
  • Are you going to make your source control repository public, or will you provide us with a tarball?
  • What level of compatibility are you aiming for? Due to the amount of potential demo desyncs due to undefined C Compiler behavior, I doubt 100% parity with doom2.exe is possible, but are you going to attempt to start down the Chocolate Doom path of improving compatibility, or will you leave well enough alone?

Share this post


Link to post

What license are you going to be releasing this with? GPL or the DSL?


Probably GPL, the same way I found it. I never really seriously studied or considered other licensing schemes ATM.

Are you going to make your source control repository public, or will you provide us with a tarball?


I get this question a lot of times...for some reason, people seem to miss the fact that the project is already public: sourceforge CVS repository, and the despite what sourceforge reports, I update several times a week (sure, it's pre-alpha work and nasty redline hell you probably won't like to touch yet).

I got some criticism for my use of CVS over SVN, but that's what works with my IDE of choice (Eclipse) out-of-the-box, and what I have experience with, so there. So far, the public repository is read-only, if that's what you mean. I have no collaborators with edit access at the moment (not that anyone applied) and I still need to properly advertise what I am doing. But the project has been and always will be public.

What level of compatibility are you aiming for? Due to the amount of potential demo desyncs due to undefined C Compiler behavior, I doubt 100% parity with doom2.exe is possible, but are you going to attempt to start down the Chocolate Doom path of improving compatibility, or will you leave well enough alone?


That a hard one to answer until everything works together ;-)

In theory, it should be "faithful to vanilla" to a large degree, even to the point of loading vanilla savegames and injecting the same player command from demo lumps. It uses the same level and BSP data, and the code is replicated 1:1 in most cases, rather than recreated based on observation. The only "Boom like" enhancement I adopted till now is the hashtable-based lump search (which could be likewise extended to uncached texture searches as well).

NOw, I noticed a few spots with obvious overflows/dangling pointers in the renderer code which had to be patched in order for Java to work, but I don't know if those can actually affect demo sync.

I've not yet broke down the actual actors code (it's 100% ported but not tested) in order to verify if there are occurrences where null references can make it inside action functions. In most such cases, Java will simply bomb with null pointer or array index out of bounds exceptions unless explicitly checked for.

To answer the question about whether I'm going to attempt to reach painstaking 100% compatibility in the same way of chocolate doom...almost certainly not.

Mochadoom has a different goal altogether, no small part of which is freeing Doom from the "slavery" of C/C++ and attempt to provide a "neutral" reference implementation of Doom that can easily be ported to other non-C languages.

I might add a hack or two to emulate some vanilla bugs (e.g. if they are eliminated due to strict typing), but I won't stoop so low as to emulate an x86 PCs memory layout. There's already an MS-DOS emulator written in Java that runs Doom inside an applet that does just that. Of course, if someone wants to make a "mocha doom with some chocolate on top" kind of port based on my code, the more power to them and good luck. I'd rather develop future branches it in the direction of a "mocha boom".

Share this post


Link to post
Maes said:

I get this question a lot of times...for some reason, people seem to miss the fact that the project is already public: sourceforge CVS repository, and the despite what sourceforge reports, I update several times a week (sure, it's pre-alpha work and nasty redline hell you probably won't like to touch yet).

I got some criticism for my use of CVS over SVN, but that's what works with my IDE of choice (Eclipse) out-of-the-box, and what I have experience with, so there. So far, the public repository is read-only, if that's what you mean. I have no collaborators with edit access at the moment (not that anyone applied) and I still need to properly advertise what I am doing. But the project has been and always will be public.


Don't worry, I've got you covered. :)

http://bitbucket.org/alexmax2742/mochadoom

Updates from your official CVS repository every 15 minutes.

Share this post


Link to post

Haha great! Although now I realize many of my CVS comments are better kept to myself, and most commits are major in nature :-p

Still, that prompted me to finish up my project webpage sooner.

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
×