Doom in the browser

[D4NUK1]

As a guy just learning programing, this is nuts.

I hope the very well for this proyect, and also nice to try to tackle with ur code first before using another code.

[kb1]

17 hours ago, meapineapple said:

 

I can appreciate your intention, but maybe have a little more faith that I know what I'm doing? I've been modifying or reverse-engineering games practically since I was old enough to hammer at a keyboard. 

 

If I need to reproduce the behavior of the original, then looking at a copy as my primary reference introduces the risk of propagating mistakes or misunderstandings that the copy itself made. They don't even have to be unintentional changes, they could be intentional optimizations that only break compatibility in rare or unlikely cases. Maybe I'll even make some of my own compromises in that regard. But if I'm writing an inexact optimization of an inexact optimization, then everything just gets even messier. 

 

I happen also to be fairly at home with C-isms. It's not as though looking at C source is going to be a problem for me, and certainly not one that needs to be solved by looking at Java instead. I may well look at the Mocha source! But I have no good reason to put it before the original Doom code. 

Keyboard? I twisted wires together, uphill, in the snow... :)

 

If I didn't have that faith in you, I wouldn't waste my time, believe me. If you would afford me the same courteousy for a minute, I'll say what I gotta say, and get off my soapbox. I'm old-school as well.

 

Mocha is a special case, for a couple of reasons. First, it's hand-translated to Java - no automated conversion tools. The development notes are good, as they chronicle each and every struggle unpacking critically packed structs, getting the goofy global gamestate vars in check, decoupling door and actor action pointers, and overall overhaul, and implementation of containment philosophies, etc.

 

It reads like a play-by-play of every snag you're going to hit along the way. That's the beauty of ripping code out of one box and cramming it into another, wires hanging. Those wires are, of course, connected to one end of each and every sin that code committed. If nothing else, it serves as an excellent checklist... a map of all the roadblocks, and (one of many possible) clever ways around them.

 

Best of all, Mocha plays a mean vanilla demo. This is an achievement that *everyone* should notice. In my experience, you only get vanilla demos to sync when your engine is emulating Doom 99.9999% properly.

 

Now, as far as optimizations go, yes, Mocha does some unique things with its renderer. From what I understand, these are fairly isolated. I think the danger of half-implementing Mocha's brand of optimizations is quite low. 

 

Mocha's the real deal. It a field-tested, mathematically correct (in-sync demos) account of things to come. Eventually, you'll encounter a lot of the same battles, so it can provide some level of confirmation.

 

From what I can tell and what I've seen, you'll get there one way or another. You've got your work cut out for you. Of all the resources available today, I feel that the best advice I could offer is to check out Mocha's dev log. I'm curious to know, after having checked it out, if you don't feel the same way.

 

Anyway, as always, good luck.

[meapineapple]

10 hours ago, kb1 said:

It reads like a play-by-play of every snag you're going to hit along the way.

 

I found this page, which talks about some quite basic aspects of porting C code to Java. But it doesn't seem to be what you were specifically referencing, and I wonder if you might be able to link to whatever it was you had in mind. 

[kb1]

13 hours ago, meapineapple said:

 

I found this page, which talks about some quite basic aspects of porting C code to Java. But it doesn't seem to be what you were specifically referencing, and I wonder if you might be able to link to whatever it was you had in mind. 

