Blzut3

Members
  • Content count

    623
  • Joined

  • Last visited

2 Followers

About Blzut3

  • Rank
    Member
  1. 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.
  2. 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.)
  3. 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
  4. 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.
  5. 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).
  6. 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.
  7. 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.
  8. 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.)
  9. Most powerful AGP card is a Radeon HD3850 or HD4670 (similar in power, and the HD3850 has hardware double precision floating point for the 2 people that care about that on a legacy system). These are OpenGL 3.3 capable cards although the final driver for them is unfortunately notoriously buggy (for developers at least). The Geforce cards are only OpenGL 2.1. GZDoom is currently compiled for SSE2 CPUs (P4/Athlon 64 or later) so not out of the box. In theory you could probably compile GZDoom with MinGW and run it on one of these systems. Now the answer to "could you get away with it" really depends on a lot of factors including your exact definition of that.
  10. I do hope that this was aimed at kb1 and not me. If it was me, I will point out that my post contained no opinions or statements of preferences so none of it should have been surprising. With that said, since you asked, I do indeed believe that a formal BNF grammar could be made for semicolon-less state definitions. Requiring parens is the easy way, but I believe the four character restriction way could be done by making an action function name (and sprite names) be special token types with mutually exclusive patterns. Yes that would require certain tokens to only be valid within certain rules, and I can't say if Lemon handles that (haven't worked with it directly yet), but this is something that does happen in the C++ grammar (in that case keywords, but effectively the same thing). Properties also don't require semi-colons. ECWolf in fact accidentally has support for constant expressions in properties, which I didn't really realize I did until Woolie Wool pointed out that random() wasn't being random when used with the sighttime property (because besides damage every other expression would be statically evaluated). In ECWolf's case this is just utilizing the parsing rule for damage expressions so either the argument is a direct constant (which theoretically could be an identifier) or is enclosed in parens. ECWolf does still use the property definition during lexing to determine which form of damage to use, but also to handle integers vs strings (although it is capable of skipping unknown properties and flags). But I can't think of a reason why types couldn't be checked after lexing. ECWolf does of course require comma separated arguments and quoted strings like ZScript. Now I do see a good argument for not requiring parens to do constant expressions. In which case yes a semicolon is required. I'd be happy to investigate this if you don't have other objections. More interested in possibly getting rid of the semicolon in states since I think there's a little bit of elegance lost having them there. (I must say the DECORATE state syntax is a really really nice solution to defining state tables in my opinion.) The properties I don't really care about, but I could see it being helpful to transition people from DECORATE. I want to emphasize that the "deprecation of DECORATE" comes from the parser being a complete mess of backwards compatibility. The suggestion of using DECORATE as a cross port standard comes from the fact that its core feature set makes very few assumptions of the underlying implementation (it is possible to implement DECORATE as a compile time language for Chocolate Doom if one wanted with probably far fewer compromises than one would think). I don't think this would be possible with ZScript at least not without effectively limiting it to the feature set that DECORATE covers. I know Quasar has a list of reasons that DECORATE is unsuitable as a content definition language for a demo compatible source port. IIRC largely revolving around how vanilla handles pickups and how that interacts with DeHackEd. In this case the fact that DECORATE is no longer a moving target is of great advantage to others. The oddities don't really need to be fixed on ZDoom's end since well written DECORATE code would work in both a real parser and the messed up one that ZDoom has (see how ECWolf parses DECORATE differently but the dialect looks exactly the same if well written). The only thing the current parser prevents is new language constructs. So to be clear: If the community adopted DECORATE as a cross port standard and it was useful to add flags, properties, or action specials to facilitate this. I can't see why ZDoom wouldn't support them as well as long as it doesn't require new language features. Another way to think of this is to think about DECORATE vs DeHackEd, or UDMF vs Hexen format. (I'm going to avoid calling those features "deprecated" since it's such a touchy word, but I think the analogy works.) Also want to remind you that Vavoom implemented DECORATE among some other ZDoom compatibility features, so for awhile it wasn't strictly ZDoom and children.
  11. This may be strictly true, but ZDoom's DECORATE parser has a ton of inconsistencies which exist due to backwards compatibility with a time when ZDoom's tokenizer was less than adequate. For example if your state doesn't have an action function then ZDoom requires a new line to terminate it. So not only is it questionable to do it, but it's actually quite a pain to do it in ZDoom as it stands. Of course well written DECORATE as-is can be parsed with a one token look ahead parser, and ECWolf does this. The only ambiguous point is an action function call with no parameters. This, however, can be resolved by not allowing 4 character action function names (what ECWolf does), requiring empty parens, semicolons (what ZScript is currently doing), or new lines (what ZDoom kind of does for DECORATE).
  12. What's different about the video? Am I less qualified to run Chocolate Doom then Linguica or something? My point is that most of the "fish-eye" effect you think you're seeing is because you're not restricting your physical FOV and the side views are not projected correctly (due to limitations of 2D video). In reality if you have the right setup the distortion is *small enough* that my brain at the very least is able to ignore it. That is: looking through the edge of the cube looks more or less like looking through the edge of a cube. This can be seen in my edited images (removing monitor bezels) where outside of a slight angle change at the seam the screen shots look pretty normal.
  13. Tested this myself and it doesn't look to be anywhere near as bad as you suggest. There is a somewhat interesting phenomenon though, from a distance it looks pretty distorted, but when I put my head awkwardly in the middle the distortion goes (mostly) away. Took some sample pictures: http://maniacsvault.net/loosefiles/chocolate-multihead/ Not perfect, but definitely serviceable if one can somehow meet all the requirements of the setup. Edit: Added some edited images removing monitor spacing.
  14. This. Not sure why people think Chocolate Doom's rendering is distorted since if you had your monitors perpendicular to the primary and you sat in the middle of them (really awkward setup I suppose) it should look fine.
  15. I don't have a PS3 controller on hand to confirm, but I'm pretty sure this is abstracted away either at the API or hardware there. I don't recall ever having trouble maxing out both the X and Y axis on any of my controllers regardless of what shape the input area is physically. Maybe the Xbox controller and/or Xinput is different, but I have no such controller so I wouldn't know. In fact not long ago there was a controversy going on over at Zandronum since some players discovered that gamepads can auto SR50 and turn at the same time, so some people started hacking their binary to compensate with keyboard+mouse controls. End result of course is we had to nerf the game pad controls.