Cacodemon345

https://github.com/jhuber6/doomgeneric/tree/amdgpu

Is there any plans to address game controller force feedback in this specification? This may sound like a rather odd question, but KexDoom port does implement controller force feedback for weapons at least, and Doom Retro does it as well. At least addressing this in the specification would be better for all source ports still lacking implementation for it, in addition to unifying it, since this topic isn't mentioned in the specs at all.

Can an explicit "levelnum" field be added to UMAPINFO for the ID24 spec? The currently-undocumented method used to determine map numbers is very suboptimal. Episode fields shouldn't restart the map number from 1 and it should be determined from checking the lump name of the map specified if there's no "levelnum" field.

No BSP-based Doom hardware renderer does so either. Not sure why you're bringing this up. Tell us how Hellion does it (especially with OpenGL 3.3) and I'll be happy to be proven wrong. :)

The tranmap handling as described here in the opening post still isn't friendly with hardware renderers IMO (although colormap rendering is). The reason is sampling from the "background" image is not as easy as it may sound. Most desktop GPU hardware are incapable of sampling the framebuffer in a fragment shader (or even if possible, without serious performance hits and/or introducing design issues on existing hardware renderers). The only other alternative involves making a copy of the image after each draw call which is sure to destroy performance. Even if such alternative were invoked only when encountering TRANMAP mobjs, it would still significantly slow down the renderer on maps featuring a large amount of such mobjs. It may work well for software renderers, but it will not be friendly to any hardware renderers that does not target solely non-desktop hardware, including the ones in DSDA-Doom and GZDoom. What should be done is abandoning this non-futureproof idea altogether and instead going for a comprehensive solution that is compatible with most hardware renderers. TRANMAP's arbitrary nature makes it impossible to support properly, and even with various Vulkan/OpenGL extensions it would still remain impractical to support. It's better to stick to alpha levels (as I mentioned in the original post) and what can be reasonably and easily adapted by hardware renderers (a good starting point is this.). I'm sure colormaps to deal with various blending modes can be reasonably generated on-the-fly.

The programming of the video card is not done properly causing this to happen.

https://blog.playstation.com/2024/09/03/an-important-update-on-concord/

Read the description (and the subtitles if you can) in the YouTube video. I don't know if this was covered before but here it goes.

It's not called "castmembers" in the reference code; it's actually called "castanims". And from what I managed to make sense of it, it is an array and for each object, the members are: "name": String. Can't be empty. Displays name of the monster in the cast screen. "aliveframes": Frames describing the animation when it is playing normally. Can't be non-array or empty. "deathframes": Frames describing the animation when it is killed and about to progress to the next cast. Can't be non-array or empty. Each frame is an object in at least either array. Format for the "frames": "lump": String. Describes the image lump to be used. Can't be empty or null. "tranmap": String. TRANMAP to use for the frame. Can be empty or null. "translation": String. Translation to use. Can be empty or null. "flipped": Boolean. Indicates if the image should be horizontally flipped. "duration": Number. Indicates duration in seconds the frame should be displayed. "sound": Number. Sound ID to play when this frame is displayed.

For the tranmaps, a mandatory lump describing those with their alpha levels should also be added since those too are poorly handled by hardware renderers. (I still sincerely hope GooberMan reads this as well after all that happened here).

This seems like it would invite trouble for source ports using hardware-accelerated hardware renderers supporting HD texture packs since those are poorly equipped to handle colormaps. I'd suggest adding in an additional mandatory lump describing colormaps and their mapping to RGBA color values to deal with this problem.

I'd argue it's because of the latter, because those modders can at least thrive knowing that Bethesda (or at least Microsoft to an extent) is openly pro-modding. Modders wouldn't be able to ever claim something like that with any AAA games from a company with an at-best neutral and at-worst very negative stance on modding.

...and these kinds of stuff getting consistently regurgitated here right in this thread is why nothing will ever get done. 10+ pages have pretty much gone by without any objective assessment on the spec itself. And the only thing I see repeating is the same old anti-corporate concerns that already got addressed. Is it genuinely that fucking hard to actually give objective assessments to the spec and actually come to a hard, set-in-stone agreement on potential actions if Bethesda/id/Microsoft starts fucking around further?! This shouldn't be that big of an ask at least.

I honestly do not understand how Goober's post can be genuinely interpreted as being "blackmail" in any sense. It makes no sense. Kraflab's mentioning the Discord logs can be interpreted as a veiled attempt at blackmailing however. He didn't directly blackmail, but he was pretty indirectly inviting everyone on his side to search for those conversation records and post them here. At least that's what I understood.

Isn't the whole thing about PDB files that those are not meant to ship in final production builds? I don't see what's there to complain about it; nobody bat an eye about GTA V, Skyrim or Fallout 4 games (or even any reasonably complex AAA games non-Bethesda, in case people think I'm somehow a Bethesda fanboy) not shipping with those despite being much more complex. You mod stuff via unofficial means, you are left completely on your own at your own mercy and shouldn't expect any official support for it.