Mocha Doom's future directions

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Mocha Doom's future directions

Pages (2): [1] 2 »

Author

All times are GMT. The time now is 23:56.

Maes
I like big butts!

Posts: 10188
Registered: 07-06

So, after v1.6 and the TrueColor stuff out of the way, where do you think I should focus next? Some of my personal priorities for v1.7:

DEHACKED compatibility (lifted from either Choco or PrBoom+, with all credit due).
Boom compatibility, rather than plain limit removing.
SWANTBLS compatibility (the code to read the lumps is already there..)
Improved cross-OS behavior in terms of A/V (but I will need Linux/OSX collaborators in order to do that seriously).
A console settings system.
Supporting non-8:5 screen ratios
Heretic-like freelook system (the code is already there, just dormant ;-)
Support for Wolf3D sliding doors (the code to make them work is implemented, but the linedef type they use conflicts with endlevel...)

Some things that crossed my mind:

A 3D anaglyph mode. Makes more sense now with non-indexed display modes and fullscreen.
Custom sprite or texture-specific colormaps.
More flexible sound system, able to handle samples in non-DMX formats and nonstandard sampling rates.
Compatibility with some form of RoR/3D floors. I'm oriented towards CDoom, which would make Mocha a more accessible way to play CDoom maps. But Boom compatibility is a prerequisite....

Stuff that might appeal to some people but I don't really care about right now:

Multiplayer: there are better ports out there for that. I might get it to basic vanilla level, and that's it.
Applet form: it's simply too full of vexing bugs, restrictions and a sphinx to debug if something goes wrong. Java Web Start form sounds more promising and less restrictive.
Android port (theoretically possible with proper UI/Audio adapters, but no idea how practical it would be in terms of performance/control).

11-13-12 13:47 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

david_a

Posts: 1378
Registered: 09-02

I don't know that focusing on new editing features will be worth it... BOOM* compatibility would have the biggest payoff.

* By that I also include the other handful of MBF and other features that are supported by ZDoom/PrBoom+/Eternity(?).

11-13-12 18:09 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Csonicgo

Posts: 4304
Registered: 03-04

How about a MIDI system or OPL sound?

11-14-12 01:35 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 229
Registered: 11-06

Maes said:

DEHACKED compatibility (lifted from either Choco or PrBoom+, with all credit due).

Boom compatibility, rather than plain limit removing.

Supporting non-8:5 screen ratios

These. (maybe Boom, but, see below)

I was under the impression that Mocha Doom was striving to be a more-or-less straight conversion of the original linux C source to a "clean" Java codebase. Sounds like you're considering "scope-creep" to me :)

The DEHACKED and non-8:5 support allows it to be "modern", without altering the mission statement. (Or, maybe I'm wrong about that - enlighten me). And, BOOM is, more or less, considered a standard of sorts, and is "finished".

Also, how about that demo sync? Don't know if you ever got to see my post about fixing demo sync in this crapfest thread: http://www.doomworld.com/vb/post/1116113 I think demo sync is the most important right now - achieving that would make Mocha Doom the definitive conversion to Java (if it's not already), proving that it's not only accurate, but byte-for-byte accurate, if you know what I mean. In other words, if you can play original demos, you can be damn close to certain that you've nailed it. I knida thought that was your original goal.

11-14-12 01:37 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10188
Registered: 07-06

kb1 said:
I was under the impression that Mocha Doom was striving to be a more-or-less straight conversion of the original linux C source to a "clean" Java codebase. Sounds like you're considering "scope-creep" to me :)

Initially, it kind of was just that: adapting the original code "just enough" so that it would run in a "foreign" language (compared to all the C/C++ ports out there). However, emulating some of C's features that Java lacked, required redesigning the architecture in several points, thus making something potentially more capable appear gradually.

Don't forget that the linuxdoom code "says nothing" of how higher resolutions (in particular, scaling static graphics) should be implemented, so that part was done -almost- from scratch. It also says nothing of how to fix certain broken features (Ultimate & Final Doom support, for instance), again leading to from-scratch solutions in most cases.

