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


  • Content count

  • Joined

  • Last visited

About JPL

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If you want to keep tabs on the very latest work done, see this view of the different branches in github: https://github.com/luciusDXL/TheForceEngine/branches Last commit was a couple weeks ago. Also worth noting that some work might be going on in non-public branches or depots. This is really normal with spare time open source projects, people get pulled away by real life stuff, energy for the project wanes and waxes, etc. I say let folks take a break when they need to. Lucius made incredible progress over the last year, I'm happy to wait.
  2. For folks following this project, it does look like great progress has been made since the last update, in this branch of the project's git repo: https://github.com/luciusDXL/TheForceEngine/commits/release Basically lots of game sim being implemented, as Lucius described in the last update: https://theforceengine.github.io/2021/04/12/GameLoop.html
  3. Thanks for the explanation Lucius! I'm familiar with that style of gradually filling in a disassembly. Your commenting style is very good and makes it very easy to understand what's going on in that excerpt, I strive for that with my own work. Looking forward to playing the results, keep up the great work.
  4. Very cool! For possible future project news posts, I'm curious to know what your process for reverse engineering is. Do you use a disassembler, monitor the running game in DOSBox, something else, or a mix of techniques? I've never done this kind of programming before and it's where lots of "reimplement old game" open source projects seem to hit a hard wall after getting the formats figured out and the world rendering.
  5. I do zero competitive stuff and thus don't have the same stake in this that others do, but I do think a lot about game pacifism, game tourism, and "nonviolent" mechanics so here's my take. I think the word "pacifism" is too laden with non-Doom sociopolitical meaning to try to revise its definition in the context of Doom. I would rather just create a new category called something different, eg "No Direct Damage". Partly out of my designer instinct for simplicity, my notion of it would be that *everything* except player-fired hitscan or projectile damage to living monsters is okay. To me that is the true shift in player headspace + tactics and it's not worth it to force players to think about game engine internals like which entity an exploding barrel considers to be its damage instigator. Just don't shoot monsters or hit them with splash. No Direct Damage. Let the current definition of Pacifism stand as it has for decades. I definitely appreciate all the interesting discussion around this though!
  6. Update: I decided to finish up the readme and release this project for real, it's now available here: https://jp.itch.io/deluxe-master-levels
  7. Hi again. This project is now hosted on itch.io, with a semi-fancy page and stuff: https://jp.itch.io/deluxe-master-levels Until it's ready for full public release I've locked it behind a password, "dewm", but anyone here who's interested should feel free to have a look. Changes since last build: Added masters_readme.html, which includes instructions on how to run the compilation and an essay-format writeup on the project, its slice of Doom history, and individual levels. Still a work in progress, pretty much the last thing I have to finish. The parts of the doc that are still being worked on are clearly marked. On Xaser's advice, renamed the final level of Inferno to "Waters of Lethe". Renamed internal map filenames to their original WAD filenames - only affects map name as displayed in automap.
  8. JPL

    The Ultimate DOOM: No End In Sight - Released

    I'm playing through the Top 100 Most Memorable Maps list in reverse order, and just got to #93, "Underworld Citadel" (E3M7), and fell down the rabbit hole that is the whole separate secret area. It looked very different and kinda distinctly 1990s-ish to me so I did some digging and sure enough it's from E1M1 and E2M4 of The Beginning of the End, Tvventy's first WAD from 1997. Just wanted to register my intense appreciation for this kind of callback here. Excellent work on this set, folks.
  9. (deleted, missed the second page's reply to a question)
  10. Hmm, yeah I knew this would have to account for the potential range of port features somehow but I'd hoped that stuff as specific render style wouldn't have to be stored. Is the point of a UDMF-like format here just that keys like RenderStyle can be optional? Anyways yeah if the answer is "It'd be a lot of work, and people don't care enough about demos / are fine with demos as they currently work, for it to be worth the effort", that's fine, it was just an idea I had.
  11. I'll defer to the testimony of actual port authors, but speaking just as a programmer I'd have to really think carefully about how to do it in my own engine. And I think certain architectural assumptions about how to handle time and simulation stepping make it relatively easy, hard, or nigh-impossible. From everything I know of Doom's architecture it wouldn't be easy. For example, how do you "rewind" an actor that existed for a while but is now destroyed (as in, not just fatally damaged, but actually despawned and garbage-collected)? You can determine the future state of an actor much more easily than you can determine what happened to it previously from a given tick. It's different for eg a time-based puzzle game where you deliberately write everything so time can move backwards, but Doom obviously ain't that.
  12. Yeah, these are 100% valid concerns and questions. That's why I'm wondering how much work the initial research would be, ie to determine what the real squeeze would be. (I'm not quite comfortable enough with C that I could just bang this out myself, unfortunately.) I do think there's a chicken-egg dynamic where more people (beyond speedrunners) might use demos if they were more widely compatible and accessible, ie as simple as pressing the Share button on a PS4 controller, but that's speculation. As for the more experimental uses, I think it'd need a killer app, something someone really wants to make that they couldn't do as easily any other way.
  13. Thanks for the responses! A couple more thoughts: The first steps towards proving something like this out would probably be to take a vanilla-compatible source port that is reasonably easy to work with, like Chocolate Doom, and hack in just the LMP playback + export support described above. Then hack in playback support for the generated data. See how much work it is to make that process stable. Check the I/O and disk space concerns. If it seems promising, start thinking about how to actually standardize the format and what features it would need to work with the full range of possible codebases. This might be a can of worms, but I'm thinking about things like the Heretic teleport "glitter", that spawn tons of actors that essentially don't affect the playsim at all, and ZDoom-derived mods that spawn tons of particle fx actors. These would bulk up the data a lot without much point. So maybe you could flag certain actor classes as "let the playsim handle these", only their spawn is recorded by the demo data and the game is responsible for updating them as in a traditional format demo. Potentially messy implications but it seems like it could be a good option to have.
  14. Demo playback. Some ports support it, some don't, and never the twain shall meet. Doom engine demo playback has always worked by streaming pre-recorded inputs into a running play-sim, which is why it breaks (desyncs) so easily with even tiny game code changes. How would one design around this? How: Brute-force serialization of every mobj / actor's transform and state, every frame where a given one changes. Traditional LMP format demos could be "exported" to this format if even one vanilla-demo-compatible source port added code for doing so. Such code would essentially run the vanilla demo playback code, but have an output buffer and write all that transform and state data to it for every frame. Ideally, this export behavior could also be run headless, ie running only the game sim as fast as the machine can handle, so that a 60 minute demo takes way less than 60 minutes to export. Adding playback support for it to any given port would basically turn over all control of actors to this serialized data. "Demo playback mode" for this format wouldn't really involve a running playsim at all, just setting everything to the stored transforms and states on a given frame. You wouldn't ever need to store anything about the internal logic of actors, just where they are and what they look like. Benefits: Gives you a "future proof" demo recording that won't break even if game code changes dramatically. A sharp-eyed viewer might notice that something that's happening in such a demo isn't how the game currently behaves, but that's the whole idea. Lets you play back old vanilla demos in a modern fancy sourceport, for the purposes of recording high quality videos etc. Seeking/rewinding/fast-forwarding would be instant and the code would be extremely straightforward to write. Turns any given supporting engine into a Source Filmmaker kind of tool, where with some additional UI you could move cameras around while the action plays, cut out highlights, and even manually add your own actors as a kind of "post production". You could "peel off" specific actor timelines from a given demo's data, such as players, and run mass analysis tools, or combine many demos to make something like the popular Trackmania "10,000 Cars" videos. This format would be a reasonable default demo format for advanced ports - users could record in it without having to worry about future changes breaking anything. More mappers might bother including demos with their WADs. Challenges: I/O demands would have been completely unworkable in 1993, but now even most low-end computers can record their entire framebuffer to disk >=30 times per second, and this would in almost every case be way less data than that. What would the actual disk space requirements be like? Obviously an hour long playthrough of a slaughtermap with 1000s of enemies would generate a LOT of data, but how much exactly? How much smaller would it be with some sort of non-lossy compression, and could this compression be done easily at runtime? The projects that would most immediately benefit would be source ports that lack demo playback support, like GZDoom. But it also seems like it has value as a preservation tool. And it lets a type of data that was previously completely restricted to certain ports move more freely between ports and their user bases, which seems like it would de-fragment communities in some modest way. I searched around here for any prior expressions of this concept, and didn't find anything. But if there has been any effort in this direction I'd love to know about it.
  15. Ah, I hadn't realized I just defaulted to extracting the graphics as PNG. I re-extracted them as lumps and the Titan maps work as expected with palette mods now. I renamed E4M7 to Chiron to reflect the author's intent. But I left the final map as "An End to Darkness", since it is only a tribute by another author and not Dr. Sleep's actual intended Waters of Lethe, which sadly is probably lost to time. Xaser's map has a hidden dedication in a texture (that can't be seen without noclip, as far as I can tell) that makes specific mention of Waters of Lethe and I'm happy to leave it at that.