Russian Doom 2.3 release plan

[JNechaevsky]

Arrival date: 25.11.2017

Releasing version 2.3 on my 32th birthday should be an interesting move.

Step 1: Remaining stuff

• :white_check_mark: Need to decide/do something about buttonlist->soundorg, implemented in https://github.com/JNechaevsky/russian-doom/commit/4b1422c5ceec9b2a0ffeefedfa8c69b09a7c892d.
• :white_check_mark: Are the all vanilla demos working fine?

Step 2: Release

• :white_check_mark: Create new screenshots.
• :white_check_mark: Update readme files in both Russian and English.
• :white_check_mark: Update change logs in both Russian and English.
• :white_check_mark: Update my translated online help for setup executable with new features.
• :white_check_mark: Update project's web pages.
• :white_check_mark: Upload binary and source code archives on the net.

Step 3: Web

• :white_check_mark: Upload project's web page and online help.
• :white_check_mark: Put online changelog files.
• :white_check_mark: Update iddqd.ru forum thread.
• :clock1: Update page on Chocolate Doom Wiki.
• :clock1: Update page on Doomwiki.
• :white_check_mark: Make a post on VKontakte.ru social network.

Notable new features

• Brightmaps! While the very first implementation attempt was kinda awful, current one is... Well, still not good enough to be good, but pretty well to be called experimental and for having first positive impressions. There are no any performance drops on vanilla maps.
• Freedoom support and translation.
• More various vanilla bugs fixed. Looks likes I have fixed all the bugs I wanted to be fixed.
• Nice weapon bobbing while firing in movement. And unique one for sawing chainsaw. This also fixes too notable shotguns shaking after firing <> standard bobbing.
• Fixed 100% of -Wall warnings on Windows build using CodeBlocks / TDM-GCC.
• Exploded HUD face from Atari Doom. Totally wicked sick.
• No more any smoothing by default.
• Pixel perfection in Doom 2's SKY 2 and 3, also in fist, shotguns and rocket launcher.
• Signed Crispy HUD.
• Added FIRELAV2 texture from mr. Romero's Doom dump. Also fixed animation sequence, which was too notable on E4M5.
• Lots of small improvements.

Couple of further ideas.

Just for the record. Not all of them should be implemented! Need to write 'em down, until they are still in my head.

• Need to understand why my R_ApplyWeaponFiringBob desyncs some demos and and crashing network games randomly. This is have to be local only effect, so why this is happening? Because of this, new bobbing is declared as singleplayer only, but I still don't see any difference in shooting mechanics with this /2 bobbing and without.
• I was going to use MSVC for release binaries, but after testing I've noticed that setup executable crashes while trying to find game servers on LAN. Is it a code issue, or something wrong set in MSVC project? No idea. I still can compile setup executable with GCC and game executables with MSVC for getting some bits of additional performance, but this is a defiantly bad ethics. That's why release build will be made using GCC.
• Take care about https://github.com/JNechaevsky/russian-doom/issues/11 issue. I see how it's actually working in PrBoom+, but yet still not lucky with code porting.
• Brightmaps: it will be cool to add some extra b-maps for some textures with yellow lamps, but -- no to all them, I don't want to game will be looking as Christmas tree. Need some kind of definition of which walls should have this extra, which should not.
• Brightmaps: some very rare random blinking in some textures.
• Ability to switch weapon positioning from left-handed to right-handed (sprite flipping).
• Some different backgrounds for Wolfenstein / Grosse intermission texts? From Wolf3D shareware, for example. Not sure, better do not take any non-Doom graphics.
• And by the way, shouldn't be "Grosse" translated/pronounced as "Gross"? Not sure, because of "Wolfenstein" translated as "Wolfenshtain" ("Вольфенштайн", meaning proper pronounce in Russian language which is very close to German in this case), not as "Wolf's stone". Not everything should be translated "as is", especially a names of some places.
• Randomly flipped teleport flashes?
• Randomly flipped dead bodies that's already placed in the maps?
• Take a rest.

[fabiangreffrath]

Signed Crispy HUD.

What does that mean?

Need to understand why my R_ApplyWeaponFiringBob desyncs some demos and and crashing network games randomly

The vertical position of the weapon sprite determines how many tics it requires to lower the weapon upon weapon change. I have fixed this in Crispy by calculating the rendered position of the weapon sprite separately.

[JNechaevsky]

Signed Crispy HUD

It's a standard Crispy HUD but with names of the sections:

The vertical position of the weapon sprite determines how many tics it requires to lower the weapon upon weapon change. I have fixed this in Crispy by calculating the rendered position of the weapon sprite separately.