Also, the requirement to make it extra-robust against overflows and limit breakage (even some that are asymptomatic or non-breaking in vanilla/boom), required making it de-facto limit removing. It probably has more safeguards in place than any other port out there, and even "digests" a couple of mapsets that even prBoom+, in all of it vanilla & C-induced laxness, can't handle (e.g. malformed sprite/flat markers in Hellraiser).

It would be pointless trying to beat Chocolate Doom at its own game: it would actually be harder making it e.g. able to display tutti-frutti "correctly" (especially of the second kind) rather than fixing it.

kb1 said:
Also, how about that demo sync? .... In other words, if you can play original demos, you can be damn close to certain that you've nailed it.

I'm actually pretty surprised that it played any vanilla demos at all. The problem with Mocha -barring any P_Random or fixed_t math errors- is that it's too "candid": only demos that wouldn't break a single vanilla limit or cause the slightest overflow are worth examining for errors -but I have a suspicion that most vanilla demos DO break some subtle limits, even built-in ones, that's why some play back cleanly and others break up pretty soon.

If I really have nothing better to do with my development time, I might go after bug and hex values chasing (and then again, only for glaringly obvious problems not justifiable by overflows or memory garbage, that's why I need a "clean" demo that is known not to break any vanilla limits or cause stack/buffer overflows in vanilla yet exhibits a clear breakage point attributable to a specific action in Mocha).

The problem with seeking 100% compatibility is twofold:

It's acknowledged that linuxdoom, per-se, is NOT, I repeat, is NOT 100% v1.9 vanilla demo-compatible, so the reference codebase for finetunings would have to be looked elsewhere.
Even ports that are specifically finetuned for that, e.g. Choco and prBoom+, may still "miss" some demos that depend on machine-specific memory garbage. I have no intention of going THAT far with compatibility, nor adding overflow handling, but hey, it's an open source project. If someone wants to port all of prBoom+'s demo-specific hacks, be my guest.

Csonicgo said:
How about a MIDI system or OPL sound?

There already is built-in MUS2MIDI music support (thanks to David Martel/finnw), and there's a pure java OPL3 library out there....only that it would be a bummer to go through all the pain to add support for it only to hear that "it does not sound like the real thing". Well, no surprise, no soundcard can output at precisely the 49716 Hz required for faithful OPL3/OPL2 emulation, and properly downsampling to 44/48 KHz can't be achieved "cheaply" (requires oversampling to a 60 MHz intermediate rate, I kid you not). So, little incentive to work on that, at all.

Last edited by Maes on 11-14-12 at 11:33

11-14-12 11:16 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Csonicgo

Posts: 4304
Registered: 03-04

Maes said:

There already is built-in MUS2MIDI music support (thanks to David Martel/finnw), and there's a pure java OPL3 library out there....only that it would be a bummer to go through all the pain to add support for it only to hear that "it does not sound like the real thing". Well, no surprise, no soundcard can output at precisely the 49716 Hz required for faithful OPL3/OPL2 emulation, and properly downsampling to 44/48 KHz can't be achieved "cheaply" (requires oversampling to a 60 MHz intermediate rate, I kid you not). So, little incentive to work on that, at all.

"The real thing" is pretty much impossible to accomplish, anyway. I wouldn't worry about anyone's opinions on that, as the java OPL3 implementation is the most accurate one out there now.

11-14-12 17:38 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

AlexMax
Senior Member

Posts: 1070
Registered: 01-03

Maes said:
I'm actually pretty surprised that it played any vanilla demos at all. The problem with Mocha -barring any P_Random or fixed_t math errors- is that it's too "candid": only demos that wouldn't break a single vanilla limit or cause the slightest overflow are worth examining for errors -but I have a suspicion that most vanilla demos DO break some subtle limits, even built-in ones, that's why some play back cleanly and others break up pretty soon.

If I really have nothing better to do with my development time, I might go after bug and hex values chasing (and then again, only for glaringly obvious problems not justifiable by overflows or memory garbage, that's why I need a "clean" demo that is known not to break any vanilla limits or cause stack/buffer overflows in vanilla yet exhibits a clear breakage point attributable to a specific action in Mocha).

I actually think it would be a worthwhile endeavor to chase down more precisely why demos tend to desync. There's always a possibility that you might find an easy compatibility fix that you overlooked.

Barring that, I think that Boom and DeHackEd support is an obvious next step.

11-14-12 23:59 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Xaser
Forum Staple

Posts: 2121
Registered: 07-03

Boom n' DeHackEd for sure. That'll open plenty of doors.

11-15-12 01:24 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Forum Regular

Posts: 675
Registered: 04-09

1. Boom as it is required for may community wad projects
2. Dehacked is commonly used
3. BEX is easy enough to add to Dehacked
4. Free-Look and shot aiming
...
500. Demo sync, as it will absorb 98% of all your time. Because the causes are:
a: use of a random numbers
b: slight differences in position, angle, or momentum from some other port that created the demo.
(I worked on demo compatibility on DoomLegacy and it does better, but won't even stay in sync on demos that it recorded).
The demo system is inherently flawed and needs radical fixing.

11-15-12 01:39 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 229
Registered: 11-06

Maes said:
Don't forget that the linuxdoom code "says nothing" of how higher resolutions (in particular, scaling static graphics) should be implemented, so that part was done -almost- from scratch. It also says nothing of how to fix certain broken features (Ultimate & Final Doom support, for instance), again leading to from-scratch solutions in most cases.

Also, the requirement to make it extra-robust against overflows and limit breakage (even some that are asymptomatic or non-breaking in vanilla/boom), required making it de-facto limit removing. It probably has more safeguards in place than any other port out there, and even "digests" a couple of mapsets that even prBoom+, in all of it vanilla & C-induced laxness, can't handle (e.g. malformed sprite/flat markers in Hellraiser).

It would be pointless trying to beat Chocolate Doom at its own game: it would actually be harder making it e.g. able to display tutti-frutti "correctly" (especially of the second kind) rather than fixing it.

Naw, I'm not suggesting that you emulate tutti-fruiti - yikes! You have a unique opportunity to create the de-facto standard of Java Dooming. It's too late for C ports, but you are the first to successfully accomplish this. Therefore, you can dictate the standard, including limit removal, hi-res fixes, and even Boom/MBF support. And, you can call it "version 1.0", and "market" it as the Java Doom standard. It can still be called "vanilla-like", and also possess limit removal, hi-res features, etc.

Maes said:
I'm actually pretty surprised that it played any vanilla demos at all.

Don't be. It's probably not as hard as you think. Did you read the link I provided? I can't stress enough how useful that exact procedure is in pointing you directly towards each incompatibility, one-by-one. You could implement my instrumentation in a night. If you're willing to try the procedure in your port, I'll provide the other half to compare to, as my home port plays all original 1.9 demos in sync. It already has this instrumentation "ifdef"ed in. What an amazing thing it would be, to not only have doom completely running in Java, but for it to be such an exact implementation as to play back the original demos. It's awesome to start your port, and watch Romero playing the demos, and, by comparison, it sucks when said demos go out of sync, or, the cop-out: "old demos not supported..."

But, please, let me know you're serious about it, first. I recently provided my support for another demo sync system, and my hard work was largely ignored, for some reason. (you know who you are...a little credit would have been nice, just saying...)

Wesley: Please check out the link I posted above. If you add the instrumentation to your port, I'll provide the other half.

The demo system isn't flawed, not in the least - it's actually rather brilliant, if you consider the depth of what it captures in a teeny-tiny amount of memory. Furthermore, it makes the slightest deviation-from-original stick out like a sore thumb, like nothing else can. Sure, you have to be exact, but, so what? That's a good thing.

11-15-12 03:06 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

LordMeow
Warming Up

Posts: 14
Registered: 12-09

kb1 said:
Naw, I'm not suggesting that you emulate tutti-fruiti - yikes! You have a unique opportunity to create the de-facto standard of Java Dooming. It's too late for C ports, but you are the first to successfully accomplish this. Therefore, you can dictate the standard, including limit removal, hi-res fixes, and even Boom/MBF support. And, you can call it "version 1.0", and "market" it as [b]the Java Doom standard. It can still be called "vanilla-like", and also possess limit removal, hi-res features, etc.

And if anybody needs a vanilla-stric Java source port, he can work backwards from where Mocha Doom stands now using Chocolate Doom as a template.

11-15-12 08:27 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Death Egg
Forum Regular

Posts: 743
Registered: 09-10

I'm gonna put in a vote for Boom and DEHACKED support too. The Wolfenstein doors thing intrigues me though.

11-15-12 09:38 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

wesleyjohnson said:

500. Demo sync, as it will absorb 98% of all your time.

I guess that's something, many who consider this an essential feature don't think about.

It's not a feature that comes naturally, but something that requies lots and lots of tedious work. It's the one thing that more often than not will be the deciding factor for implementing a new feature.

11-15-12 09:43 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10188
Registered: 07-06

LordMeow said:
And if anybody needs a vanilla-stric Java source port, he can work backwards from where Mocha Doom stands now using Chocolate Doom as a template.

The problem is that in Java you can't just let overflows happen like you can in C, and the memory model is very different, so you'd either have to add exception catching with deliberate emulation of side effects everywhere that overflows could occur. Rather than looking plain and basic, such a port would look like a patchwork of one-time hacks, artificial constraints and just trying too hard to be something it's not.

The other solution would be resorting to writing a full-fledged MS-DOS emulator or even a sort of C virtual machine in Java (which is sort of what this and this do, the latter using JavaScript), which would emulate C's flat memory model more faithfully. It's also quicker to do.

But at that point it would no longer be a "source port" proper that you can edit, extend, and use language features in, but respectively an MS-DOS emulator and a bytecode VM which tries to bypass the execution platform's (Javascript & HTML 5) limitations. Development would still need to be done in C, not in the target language, and it would be harder to "punch through" the VM's limitations and add things like e.g. true color, sound or network support.

11-15-12 09:45 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Springy
Member

Posts: 562
Registered: 09-12

I agree BOOM compatibility and Dehacked support should be the next primary focus as for the platform support (android, applet) I don't think they really matter for now (probably should be done right at the end if you want). Multiplayer I think wouldn't concern me as much, personally.

11-15-12 09:48 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

LordMeow
Warming Up

Posts: 14
Registered: 12-09

Maes said:

The problem is that in Java you can't just let overflows happen like you can in C, and the memory model is very different, so you'd either have to add exception catching with deliberate emulation of side effects everywhere that overflows could occur. Rather than looking plain and basic, such a port would look like a patchwork of one-time hacks, artificial constraints and just trying too hard to be something it's not.

The other solution would be resorting to writing a full-fledged MS-DOS emulator or even a sort of C virtual machine in Java (which is sort of what this and this do, the latter using JavaScript), which would emulate C's flat memory model more faithfully. It's also quicker to do.

But at that point it would no longer be a "source port" proper that you can edit, extend, and use language features in, but respectively an MS-DOS emulator and a bytecode VM which tries to bypass the execution platform's (Javascript & HTML 5) limitations. Development would still need to be done in C, not in the target language, and it would be harder to "punch through" the VM's limitations and add things like e.g. true color, sound or network support.

It's obvious you'll never reach full compatibility by normal means, since in Java you're compiling for the JVM which is a pretty different beast.

I think that Mocha as it stands now should be the 'standard' of Java Doom ports, since its the first completed. So if anybody does not want what you are going to develop now, he always can resort to these first versions.

What you showed us here is far beyont the original goal of Mocha, to my taste... which I understand was 'to develop a port of Doom as much compatible with the original as possible in Java'. Doing anything out of what you've done is stepping on the emulation/simulation territory, and will convolute the code too much to be of educational use regarding Doom.

11-15-12 10:58 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10188
Registered: 07-06

LordMeow said:
It's obvious you'll never reach full compatibility by normal means

Something that not even the MOST compatible ports (Choco and prBoom+) can claim to do, in the strictest sense. There's no such thing as 100% compatibility. Maybe 3-nines (99.9%), 5-nines even (99.999%) but not 100%.

Hell, even vanilla doom.exe can produce demos that are not 100% compatible with itself unless executed on the very same machine that produced them in the very same state they were recorded at, because they depend on precise memory garbage values. prBoom+ tries to emulate this to some degree, but I doubt they'll ever catch'em all, so to speak. So there's really no point trying to beat those super-specialized ports at their own game, just trying to be compatible within reasonable limits, at least for "clean" stuff.

Last edited by Maes on 11-15-12 at 11:56

11-15-12 11:42 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Phobus
Forum Staple

Posts: 2138
Registered: 10-06

Death Egg said:
I'm gonna put in a vote for Boom and DEHACKED support too. The Wolfenstein doors thing intrigues me though.

This and mouselook would make this quite an interesting port for me, as it'd then be as playable as ZDoom and Eternity are, have a very wide range of compatability and also introduce something interestingly new.

Shame there isn't a common standard for MAPINFO, or I'd say go for that as a helpful addition for modders.

11-15-12 12:30 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Death Egg
Forum Regular

Posts: 743
Registered: 09-10

Oh, I completely forgot to say that you should add built-in Chex Quest support. Maybe be the first source port to have CQ demos that aren't broken and support for the intro and outro videos as well.

11-15-12 19:04 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9158
Registered: 07-07

I'd vote Boom features (including DEHACKED and BEX support), then moving onto "Boom+" stuff (MBF features, especially the sky transfer line special, MUSINFO, and other features shared by at least PrBoom+, Eternity, and ZDoom).

Death Egg said:
support for the intro and outro videos as well.

Didn't they use some RADTool/Bink/whatever format? Without a freely-bundlable reader, it'd be a lot of effort for a very small payback.

Last edited by Gez on 11-15-12 at 22:36

11-15-12 19:09 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14809
Registered: 04-02

Maes said:
I'm actually pretty surprised that it played any vanilla demos at all. The problem with Mocha -barring any P_Random or fixed_t math errors- is that it's too "candid": only demos that wouldn't break a single vanilla limit or cause the slightest overflow are worth examining for errors -but I have a suspicion that most vanilla demos DO break some subtle limits, even built-in ones, that's why some play back cleanly and others break up pretty soon.

I say just leave a "clean" compatibility mode which would be primarily useful to play vanilla levels. Boom itself tried to have such a feature (although it has bugs). Perhaps it could record with a "Mocha vanilla" version identifier, and this code would also read v1.666 to v1.9 demos without overflows or weirdnesses, but it would not record with such version identifiers to avoid causing headaches to vanilla, Chocolate or PrBoom/+ users.

11-15-12 20:37 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 229
Registered: 11-06

Maes said:
So there's really no point trying to beat those super-specialized ports at their own game, just trying to be compatible within reasonable limits, at least for "clean" stuff.

Aw, man, it sucks that you feel that way. It's not a competition, but rather, "proof", or something, that you've got a really close emulation going on. And, you can see the IWAD demos! I can't say that I know for sure, but, to loosely quote, I'm 99.9% sure that there are no funky overflows in the IWAD demos.

I'm not talking about boogering up your source, quite the contrary. The fact that it does plays some of the IWAD demos proves that you're really close. If I had to guess, I would say that, maybe, you goofed on one or two silly little things that are keeping it from playing the IWAD demos.

The benefits are:

confidence that it'll play a real good emulation
the joy that comes from seeing it play the IWAD demos successfully
gaining the mindset of optionally preserving the original gameplay, especially in the light of contemplation of adding Boom, and other new features.
upon adding those features, the confidence in knowing that they were added "cleanly".
it's really not that difficult, especially at the stage you're at.

My motivations for wanting to help are:

I think Mocha is an awesome concept
I know I was very proud when my massively-hacked-up source finally played the IWAD demos
I wish I had known about these simple steps to correct demo sync, when I was in the middle of it.
I wish I had known just how powerful this specific instrumentation was, and how easy it is to implement.
I want to give something back to the community.

Aren't these good enough reasons to take a chance, and devote a few hours towards maybe having something exceptional? Once again, I'll help by doing the other half, if you're willing to give it a shot. We'll stop short of having to do questionable things to the source - I don't believe that'll be a problem.

Come on, man, just try it :)

11-15-12 23:10 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 229
Registered: 11-06

wesleyjohnson said:
500...Demo sync, as it will absorb 98% of all your time. Because the causes are:
a: use of a random numbers
b: slight differences in position, angle, or momentum from some other port that created the demo.

Wesley, it's just not true! Yes, you *could* pull your hair out, and spend a ton of time - I know that's what I did at first. But if you use the system I describe, the first error in chronological order typically pops up, complete with current tic, and usually, the offending function itself. When it does not, typically the player movement stuff is the culprit. Some additional logging of the movement functions will almost always find those as well.

Once again, if you're serious, I offer my services to you as well. Let me know.

11-15-12 23:21 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10188
Registered: 07-06

kb1 said:
Come on, man, just try it :)

Well, you sure got me curious. Other than your tools, I'll need some simple enough demos (perhaps with ultra-simplified maps, in order to allow focus on specific actions) that, however, do display obvious breakage points, and work in a bottom-up approach from there.

Yes, this might mean making a big open space with two shotgunners or a bunch of pinkies, record something in vanilla Doom, and then see if it will play back exactly the same, at least at this level of simplicity, and then slowly work up from there. Trying to keep up with what's happening to dozens of awakened monsters in a "full fledged" demo would not be a good debugging scenario IMO, unless you're positive that the most basic stuff is 100% nailed down.

Last edited by Maes on 11-15-12 at 23:46

11-15-12 23:31 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Dragonsbrethren
Senior Member

Posts: 1457
Registered: 03-09

I'd definitely like to see vanilla demo compatibility too, if it's feasible.

11-15-12 23:49 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 229
Registered: 11-06

Maes said:
Yes, this might mean making a big open space with two shotgunners or a bunch of pinkies, record something in vanilla Doom, and then see if it will play back exactly the same, at least at this level of simplicity, and then slowly work up from there. Trying to keep up with what's happening to dozens of awakened monsters in a "full fledged" demo would not be a good debugging scenario IMO, unless you're positive that the most basic stuff is 100% nailed down.

Let's start with IWAD demos - that way we'll both definitely have the same exact demo. You pick which ones, and let me know, so I can begin on my end.
No worries about creating a specialized scenario. As far as monster counts goes, the more, the merrier, because more monsters will make problems happen quicker.

Those instructions I posted are basically it, but, I'll formalize them a bit, so you know exactly what I'm looking for (it's beneficial that we use the same formats for comparison!). Some time tomorrow.

All I ask is that you assure me that you're serious - please don't get me to bust my ass for nothing :) Of course, if we get into it, and the required fixes become uncomfortable to your plans, just let me know.

For now, here's what I need:
1. Mentioned assurance.
2. A list of IWAD demos that don't sync, with IWAD version number.
3. It would be nice to have a place to upload files easily - these files can grow rather big rather quickly (although they zip well).

Tomorrow, I'll send you specs to instrument your source in an exacting manner (but my specs will be C-based, so you'll have to translate).

