Afterthoughts - Part II

I think a sufficent time has passed since Assembly, so it's time for the part 2.

I'm still undecided what 3d API I should be using next. There's lots of good things to be recycled in our old OpenGL framework, and using that is really easy for me since i'm used to it by now. However, the XNA adventure showed that it's not THAT difficult to move to another api and get something done with it.

The problem is that our old engine is basically written for fixed pipeline, glDrawElements and glCopyTexSubImage. Those are getting way old (and slow) for modern day demos, which "should be" using shaders, VBO ja FBO. One alternative would be naturally to implement those into the engine, but the problem is that it's a large steaming pile of code, and rewriting half of the engine is not on my "things i want to do"-list. Also, i dislike the OpenGL state machine with millions of flags instead of one self-describing flag per state as in XNA (and also DirectX i assume). And i HATE having to check for support for every goddamn extension, coding possible fallbacks, querying the function pointers etc. Yeah I know there are libraries and shit for that, but i dislike them aswell :). I want all the necessary stuff to be in the API itself without any additionall bells and whistles.

Currently XNA is a nice start, but with all it's bugs and crappy audio playback, it's not the thing I want to use for each and every demo. The XBOX 360 distribution model (having to pay $100/year to be able to even WATCH demos or play crappy DIY-games) is retarded, and for PC's there are better and faster ways to do the job. I'd be more willing to use it if there was a free "XNA player" for the X360, and even pay for a developers' licence. Anyways the box itself is a really nice machine, so it's possible that we'll do something more with it some day.

At the moment, we have no plans for our next demo. There will be more though, at least a couple of demos to complete the series. After all the demos are finished (i was thinking 8 or max 9 demos total), we're probably going to release them on a DVD (or even HD-DVD/Bluray) remastered and revised. All of them have some minor (or major) flaws, the different look on STS-06 to name one (a "final" version with cell-shadier look and more STS'ish stuff is on my todo-list). But if the re-editing of the demos is ever going to happen, it's solely for the DVD and there won't be any binary re-releases.

As for the API, i think i'll wait and see the OpenGL 3.0 which should be out soon. If the driver support (and even an SDK?) is usable soon, i might start using that. If not, i'll consider moving to D3D.


Afterthoughts - Part I

It's peculiar how people are always "expecting more", even if we had only a month to make a demo, and the framework, language and 3d API had all been changed since the last demo. In my opinion, i think we managed to do a decent, watchable and technically good demo in a very short period of time. But still people expect it to be as good, or better, than our previous demos where the month or so was spent on writing effects and design rather than framework code.

I'm more than pleased with our ranking in the compo. I actually was expecting FLT to come to second place, but you never can be sure when it comes to party voting, especially at Assembly. Also, the ASD or Fairlight demos had both been under work for ages (although FLT guys said they had made it in a week or two, but this was the demo they didn't finish for last BP in April). ASD guys worked on their demo for 7 months and it shows. Insanely huge amount of stuff, filling the 8++ minute timeline.

I'll be posting a second afterthoughts post about XNA stuff later. Probably when I've decided what framework I'll be using next.

-Medicine Man

Asm'07 over - We got 2nd place

So finally we got the demo (STS-06: Microdots) finished and released. Second place at democompo is better than we expected, but it's always nice to do well. Congrats to Conspiracy for winning the best XNA prod award (1000€ cash).

Video  ... The video version seems to be out of synch after 1-2 minutes of playing. We will release a properly synched lowres-version of the video within a couple of days.

There are some issues that need to be solved if we wish to release a Windows binaries. For example the SpriteFont thing refuses to load the font from bitmap on Windows, while it works fine on the xbox. The other issue is that while the demo runs constant 60fps (720p resolution) on the xbox, it only runs at 2-5fps with my laptop which has a GeForce Go 7600 and dualcore AMD processor.

-Medicine Man

Some progress

Finally, things are starting to look a bit better than last time posting. I've managed to put together some content and put it on timeline with some synchs. Roughly half of the design (what some people would call direction) done, I can already say this one will be more straightforward than people usually expect from us (I'm already imagining a "I expected more"-comment on Pouët). Less smooth transitions and simpler camera work, but that's what I need to do in order to deliver the demo on time.

Designing a demo is really time consuming (at least the way I do it) especially when you don't have any 3D tools or a timeline editor. Just imagine how difficult it is to find proper random values for sine / cosine camera tracks that won't hit into objects that are placed around the scene :D. And every time I change a value, I have to recompile and see the part again, so that no objects are in the path of the camera... I should seriously consider writing an algorithm for camera tracks that look natural and don't hit anything, or write a camera path editor of some kind (This is the part where you should be laughing at me :)).

- Med$Man

Some progress, GameTime bug (plus a fix)

Less than 3 weeks to go, and there's still huge amounts of work to be done. I don't have a single piece of final graphics content done, just some tests. However, the code base seems good enough (there really isn't much to add with XNA, most of the needed stuff is already there) so i can move to creating the actual effects, synch and design.

First thing to do when doing design/synchs is to get a timer that's running on the same speed as the tune is. I use a timer that advances 1.0 per 16 beats (or some oldskool might think it's "patterns" like in trackers; I call them patterns :)). Do do this, I used a simple conversion from XNA's GameTime to demotime. However, when I started to test on some synchs I noticed that the timer was lagging, about one or two beats after a few minutes of demo running. That's really really really bad, hmmkay.