A-aaa-aaa-rgh, that's it. Thanks! I was not able to figure this out, but better will not try to fix it until 2.3 release. :)

[JNechaevsky]

Meanwhile... I have successfully extracted the IWAD file from Atari Doom ROM file using a HEX editor. It starts from 0004:0000 (from IWAD marker) and ends in the end of the ROM file: http://screenshot.ru/upload/images/2017/11/16/hex6134d.png

All exploded faces are on place, but the whole iwad structure is kinda interesting: http://screenshot.ru/upload/images/2017/11/16/574344f0bc54789396297.png

[JNechaevsky]

Okay, got i686-w64-mingw32-gcc 7.2.0 working fine, no performance issues as it was with 6.3.0. Yeah!

[JNechaevsky]

Got unpacked IWAD file from PlayStation Doom, an exploded face is different here:

It seems to be just more bloody, but less maniacal. Hmm, let's think why - PSX Doom was released on November 16, 1995, while Atari Doom was released on November 1, 1994. My theory have two possible ways:

• Williams Entertainment asked id to create a less maniacal version of that face.
• id Software's artists recreated that face for some reason (improvement? less maniacal?).

Probably we will never know, and probably my theory is completely wrong. :(

Speaking about my project, I think I prefer to stay with Atari version, but will use last exploded face from PSX for player's crushed state (S_GIBS). Maybe not, just need to experiment and decide something.

[JNechaevsky]

Pssst! Binaries are here!

Not sure I will be able to do a full release tomorrow, since I have, ahem, some plans for birthday celebration. Anyway, announce will be made today after midnight.

Version for Windows: russian-doom-2.3-win32.zip Version for DOS: russian-doom-dos-1.1.zip Source code snapshot: russian-doom-2.3-source.zip

Full changelog in Russian and in Russian English :) Updated PNG font atlases: russian-doom-fonts-png.zip

Some screenshots

[fabiangreffrath]

@JNechaevsky Happy Birthday My Friend, I wish you all the best for the next year and all the years to follow, stay around and stay healthy!

• Fabian

[JNechaevsky]

@fabiangreffrath, mein lieber und gütiger Freund! Thank you very much for all your kind words and wishes, for all your help and kindness, and.. for everything, actually. :)

Good things and suggestions will happen soon!

I just need some antifreeze now - today we was having an eight hour picnic on fresh air with -6 C°. :snowflake: But I'm okay and will be back in the deal tomorrow!

[JNechaevsky]

I must be honest: this version is a bullshit already, and does not require any remaining release activity. Very soon I will be ready to show to the World this:

And this...

And of course this... :grin:

[fabiangreffrath]

I have to admit I am a bit jealous of your brightmaps... ;)

[JNechaevsky]

Thank you! I can't believe I have solved performance issue, and as always, proper solution was right before my eyes - current implementation using the same idea as with pre-loading sky textures (R_InitSkyMap). So yeah, as I though before, real performance problem was with texture look-up.

There are still one small problem, though. B-maps are applied as walllights, and the walllights itself are affecting whole wall segment (upper/middle/lower textures). From one side, this meaning that lookup can be probably optimized even more (i.e. not by checking midtexture/toptexture/bottomtexture, but the whole "line"), from another... For example, if lower texture have redonly b-map, and upper texture have some red pixels, those red pixels will be also in full brightness.

For my hugest luck, vanilla levels does not have this problem. Well, there was only one place, but I knew it and fixed it by making special blueonly b-map. In PWADs this may have very bad aftermath -- but, I'm never interested in supporting any kind of PWADs, my primary interest is making everything perfect only in vanilla levels/series. So I'm not planning to make any further big activity on b-maps. They are looking fine, they are working fine, and that's all I needed. :)

Hey, no need to jealous of! We just need an idea, how they can by applied in Crispy without any kind of pwad. I see few ways already:

1. Hardcoded right in the executable. This will require some obvious compatibility definitions, though.
2. Hardcoded right in the executable, but using a PLAYPAL approach, like in Doom Retro. This way is more technically smarter and will not require editing COLORMAPs (roughly saying, just need to define what colors should be always bright in PLAYPAL lump). But it also gives a little less flexibility like support for some diminished lightning. Probably I'm wrong here, and this is also can be achieved, and just some additional code work should be done.
3. You are probably remember my thought about "some kind of modding standard using custom COLORMAPs"? I have a feeling that PrBoom+ already have something like this, at least for sectors... I can't say for sure, since I'm not very familiar with all BOOM editing features.

P.S. Ah yes, excuse me for being too quiet last days, now you see for real what I was making. :)