11-16-12 00:47 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

kb1 said:
Wesley, it's just not true! Yes, you *could* pull your hair out, and spend a ton of time - I know that's what I did at first. But if you use the system I describe, the first error in chronological order typically pops up, complete with current tic, and usually, the offending function itself. When it does not, typically the player movement stuff is the culprit. Some additional logging of the movement functions will almost always find those as well.

Once again, if you're serious, I offer my services to you as well. Let me know.

The problem is that you need to sync all the P_Randoms with vanilla, which is not always a certain thing to do and will require some effort. However P_Randoms and movement are not always clear cut. It also is not perfect, it can find most desyncs but not all of them. There are also cases where desyncs are not on the same tic so you still need to backtrace events.

11-16-12 03:16 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 229
Registered: 11-06

Ok, here's your weekend homework...

code:
****** STEP 1: Translate and add the following code. I decided to just go ahead and give you ALL of the instrumentation I use  *
    when tracking down sync problems. By the way, this code works equally well when trying to synchronize net games.
******


[d_main.c:(global scope)]

    FILE *syncdebugfile;



[d_main.c:D_DoomMain (somewhere near top of function)]

    // [kb] open the sync debug file
    syncdebugfile = fopen("syncdbg.txt", "a");
    fprintf(syncdebugfile, "*** Debugging started ***\n");



