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


  • Content count

  • Joined

  • Last visited

About DavidPH

  • Rank
    Warming Up

Recent Profile Visitors

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

  1. DavidPH

    UDMF common namespace, first draft

    Doing a translator on the code allows for the interpreter to be structured to be more maintainable. The core interpreter loop itself can contain only the generic computational instructions, making it smaller. Which aside from making it a less daunting function, also potentially helps with cache coherence (not sure, though, as it does still have to call out for array accesses, so it may be a wash in that respect). Doing callfuncs as function pointers is half because ACSVM is a separately developed library and half because being able to distribute those function definitions across multiple files is a useful organizational tool. (Eternity's acs_func.cpp needs to be so split at some point. I really hate massive source files.) It also allows for some performance improvements in the interpreter. The check for the compressed bytecode is handled entirely in the loader, rather than during execution. There are no gaps in the internal code indexes for a switch to have to work around (or a jump table and computed goto can be used). I also use the opportunity to turn jump table instructions into small hash maps. And the guards for executing past the end of bytecode are handled by simply inserting additional instructions into the output. There are also some code analysis opportunities, though I do very little with that at present. I have at least considered the possibility of autodetecting if additional global/world/map variables are needed, since the translator is able to see what indexes for those are used.
  2. DavidPH

    UDMF common namespace, first draft

    All of the PCodes with a translation work. All of the not-commented translations and all of the ranges noted as "ACSVM internal codes" here are translated. As for ACS functions which result in multiple instructions: Eternity does not implement CreateTranslation or HudMessage, but should have all of the other printing functions (Print, Log, StrParam, etc.). It does not implement the k: print specifier and the l: specifier just prints the input string. All other print specifiers should be implemented. And since you were asking earlier where the translation actually happens, that would be in Tracer.cpp.
  3. Why is it suddenly acceptable to say "Well, it works for most people, so that's enough for everybody."? I'm aware that some edge cases are too remote to bother supporting, but we're talking about forcing people to set up their filesystems in a particular way and to name their files just so. It's not like we're proposing the abolishing of all existing mechanisms for locating IWADs. We just want a way for the user to unambiguously and explicitly declare the location of each game's IWAD.
  4. I am definitely in favor of this. The current directory-based solutions, which depend on a strict and port-defined naming convention, strike me as dodgy. And while Eternity's solution gets around that, it's not very convenient having to muck in its config. And of course that only helps the one port. As an aside, I also like the wide coverage, but I notice you did not list an entry for Strife's voices.wad.
  5. I'd write it in C++, design everything to be dynamic and portable from the beginning, base it around a simple but powerful scripting engine, and call it something silly like DoomPLX. But maybe that's just me.
  6. DavidPH

    Chocolate Strife Beta 2 Released

    Progress continues on the Chocolate Strife project with Quasar's release of the second beta, which includes numerous bug fixes, compatibility tweaks, and is based on a much newer version of Chocolate Doom. Details are available here.
  7. Progress continues on the Chocolate Strife project with Quasar's release of the second beta, which includes numerous bug fixes, compatibility tweaks, and is based on a much newer version of Chocolate Doom. Details are available here.
  8. DavidPH

    Doom Wiki - new name?

    Seems to me that DoomWiki.org unambiguously says everything about the site in the least number of characters.
  9. DavidPH

    Pending UDMF Revisions

    Except that it doesn't. There is no reason you couldn't use the 5 object types to create true 3D architecture. In some ways you do, 3dmidtex for instance. 3D floors to a slightly lesser degree (it uses a control sector so it's sort of in between).
  10. DavidPH

    Pending UDMF Revisions

    Does base-10 necessarily lose data (for any arbitrary data)? Or is this purely an implementation concern? If the latter, then I think it would be most appropriate to leave it alone. Otherwise, perhaps a base 16 decimal format (0x[0-F]*.[0-F]*) would work (a parsing function for that would be quite trivial, I think)? The concern I see with using a hex qword (assuming you mean to store a double) is that it kind of goes against the point of using a text format to begin with: not locking ourselves into a particular binary representation.
  11. DavidPH

    DH-dlc: a wad programming language

    Go for it. I'd be interested to know how such an experience goes. I would expect trying to recreate a map would be annoying, but doable. As for cool demo maps... I used to have one, but somehow I broke it, so I'm working on a replacement. (Along with replacement libraries for the ones that I broke. (Sorry.)) Oh, and I'd like to note that there is (as far as I know) fully functioning ExtraData support now available in the latest commit. Will have a Windows build up as soon as the guy who makes them does another one.
  12. DavidPH

    WadC Community Project?

    I think what he meant to say was that it has only been tested in Linux (Ubuntu, specifically). Other than that, everything he said is true.
  13. DavidPH

    WadC Community Project?

    Well, I did finally add the ability to define custom functions. But abstraction is really left to compound objects. In theory, a good library of compound objects would allow you to quickly build large, complex maps. (A tautology, I suppose, since that's what would make it a good library.) For instance, if you use the ZDoomDoor compound object from map-libs, you can easily swap it out for ZDoomPolyDoorSlide with very little hassle or probably any other door if I end up adding any (the compound objects in map-libs are mostly just meant to be examples and starters, not all-encompassing).
  14. DavidPH

    WadC Community Project?

    Heard there was interest in mapping in text around these parts. It was suggested to me that I should mention a project here that I've been working on for a while: http://github.com/DavidPH/DH-dlc It has a very different syntax from WadC (which I hadn't heard of until well into DH-dlc). It supports UDMF, Doom, Hexen, and Strife (different thing flags) format, nested comments, compound objects (configurable prefab geometry), expressions, and a few other things. Custom functions should be coming soon. It is a purely command-line utility, so it doesn't allow for previewing except by compiling and running the map. Slightly outdated Windows binaries are available here: http://forum.zdoom.org/viewtopic.php?f=19&t=25016 Of course, WadC has its merits. But I think that DH-dlc has a lot to offer this project.