Projected release for 3.33.50

I'm fairly confident that I will be able to release 3.33.50 either at the end of this week or the beginning of next week. This is fall break week at school. I'll be working alone Wednesday, and off work Thursday and Friday. This should give me plenty of time to finish up everything remaining (mainly, polyobject sound sequence support, saving/loading sound sequences, and finishing joe's pillars, Small functions, and steam generator thing).

It has not coincidentally been approximately a year since the release of 3.33.02. 3.33.33 was released back in May, which seems like a long time, but we did have two SVN maintenance releases thanks to joe which helped offset the delay this time ;)

There will probably *not* be a fix to wobbly lines in 3.33.50. I'm beginning to think that writing a new, floating-point-based renderer might be a good idea. The renderer is largely self-contained, and so with a few function-pointer-bearing structs, it should be possible to allow more than one easily. My main concern still remains the overhead of float->int conversions on Intel processors, as these would be necessary at some point before column and span drawing are done. Apparently int->float isn't that bad, and so the interface between the engine and renderer, with one remaining in fixed-point only, shouldn't be that much of a problem.

Quasar said:

My main concern still remains the overhead of float->int conversions on Intel processors, as these would be necessary at some point before column and span drawing are done.

Asm to the rescue

According to some guy that presumably works for them, Microsoft uses SSE2 for double-to-int in .NET:

we didn't do much optimization work in the JIT for v1.1, except for some very targetted ones that offered a significant speed boost in exchange for little dev work [...], such as the double to int cast (40x speed increase by just using SSE2 instruction)

Might be something else to look into.

I suppose the old-fashioned trick of providing assembly for the Intel platform wouldn't be out of line. Only problem is, how to do this in a way that doesn't end up generating unnecessary function calls on platforms that can just do x = (int)doublevar; without a performance penalty? :P

Quasar said:

I suppose the old-fashioned trick of providing assembly for the Intel platform wouldn't be out of line. Only problem is, how to do this in a way that doesn't end up generating unnecessary function calls on platforms that can just do x = (int)doublevar; without a performance penalty? :P

inline anyone?

Look for 'quickertoint' in the ZDoom source. There's different implementations for all platforms there. You just have to put in a few #ifdefs to get the correct one.

SSE2 is not a real option because it's only supported by modern processors. But you don't really need it. As long as you can get rid of the function call for the conversion it isn't such a problem.

Julian Hope said:

inline anyone?

Unfortunately inline is only a "suggestion" which compilers may ignore at their whim based on some metric they think makes inlining worse but in fact kills the performance of your program. Apparently Visual C++ has a __forceinline keyword (which I've never seen until now) but that's hardly a generalized solution :P

Graf: thanks for the pointer. Although I doubt the floating-point renderer, if I do implement one, will be targeted at low-end machines anyway, I don't think I want to rush into something as specific as SSE2 either ;)