Graf Zahl

Here's the latest release of my PrBoom fork with UMAPINFO support: https://github.com/coelckers/prboom-plus/releases/tag/v2.5.1.7um The changelog can be found in the above link So far there's only a Windows 32 bit version because I am unable to create release packages for macOS and Linux, so any help here is welcome. This has been built with Visual Studio 2019 so there's no Windows XP support. Please report issues at the Github issue tracker.

I doubt it. The last time this happened for me was Caverns of Darkness. I thankfully declined when faced to play this with the semi-broken DOS EXE it came with. Fortunately I was able to come up with an alternative solution. Now what would a techically less knowledgeable user do if faced with a setup they do not like? Not even the best mod in the world would help if the obstacles are too high - and that's totally a subjective assessment.

No. My guess is that most regular people who want to play Doom on a modern system will Google for "Play Doom on Windows/Mac/Linux" and be guided to some tutorial to set up a source port - or use the Unity version right away if they do not own the game yet. DosBox is arcane for those who grew up on modern computers and have no interest in technical solutions. They may unknowingly use it if they get a predefined setup, but they most likely won't be able to create one themselves. But even if you gave one to them, the first question you are likely to get is "How can I set this to a higher resolution?" and they either stop right there or look for a better solution (read: Look for a source port that best matches their interest.) since the answer is "You can't".

I don't think that this kind of user will ever use DosBox and Doom.exe to begin with - they'd probably settle on something easier to handle...

I need the file you get when clicking on "Save Report to Disk..."

Please post the crash log. Without that we can only guess at what went wrong.

Sorry, Lila Feuer, but that's classic armchair advice you were giving here. Where I work there's one guy whose sole responsibility is to think up new test cases and run our software through all sorts of ludicrous scenarios. But he's doing nothing else the entire day, 5 days a week, 52 weeks a year minus vacation. But for something that's ultimately a hobby project on a limited time budget with too few people working on it that's totally impossible, even on a smaller scale. We inevitably have to depend on users to report when they see something wrong.

What can you do if nobody reports it for all the time...? I never noticed because I don't like playing the Cleric.

RNG tables were also changed in PrBoom. Funny that it is constantly overlooked that this change dates back to Boom.

What I'd like to see more than a Q1 port would be a Q2 port that takes an active effort to convert the game DLLs into a scripted language so that the game can live on without being inconvenienced by a binary extension interface.

Binary patches of executables always come with a risk, though, and that's not limited to exploits. Just have a look at Quake 2. Thanks to its DLL interface, any port switching to a different architecture other than 32 bit Windows is left in the cold with many of those old user mods which shipped their own game DLL but didn't bother including the source.

If it didn't "change any of Doom's internals" it would not work. The entire purpose is to do that! And in this regard it is completely irrelevant whether you apply it statically to the .EXE file or through an exploit at run time. Seriously, the only new thing here is the delivery method. Patching an executable to do thiings it was never made for is an ancient concept - remember Entryway's limit epanding modified EXE?

It's more a question of feasibility. The way this thing works you need to create machine code that's hardwired to the DOS EXEs intricacies. Trying to execute that code in a different context will be a gargantuan effort that'd only be worth it if there was a genuine gain. And a handful of projects isn't really it. My guess is that the scope of these changes will be on a scale where it is easier to reverse engineer them to source code (unless provided directly, of course) and integrate that code directly into the port or script it in a port capable of instead of trying to run the actual machine code.

Obvoiusly any port trying to support things like this would have to check for the overflow condition and deal with it on its own terms instead of letting it run amok on the system. But the real problem lies elsewhere. It would only work on x86 32 bit, but that's not really a future proof platform. So to support it on other architectures you need an emulator - but you not only need an emulator but a code checker that blocks malicious attempts to access functions and system calls that can cause real damage. It also needs total knowledge of where functions start, especially in cases where some jumps into the middle of a function are performed. The amount of work needed can quickly exceed any reasonable effort. So sorry for anyone dreaming of getting this to work with more modern ports: It won't happen.

No, the firestorm also was fixed recently, its parameters for radius damage were not correct.

