• Content count

  • Joined

  • Last visited

About Maes

  • Rank
    Here's an old post I made on the subject,
  1. Well then, at least for GPU-accelerated ports, it seems that big sprites are not a problem. That being said, there's something comical about those screenshots....
  2. But does it make them more versatile than the Spider Mastermind, that is the question... they don't normally shoot, but at least they don't take a crapton of space.
  3. Most versatile: Revenants, just like Imps but tougher and more annoying. They are like that "tough skinny motherfucker" kind of enemy in brawling games -they come by the truckload, are as common as garden weeds, yet you can never truly underestimate them or dismiss them with no real danger to yourself, and the damage they can do individually is always significant. Whether they gang up in your face, throw you a sucker punch here and there or even shank/backstab you (with a rogue homing missile), you must always be on your toes when those guys are around, which may mean "all the time" depending on how liberal their usage is. Least versatile: Commander Keens, obviously. They are so un-versatile that you can only use them in one specific map slot, literally (well, at least if you want their death to mean something....)
  4. Well, so far everything seems to point towards that direction, so the only ones potentially affected are Chillax BFG spammers -and those couldn't care less about the sprites being hi-res In the first place. On a completely academic note, just how big are those hi-res imps?
  5. My point was that with DOR (which has no more than 500 monsters all in all) you never fight more than what, 50 at a time? That's nothing for Doom, even if way more than that may be active "off screen". It's also true that with NUTS.WAD-like monster counts, the gameplay code can be just as "heavy" (if not more heavy) than the rendering one, but the latter one depends on many more variables: type of renderer, display hardware and driver (if it's a HW accelerated port) etc. Don't forget that, at least in the past, it wasn't unusual for prboom+ to mop the floor with glboom+ in timedemos, simply because the hardware couldn't stand being "zerg rushed" with tons of individual draw commands.
  6. TBQH, the used examples (except the 120 imp one) don't really test what they are supposed to test. They look like Doom 4 or any other modern "Doom-like" FPS, at best. High monster count for a modern FPS, but low compared to what even the most tame slaughtermap can throw at you. Dawn of Reality's monster count is really low for a map of that size, and in my book it would not classify as "slaughter" in the classic sense. Try going straight to NUTS.WAD or any of the CHILLAX.WAD maps and see what happens then.
  7. Well, if it takes him all of 30 minutes tops to records such a speedrun, he won't waste much time retrying it 2-3 times in a row ;-)
  8. All these hand microoptimizations and trickeries are mentioned further down in the thread I linked to. It goes pretty deep, almost esoterically so :-) The 64/128 KB limit is somewhat of a confusion caused by Boom extending it by using unsigned pointers into the blockmap, but even with that extension it's very easy to render useless. Just having a blockmap of size 256x256 means that you can't store anything in it but pointers to...well, nothing, and with the vanilla limit of 64 KB it'd be even worse.
  9. IIRC, _bruce_'s truecolor Chocolate Doom branch did all lighting and color manipulation in HSV or HSL color space -changing the light level of any pixel or texture/sprite was a breeze, as was adding colorization effects, however other effects like transparency were much more expensive to do (no Alpha in HSV space!) and everything required converting back to RGB for rendering. In Mocha Doom I used a mixture of 8-bit textures and a series of true color palettes precalculated for each lighting level -there could be more than 32, and in theory there could even be separate sets of palettes for specific sprites or textures, somewhat breaking the limitations of strictly 8-bit resources.
  10. There are also more subtle practical limits like the blockmap limit: if your map extends more than 256 blocks (1 block =128 units) in either direction, many regular collision and navigation mechanisms will crap out, unless the port fixes that by using a blockmap extension to 512x512. Another limit is that if the blockmap's size ON DISK exceeds 128 KBs, it will also crap out and will not be read reliably. This can be fixed by a port that automatically generates the blockmap internally. In practice, you want both fixes to the present at the same time. Here's an old post I made on the subject,
  11. What about sprites? Also, is lighting computed in real time or are there precalculated copies of the same textures at different lighting levels? Certain effects like overall brightness are not cheap to apply in RGB space, if that's what the renderer uses.
  12. Heh, so they started complicating GPUs with NUMA now? Wow. I am not very familiar with GZDoom's truecolor software renderer, TBQH. Does it support truecolor resources as well, or only 8-bit ones?
  13. Of course, all this talk about cache lines etc. presumes that hi-res sprite support would be implemented with a software renderer, which is certainly not the case today, at least not with truecolor resources. And realistically, any future ports supporting it would do the heavy lifting on the GPU, so we're really looking at GPU architectures here. There you have no caches, no NUMA, only -hopefully- very wide and independent memory channels, and any increase in the size of assets/textures will have an immediate impact on used memory bandwidth -hopefully way below what the hardware can handle. Now, if you manage to pair GPUs with continuous main RAM access....then you get the worst of both worlds.
  14. So, pretty much every official console port of Doom back in the day was dogged either by technical limitations, or poor design decisions, being rushed, or a combination of these factors. Even later official ports like e.g. Doom '95 or the Mac ports weren't very polished, while even the "Classic Doom" included in Doom: BFG Edition leaves a lot to be desired. Doom 64 seems to be the one brilliant exception, and maybe the PSX port (still pretty cut down, but with enough exclusive content/features to make them stand on their own). I dunno, but for a game that pretty much had gained undisputed "legend" status already in its heyday, Doom sure seems to have gotten the short end of the stick when it came to ports. Not in terms of numbers/quantity, but in terms of quality. It's almost as if they wanted to get it out of the window....quite literally.
  15. No wonder, since along with the SNES version, it's the only "official" port not using the actual Doom engine.