Mocha Doom Endlevel update ;-) [with demo animations]

Here's a little something for you...

6.6 MB animated gif of endlevel screen

This was generated procedurally entirely by the Mocha Doom code, by simulating an "end level" situation with a wbstartstruct_t, setting up a video renderer, an overall doom status, loading data from the shareware IWAD and letting the Ticker() flow, while Drawer() was called, for 200 simulated tics (frames were written to disk as pngs).

In case you wonder, yes, it's a singleton "EndLevel" object that can be instantiated independently, as long as a Doom game's context, wadloader and renderer are passed to it in its constructor. It has no static dependencies except for some global variable defines. All of its methods (except ONE) are instance methods. It contains methods from wi_stuff.c, properly objectified.

This proved to me at least that the approach of splitting the codebase into isolated singletons is workable, and the model I used for animation, data loading, patches arrangement in memory, etc. is solid and workable. What's important, is that it's pretty damn close to the C code, as much as Java can do it without resorting to a total rewrite/remake.

Here is another example:

6.6 MB animated gif of endlevel screen with key events and Hangar hack

In this one, two key events are simulated (by injecting them directly into the player structs) at 100 and 120 tics. The first causes the "endlevel" to end prematurely, the second triggers the "Entering" screen, which displays "HANGAR", because the current level hasn't been properly set in the test case, and thus you start at "episode 0, map 0" (or E1M1), something you normally don't get to see in-game.

I'm not convinced until I see e1m1, dammit.


good work nevertheless. :3

Csonicgo said:

I'm not convinced until I see e1m1, dammit.

And similarly I know I won't be taken seriously until I showcase just that. As of now I'm probably at the same point as the DoomCott project (the unreleased 0.5 version) claimed to be (being able to display title screen, menus and maps).

However the SC is out there, it's public, and I keep putting work hours into it. I know I should make a detailed public documentation and discuss the design details publicly if I wish to attract attention from programmers.

BTW, the tester for the above animations is in mochadoom/src/testers/EndLevelTester.java ;-)

In a way, it must be refreshing to be able to test Doom "piece by piece".

Fantastic work Maes. Can't wait to see the finished product.

EDIT: If I'm reading this correctly, will this mean you will be able to procedurally generate pictures of maps by loading the first 'frame' of each level? If so, holy shit.

AlexMax said:

Fantastic work Maes. Can't wait to see the finished product.

EDIT: If I'm reading this correctly, will this mean you will be able to procedurally generate pictures of maps by loading the first 'frame' of each level? If so, holy shit.

