Graf Zahl

You'd have to run the tests manually, so it's probably not worth doing it on non-Windows systems. What kind of graphics card do you have?

Since GZDoom recently added a new low end GLES2 render backend we are currently running a benchmark test to see how this code works on different hardware. So far we got good coverage for everything from OpenGL 4.0 and upward. What's currently missing is some results from vintage GL 3.3 hardware, i.e. Geforce 8xxx, 9xxx, 1xx, 2xx series or AMD 4xxx-6xxx. Since this is the primary target of the new backend we really need some numbers there. So if there's anyone here interested in helping, please visit https://forum.zdoom.org/viewtopic.php?f=49&t=73109 run the benchmark and then post the numbers, either directly in the benchmark thread or here.

Actions that take weird parameters mostly, and some redundant ones postfixed with Times8. Since it had to shoehorn things into 8 bits many values have to use weird multipliers to get a usable value range. Unfortunately there's not much that can be done about it these days. Someone has to make it work first. I was just saying that it might be easier to extend the engine to support Hexen specials, including the full set from ZDoom, than the editor.

Should that ever be done it should of course be a game-independent layer that carefully merges the features of all games. TBH, in that case you might just incorporate ZDoom 2.8.1's play code with some adjustments to strip out the problem parts and pure modding features. However, if you wanted that it might make more sense to just fork ZDoom, and develop a demo-centered port from that - I do not really think that this would really make sense for DSDA. There's really no need for that anymore. DEHSUPP has nothing to offer DSDA cannot already do with its unlimited actors and states. The whole point of it is to map additional content into the modifiable set Dehacked can use - in case of ZDaemon that mainly means accessing Heretic assets (AFAIK Hexen wasn't even finished when it forked off.) The main issue with EDF is that it is an all-in-one solution not just for new actors but for all kinds of resources. It may be a bit too complex. DECORATE as-is also won't be the right solution as it depends on some of ZDoom's internal workings. If we ever get a high level definition language it might be based on DECORATE's syntax but be something a little bit different to better match the underlying architecture. Nah, it doesn't work that way. Hexen ACS has one major limitation (special arguments are bytes, in ZDoom and Eternity they are full ints - you'd need that for UDMF!) and this has led to some ugly design in Hexen and early ZDoom days. I wouldn't want to see this mistake repeated. Of course you need the original ACS VM for Hexen demos, but I wouldn't use it for expanding the engine, it's just not good for that. While these namespaces were defined, I do not think that any tools exist that support them, so it may actually be a lot easier to extend the action special set by ZDoom's types and have full feature support for Hexen format specials instead of hoping for the tools to catch up. You'd need the new namespace because the Doom namespace has been explicitly limited to Boom line types. It is essentially feature-locked. If you want to extend it you need a new namespace. But then I'd name it by the feature standard it wants to support, not "PrBoom+". ;) I think you got that right - it is mainly two things: 1) a rendering trick with not drawing the sky over two-sided linedefs. 2) using scripts to move the sectors around and change their textures. I wouldn't want to subject any mapper to such an approach. It also needs a bit support in the renderer to not glitch out which would most likely make it a no-go. Neither do Boom's fake bridges so there's nothing gained, nothing lost. That's something that's surely doable and not even that much code to add. I'd list this as one of the more useful things an MBF22 standard could add.

Bridge things require proper height clipping against sprites. This does not exist in any of the more traditional ports and surely won't be added because it'd essentially a complete second path for collision detection that's more like ZDoom's code (also used by Eternity when playing advanced content) I honestly do not see this happen for a port like DSDA.

Ah, now I understand. The seeker code works so that if a homing missile is within the target's z range it won't affect its vertical trajectory, even if that means it can hit the ground or ceiling instead. This is actually a vital part of how a player can evade seeker missiles. ZDoom ran into the same problem a long time ago. Here you can find some info: https://forum.zdoom.org/viewtopic.php?f=7&t=25534&p=487350 This problem was ultimately resolved by offering two seeking modes - the one present in Heretic and one that is a bit smarter and does alter its vertical trajectory to be more precise. Just doing this unconditionally adversely affected Heretic and had to be reverted again. I think what DSDA should do is copy that functionality and offer both modes as both have their use.

