Sometimes there are pieces of code that are not principally buggy but rather unoptimized or excessive. I wonder if it could be a good idea to have a thread for such cases. As a start, here's a code from Actor.Special final void A_KlaxonBlare(): Self exp

actors/strife/strifestuff.txt

actor KneelingGyu 204

Spelling error in "guy".

It's called "refactoring", right ? When you talk about optimization, the first thing that comes to my mind is execution speed. Am I to report typos in comments as well ? "Delfection angle" and so forth ? There's a lot of repetition i

If you want to post something, consider yourself <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> (I wouldn't report lengthy functions though, unless same code is used more than once). BTW, I also noticed that sam

When functions or methods are very long, it's harder to understand them. Take a look at HitMobj and HitLine in EntityEx.Physics.vc . I've found several bugs in the two methods already, and there are more coming ! A good rule of thumb is to avoid functions

[quote="b0rsuk":1wf2m3km]When functions or methods are very long, it's harder to understand them. I am not going to report that because that's too obvious. Simply that. I just wanted to pay attention to less noticable things.

    if (Special1 == 3)
 57         {
 58             damage <<= 1;
 59             power = 6.0;
 60             PuffType = HammerPuff;
 61         }

This is "third punch" of Hexen warrior (Spiked Gaunt

LOL that's not the kind of "mistakes" I was going to post in this thread. <!-- s:? --><img src="{SMILIES_PATH}/icon_confused.gif" alt=":?" title="Confused" /><!-- s:? --> but, oh well....

[quote="b0rsuk":k467vn37]I know bit shifting is faster than multiplication by 2, but performance gain here is marginal ! It has its place in the renderer, the engine etc. But this code is being run only once per 3 punches of the player, and it h

I also think that these type of problems reported here won't help much in terms of performance. Also, that class typo can't be changed without affecting ZDoom's compatibility, unfortunately, that's how the class is named in ZDoom, if we change it, that c

[quote="Firebrand":2qs29df4]I also think that these type of problems reported here won't help much in terms of performance. Also, that class typo can't be changed without affecting ZDoom's compatibility, unfortunately, that's how the class is n

[quote="BondEar":2ww7f8up]It would be interesting to know whether that was in the original Hexen source. Yes it was

The one reported by Crimson Wizard is fixed.

I have one undeniable ugly bit, and one questionable one. 1. (questionable) in linespec/EntityEx.Morphvc, method Morph checks for bIsPlayer and calls either MorphMonster or MorphPlayer. Then in MorphMonster, there's another bIsPlayer check - but it wil

I've found a really strange thing while debugging my special effects. In progs/linespec/EntityEx.Physics.vc, method HitFloorType:

1288     // Small splash for small masses
1289     if (Mass < 10.0 || bSmallSplash)
1290         smal

[quote="b0rsuk":g6q6ni9n]

1288     // Small splash for small masses
1289     if (Mass < 10.0 || bSmallSplash)
1290         smallsplash = true;
1291         print("Classname: %n", GetClassName(Class));
[/code:g