Well, I can set up independent objects such as map renderers, level rendererers, menus etc. and trigger/advance them independently (that's what making Doom "Object Oriented" means) as long as I initialize them correctly. By piecing them together, of course, I will have a complete Doom game, and I should be able to do stuff like attaching multiple renderers to one game context, or have alternate renderers which can be hot-swapped in etc.

This example showcases how I can create an object that includes all of the "endlevel" functionality within its own module, and can be advanced, inspected and manipulated on demand. Obviously I will be able to do the same with other modules.

You have confusing project goals. Making an object-oriented DOOM and making the code similar to the original seem like conflicting goals to me. This is cool, but also somehow odd.

Well, I decided to make it OO to avoid making it a hell of static defines, static methods, and static classes with clashing namespaces.

This may be "typical" in C, acceptable up to a point in C++, but absolutely horrible in Java, .NET or any "modern" language.

BTW, that's what DoomCott actually did, from what I gathered from its disassembly, although it had a mixed approach).

Therefore, I have to move from static classes to singletons, which means making an object not only of obvious stuff like C structs that represent finite entities like map objects, vertexes, lumps, patches, etc. but also of the various code modules that actually use them.

It's more intuitive than it sounds, really.

E.g. the HU code (heads-up display) contained several structs that represented widgets like icons, text strings, etc. and there were methods that operated on SPECIFIC INSTANCES of those widgets.

There you go -> make the structs objects, and make those methods instance methods instead of the wish-it-was-OO "static methods + reference passing" method used in Doom. Don't forget that at Doom was the very least influenced by Objective C (perhaps even meant to be written in it), and some of its design sure does seem like it.

Other times, I have to improvise "objectifications" for C functionality that has no real equivalent in Java: e.g. the Menu code uses function pointers to either menu routines that perform actions (1 int parameter) or menu routines that perform drawing (void), and these need to be swappable.

In C and C++ you can just use fugly function pointers, in Java you can either use an interface + implementing class approach (e.g.

public interface MenuRoutine { public void invoke(int choice);}

public interface MenuDrawRoutine { public void invoke();}
}

and implement the actual menu functions as the body of the invoke methods, and add an .invoke() whenever a "menuroutine" is supposed to be called. This is actually faster by an order of mangitude and cleaner looking that using Java's Method reflection functionality (since 1.5).

So no, I'm not making Doom OO because of some kind of caprice or to look cool, it's just because it's actually easier to do so on the long run, with the language I'm using.

Looking good so far.

One thing you hopefully will be able to do with this approach is separating the different game behaviours into different objects i.e.

vanilla compatible engine
boom compatible engine
stable enhanced engine
...

Aliotroph? said:

You have confusing project goals. Making an object-oriented DOOM and making the code similar to the original seem like conflicting goals to me. This is cool, but also somehow odd.

I think he meant "as vanilla-compatible as possible".

Also, is there a SVN repository somewhere? I ask because if not I'd love to follow development of it using something like BitBucket or Github.

I have a CVS already set up for the project and the source code has been public since day one.

And yes, my intention is leaving as much of the original code in place, without resorting to using a different engine that "looks" like Doom but ain't it. A consequence of that is that the codebase will be "for the most part" vanilla-compatible, although I'm throwing in some Boom enhancements here and there (a Boom compatible version is next in line)

I recommend using the Eclipse IDE for checking it out, as that's what I'm using. You will see a LOT of redded out error stuff of course, but there are individual modules and testers functioning, which either test stuff like wad loading, fixed point arithmetic, video, etc. or perform benchmarks between different ways of doing things.

Just today, I commited a half-functional Menu module , and also updated the WadLoader module with a replica of Lee Killough's hashtable-based lookup. It IS indeed a LOT faster than linear search, although I used a different hash function (Lee Killough's is written in a mind-boggling wa y that's a PITA to port into Java, so I use either String's hashcode() or simply use the precomputed long 64-bit value of the lumpinfo string field as a hash (this also allows for faster comparisons).

If you feel like contributing, I can give you more details over implementation, pending issues, coding conventions etc.

The image speaks for itself, I think.

Automap + Status Bar are fully functional, and even their responders work correctly. Here they are shown working together. Menus are similarly completed. Obviously, the level loading code works (but I need to implement the object spawning code, as those are much more dynamic).



As an added bonus, I re-enabled a disabled feature which was commented out in the Linux source: the infamous automap "funky strobing effect" (sic) which IMO looks like ass, and I never heard of or seen before. Was it supposed to be such a PITA to use?

BTW, the movement and panning are simulated by injecting "keyboard events" into the Automap responder, even more than one per tic ;-)

This means that I reached the same critical point where the (unreleased) DoomCott 0.5b had reached, if its screenshots are to be believed.

Now, the challenge is to go the extra mile and actually make something that works...

Is the latest source code checked into CVS? Sourceforge says the last commit was in June.

Thanks
Dave

jendave said:

Is the latest source code checked into CVS? Sourceforge says the last commit was in June.

Yup, I commit almost everyday. Dunno what's up with Sourceforge...maybe it just plainly sucks :-p

look in the testers package for the "AutoMapTester" class.

As I said repeatedly, grab Eclipse and get ready for a LOT of redlining...stay on the safe spots to keep your sanity ;-)

BTW, I commited an update which fixed some bugs with passing "pointers" to the status bar widgets. I initially used Integer, but turns out they're immutable -_-.... back to good old single-element arrays, fo' shizzle!

Never even heard of that strobing thing before, and I have to say it looks absolutely horrid. What in the world were they going for? The only thing I can think of is in Aliens when Hudson is freaking out and you see some really jumpy shots of the motion tracker.

david_a said:

Never even heard of that strobing thing before, and I have to say it looks absolutely horrid. What in the world were they going for?

Probably some feature to make the automap harder to use/less useful...in any case the code that did this was fully implemented but commented out in AM_Drawer().

Chocolate Doom has kept this method as "dead code", but other porrs like Boom (and probably most of its derivatives) have ditched it altogether. The animated .gif just doesn't show it at the proper speed inside browsers, the effect should be more "catchy" to the eye but still...wtf.

Edit: I added this info in the wiki, along with a more "static" animation that demonstrates the effect.