Smooth Doom [WIP 2.0 TEST? WOWIE ZOWIE]

[Retraux Squid]

Do you not think we're suffering from feature creep in this mod by now? What happened to "keeping it simple" without excessive bells & whistles?

I don't see one lick of actual gameplay change in that upgrade mod. Everything's aesthetics (and damn good ones, save for the unfinished Chaingun Major).

[Gifty]

@RSSwizard WOW, I am seriously impressed by this addon. The sprite-based projectile effects in particular are really excellent, I think I'll be taking inspiration from them in my new project. I can't seem to get the cacodemon effects to appear, any clue why that is?

[Someone64]

Why are the plasma shots kinda jittery compared to other projectiles? Also, I'm not super into the overall color change of everything being darker and less saturated.

[Armaetus]

Projectile colors should be left alone.

[RSSwizard]

@RSSwizard WOW, I am seriously impressed by this addon. The sprite-based projectile effects in particular are really excellent, I think I'll be taking inspiration from them in my new project. I can't seem to get the cacodemon effects to appear, any clue why that is?

The caco fireball impact has been replaced, it switches to the rocket explosion graphics at roughly 1/2 scale. As long as "player and monster" plasma sparkles are turned on, it will also emit sparks on impact, as well as small sparkles in its trail. I also replaced the first frame of the rocket explosion with a "no spikes" variant.

Why are the plasma shots kinda jittery compared to other projectiles? Also, I'm not super into the overall color change of everything being darker and less saturated.

(yeah but there are Alot of people who Like everything being darker. The PalPlus palette was used as a basis to make further modifications from)

Because I only have a 1 tic frame timespan to work with unless I want to make their state jumps alot more complicated. That means even if I was working with standard spiky plasma shots they would be very jittery.

