Blzut3

Members
  • Content count

    630
  • Joined

  • Last visited

2 Followers

About Blzut3

  • Rank
    Member
  1. Of course you can. It's a bit of a pain since you need to type out the command line arguments manually, but the Android version has everything the PC version has.
  2. Usually symptoms like these are caused by the joystick being enabled.
  3. Mostly just to bring up an opposing viewpoint I wonder if, given the point is to keep things simple, there's any point to including single child parents. That is remove WinDoom, MBF, SMMU, Skulltag, JDoom, and continue leaving out EDGE. If I'm reading the tree without context of the community as a whole the stepping stones honestly don't say anything about the relationship between the ports in question and thus not really useful information.
  4. Well if the constraints are "the tic command format shall never change," then there's not really anything else that can be done. Certainly several orders of magnitude better than hard capping the controls in my opinion. Well I certainly understand the Jell-O comparison, but I'm not a latency sensitive person, so I personally found that I was able to make quick turns and end up at the desired angle no problem. Would probably be even better if the camera pitch/yaw was detached from the player similar to how GZDoom handles mouse input above 35Hz, but not sure since that would mean you can potentially end up firing into a wall unintentionally. But if the issue is keyboard players not wanting to switch to the mouse in competitive games then they're intentionally keeping their community small, and the only way to change that would be to just fork the project and let the players decide.
  5. I think it was Blastfrog that once had me look at improving the controls, and at the time I was under the impression that the sentiment was that a solution was impossible without breaking demo compat thus they weren't interested in trying. Certainly didn't hear of anyone crying foul for competitive reasons, but I wasn't involved with the game or its community so I could be wrong. Actually implemented buffered turning and it worked surprisingly well. Sure fast turns lagged, but it felt better and generally you're not making 180 degree turns so it usually only took an extra tic or two to match the logical yaw. For one reason or another that effort got discarded (the specifics are not really important here), and I don't remember if I sent him the diff. I think the fact that you can't find the site pretty much answers your own question. Mortiz Kroll was pretty slow to respond to my emails when I started ECWolf and by 2012 he sees to have disappeared. The site moved to o2mail when his ISP got bought out, luckily someone in the Wolf3D community managed to find it. After a year or so it seems the site got deleted. To the best of my knowledge ECWolf is the only maintained source port of Wolf3D. It did largely do one thing and do it well relative to the time when all Wolf3D source ports were hardware accelerated and borderline engine recreations at best. That said it appears much more conservative on the surface than it actually is. I wish I had infinite time to maintain two source ports as it would be nice to have a vanilla accurate reference port a la Chocolate Doom. (No, Fabien Sanglard's "Chocolate Wolfenstein 3D" doesn't count. It's Wolf4SDL with an added "CRT emulator" and some ifdefs flattened. It still contains the renderer and pushwall improvements among other changes.) Alas I barely have time to work on ECWolf these days. Just reuploaded the files that I have to the downloads page. Not that anyone is looking for it here, but the Wolf4GW download seems to be gone (wolf4gw_freepush3.zip). Found this repo though which the first commit sounds like it's mostly a raw dump of the zip: https://github.com/TobiasKarnat/Wolf4GW This stuff is doing a surprisingly good job at being an exception to the "what goes on the Internet stays on the Internet" rule despite being fairly popular.
  6. Are you not getting responses to queries or something else? In the former does using the "Cautious" query speed fix the issue? Doomseeker works fine on every network I've tried it on so whatever the issue may be it's going to be a drawn out process to debug it if someone is willing to help. Doomseeker tracks meta data so it should be just a matter of selecting a demo and pressing the play button. If not then there's a bug. Again specific criticism on how it can be improved would go a long way. Telling me it sucks doesn't provide anything actionable/constructive. This doesn't work on everyone's system. On Windows for example if the game is installed in Program Files then it will not work if we default there. We chose defaults that should work for users 100% time since most users will never look at the configuration dialog. This is something we learned the hard way early on since people were installing Skulltag in Program Files. Ditto. Also if you're a power user that cares about micro managing your file system why is changing the setting so difficult? It's not like we reset your settings on updates. SRB2 is based off Doom Legacy so it pretty much qualifies. Turok 2 was contributed by Edward850. In any case if you don't need the plugins just delete the dlls. Doomseeker will not reinstall them automatically so I'm not sure why anyone would complain about this. Drag the "tiny-ass window" on top of the server list and enjoy your tabbed interface. Flexible docking has been there since the beginning and we even show this on the screen shot on the homepage. Default positioning was designed after Doom Connector/Skulltag Online.
  7. Could you be more specific? In more technical terms: The ZDaemon devs specifically worked to prevent Doomseeker (which that site uses to collect information) from querying their servers.
  8. Jaguar Wolf3D obviously uses the same resource management code as Jaguar Doom (not unlike how ROTT uses Doom WADs). The map format is the same as the SNES/Mac/3DO although if I recall correctly (been awhile) it uses 16-bit words instead of bytes. Someone would really need to dig in to claim that it's running on the Doom engine since it's going to look similar on the surface. Doom and Wolf3D aren't that far removed from how they handle actor logic (which is why ECWolf can easily map things to ZDoom concepts). The SNES version of Wolf3D uses a BSP tree for rendering, and I'm pretty sure I saw the same nodes in the Jaguar version. Obviously this change was done with research done for Doom so it should come as no surprise if the renderer has some similarities. That said it probably has the same limits as the SNES renderer. Ignoring the new renderer, similar to Jaguar Doom vs PC Doom the optimizations that happened going to the SNES largely comes down to reworking some formulas to use bit shifts and masks instead of division. So I don't really see a reason that the core wouldn't be the SNES Wolf3D engine. xttl: The folks behind Wolf3D Redux made a program for extracting resources from the Jaguar version. Might be a little more helpful. I do believe the compression is the same LZSS compression used in Jaguar Doom which is why Slade can open the wad.
  9. Awhile back I did make a start at writing a tool to turn a DECORATE dialect into Chocolate Doom's info.c. Might be useful for inspiration here: https://bitbucket.org/Blzut3/declarate/overview It's not complete, but it gets a decent ways in with 1,000 lines of code for parsing and output, and under 1,000 lines for the entire tokenizer which is ripped from ECWolf so has a few unneeded features (like sc_man style unquoted strings). The input file I was using can be found on the downloads page there. In terms of parser cross compatibility, like with ECWolf there are things that are valid here that would be invalid in ZDoom and vice versa. But any well written code (i.e. you don't go out of your way to do things wrong) would parse in both. There's details on that in the markdown file I posted on the downloads page as well. The idea of the project was to demonstrate that DECORATE can be a one to one mapping to vanilla structures. To that end it's definitely possible to finish it as a tool for building custom games on Chocolate Doom. But as a way of demonstrating a reference implementation of DECORATE as a candidate for a universal language, when Ran this by Quasar early on and he pointed out one of the key problems with it is that vanilla's model of inventory doesn't really fit the way that DECORATE wants to represent such things. (I'll let someone more intimately knowledgeable repeat the details.)
  10. My primary desktop specs are pretty comical at this point. Case: Rosewill R6AU6-BK Motherboard: Gigabyte P55A-UD3 CPU: Core i5 760 RAM: 2x8GB G-Skill Ares DDR3-2133 (Running at 1333 with tight timings) GPU: AMD (Sapphire) FirePro W7100 VRAM: 8GB GDDR5 Storage: Western Digital Black 2TB (WD2003FZEX) + Intel 530 480GB SSD Sound: Sound Blaster Audigy 2 ZS + Realtek ALC892 for extra line in Video Capture: Magewell Pro Capture AIO OTA TV Capture: ATI HDTV Wonder Optical: ASUS BW-16D1HT BD-XL Floptical: Iomega Zip 750 Floppy: Rosewill combo floppy and media card reader Power Supply: Cooler Master GXII-550W Display: 3x1600x1200 NEC 2090UXi (One with ELO Touch) Keyboard: WASDv2 Brown switches with Workman Layout Mouse: Microsoft Intellimouse 1.1 Primary OS: Kubuntu 16.10 64-bit Secondary OS: Windows 10 Pro 64-bit
  11. I can't tell if the OP is about Doom mods or real world usage. The last sentence about preferring "MIDI with the exception of some more advanced source port compatible wads" makes no sense since if the mod is targeting vanilla or Boom compatibility they don't really have a choice in the matter. If sampled music is used in source port mods it is usually Vorbis from what I've seen. Those that still use MIDI either do so out of tradition or because there's still a general stigma around having 80% of a download be music (although that has become increasingly less problematic). Also no idea where same quality at half size came from unless you're comparing a reasonably encoded Vorbis against 320kbps MP3s that are sold. They are usually pretty close in the tests that I've seen. Of course Opus changes that, but Opus is having the problem that it came onto the scene well after people stopped caring about audio size. Worth emphasizing this. Years back my brother and I standardized on Vorbis and when he got a Portable Media Player that supported Vorbis and FLAC the result was very significantly reduced battery life since the decoding was done in software for these formats. Since he used his media player a lot he switched to encoding straight to MP3. No idea if this applies to modern smart phones at all or not. These days I have everything in FLAC since I now have a large storage volume for them and re-encode whatever I want to take on the go.
  12. For what it's worth, a MinGW build just before the assembly code was ripped out works on Windows 98SE with KernelEx. Didn't test with KernelEx disabled, but I suspect a few of the recent commits need just a little tweaking. Still ran decent on a Coppermine Pentium III 1000EB. Windows 95 support was dropped after 2.2.0 since FMOD Ex doesn't support it and no one noticed it was broken for a long time. I suppose the OpenAL code could theoretically work on 95, but from what I understand an older version of MinGW is required and strictly speaking ZDoom doesn't officially support the OpenAL backend (GZDoom does).
  13. More importantly on the given example, the mod is designed for higher resolutions so the graphic in question is being scaled down to fit 640x480. There's not much that can be done to make that look better. Except perhaps having an option to render the 3D view at a lower resolution than the 2D elements.
  14. Don't know if it's quite comparable since the SNES version and derivatives had an automap, but I understand not wanting to use it.
  15. Thanks for the correction. I missed the commit where you added that to the CMakeLists.txt, so I thought we used the default. (I will note though that MSVC will still generate x87 instructions at times with the SSE2 arch, so "uses x87 instructions" doesn't say anything about the setting of /arch.)