Jump to content

Blzut3

Members
  • Content count

    634
  • Joined

  • Last visited

Everything posted by Blzut3

  1. Starting using Eternity, initial thoughts

    midiproc isn't built by CMake to my knowledge.
  2. Retro PC circa 93/94 help

    I'm not sure you followed what I wrote. You said that being able to rewrite a row in your preallocated table a "maximum of 4,000" times is unacceptable. My response is that if you took any modern SSD and hammered the same logical block you'd get several orders of magnitude more than 4,000 writes since you'd actually write to a different physical block each time the row was updated ergo the part of your message that I quoted was blatantly false. Or do I not follow your point?
  3. Retro PC circa 93/94 help

    I think we found your false assumption here. You appear to think that SSDs work like HDDs in that over provisioned space only gets mapped in when a cell dies, but the reality is that any SSD in at least the past 4/5 years is constantly remapping cells. Not only does this allow wear leveling to occur, but it also prevents the drives performance from degrading after you've written to it. Since there are several gigabytes of over provisioned space odds are there are enough precleared (garbage collected) cells to handle whatever write you throw at it. By the way this is also why TRIM isn't as important as it once was. Preallocate to your heart's content, but there's no direct mapping between block level sectors. So really you can look at it as "how much do I write per day" in gigabytes and find a drive that has an endurance rating that exceeds your write rate. Doesn't really matter what your access pattern is. Oh and database servers are a common use case for SSDs in the data center. These are exactly what people do with SSDs and I don't hear anyone complaining about premature wear out. Again I put a 0.3 DWPD 120GB drive in a machine used daily for web browsing 4 years ago and it's still going. These days I have SSDs in every one of my systems (including my retro builds thanks to IDE to SATA adapters (by the way StarTech's IDE2SAT2 works really well if anyone is looking for such a device)) and I'm not concerned about any of them, but I don't want to extrapolate too much from that since this only happened in the last 2 years. I do a lot of compiling, run VMs, and build multi-gigabyte disk images daily. I'm not trying to convince you to go buy an SSD, but I think your post is unfounded FUD. Especially the part where you advised against putting any user data on flash.
  4. Retro PC circa 93/94 help

    Your fear of SSD endurance is grossly overblown. While I'm not going to deny that hard drives can last a long time since I still have Maxtor drives and sub 1GB drives that work, the reality is that under non artificial workloads an SSD should last just as long. The normal high end drive is typically rated at 2-3 full drive rewrites per day for 3 years with write intensive drives exceeding 6 drive writes per day. Cheaper drives go down to 0.3 drive writes per day, but I don't hear people talking about how unreliable SSDs are so it seems that most people don't even hit that. So far the only flash I've seen wear out were removable flash (USB drives, compact flash, SD cards). These are generally made from significantly cheaper flash with very low endurance and cheap controllers, but I've only been using SSDs for 4 years. That said the first SSD I've deployed is a 0.3 DWPD 120GB Kingston drive that is used daily and still going strong 4 years later as the only storage in the system.
  5. 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.
  6. Usually symptoms like these are caused by the joystick being enabled.
  7. 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.
  8. Why Does Wolf4SDL's Controls Suck?

    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.
  9. Why Does Wolf4SDL's Controls Suck?

    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.
  10. Does anyone play besides bots?!?!?!

    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.
  11. Does anyone play besides bots?!?!?!

    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.
  12. 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.
  13. 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.)
  14. What are your computer specs?

    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
  15. .OGG files

    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.
  16. I thought zdoom was meant to work on windows 95?

    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).
  17. ZDoom and Zdaemon - questions

    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.
  18. Wolf 3d on an 8086

    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.
  19. what's the lowest system gzdoom would run on?

    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.)
  20. what's the lowest system gzdoom would run on?

    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.
  21. A word about dealing with problems in ZDoom

    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.
  22. A word about dealing with problems in ZDoom

    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).
  23. 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.
  24. 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.
  25. 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.
×