[(in your shutdown code)]

    // [kb] be sure to close the file proper on program shutdown
    fprintf(syncdebugfile, "*** Debugging stopped ***\n");
    fclose(syncdebugfile);



[m_random.c:P_Random (replace whole function)]

    int P_Random (int caller)
    {
        prndindex = (prndindex + 1) & 0xFF;
        fprintf(syncdebugfile,"PR #%i [%i]=%i\n", (int)caller, (int)prndindex, (int)rndtable[prndindex]);
        return rndtable[prndindex];
    }



[p_inter.c:P_KillMobj (at the top of the function)]

    if (source)
    {
        fprintf(syncdebugfile, "KillMobj src %i [%i] xyz=%i %i %i\n",
                                source->type, source->info->doomednum,
                                source->x, source->y, source->z);
    }

    fprintf(syncdebugfile, "KillMobj targ %i [%i] xyz=%i %i %i\n",
                            target->type, target->info->doomednum,
                            target->x, target->y, target->z);



[p_inter.c:P_DamageMobj (at the top of the function)]

    fprintf(syncdebugfile, "DamageMobj Targ %i [%i] xyz=%i %i %i\n",
                            target->type, target->info->doomednum, target->x, target->y, target->z);
	
    if (inflictor)
        fprintf(syncdebugfile, "DamageMobj Infl %i [%i] xyz=%i %i %i\n",
                                inflictor->type, inflictor->info->doomednum,
                                inflictor->x, inflictor->y, inflictor->z);

    if (source)
        fprintf(syncdebugfile, "DamageMobj Src %i [%i] xyz=%i %i %i dtype %i\n",
                                source->type, source->info->doomednum,
                                source->x, source->y, source->z, damagetype);