I'm sorry to tell you, but you must really be imagining things here. I've run some tests on both GZDoom and Boom's RNG - same as in its child ports - in the past and while the actual sequences are not the same, the resulting distribution is very similar. It's both a lot more random than Doom's original one. I think what you really feel here is that GZDoom does not use a single RNG but hundreds - a lot more than even Boom and as a result you get poor sequences for some events. If you really want I can do a test build for you switching back to Boom's RNG, which ZDoom had been using in the beginning, and mapping all calls to a single one for SP games. It might be interesting to hear your impressions.

Here's the right place for making requests on those "lacking" aspects: https://forum.zdoom.org/viewforum.php?f=15 ;)

Although, truth be told, this had nothing to do with Build, but with a developer team that obviously - judging from a famous message - had problems getting along with the provider of their engine.

If you look at the entire Blood source you will see this attitude everywhere - the map format is different (hopelessly convoluted with bit fields for properties, also encrypted), the palette management does not use the standard features, it overrode several engine functions with their own, courtesy of the linker prioritizing their own content, etc. Although with the file system the actual reason was that GRP was added to the engine relatively late and since the Blood team had already set themselves up to use their stupid resource indices (another thing that makes it very hard to replace stuff) they just circumvented the GRP code, which admittedly was a piece of shit all of its own.

E1. The rest strongly suffers from the limited set of textures the game has.

The Microsoft model depends on local play, it's not just an interactive video stream. As such, it's a business model I'd find more interesting than buying renting DRM-crippled games but pay full price. At least it is honest about its intentions. Too bad then that the speeds that need increasing can't be. The problem is not a question of bandwidth - it's a question of how long a single bit from your system takes to reach the server, and like I pointed out, that's subject to physical limitations - the further away your server farm is from your customers, the longer the bits take to travel back and forth between your system and the server and the more lag the customer will experience.

Those people who, according to the industy, "have no need for a real computer". The story probably goes like "Hey, in order to play new games you constantly have to buy upgrades to your home computer. Why not come to us? - all you need is some cheap hardware that's capable of decoding a video stream." "If there is no market, we will create one." Sometimes there's a genuine Cloud-Cuckoo-Land mentality around there, it's very clear that these IT guys often have no idea how real people tick. I think a big part of the master plan is to take control of as much as possible before our dear politicians finally wake up and try to combat the monster the had allowed to grow. But seriously, there's definitely a market for gaming subscriptions. The problem is that streaming is not the solution for it because it simply cannot work due to the technical limitations.

Heh, yes, and it was inevitable that it totally sidestepped the one problem they'll never be able to overcome. Can't beat the hard limits of universal physics. What they totally forget is that unlike movies, gaming is a two-way affair - data goes in and out. With movies it doesn't matter if the data travels for a second or two, what is important is that you get an uninterrupted stream. But with games it is of the utmost importance that no time at all is lost for data transmission which is a physical impossibility. Yup, most definitely.

Typical hogwash. Like nearly everybody invested in this they ignore the fundamental technical issues. The only really interesting thing in that article was the statement about Apple who again abuse their power to block competitors, the rest was all the same type of pipe dream that seems to run rampant among these internet types who have no clue about the inherent limitations. The input lag problem is not easy to overcome - even with dedicated multiplayer clients of today you need movement prediction and other kludges to reduce its impact, i.e. you need a local client that know the game it plays. But with these services the client is merely a dumb terminal only receiving a video stream. As a result the lag will hit with full force and with long distance connections being a necessity here it should be obvious how this will play out. And these people may repeat endlessly that this can be overcome - it can't! This is bound by the speed at which information travels through the internet, which is finite (from what I read, roughly 200'000 km/s, 2/3 of the speed of light.) So imagine your server is 2000 km away. That will result in 1/50 s of lag (have to factor in both ways of travel!) that's impossible to remove - for gaming that presumably measly time can already become a problem because the game won't feel snappy anymore. Of course that time is merely the travelling time of your information. The data will get routed through multiple intermediate nodes that all add their own delays to this time so you'll never even match that 1/50th of a second. Not even the fastest internet connection in the world will be able to overcome a hard physical limit! So, you have to essentially keep your gaming server very close to your customers to make this work. Does it now become clear why this is a fool's proposal?

The current info is that this corruption only happens on NVidia with recent drivers and only on Windows 10. But so far no pattern could be recognized that may trigger it.