Graf Zahl

Members
  • Content count

    10340
  • Joined

  • Last visited

About Graf Zahl

  • Rank
    Won the popularity contest
  1. Hardware rendering performance for voxels strongly depends on graphics hardware. On more performant cards they actually never drop performance one bit. But yes,on older cards with weak vertex throughput they can cause quite a drag.
  2. Well, that's life. Each computer is different. Many monitors are calibrated differently so no serious mapper can expect that things will look identical everywhere. Ultimately it's supposed to be fun. Too bad that for some people even other people's fun is being considered serious business... :(
  3. GZDoom can play large parts just well. But since you did not even bother to post your system specs, there's no way to help, never mind that your post is quite off-topic.
  4. Same here. It may be that the gradients have been tweaked a bit to look better with software rendering but in the end it's still 8 bit limited. I clearly prefer ther greater color fidelity of true color rendering over such apparently minor optimizations which most people will probably never notice. I for sure didn't when I tried it with software rendering to see what's up. That said, I haven't been using the software renderer for actual playing since 1998 or so and if it still was the only choice I wouldn't be here anymore.
  5. No, the main reasons are support for slopes, 3D floors, portals, Heretic and Hexen features and other options ZDoom provides. If you compare some of the core movement functions you'll see that ZDoom's variants are a lot larger because all these things need to be checked as well. And even though for single actors it's not noticeable, when having 10000 monsters and their projectiles active at the same time, stuff will just add up.
  6. Wrong, actually. In the original code they are explicitly being excluded by type - which means that if you reshuffle them via Dehacked they will become vulnerable. In ZDoom it's not the BOSS flag but the NORADIUSDMG flag that handles this.
  7. Manual reloading is a stupid idea, if you think about it. Good solutions would mean that an empty weapon would automatically reload once it's empty and you try to shoot again - but pressing some random key on the keyboard totally disrupts the flow of the game, unlike reloading a real weapon. This is a classic casr where supposed realism actually thwarts the intended effect. That said, I do not play games where clumsy weapon reloading is part of the 'experience'. It's a killer criteria for me.
  8. The problem is that if you overbid too much there's a high risk that people will test your limit, resulting in higher than necessary final prices.
  9. Tha Actually that happened a lot to 60's and early 70's TV content. A lot of stuff that some people wish they could get back has been lost forever because it was considered worthless.
  10. The bidding looks perfectly legitimate. I do it all the time to avoid bidding too high. Better increment in small steps until you reach your limit, so that when you finally catch up you only are s small bit in the lead. The entire thing still looks like a scam, though.
  11. It doesn't support #includes but you can put multiple ANIMDEFS into your mod.
  12. It seems you do not really know how modern CPUs work. Windows reports CPU load across all cores, so on a 4 core CPU with hyperthreading one core equals 12.5%. Now for the problem: Doom is a deterministic engine, i.e. all operations need to be run in sequence. This unfortunately limits the game to one thread, i.e. one core and will most likely hover between 12.5 and 20%, depending on how many threads other subsystems use. And why is ZDoom slower than PrBoom? Well, for the simple reason that the engine is a lot more complex than PrBoom or other more basic ports and has higher overhead for checking all those 10000 monsters.
  13. You don't. Unless you rewire the level transitions, you got a secret exit from MAP15 to MAP31 and from MAP31 to MAP32. And the game will simply end when finishing MAP30. All this stuff is hard coded into the executable so unless a port changes the setup it's set in stone. And no 'classic' port changes anything here.
  14. The reason for the glitches are not the actual rendering structures, but maps which abuse how they work, like missing texture areas getting filled by the adjoining flat and more importanrtly, how the renderer deals with unclosed sectors. Some of these effects are very hard to get right in a hardware renderer which needs to polygonize each sector's surface - which in such cases is often not possible.
  15. Endgame=true should end the game. End of story. Whether it's broken in my current PrBoom repo is irrelevant to that. This is a bug that needs to be fixed when I find some time to debug it.