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


  • Content count

  • Joined

  • Last visited

1 Follower

About Lollie

  • Rank

Recent Profile Visitors

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

  1. Lollie

    [v 0 .9] Doom Neural Upscale 2X

    You're probably loading another mod that affects the HUD weapons. I had this same issue, I forgot that I had the Doom Sprite-Fix mod set to auto-load. Make sure that you're only loading the Neural Upscale mod.
  2. Lollie

    [v 0 .9] Doom Neural Upscale 2X

    In my experience, this tends to be an issue with OpenGL renderers. If you're using GZDoom, there's a couple easy fixes: Option 1: Display Options > OpenGL Options > Set "Adjust Sprite Clipping" to "Smart", "Smarter", or "Always" Option 2: Set Video Mode > Set "Render Mode" to either "Doom Software Renderer" or "True Color SW Renderer"
  3. Lollie

    Which source ports would you like to see revived?

    Obscure port mention: Devin Acker's port of PRBoom for 3DS from 2015. Doom has been available on DS/3DS for a while, thanks to DS Doom and elhobbs' prboom3DS. Though Elhobbs' port is virtually feature-complete (including 3D support), it's a direct port of DS Doom, and sticks a full keyboard on the second screen in a way that feels obtuse. What made Acker's port stand out to me when it was in active development, was that it was a direct port of PRBoom to 3DS. It offered proper start-up options (including screen resolution - 320x200, 400x240, or a combination of the two - and the ability to load pwads), all buttons were labelled correctly for key bindings, the bottom screen offered an always-on automap. It felt cleaner at the time, more mindful of the 3DS in general. Screenshot comparison under the spoiler. Nowadays, elhobbs' port is stable, and simply offers far more than Acker's port - It does whatever it needs to do, in order to get the job done. But I would've loved to see Acker's port progress to the point where it could become the port of choice for 3DS. It's a bit late for a comeback now, but it had a lot of potential.
  4. No mention of Linguortals? For shame. Programming, hacking, basically the same thing.
  5. Lollie

    Chocolate Doom

    I know, lol. I just installed the build dependencies exactly as they were listed in the Choco Doom wiki article. Copy and pasted the install command right into the terminal, leaving nothing to chance. All I can assume is that the Python Imaging library / Pillow are not included in that command, and weren't installed when updating MSYS2 with "pacman -Syu", either. Same with "pandoc". For what it's worth, I'm not seeking help for the warnings. I'm just stating I encountered them, in case anyone else attempting to build Chocolate Doom on Windows happens to encounter the same warnings.
  6. Lollie

    Chocolate Doom

    Happy to confirm too, just did a test build and got a working executable. ✌ I did get a few warnings/errors (under the spoiler), but they seem completely inconsequential and didn't appear to affect the build in any way.
  7. Lollie

    Chocolate Doom

    Quick question, are the current instructions for building Chocolate Doom on Windows up to date? There was some discussion last year on GitHub about incorporating CMake (link to that discussion), but I haven't been able to find more info about this.
  8. I emulate PlayStation a ton, so I'm quickly chiming in here with a couple tips: Mednafen supports loading games via drag-and-drop. Simply drag your .cue file onto Mednafen.exe, and it should automatically load the image with the correct emulation core. Quick and easy. XEBRA shouldn't require images to be mounted. File > Open > "CD-ROM image". You may need to select the .bin file - like Dragonsbrethren said, XEBRA is extremely slow at loading .cue files. Mednafen is pretty damn accurate these days, and great on performance. I used to love XEBRA myself, and there's no doubting its accuracy, but in my experience performance tends to be a bit sluggish - I'd argue only using XEBRA to double-check compatibility.
  9. Lollie

    PrBoom-Plus, ver.

    Just to suggest another module player library: libxmp / libxmp-lite. Learned about this library after an interview for a build-engine game called Ion Maiden (interview link, @ 28:48), and from what I've heard, it does the job real nicely.
  10. Lollie

    Hacking the actual PSX Doom?

    This stuff is so wicked, never would have figured that the engines for PSX Doom and Doom 64 were directly related. Makes me wonder if Doom 64 EX could be extended to support PSX Doom levels. Out of curiosity, which version have you guys been editing? 'Doom' or 'Final Doom'? The only reason I ask is because of mouse support — Final Doom had it, but PSX Doom was strictly controller-only. I have a one-handed PS1 controller + PSX mouse setup specifically for Final Doom, it's about as close to keyboard+mouse as you can get on PS1. I'd love to experience proper PSX Doom with the same setup.
  11. That's what I mean. Simple. You might hate it as a programmer, but artists love that layer of abstraction — it's why tools like Game Maker Studio or "PlayMaker" for Unity have ended up being so popular. (No, I'm not suggesting visual scripting for Doom maps. ...It sounds nice though, shit.) In Doom's case, a scripting language wouldn't need to do half of what ACS is capable of doing, it just needs some basic "Doom Level"-specific conditions and actions. eg: Perform Action [X] when Sector [Tag ID] has completed an action. Tell Linedef [Tag ID] to change [Property] to [X] when Thing [TID] is dead. Spawn explosions/bullet puffs/blood/etc along Linedef. End the level after a duration of [Y] ticks. That's okay! It's perfectly fine to have a scripting language that can only do a limited set of actions. You could take FraggleScript, strip out all the stuff about handling cameras, HUDs, etc, limit it entirely to functions that are specific to levels and in-game objects, and it'd still be able to handle a lot of basic tasks. It'd be nice to be able to just take a linedef and plug in a couple basic lines when needed. It doesn't need to be simple and powerful. Simple is enough. ACS isn't disappearing any time soon — If someone needs more advanced capabilities, then that is what ACS should exist for. Edit: Most of my misgivings came down to the tools available, plus a misunderstanding about the scope of use that ACS is intended for. Sorry! Glad to see discussion continued despite my misinformed pot-stirring.
  12. The call for introducing a new cross-port scripting language comes down to wanting something that is high-level. It only needs to be able to perform common Doom-related tasks in a way that is moderately approachable to a non-programmer. Importantly, a scripting language shouldn't require non-programmers to wrap their heads around C/C++ style programming syntax. It should benefit level designers first and foremost. Hypothetically, if ports like PrBoom or Doom Retro (which currently lack support for map scripting) implemented support for high-level Doom scripting, along with ports like GZDoom and Eternity (which already support scripting languages like ACS), this could ultimately give map-makers more freedom to create maps, and give players more freedom to play maps, without anyone having to worry about whether said maps are compatible with their port of choice. The entry bar for creators and players still has some room left to be lowered.
  13. What would you consider to be a "serious" use case? What makes a simple language less suitable than a dynamic language? I can only speak as an enthusiast here when it comes to Doom, but this really resonates with me: You could be an absolute programming wizard and pick the tightest dynamic scripting language ever, and a level designer would still look at it as if it were nothing but hieroglyphics. Unless your project is doing something wildly different, most artists aren't going to need the serious tools — there's a reason why most work with visuals, and not code. We appreciate when something simple is available to us, it lowers the bar for entry and makes development tools more accessible.
  14. Lollie

    Rise Of The Wool Ball :3 (v1.2 now GZDoom compatible)

    Encountered this same bug in a few levels, it happens whenever he's killed while hovering over a decorative object.