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


  • Content count

  • Joined

  • Last visited

About AlexMax

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. I wouldn't even blame /r/doom for being what it is, it's just the sort of community you can expect when you have a forum software that gamifies engagement and is owned by a company whose job is to draw as many eyeballs to the site as possible, quality of conversation be damned.
  2. AlexMax


    True, but I think they're correct in the broad strokes. If you're writing a library, you are essentially trying to help solve other developer's problems, in which case a more permissive license is fine because we're developers helping developers and we're all in this together. Finished software, on the other hand, the calculus is much trickier. If you're doing it for the love of it, then fantastic, use whatever license strikes your fancy. However, if you ever have the expectation that what you're creating might be valuable, or even that you might want to start a business around your open source software, then I think that a permissive license would be an incredibly foolish choice.
  3. The format of the video uses extended snippets of the original, and the rebuttable can be expected to be longer than the snippet itself. Given the format, I would have been shocked if the rebuttable video was shorter than the original. 1.5x seems like a reasonable target to hit. Writing a script is hard. Editing is hard. From that CGP Grey video:
  4. GmanLives is a reasonably popular YouTuber, and when he releases a video that contains factual inaccuracies and misunderstandings that kind of eat away at the core point of what he's trying to say, I think that someone releasing a video that tries to clear some of those misunderstandings should be expected When people search for this video, if the actual video comes up #1 in search results, the rebuttable video will likely come up #2, and anyone who clicks on it might have some of those misconceptions from the first video cleared up. Ironically, Gman taking the video down means that anybody searching for that video will likely find DoomKid's, which only has the less flattering excerpts in it. I imagine that for content creators, getting stuff wrong in a video is never fun. However, I can't help but be reminded of this video by CGP Grey, who had a major messup in one of his recent videos and handled it about as well as you could expect anyone to: To summarize, CGP Grey made a big oopsie that basically torpedoed the main thrust of a video in a way that could not be salvaged. He took the first video down, put up a second corrected one, plus wrote this video that in a very contrite and humble way outlined his writing process and where he made the mistake. At no point did he try and explain away his mistakes with moon logic, and he also didn't delete the video while playing the victim.
  5. I mean, that's just my assumption. If you want, you could ask the speedrunners if they could find some use out of it. There's a forum for them here, and a discord as well.
  6. I've thought about this in the past, before realizing that the juice was not worth the squeeze. The people who use demos the most in 2020 are speedrunners. I'm not a speedrunner myself, but I highly suspect that most speedrunners would consider state-capture demos strictly inferior to deterministic ones in determining authenticity - if you can't trust the sequence of events in the demo, why not record an attempt live on Twitch instead? And once you cross speedrunners off the list, what do you have left? Attract demos, which only appear at the start when you're not actually playing the game, and have been disabled by ZDoom for decades anyway? Considering also that any new demo standard would then have to have WAD's that include demos with that new standard, with a lot of older ones being left out. I dunno, just doesn't seem worth it.
  7. AlexMax

    Diablo 3

    Oh man Diablo 3. The graphics and artstyle didn't bother me in the slightest, but everything else did. In particular, pretty much everything about the progression and loot system was a gigantic turn-off. As shipped, it was broken and turned progression into a brick wall until you visited the auction house. Unfortunately, what they replaced it was was merely boring and unimaginative and leaning on sets for gameplay variety, plus kneecapping player trading in the process - I suppose if they weren't allowed to make money on the auction house, nobody was. What's more, the decent writing of the second game took a nose-dive and replaced it with Deckard Cain being killed by a butterfly out of nowhere and Azmodan ham-fistedly crooning his villainy into your ear through the entirety of Act 3. There was a way to tell that kind of story artfully, and the way Blizzard went about it missed the mark. Path of Exile was the real Diablo 3 in every meaningful way except in name, which is absolutely crazy when you consider that PoE is free-to-play game from an indie developer that subsists almost entirely on cosmetic micro-transactions. When I can fire this up to get my ARPG fix, it would take a lot for Blizzard to coax me back to the Diablo IP.
  8. The whole reason I started getting serious with ASan was because of this talk, and even after that it took me a few personal instances of "Holy cow that would've taken me forever to track down" before I was a believer. Facebook is certainly not stuck in in ancient C++ land, and most of the listed bugs have nothing to do with the usual suspects of C cruft, but instead are ways that idiomatic C++ can be used carelessly. I suppose that I am fortunate to be in the position where I can always afford the spare CPU cycles to compile with it always turned on, so I'm never in the mindset of it being a tool to track down a specific bug, but instead an additional set of guardrails that I don't have to think about until I slide into them by accident and I think "Whew, glad I had that turned on".
  9. I find printf invaluable for analyzing program flow - like if I need to figure out what a set of nested for loops is doing, or figuring out what some confusing twisted maze of function calls is doing. That said, I'm all about those debuggers, breakpoints, and stack traces. They're simply too useful to ignore. But let me tell you, once you go ASan, you'll never go back... If this doesn't knock your socks off, you probably were wearing sandals. I think Visual C++ can do some of this with the debug heap, but I can personally attest that ASan has caught loads of bugs that the debug heap never found. I think Valgrind could do some of this too, but my memory is that it was tricky to set up and much slower. This level of verbosity has turned many occasional crashes and wild goose chases into "Oh, that's what's happening. Fixed." It has saved me countless hours and countless dozens of strands of hair on my head. Debuggers aren't modern tooling by 2020's standards. Stuff like this is.
  10. I don't think that Lua's use of words to end blocks is a problem, especially because it nearly universally uses only a single one...end. Then again, as far as blocks go, BASIC's aren't terrible either, since it's nearly always END whatever. What I find most objectionable are inconsistent cutesy ones like fi and esac and done used by bourne shell - they're not even consistent. I also have no love for Python's indentation blocks, since they tend to result more crashes and unexpected behavior at runtime as opposed to a simple "Unclosed block" at compile time. If there's a problem with Lua, it's 1-based indexing, and I very much would have preferred if that misfeature wasn't baked into so many aspects of the language and standard library. it might have been a reasonable idea in isolation, but the problem becomes especially nasty when you start porting code from nearly every other language out there to Lua, it's a minefield for bugs and off-by-one errors. A damn shame, because nearly everything else about the language I find fit-for-purpose when it comes to embedded scripting languages, and whatever other gripes I have with it are mere bikeshed-fodder. I was looking at Wren as an interesting alternative embedded language that prioritized speed and had braced syntax, but the original maintainer became busy and it's only recently that a new set of programmers have started committing to the language regularly.
  11. There are a couple of features from C++98 that I missed, but many more features I coveted were from newer standards Besides, the reason I stopped work on the project had nothing to do with C - the lack of classes and std::string was a minor inconvenience, but a manageable one. Usually when a device is jailbroken, if Doom is one of the first things ported, RetroArch is usually not far behind. That being said, it's more than just retrocomputing. A friend of mine puts food on the table writing C for embedded devices, and from what I've been able to make out C++ is still not common in the areas he works in.
  12. Right, but for my engine, the goal was to be compiled as both an SDL app and a RetroArch plugin DLL, and RetroArch runs on all of these platforms. If wanted to be portable, I only had two options - ANSI C or C++98. I suppose that if you are 100% sure that your program or library will always be compiled with a C++ compiler from this decade that is relatively free of bugs, then sure, I can see how the case for C is pretty much nil at this point.
  13. Fair warning, I currently only write C and C++ for hobby projects and contract work. I've "known" C/C++ for a while, but a year or two ago I started a hobby game engine in C from scratch, and I actually found that the language was overall quite pleasant to use. However, there were certainly some shortcomings to it. Lack of spans. A pointer/length combo is such a useful construct that forcing me to write out the struct by hand was quite irritating. Spotty availability of useful standard library functions. I shouldn't have had to shim useful things like reallocarray and asprintf. Lax implicit casting rules, and implicit function declaration. This is something that bit me more often than I care to admit. Thankfully, GCC has the ability to turn warnings for these into errors, and once I did the vast majority of these problems were taken care of. Strange rules about casting function pointers that everybody ignores but still shows up with an undefined behavior warning. Groan. Lack of generic types. I actually didn't need this as much as I thought I might (except for spans I guess), but it'd be nice if there was a hashtable built-in, instead of having to bring in khash, that BSD hashtable, or writing your own ad-hoc hashtable with a copy-pasted djb2 for the billionth time. Macros. On one hand, they help shore up some of C's weakness. On the other hand, good grief they're a nightmare to read and debug. The ability to do init functions without resorting to goto fail would sure be nice. Something like Go's defer. Building cross-platform software is headache-inducing. I am much better at CMake now than I was before I started, but it wasn't easy. Thing is, for all the issues I have with C, I'm also not enamored with C++. It is a vastly more complicated language and while some problems from C are resolved nicely, it introduces its own brand of paper-cuts and misfeatures, continues to have strange omissions from the standard library relative to how popular it is, balloons your compile times, and sometimes the decision-making process of the standards-committee can be facepalm inducing (I'm thinking of you, std::embed). I do write C++ for some things, despite its flaws, but I do wonder if there's a better "better C" out there than C++, that balloons the complexity only slightly. Zig is currently on my bucket list to get to eventually. Rust is also on my list for different reasons - if I have to wait for my program to compile anyway, at least give me some carrot instead of all stick. EDIT: Also, if you have the ability to, yet are not using address sanitizer, you seriously need to start yesterday. I thought I was pretty careful when I started my hobby game engine, but ASan humbled me countless times and I can't recommend it highly enough. I don't think I'd be working on doom ports again without it.
  14. AlexMax

    Do you use texture filtering? Why or why not?

    Oh absolutely, you like what you like. I just think of it more like what's the better default, and since Doom hails from that era of unfiltered pixel art, no filtering is probably the better default.
  15. AlexMax

    Do you use texture filtering? Why or why not?

    The art has to be made with texture filtering in mind. For example, if you turned off filtering on most N64 games, you would end up with gigantic pixelated soup that doesn't look flattering at all because the art was designed to be filtered. Doom is like that going the other way. Doom actually hails from that exact era of gaming.