[p_mobj.c:P_MobjThinker (at the top of the function)]

    if (mobj->momx || mobj->momy)
    {
        fprintf(syncdebugfile, 
            "Mobj %i (%i) xyz %i,%i,%i (%i,%i,%i) mom %i,%i h=%i fl=%i\n",
            mobj->info->doomednum, mobj->type, mobj->x, mobj->y,
            mobj->z, mobj->x >> 16, mobj->y >> 16, mobj->z >> 16, mobj->momx,
            mobj->momy, mobj->health, mobj->flags);
    }



[p_mobj.c:P_SpawnMobj (near the top of the function, after "info" is valid)]

    fprintf(syncdebugfile,
        "Spn %i (%i) xyz %i,%i,%i\n",
        (int)type, info->doomednum, x, y, z);



[p_tick.c:P_Ticker (at the top of the function)]
    fprintf(syncdebugfile, "\n--- TIC %i ---\n", gametic);



[p_user.c:P_PlayerThink (at the top of the function)]
    fprintf(syncdebugfile,
        "Plr %i xyzpvv %i,%i,%i,%i,%i (%i,%i,%i) mom=%i,%i h=%i\n",
        player->mo->info->doomednum, player->mo->x, player->mo->y, player->mo->z,
        player->viewheight, player->viewz,
        player->mo->x >> 16, player->mo->y >> 16, player->mo->z >> 16,
        player->mo->momx, player->mo->momy, player->mo->health);