The main piece of work here would be backporting a huge number of line types from ZDoom because Hexen itself is missing a lot of stuff Doom uses, but the basics are already there for Hexen and it shouldn't be too hard to reroute the code as needed. Of course Hexen's ACS interpreter is ill suited for modern use of ACS so it would make sense to borrow one either from ZDoom or Eternity to get a full feature set. The homing code tries to home in on the target's center. Yes, this can occasionally mean that a target is harder to hit with a homing missile because by trying to home in it hits some obstacle instead. But that's an issue with real-life homing missiles as well. If you have a straight line to a non-moving target a direct attack will always be more effective because nothing can make the missile go off course.

It may make a little sense to give other port developers a bit of breathing room to catch up. If you go too fast you may lose some here. Also, before adding any more features, let's please consider adding a higher level actor definition format to make use of the unlimited entries to all these lists. If you add more and more stuff to the engine this may later become harder than necessary because it needs to consider all that stuff.

While I have little doubt that there is a correlation between CO2 and global temperature changes I surely have my issues with the climate change activists. Like everybody pursuing a specific agenda these people will conveniently ignore everything that may harm their cause and overemphasize the effects of what they want to be changed. Of course the global change of temperature was not such a smooth curve as being presented in that cartoon. That's simply not how things work. Logically this also means we cannot conclusively tell whether the current spike is an aberration or something normal. The actual problem is that once we *can* tell, it'd be too late to change course.

You sound like a typical anti-nuclear activist who does not know how things work. While there are legitimate reasons to be concerned, none of what you say is true but is commonly used by activists to spread FUD. Tell that to all the people who work there or the tourists who routinely make a visit. And all the wild animals that are thriving in the area. It's only the immediate vicinity of the reactor that's sufficiently contaminated that prolonged exposure is immediately hazardous. The operative term is "prolonged exposure". You can spend some time there and not risk your health - what is not advisable is to continuously live there. Let's also not forget that more than 30 years have passed since the accident - the two most significant contaminants have decayed by half already in that time. BTW: https://allthatsinteresting.com/chernobyl-atomik-vodka

You know, much of this reads "too good to be true". There's so many 'if's involved here that the ultimate outcome is highly uncertain. In any case, most of the values mentioned here are purely theoretical, we'll have to see if they can manage this kind of efficiency. Actually, no. Most of the hate is fueled by activists with a diffuse fear of radioactivity and often little knowledge of what it is really about. Here in Germany these have such widespread support that even engaging in a reasonable discussion about better ways to use nuclear power has become impossible. That includes Thorium and fusion reactors. I agree with one of their views, though: The current Uranium fuel cycle is not future proof. It creates way too much dangerous waste and requires resources with limited supply, which would last for decades rather than centuries if current rate of consumption continues, and on top of that is accident-prone with catastrophic worst-case scenarios. But with all that justified criticism, these people have all but managed to prevent research into better alternatives here. Actually, the next longer lived relevant isotope with a relevant fission yield is technetium-99 with a half-life of roughly 200000 years. But since the half life is 10000 longer the activity is 10000 times less and with the amounts released into the environment not a major issue. It's also an element that has no biological role and is therefore less dangerous than the two main contributors of radioactive pollution with a half life of roughly 30 years each. So yeah, the 20000 year thing is a lie. But you know, it's easy to lie about things where 99% of Humanity has no deeper knowledge about the subject matter. Like I said before, a lot of the pollution here is generated long before the fuel is put in a reactor. Mining, in particular when done in less developed countries, often does not properly dispose of this waste so a large part of it enters the environment. For Uranium 238, the longest lived products aside from Uranium 234, which won't be separated by purification, have half lives of 70000 or 1600 years. Equally bad is that one of the decay products, Radon-222, is a gas which can diffuse into the atmosphere and spread radiation into other areas. For Uranium 235 things do not look much better as its longest lived decay product has a half life of 30000 years. Oops. This waste will be toxic and extremely dangerous for a very, very long time. For comparison, the longest lived decay product of Thorium only has a half-life of 5 years, meaning that this waste would be safe within a century. Which brings us back to my earlier "too good to be true" statement about using Thorium for energy generation.

Mainly that it may take time to get this ported to other ports, actually. For GZDoom this may be a bit tricky due to how it handles actor definitions. There are no static tables, everything is done through ZScript and DECORATE. Dehacked is just a postprocessor of the already defined data and operates under the assumption that this data is finalized and can use some static lookup tables to address the data to be edited. Which with this extension it isn't anymore. It's surely all doable but not a trivial extension of what's there. I cannot say how this may affect other ports, some may have an easier time, but some may even face more difficulties, depending on how they work internally.