I feel like an ass - I can't find what I was remembering. It must be in the source, and I'm not having much luck pulling that either (don't have the software here). The last thing I wanted to do was slow you down.

 

That page you linked is a nice start, and it does go into some specifics of the Doom conversion, but I'm sure there was more. I know some of it was scattered within a couple of threads here. I'll keep looking.

 

EDIT: It looks like it's changed hands:

https://github.com/AXDOOMER/mochadoom

 

Still no luck finding the notes I was expecting. I guess, maybe I'm merging that page you linked, and memories of reading the source, into something else (senior moment...). I'll keep looking.

 

Meanwhile, I wanted to ask: What kind of port are you going for? (I mean like vanilla, limit removing, Boom/MBF, or geared towards multiplayer)? Just curious.

[VGA]

In the OP he said he is thinking of a Boom-compatible port, which is smart. Only vanilla would mean a TON of stuff missed...

[meapineapple]

2 hours ago, kb1 said:

Meanwhile, I wanted to ask: What kind of port are you going for? (I mean like vanilla, limit removing, Boom/MBF, or geared towards multiplayer)? Just curious.

 

First Boom and limit removing that works as long as a map isn't using really unconventional tricks or exploits. Then I'd like to try to add options for emulating less commonly used Doom glitches. (I was recently reading about various intentional or unintentional reject table problems, which is really interesting, and not something I'm going to worry about as I just try to get basic functionality working.) I'd really like for it to support ZDoom and GZDoom features sometime after that, but that is a long way off of it ever does happen. 

 

I haven't been thinking about multiplayer support yet, and might not ever. Getting that right is a heck of a lot of work.

Edited November 1, 2018 by meapineapple

[meapineapple]

Wow, there's now handy instructions on how you can now build your own jsdoom WAD inspector! Currently it only knows how to accept WADs on a user's local machine, but with only minimal tweaking you could use it to view WADs hosted on another website, instead...

 

https://github.com/pineapplemachine/jsdoom

 

The inspector can now show you what maps look like:

 

Spoiler

 

 

 

 

Edited November 1, 2018 by meapineapple

[fraggle]

That's great! It would be really nice if you could perhaps grow it into a full level editor - "web-based level editor" has been on my mind for a while as something that would be a great idea. Specifically it potentially gives an editor that works anywhere (including tablets and Chromebooks) and it could potentially be grown to have interesting collaborative features. I'd really like to see an editor where multiple people can edit the same level together in real time - apparently the original DoomEd had this, but as far as I know, no fan-made level editors have ever attempted it.

[meapineapple]

@fraggle I agree that an in-browser map editor, especially a collaborative one, would be hecking awesome.

 

...Wanna help? It would take ages to make a wad sharing site AND a browser port AND an editor all on my own

Edited November 1, 2018 by meapineapple

[Mr.Rocket]

Woah nice!

As described above, where others could take part in drawing a map (on-line) in the same editor at the same time is an awesome idea!

Oh man, the possibilities!

Good Luck with this! it would be really neat!

 

[kb1]

9 hours ago, fraggle said:

That's great! It would be really nice if you could perhaps grow it into a full level editor - "web-based level editor" has been on my mind for a while as something that would be a great idea. Specifically it potentially gives an editor that works anywhere (including tablets and Chromebooks) and it could potentially be grown to have interesting collaborative features. I'd really like to see an editor where multiple people can edit the same level together in real time - apparently the original DoomEd had this, but as far as I know, no fan-made level editors have ever attempted it.

Damnit, you're stealing my idea! No, seriously, I've been planning a multi-user editor for some time now. There could be different roles. Like the map planner, who's job is to split the edit area into physical sections that define regions where users would have temporary exclusive access. Another role would provide global access, for the purpose of joining user sections via doors/hallways. I think such an effort would yield some interesting maps!

[Mr.Rocket]

I could see a testing phase involved, of some sort at first, but then basically a mod where "next in line" could draw/create a door or hallway, and then next user "if wanted" (spec mode) could take part, or watch the piece evolve. ~ maybe a timer..? There could even be game-play or even team-play mod styles, where team tournaments could map for a team side and the other team map for his/her team. There's really nothing that's been thought of for this sort of thing yet..  

I know there's a (wooh bettsie) on the dev scale of things; I get that,  but omg..   

[kb1]

On 11/1/2018 at 10:53 PM, Mr.Rocket said:

I could see a testing phase involved, of some sort at first, but then basically a mod where "next in line" could draw/create a door or hallway, and then next user "if wanted" (spec mode) could take part, or watch the piece evolve. ~ maybe a timer..? There could even be game-play or even team-play mod styles, where team tournaments could map for a team side and the other team map for his/her team. There's really nothing that's been thought of for this sort of thing yet..  

I know there's a (wooh bettsie) on the dev scale of things; I get that,  but omg..   

The coding effort is big but not huge. Basically you re-route user commands through the network vs. local. Using dedicated map regions can simplify things a lot, though I would not want the program to have to depend on that. You'd want to virtualize unique resources like trigger line ids, or at least assign X line ids to each mapper. Tools like Undo/Redo can get quite tricky.

 

There's 2 transmission methods: Sending edit commands, or sending entire map regions. Both have advantages and disadvantages:

• Sending the commands keeps transmission sizes small. But each copy of the editor must be able to recreate the results exactly.
• Sending your specific map block sends the exact results to everyone, meaning that it will work, even if users are using different versions of the editor. But, that's a lot of data.

Doing both complicates the code, but may be warranted. For normal commands, sending the command keeps things fast. But there could be special commands, like "Re-synchronize" which would make sure you have the latest and greatest. That would also be useful to allow people to connect in the middle of an editing session.

 

I am working hard to finish my current RL projects, so I can start to work my Doom queue. If that ever happens, this will become a high priority, cause it could produce some very cool results!