The overall construction of the plasma shot is as follows:
SpawnitemEx on a plasma ball that has "light rays" coming off of it at the front. It has 4 possible frames to choose from at random with adjusted light ray variations coming off of it (I interpret the spikes on the plasma shots to be light rays akin to lens flares when you're looking at a bright object with a camera).

Then it spawnItemEx's a stack of plasma ball sprites identical to the one with the light rays, except without the light rays. As they are spawned behind the main projectile they get progressively smaller in scale (A_Setscale is used on the main projectile to pass the intended scaling to them via SXF flag). Each of these also has 4 possible frames to choose from.

Then if plasma sparkles are turned on it moves to another state which generates a BlueSparkle behind it. The BlueSparkle is an invisible object that spawns a random number of sparks in place (distribution is I believe random -3,3 cube).

The plasma projectile is built for inheritance, it can even have a custom pre-death state called to give it explosion damage or something, as well as a 1 time Spawn state pass. The arachnotron plasma inherits from the player plasma, uses a color translation to make it as displayed. On the plasma sparkle state it also checks to see if the plasma sparkle option is set only to display the players' sparkles, if so it drops back to the regular animation all over again.

(all of this operates under a 1 Tic window)

Do you not think we're suffering from feature creep in this mod by now? What happened to "keeping it simple" without excessive bells & whistles?

Projectile colors should be left alone.

This is a 3rd party mod/patch, you dont have to use it if you dont want to.

The blue to teal color change makes the plasma shots look a little more realistic in my opinion, but really this is a result of changing the color palette. Since I use GZdoom 2.4 im still bound to a color palette and actually I Prefer the old engine recoloring method, im not impressed with the way the truecolor engine abandons the old recoloring algorithim rather than presenting an option to use it if desires (or use the old engine altogether).

So I made this mod FOR MYSELF, for my own enjoyment, and then decided that it was pretty cool and offered to share my work with others and possibly lend some inspiration with the oldschool additive alpha tricks (doing alot while working with much less). As for the plasma gun colors I see the inclusion of TEAL as a vast Improvement in the game, just like it is in BTSX except without washing out the brighter blue colors, yet I had the darker water colors preserved pretty much so that the darker blue computer grid floors and blue water would still retain the overall look.

In case you're wondering the new truecolor rendering system in GZdoom locks up on my computer (GZ v3.0 or higher I think). For no good reason at all after about 5-15 seconds the game's fps grind to a halt and then I have to close the program with the task manager.

I only have OpenGL 1.5 so I cant use hardware acceleration at all (even though oddly hardware acceleration works just fine for me on UT2004, and I can even play Doom3 at like 8fps if I use 3dAnalyze).

Until the lockup issue is solved I will never be playing GZDoom at a higher version than 2.4. I may try out new versions to see if the lockup issue has been spontaneously fixed, either by accident or due to attention being given to it.

So I do not experience dynamic lights in this game, and I do not experience truecolor rendering either. In fact I have never experienced dynamic lights in this game even when I was using my previous computer, I dont even know the decorate coding for providing dynamic lights. To give an example, as to explain that I cannot effectively cater to these issues.

I suppose I could have provided True Blue colored plasma shots for the player to cater to those with the new versions, but since those would be sprites with their own individual palette (or 24bit) and they wouldnt be capable of being inherited from as a projectile object (since im using color translations to make the arachnotron plasma), and it would not provide any benefit for me personally whatsoever, I decided to do it my way.

[drfrag]

In case you're wondering the new truecolor rendering system in GZdoom locks up on my computer (GZ v3.0 or higher I think). For no good reason at all after about 5-15 seconds the game's fps grind to a halt and then I have to close the program with the task manager.

Looks like a driver problem.

I only have OpenGL 1.5 so I cant use hardware acceleration at all (even though oddly hardware acceleration works just fine for me on UT2004, and I can even play Doom3 at like 8fps if I use 3dAnalyze).

Doom3 ran with OpenGL 1.4 or even lower without 3DAnalyze (i played it with a Geforce2 GTS back then).
You could try ZDoom LE, it's an old version but only requires GL 1.2. SmoothDoom runs with it but as i mentioned you'd need to remove the '+' from the '+2' in some spots. I don't know why Gifty added a '+2' to some A_Jump statements since that was never allowed and there are no negative jumps, then there was some copy-pasta. Unfortunate. Your modification won't run however.
I guess you're on intel so you could try to run ZDoom32 @320 (since your card should support that resolution natively) with the software Mesa driver (either fdossena or _mental_ version) and could be playable with a decent cpu. Seems like the modern renderer is not compatible with Mesa, here the game is rendered on a small (1/8) portion of the screen.
BTW the old truecolor software renderer has no support for truecolor textures and 3d floors are somewhat broken (missing textures) but it's fast. I cannot fix them and i don't know how to translate from LLVM to C++.

@dpJudas: unrelated but i'm afraid the dancing sprites have returned in TC mode (on one of the latest devbuilds). Seen at the start of DOOM II MAP02.

[RSSwizard]

SmoothDoom runs with it but as i mentioned you'd need to remove the '+' from the '+2' in some spots. I don't know why Gifty added a '+2' to some A_Jump statements since that was never allowed and there are no negative jumps, then there was some copy-pasta. Unfortunate.

I have NO idea what you're talking about here. Are you talking about (to use an example):

Code: Select all

goto Death+6

or

Code: Select all

A_JUMP(128,Death+6)

I know the latter wont work and I never understood why, but the first one I think has always worked because its integral in vanilla to both the chaingunner and arachnotron (to skip past the first frame of the missile state, the one that gives a warning to the player that they're preparing to fire). Those have Missile+1 which means goto missile state, then advance one frame.

As for really old versions of Zdoom they wont work with any of the other mods and stuff that I use, probably because SpawnItemEX came about later, and possibly the extended functionality of A_Explode. Function wiki doesnt go into any detail about which point functions were added or extended on.

(for that matter ROLLSPRITE and A_SETROLL are supposed to work in Gzdoom but they dont appear to be functioning in software mode)

[drfrag]

TNT1 A 0 A_JumpIf(CallACS("Gibtoggle")==0, +2)
tnt1 a 0 A_JumpIf(CallACS("CasingToggle")==0, +2)

I don't think Gifty will get upset as i've just removed the '+' from the '+2'. The link will be alive only for a few days.
You'll get some errors in the console but i guess that's due to wrong names for some states, such as '64ready' and '64fire' instead of '64Ready' and '64Fire'. ROLLSPRITE was added later.

Edit: they were actually missing states but it's harmless. Link removed.

[dpJudas]

@dpJudas: unrelated but i'm afraid the dancing sprites have returned in TC mode (on one of the latest devbuilds). Seen at the start of DOOM II MAP02.

Not spotting any dancing sprites on my computer. Also checked the original test locations for sampling errors: https://imgur.com/a/XLJO3. All looks fine to me.

To my knowledge nobody has touched the software renderer for a while, making it very unlikely for this to suddenly break.

[drfrag]

Sorry i was wrong, it's a different problem (may be it's normal). Only happens with the poly renderer at the start of MAP02 with the two zombiemen in front of you when looked from behind. Switching soft renderers the difference is very noticeable.

[dpJudas]

Ah yes, softpoly does have some kind of offsetting issue with the sprites. I'm not sure exactly what is causing it - something to do with the way it calculates the UV coordinates. There's also a lamp on map05 that twitches like this.

[Muerse]

Im using Gzdoom, and on the smooth doom menu there is no way to change the weapons. If you could help, i would appreciate it.

[Gifty]

Im using Gzdoom, and on the smooth doom menu there is no way to change the weapons. If you could help, i would appreciate it.

Yeah, I've temporarily disabled the weapon skins while I work on better sprites/cleaner code. They should be back soon, sorry about that!

[Trar]

Some monsters have no archvile-revive sprites. Can't remember which, but IIRC they were usually skinned zombies.

Can confirm this is still a thing.

Other than that this is one of my favorite wads, keep up the good work!

[StroggVorbis]

Bug report:

-SD_VARIANTSPAWNFLAGS in DECO/Variants.txt is missing the SXF_TRANSFERSPECIAL flag, breaking maps which rely on specials executed by monster deaths.

-ACS scripts or linedef triggers involving keys don't work, either because of LOCKDEFS or the key replacements.

-Mancubus gibs don't disappear even when giblet toggle is off, I think it has to do with the order of the death states.