Uh, sorry, but no. Fission does not work like that. Size of the fragments is random and no matter what you use as your fuel, you'll always end up with a mixture of the same longer lived nuclides. You may get less of some of them, but you'll still get them.

Oh my. Remind me to nominate him for the Darwin award when he finally dies - which may take a few months or years depending on the substance and the amount he consumed. Like this guy: https://en.wikipedia.org/wiki/Eben_Byers

Well, obviously. Still, some people try to pass it off as a 'clean' source of energy, which it clearly is not. And yet they bet on another resource that is limited to avoid doing the needed research into forms of energy production that are actually sustainable. The only way this can happen if the available coal resources are no longer exploitable so coal becomes very expensive. But here's the thing: Available coal resources will last a lot longer than available Uranium resources. So it'll never happen.

It's ironic that everybody here seems to ignore the cost and dirt that gets produced to even get the Uranium into the reactor. Of course this is often done far away from the places where the energy is consumed - apparently ignorance is bliss. Uranium mining is an extremely dirty business that releases large amounts of radioactivity into the environment. Uranium enrichment is also a very dirty business it deals with extremely toxic substances that often get left behind because proper disposal is too costly. Also, disposal of spent fuel is still an unsolved problem and reprocessing also releases a lot of radioactivity into the environment. So yes, the reactor itself is mostly clean (as long as it is operational - after that it will also become a liability) but the entire chain of production is certainly not. Of course the producers lie about that. They want to take the money while leaving the problems to society. Last but not least, Uranium is, just like fossil fuel, a limited resource. It may give Humanity 50-100 years of breathing space until a better alternative is found, but putting all eggs in this basket is just as short sighted as continuing to burn coal.

The rules here come directly from how Doom Legacy implemented its 3D floors: - inside top and bottom flats are only being rendered if there's a gap to the real floor or ceiling or a neighboring 3D floor - if both planes match up precisely the inner one will not be rendered. You may be right that it never was officially defined, but this is really the only way it can work as intended.

Got it. Although it was a lot of work to get this supported in GZDoom I think it's complete now. Just have fun looking at that mass of code once I commit the last part later today - the flag stuff is more than 300 lines of code, not to mention the changes elsewhere... :D

Ah, ok, I missed the part where the flags are being translated. It was a bit off the path where I was looking. This already clears things up a lot. Seeing how your checker works, I don't think you can simply go 32 bit, as you want to check the higher bits as well. That just leaves some of the flags in the first word No idea how you want to handle it. Currently the args array is 'long', which means the size is not consistently defined - it's 32 bit on Windows but 64 bit on Linux. If it's supposed to be 64 bit it needs to be 'long long'. Considering how your code performs the checks you definitely need 64 bit words here to do it right. But the flag functions truncate the value to 32 bit, losing all the upper flags, even if the args were 64 bit so this definitely needs to be fixed. Plus handling MF_NOBLOCKMAP and MF_NOSECTOR properly. AFAIK this can cause crashes if you clear these without unlinking the actor in the process.

As I am currently implementing the standard in GZDoom I'd like to give some feedback. The vast majority of features was no problem, but there's one thing in here that I have to consider a major portability hassle for an open standard and that's the 3 functions for setting and checking the flags (A_JumpIfFlagsSet, A_AddFlags and A_ClearFlags.) Here's a list of problems with this, some are only relevant for ports that changed things under the hood, others are general issues, applying to all ports: * the set and clear functions make no checks for special flags like NOBLOCKMAP and NOSECTOR. Just flipping these will most definitely cause problems with actors not being unlinked/relinked into the proper chains. * No checks are being done to mask out undefined/non-universal flags. It just performs a binary comparison of the flag words, requiring each port which wants to implement this feature to replicate these words bit by bit. As an example I'd use MF_SLIDE. ZDoom, for example, removed MF_SLIDE long ago as it was not used for anything useful. Another one would be MF_TRANSLUCENT or MF_TRANSLATION. Again, this is not how more advanced ports would handle translucency - it's very limiting and if a port handles this differently, having these flags among the checkable ones may be a major issue for robustness, resulting in undefined behavior of the A_Jump... function. * The args are only 32 bit so this covers all the Heretic flags in the second flag word but only half of the MBF21 flags that would be of actual interest. It also misses several important high flags in the first flag word. With this in mind, is there still a chance to revise these 3 functions so that they work in a truly portable fashion by only allowing to check a well-defined set of flags that other ports can easily implement without having to compromise their implementation of the underlying features - and by making sure that they can actually access all relevant flags and not miss a significant portion by not allowing to check the higher bits?

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.