So after posting to XNA creators club's forums and googling I found this. It seems it's actually a real bug instead of me messing with my code as it usually is... Just use DateTime.UtcNow.Ticks instead of GameTime and everything will be in perfect synch.

Now all i have to do is create 3D models, graphics, effects and direction for our 5 minute demo, in 18 days. That gives me 3 days per demo minute (if I'd be working on the demo every day, which I won't).

Oh and I still have to find a way to fast forward / rewind the song with XACT, since:
a) We have no timeline editor whatsoever
b) We will never have a timeline editor whatsoever
c) Watching the whole 5 minutes before seeing the change made to the final minute of the demo would be really frustrating

If no solution to the ffw/rwd issue is found, i may have to split up the song in 5-10 different samples and trigger them or something... Doesn't sound very good at all.


Xbox 360 HLSL microcode stuff

I've been mostly fine tuning a post processing effect this week, which has been a frustrating experience, as fine tuning always is. This time my frustration has nothing to do with technology, but rather with the impossibility to achieve the effect with I want with only 1 or 2 post processing steps and still keep it looking good and running fast. However I think I managed to do a solution that isn't butt ugly at least.

So after the post processing was good enough for me, I moved on to making some vertex shaders so that we can put some life to objects rotating on the screen. The idea I had required me to have a texture lookup in vertex shader, so I thought I'd just put a tex2D(texturesampler, texcoord) there and it'd be all fine, but instead I get this bizarre error message:

(28) : error X3556 : Microcode Compiler tfetch instruction cannot have UseComputedLOD=true and UseRegisterGradients=false in a vertex shader
(122) : ID3DXEffectCompiler::CompileEffect: There was an error compiling expression
ID3DXEffectCompiler: Compilation failed

So I entered some of the keywords to google and found absolutely nothing. I went on to MSDN, and finally the "UseComputedLOD" guided me to a page telling about Inline Microcode Assembly in HLSL, which is the native shader assembly language of Xbox 360. If you're into programming any Xbox 360 exclusive stuff, i suggest you take a look at it, there's some interesting stuff that might become handy later on.

Normally I don't do any of code sharing (mainly because I'm a bad coder :)), but since many fellow sceners might be facing this (and because it's practically on MSDN if you know where to look), here's a code snippet that enables you to do texture lookup in vertex shader (XO only, I guess):

float4 tex2Dpier(sampler2D s, float2 uv) {
  float4 result;
  asm {
    tfetch2D result, uv, s, UseComputedLOD=false
  return result;

If you'll find a way to get around the microcode thing by setting the UseComputedLOD to false some other way, let me know. At least the sampler_state thingy didn't work for me.

Today I'm On Fire

In comparison to spending most of this week banging my head against the wall with the tune, today I just sat down and completed the whole thing in a bit over five hours. Definitely my day today \o/.

Mixdown still needs some work but I'll look into it closer to Assembly.. fresh set of ears and all that.

-- Man With No Alias

Bug or feature?

I don't know if it should be called a bug or a feature, but I found out something about rendertarget surfaceformats yesterday...

Depth textures can be useful for many things: shadow mapping, depth of field effects and other cool postprocessing effects. Unfortunately XNA doesn't support depth texture rendertargets (at least yet), but this can be circumvented by storing the depth values to a regular texture. You can do that easily with shaders, plus you can add some depth algorithms of your own while doing so if you need to.

My first attempt was to split up the depth value to r/g/b channels in a SurfaceFormat.Color texture, and then unpack them in postprocess shader, but that caused some minor artifacts no matter what i did. I suspect it might have something to do with rounding, even though i used floor (or subtracting the less significant component from the more significant) whereever i thought it was necessary.

So i switched my rendertarget format to SurfaceFormat.Single, which has a single 32bit float channel (red). That worked fine without any artifacts as long as i kept reading the texture with point sampling. But with bilinear sampling, the texture seemed to be interpolated the same way as if it was a normal RBGA texture, so we got quite much garbage in the red channel near the areas where i imagine the less significant bytes get interpolated (and maybe clamped too) instead of wrapping.

- Medicine Man

Tune progress

After much fiddling around, the track for the Xbox360 release is finally starting to get its foundation laid out. As it turned out, the plan of trying just to start somewhere and see where things flow from there definitely was a no-go for me. I just got buried to a huge mess of kazillion sound clips. So, to get things back on track (and actually going somewhere) I spent most of this weekend cleaning up that mess and deciding on some key elements. For this track I'm also getting some sound programming support from 1in10 of mfx; the amount of raw material he keeps churning out is amazing.

The overall mood/feel of the tune still needs to be decided on. I have a few viable alternatives that do fit the current song foundation; out of these it'd of course make sense to pick out whichever goes best with the visuals of the production. And those really don't exist at this point :)

All in all, I should decide on the overall structure and elements (plus implement them) of the song within a week since I will be totally unable to make any music for most of july. Summer trips and whatnot, but I bet Medicine Man would still like to have something to work with a bit earlier than a week (or so) before Assembly 07 ;).

-- Man With No Alias