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

MTrop

Members
  • Content count

    603
  • Joined

  • Last visited

About MTrop

  • Rank
    Self-Described Legend

Recent Profile Visitors

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

  1. That was the goal, my friend! I think I gotta start making a tutorial page for DoomMake so that project creation can really be streamlined. After DSDHacked support in DECOHack, though. Almost done!
  2. MTrop

    Microsoft Windows 11 confirmed exclusive to 64-bit CPUs.

    When Microsoft inevitably makes Windows 12 to address all of the complaints about Windows 11.
  3. MTrop

    What does Vulkan do differently than OpenGL?

    Shortest answer: As an end-user, if your chipset vendor supports it and can parallelize GPU operations (practically all of them today), Vulkan offers better performance. Usually. If the code is written well. Short answer: Vulkan is an API that does things in a way that is more representative of how graphics cards today do graphic processing, with control over pipelining and threading and queueing and memory access strategies. OpenGL is an API that is state-driven, which worked well at its inception, but graphics cards aren't that way anymore, and are bottlenecked by OpenGL's single-threaded scheme and assembly line-like processing. Vulkan is "outside-in" for creating contexts - lots of boilerplate. OpenGL is "inside-out": small, it but gets hairy when you need to make something sophisticated. Long answer: There was a time when OpenGL was king. When it was written for humans. Somewhere along the line as more people made graphics cards that did more generic calculations than just vomiting color information into a chunk of memory, it became a miasma of vague numerals and needing to write lengthy programs for painting a single triangle. Where once was a dedicated place for vertices, colors, texture coordinates, and matrices, a tangled mess of arbitrary numbers matched to other arbitrary numbers crept its way in while an ailing compatibility layer held on for dear life as the specter of GPU-driven tech and transform callbacks threatened to overcomplicate everything so that we could simulate flapping cloth and push extra triangles to paint your favorite avatar's buttocks at varying distances. You could have taught it in schools. Now you need a a technical manual. Then along came Vulkan - if the first horns of the apocalypse were sounded at the genericization of OpenGL, Vulkan is the Third Woe. Any and all sense around drawing simple geometry is dashed against the rocks, several lines of code needing to be written to pass a single vertex and texture. Only the turbo-est of the turbo-nerds are able to parse every layer, every component, every last method of configuration before pen is put to paper - defining not only the mechanism by which the pen extends and retracts its tip, but every piece of pulp used to make the paper it writes to. It is only afterward, days into your training, that you realize that you're not even holding a pen, nor writing it to paper! Days turn to months as the graphics programmer slips away into the void, alienating their friends and family taming the many-headed, many-mawed beast that is Vulkan. I am one with the machine. The machine is me.
  4. MTrop

    DSDhacked [unlimited everything]

    Of course I love it. I made it. ;) Also, any port that discards DeHackEd in favor of a better language is pretty unnecessary unless the port author just wants to shed the shackles of needing to keep an older spec up-to-date. For mod authors, this means nothing, since mixing DeHackEd and DECORATE outside of addressing compatibility issues leads to disaster. We've got (G)ZDoom if you want a port with a better modding language, and solutions are out there for covering the gaps between DeHackEd and EDF and DECORATE and ZScript in terms of writing something legible and maintainable. We can't stop hobby projects, but an entirely new port would just introduce potential user fragmentation and divided effort when existing efforts should be concentrated on learning what each port's individual strengths are and addressing their weaknesses without losing their identities, at this point. The current zeitgeist is backporting engine features that can feasibly be added to an existing chain of Boom-compatible ports (and their spiritual descendants), and I'm not above killing some high-horses to make the glue between them!
  5. Just noticed this post. By all means, let me know what you put together! I may be able to incorporate some of it into DoomMake's default templates if they're universally useful. (I've really been meaning to put the command to clean the dist folder in the clean target - dunno why I haven't done that sooner)
  6. I guess since this thread's a tad more active, I can post an update. Latest version of DoomTools is up. Fixes the following: DecoHack -------- Changed for 0.18.1 * `Fixed` Editor keys were not being saved if a Thing body didn't have parse-able content right after body start. * `Changed` Copying a definition from the exact same one will not perform a copy, as there is nothing to do. If you have DoomTools (version 2021-09-21 and higher) installed and on your PATH, typing doomtools --update will grab it.
  7. @boris That's weird - it works when I try it in my mod, but not when it's a single Thing. I'll take a closer look. EDIT: Oh, Lordy - I figured it out. The comment key context is getting cleared at the wrong time due to how I'm starting the thing body parse. If you put those lines after one of those property lines, it'll work. Should be an easy fix.
  8. I would also expect this as well. This is a strange bug, especially since it did a copy from itself to itself. I'll have to take a look. EDIT: Added an issue: https://github.com/MTrop/DoomTools/issues/52
  9. There is currently no way to convert a DeHackEd patch to a DECOHack source file. There is critical information lost in a DeHackEd file that would enable me to create a human-readable patch of some kind that makes sense, such as how states link to Things or Weapons. It can be inferred through some references, but in order to be correct, I would need to try to group together states in a meaningful way via the "Next State" indices (which is not always helpful), and then create stubbing for each Thing or Weapon that points to those states. All of that would require a lot of work and assumptions that I can never be sure of 100%, and even then, you'd still need to break up the results into something meaningful to yourself. Maybe one day when everything else is done I'll look into seeing if it is feasible in some way, but for the moment (and the future), it can not and will not be done. I'm sure you'll find it's still easier to port everything to DECOHack by hand. A lot of time spent modding is in design, rather than implementation, anyway.
  10. Yeah, maybe one day there could be consensus, but for now I'm just gonna go by whatever's in https://zdoom.org/wiki/Editor_keys as a basis.
  11. Should I go ahead and make that a reality? That's a really quick change on my part.
  12. Ooh - that's a good point. Didn't catch that. Next version! Or maybe we should rope one of the main SLADE devs in here, in case they also adopt DEH scanning for their map editor? I'd hate to discard a feature entirely - RGB would be more flexible everywhere, if adopted in both editors at some point. EDIT: It looks like SLADE supports the DB color id, but yeah - still misleading. I don't think I check for "value correctness" though, so it's not as big a deal, but it needs correcting for clarity.
  13. DECOHack v0.18.0 now supports this in the same way DECORATE does via the special comment directives in Things: //$Angled //$NotAngled //$Category <String> //$Group <String> //$Color <Integer> //$Colour <Integer> //$Sprite <String> //$EditorSprite <String> Update it here: https://mtrop.github.io/DoomTools/
  14. MTrop

    DSDhacked [unlimited everything]

    "In a vacuum" was probably an exaggeration on my part, but yeah - a much simpler DECORATE from the '04-05 era would be a more ideal starting point. Weirdly enough though, I would probably still stay away from the merging of Things and Weapons into "Actors." That feels like a product of ZDoom's early actor code and inventory systems merging and not how Doom functionally separates the two, despite the shared state table. At the moment, the only thing solid enough for the later-gen ports and easily accessible to the Boom-era-lineage ports is the DeHackEd format, and while it is painfully low-level, it is still a decent enough abstraction as an A-to-B mapping medium, even if the interpreting ports won't exactly implement it as such. The "unlimited" nature of DSDHACKED will already force implementing ports that already had a contiguous state table into needing to use a sparse index lookup at the very least.
  15. MTrop

    DSDhacked [unlimited everything]

    DECOHack's final feature set is incomplete and it would be a moving target for implementors. It was really never meant to be anything more than just a different (and hopefully easier) way to make DeHackEd patches without a GUI slowing me (or anybody else) down. Besides, even if DECOHack's exact DECORATE-inspired language were implemented in ports, you would have to emulate its logic for cobbling a patch together, and the results may not be 1-to-1 in terms of what it has to do regarding state allocation and all the other low-level stuff that needs to happen to create a functionally equivalent DeHackEd patch, not to mention implementing all of DECOHack's other procedural niceties like bulk-redefining fields and whatnot. As stated before, DECORATE is high-level. DECOHack has to make concessions (and have additional supporting language) to make it as flexible as low-level DeHackEd, because its goal is to be a DeHackEd patch creator (its ultimate goal is to be as flexible as Fraggle's DEH9000). Every implementing port would have to ensure that their implementations of DECOHack have equivalent results just for safety's sake. You don't have to worry about all of that if it compiles to a singular common output that every port can already interpret unambiguously. And if you wanted to use an uncompiled DECOHack-ish definition language for modding Doom in your favorite port family, why would you even want to care about the fine details of Thing table indices, State table indices, and so forth? It's a needless complication for a modder to endure when they want to just make stuff. That's why we have DECORATE! To reiterate, DECOHack is for making DeHackEd patches (especially within the limiting confines of DeHackEd), and even if MBF21/DSDHACKED didn't exist, it would still have a use. Any other purpose would be a waste of time for port authors to implement to ensure some kind of consistency when they don't have to. And if a "New DeHackEd Language" or "DECOLITE" were made, it should be made in a vacuum, and not take DECOHack's lead as a strict basis for it. Adopting its forced anachronisms would be a mistake in the name of progress.
×