****** STEP 2: The hard part :) This part is difficult, simply because there's a lot of entries. Here we add enums to every instance of P_Random. See below:

// The following is just an example, please add your own. Basically, you want to create a new name for each instance of P_Random
// in your code, by creating a descriptive enum for each, and using the enum as an argument to each P_Random call. 
//
// I was going to provide the list, but, my game has many hundreds of them, that don't all apply to Doom. Once you
// create your list, be sure to send me your enums so I can map them to my numbers (shouldn't be too difficult - I assume you
// followed the layout of v1.10 closely??). In naming them, please follow these guidelines:
//
// 1. Name should be short, but descriptive, and should really match the function name.
// 2. Follow multiple entries within the same function, with a number (like "pr_facetarget2").
// 3. Make sure they're unique, and that you covered them all.
// 4. Put the actual value in a comment as below. It'll suck otherwise.


[m_random.h: (Example enum list)]

    typedef enum
    {

        ...

        pr_facetarget1,   // 0
        pr_facetarget2,   // 1
        pr_posattack,     // 2

        ...

        pr_bfgspray,      // 57

        ...

    }  random_t;

[Here's an example of using the enum in a P_Random call]

        damage += (P_Random(pr_bfgspray) & 7) + 1;
    

***********************
* STEP 3: Compile!    *
***********************

Actually, here's the whole sequence:
1. Compile.
2. Run.
3. Load demo in question.
4. A syncdbg.txt file should be getting written. warning: The file will not grow too big for the iwad demos.
5. Stop the program when the demo goes out of sync.
6. Send me your enum list.
7. Send me your syncdbg.txt file - it will compress to a reasonable size.


*************
* NOTES:    *
*************

The goal here is that you generate a syncdbg.txt file that, when compared with my syncdbg.txt file, will match byte-for-byte, if both
games are in sync. So, please be very careful when typing the file output strings, and be sure you're outputting signed 32-bit ints.
It's a bit of work to add the instrumentation. If I were you, I would place it all under conditional compile (except for the P_Random
entries - it's a bit difficult to conditionally compile them with/without that enum argument!).

Here's is what the output of tic 446 (~8 seconds in) of the first UD v1.9 demo looks like:

code:
--- TIC 446 ---
Plr -1 xyzpvv -10463644,-499023,0,2686976,2212600 (-160,-8,0) mom=685189,-81469 h=98
Mobj -1 (0) xyz -10463644,-499023,0 (-160,-8,0) mom 787090,-71394 h=98 fl=33557574
PR #2 [220]=123
PR #6 [221]=251
PR #23 [222]=26
PR #23 [223]=36
PR #30 [224]=17
PR #30 [225]=46
PR #31 [226]=52
PR #418 [227]=231
PR #418 [228]=232
Spn 38 (-1) xyz -9360852,-1582141,1895971
PR #395 [229]=76
PR #419 [230]=31
DamageMobj Targ 0 [-1] xyz=-9676554 -570417 0
DamageMobj Infl 2 [9] xyz=-9813184 -8992320 0
DamageMobj Src 2 [9] xyz=-9813184 -8992320 0 dtype 9
PR #358 [231]=221
PR #30 [232]=84
PR #30 [233]=37
PR #31 [234]=216
PR #418 [235]=165
PR #418 [236]=212
Spn 38 (-1) xyz -10213577,-1798670,1862513
PR #395 [237]=106
PR #419 [238]=197
DamageMobj Targ 0 [-1] xyz=-9676554 -570417 0
DamageMobj Infl 2 [9] xyz=-9813184 -8992320 0
DamageMobj Src 2 [9] xyz=-9813184 -8992320 0 dtype 9
PR #358 [239]=242
PR #30 [240]=98
PR #30 [241]=43
PR #31 [242]=39
PR #418 [243]=175
PR #418 [244]=254
Spn 38 (-1) xyz -10296023,-1889875,1835101
PR #395 [245]=145
PR #419 [246]=190
DamageMobj Targ 0 [-1] xyz=-9676554 -570417 0
DamageMobj Infl 2 [9] xyz=-9813184 -8992320 0
DamageMobj Src 2 [9] xyz=-9813184 -8992320 0 dtype 9
PR #358 [247]=84

Note: Your numbers after "PR #" will be different, but everything else should be the same. Good luck!

11-16-12 19:34 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

kb1 said:
Stuff

sed is your friend. Along with source code parsing and C macros. So rather than doing the work manually, your script can do it all for you.

Also, all those fprintfs all over the place should just be replaced by a single function call which does the equivalent. It just hides the fprintf (so you'd hide the badly namespaced syncdebugfile). And you could also do other things with it, without changing tons more lines of codes.

Do it for said port and Chocolate Doom (a nice base).

Then you can modify fraggle's "check every compet-n demo" script to create original synchronization tables for every single demo. Then run the same script to create synchronization tables for your own port playing the demo. Then compare the files ignoring whitespace and line ending differences.

11-17-12 17:13 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 229
Registered: 11-06

In this particular case, I just wanted to convey the simplest possible addition to the code, to get the results I'm looking for. But, you're right, having a standardized format would maybe make sense - it would be nice to be able to download a profile for published demos, to check against each port. It would be a lot of work (and would take up a lot of space), but, it's an interesting idea.

11-19-12 16:56 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 23:56.

Pages (2): [1] 2 »

Doomworld Forums > Classic Doom > Source Ports > Mocha Doom's future directions

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >