Programming. Realtime computer graphics. Demoscene. Game development. Stuff.
The Escapist is a good read from time to time. This time, it's Greg Costikyan:
And actually, EA tried to kill The Sims many times before it was finally released. From what I've heard (and this is definitely hearsay), Bing Gordon's comment at the meeting where publishing was approved was: "Well, it'll only sell a hundred thousand copies, but it'll get Will off our backs."Gee, I'd want all magazines to be like this. Focused, to the point and without trivial crap that most of them are 99% full of.
After taking a break, I already want to do something programming-related in my free time. What should I?
On the unrelated note, I'm doing a Oracle and XSLT related project at work. While Oracle stuff I'm dealing with really sucks, XSLT isn't bad at all. Sure, it's not "programming" that I'd love very much, but the whole concept is very powerful.
Maybe XML isn't such a bad thing afterall, especially once you start doing funky things with XSLT and XPath. I still love the quote "XML is a giant step in no direction at all" though :)
Software of the week
It's never too early for Software Of The Week awards, even if it's only Tuesday. Ladies and gentlement, Aras' picks are:
Guns & games
The comment on the blog entry here is great:
38% of Americans own game consoles. Around 40% of Americans own guns. The gun lobby is damn powerful. We shouldn't need anywhere near as much money as the gun lobby, because unlike games, we are absolutely, 100% sure that guns actually do kill people.
What's in the engine?
As always, here's a thought that's more about demo-engines than about game-engines; and mostly dealing with graphics stuff.
Some folks add whatever gfx effects/techniques they use to "the engine". Quote from Plastic:
We've also added a couple of new features like <...> wireframe/particle shader.Now, I don't have a problem with that, but what strikes me is that for whatever reason our engine doesn't have any effect/technique in it. Zero shaders, no shadowmaps/PRT/refractions/whatever.
The obvious disadvantage of our approach is that for each demo I basically write the shaders and "effects" from scratch (ok, copying them is also fine). There's no central place where, for example, a Gaussian blur postprocessing filter or shadowmaps rendering code is stored.
On the other hand, that means (nearly) complete freedom for each demo. In each prod I can tweak whatever I want and implement completely different rendering techniques. For example, in.out.side demo is quite different from Visual Gaming viewer or Xplodar FEM demo, yet they all share the same underlying "engine" (read: bunch of code).
Still, what I'd like to do is have "somewhat stable" stuff gathered in one place. I don't tweak my basic lighting functions, standard postprocessing effects or shadowmap sampling patterns that often :)
Back #2 - tiny photos from Japan
Left to right, top to bottom: The fractal house on our way from Narita Airport to Yokohama. Visual Gaming competition in action - hey, it's the 3D viewer I wrote! Paulius in the ferri wheel - demo or die. Me showing our demo before the dinner. The wistful photo - me looking at the horizon. Yokohama - we were here.