Smooth weapons decorate Add ON- 8Mo
This is a zdoom decorate wad with smoother weapon animations that are all upscaled.
It makes a pretty good companion wad.
Suba Steve made one that works with vanilla too, but it seems pointless since the neural wad only works in zdoom anyways.
I have been playing with different image upscaling neural networks : letsenhance.io and Nividia's GameWorks SuperResolution.
I finally used Nvidia's solution (it took some time to be in the beta!) : Infinite amount of requests, better results.
little drawbacks : max output size is 8192, so, for 8x it's a 1024 input, etc... 2 files processed at the same time max.
The process was to pack doom textures into different 1024x1024 pngs (7 iamges), then get the 8x upscaled versions (using 2 different techniques), then blend those results together as they both have qualitys and issues, downsize to 4096 with bicubic supersampling to blend some noise, then downsize to 2048x2048 with nearest neighbour supersampling to keep the sharpness feeling of original doom textures.
the 4x and 8x versions have too much funny AI artistic style artifacts to be used
Unfortunately this comes with some unwanted pixels here and there and a heavy de-noising work was needed. Also the contrast is changed, bright details are brighter, and dark one are darker too, this had to be cleaned as well by removing them and leting the original texture color appear.
The clean isn't perfect but a first alpha release stage has been reached and I can test it ingame...
but I'm stuck, I can't make this work and I need some help to be able to launch gzdoom with the -file parameter and a folder with all Hires pngs . then I can fine tweak from photoshop to gzdoom easily.
If someone more skilled than me with gzdoom modding could take a look
My files (pngs, notworking pk3s) are shared in this google drive folder
Here are some previews of the results (note : the transparency of the vine has been done manually, sadly the upscaler can't handle black and white shapes, but It's not that hard to do manually)
Just rename the /TEXTURES folder to /PATCHES. There are a few issues, since you're using PNG's instead of paletted LMP files, so anything with cyan will need to be actually transparent in the PNG. I'm sure a lot of work is left to go as these patches cause texture alignment to go out of sync. STEP1 and STEP2 also have issues where they're replacing the texture despite being intended for FLATs.
Thanks for the help DragonFly and Gez :)
Spectre01 : it works pretty well on sprites too :), I wanted to release everything at once, but well, I need the textures to work, finishing this will teach me things that will be usefull when doing sprites .
I renamed /TEXTURES TO /PATCHES and now everything loads but all the replacement textures aren't scaled down, so instead all the walls have the blown-up upper left quadrant of the texture covering the surface. Are there any instructions on how to fix this?
Dragonfly : I re-uploaded transparent textures as transparent pngs without cyan background
DooM_RO : I uploaded some 8k sources here, I'll take look in smoothdoom files to see if I can upscale them at the same time of the original ones. Doom2 minor sprite fixing project seems also to be taken into consideration. what bother me is that it's no longer a Hires override pak but a full mod (actually, as I can't make Hires folder work, it's already no longer a Hires pak lol).
Linguica : I'm still fighting with my files to make this work worrectly, with no success :(.
-I split Flats and Patches, did a flats.txt and a patches.txt. only the scale of flats is working, patches scales are still ignored.
-I tried to understand how the HD-Textures.pk3 works, because it does, ( as opposed to mine :D), and still has crazy filenames different from the ones in doom2.wad. The .txts in that file are just appearing as "readme", the patch/scale informations are hidden somehow.
These are very impressive! It's the first sprite resizing project in a while that genuinely looks like it maintains the feel of the originals. They made need a little tweaking, but it's a great start.
This is a very early result, just to run the game, but that was the hardest part for me. Dealing with makefiles and compiler is really not my cup of tea so having the game running means that now I can focus on the game control, presentation and optimization.
The most difficult part was to deal with the linker that was complaining about some missing references in libc. After spending two evenings chasing every libc functions that might be problematic, I found out that there is some magical linker option.
But I have to say that this is possible mostly because the Doom engine is extremely well done and organized and can be easily ported. It is not a mystery why this is the game that is always ported everywhere.
Something I forgot to mention is that I used STM32Doom for the port which itself in based on chocolate doom. I will share the source when I am a bit further and after cleaning some code (If anyone want to source already, feel free to DM me).
This is still pretty rough. I tried to add controls but now the game crashes in the simulator when I try to launch the proper game. I also have a new crash on device, a totally different one. It will be (not) fun to track them down.
At least the rendering is a bit better. I use a dithering map texture which indicate which part of the screen is blue noise, ordered of just threshold. On the long term the key will be to add contrast to make some element like enemies pop more.
But now I went back to the blue noise rabbit hole and started to experiment generating my own blue noise textures. That will be interesting to improve the picture quality (and I have an idea that might force me to go back to my video experiments)
I don't want to throw extra work on your plate, but this made me think about a post about dithering in Return of the Obra Dinn, and how the dither pattern was rotated with the camera. Since you're working with Doom's source directly, I would imagine this means you have easy access to the camera rotation angle, yes? If so, I wonder how easy it would be to scroll the blue noise texture correspondingly, and if it would make the scene look any better or worse?
So if you don't go on the discord you might not have seen that Poom is kind of playable. I say kind of because I still have a lot of random crashes when navigating the menus. I am waiting to be able to debug on the simulator figure out what is the issue.
A couple friends of mine who don't know anything about playdate or that I'm in the preview, individually shared your update tweet with me saying how cool it is and how the device is so unique and looks fun.
As my client described doom piles as a messy consequence of her ADHD (especially undiagnosed ADHD), I immediately thought of the mountains of paperwork on my desk. Though I loved my career as a therapist, some parts of my work made me feel anxious all the time. It seemed like my work life was ruled by unopened emails, unchecked voicemails, and piles of incomplete case notes.
Diving deeper, I realized that doom piles have always been a part of my existence. Whether it was a messy closet behind a closed door or a school locker full of crumpled-up papers, doom piles were always there. I also thought about how disorganized, restless, and anxious I felt most of the time, even as a child, and how I believed I was lazy and prone to chaos.
Then came taking a hard look at the organizing systems (or lack thereof) I had both at work and at home. Each week, I would schedule a few hours to read about ADHD, planning, and organizing. I looked into how others with ADHD tackle their own doom piles, but the most valuable thing I learned is that there is no one-size-fits-all approach. What worked for someone else with ADHD may not work for me.
As I sorted through the doom pile in the trunk of my car, I grappled with the surprising difficulty of parting with items that had followed me for years. Still, I knew it was necessary. Organizing the smaller things gave me a sense of accomplishment that kept my motivation high.
SUPPORT ADDITUDE
Thank you for reading ADDitude. To support our mission of providing ADHD education and support, please consider subscribing. Your readership and support help make our content and outreach possible. Thank you.
This is probably the best-known example of how performing a cryptographic operation before verifying the MAC on a message can go wrong. In general, there are three different ways to combine a message authentication code with an encrypted message:
When receiving a message, one would decrypt it, look at the value of the last byte (call it N), and then insure that the preceding N-1 bytes also had the value of N. Should they have an incorrect value, one has encountered a padding error, and should abort. Since the MAC is part of the encrypted payload, all of this needs to happen before the MAC can be verified. And thus, inevitable doom.
We see that SSH has the same problem as above: in order to verify the MAC, one first has to decrypt the message. At first glance, however, SSH is safe, because the type of padding it uses does not make it vulnerable to Vaudenay. By specifying the padding length in a one byte field at a fixed location prior to the payload, it slips by.
SSH has another strange feature, however, which is that the length of the message itself is encrypted. This means that before a recipient can verify the MAC, they first need to decrypt the first block of the message. Not just so that they can calculate the MAC over the plaintext, but so that they even know how long the message is, and how much data to read off the network in order to decrypt it!