Anyway, one of the things I've been playing with is post-processing, and generally sorting out the rendering architecture. The rendering framework started as a clone of my previous C++ efforts, and I think it's a bit ugly because of that.
Here's the current look with a post-process slapped on top. I wanted a bloom type effect, but went for a six-pointed star rather than a normal separable Gaussian affair. Sparkles should fit with the way I want to render magical spells and suchlike...
And yes, the stars aren't actually that visible with such large bright areas. And yes, it is hugely overdone for testing purposes. Expect a little more subtlety... eventually. For now, huge glow was damn satisfying!
Hmm. Just noticed the water appears to be glowing, too. That's not right.
4 comments:
The water is not glowing. Have you been eating some of those strange mushrooms? :P Hehe just kidding. Looking great!
(Hey look at this captcha: relol. ?!)
Knarkles, that sounds quite cool. What kind of uses do you find for having multiple components of the same type? I'm not hugely familiar with python, is extending the number of attributes stored in the entity easy?
I experimented with using a property bag as a weird kind of serialisation target, such that components are packed/unpacked from the bag and individual properties rarely directly used. I still end up with a plethora of Maybe/Option objects kicking around, but it might be useful eventually.
Jotaf, thanks :P
I found the source of the (admittedly very subtle) glow. I added some faked caustic stuff, but hadn't tested it. It's currently just making underwater areas very slightly blue and unlit, but it's almost impossible to see except in dark areas. In any case, not the desired effect.
Still, at least the mushrooms aren't to blame!
Ah, simplicity - score one for dynamically typed languages!
I like the approach, as there are many attributes which are read by multiple components and systems, but written by very few. The transformation matrix being a great example... *g*
Out of curiosity, do you enforce read/write access so only the physics component can update the transform, or just leave it as convention that other components treat it as read-only?
Post a Comment