Log in

Synesthetics [entries|friends|calendar]

[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Afterthoughts - Part II [10 Oct 2007|09:44am]
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.

4 comments|post comment

Afterthoughts - Part I [09 Aug 2007|10:58am]
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
9 comments|post comment

Asm'07 over - We got 2nd place [05 Aug 2007|07:30pm]
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
9 comments|post comment

Bagged and tagged [03 Aug 2007|02:19pm]
Just in time for the party, I complete final adjustments on the demo tune :)

-- Man With No Alias
3 comments|post comment

Some progress [19 Jul 2007|10:19pm]
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
17 comments|post comment

Some progress, GameTime bug (plus a fix) [15 Jul 2007|04:46pm]
[ mood | frustrated ]

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.


1 comment|post comment

Xbox 360 HLSL microcode stuff [12 Jul 2007|12:57am]
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.
7 comments|post comment

Today I'm On Fire [08 Jul 2007|05:30pm]
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
4 comments|post comment

Bug or feature? [05 Jul 2007|10:11am]
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
4 comments|post comment

Tune progress [01 Jul 2007|11:45pm]
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
post comment

Intel demo ready! [30 Jun 2007|05:45pm]
Our entry, STS-05: Royal Temple Ball, for the Intel Demo Competition 2007 is finished and submitted. The demo will be online along with the other demos July 2nd, so follow the link to download it and don't forget to vote while you're at it ;)

Now we can fully concentrate on the XBOX 360 demo for Assembly, so more about that soon.
1 comment|post comment

Electric Kool-Aid [26 Jun 2007|12:46pm]
There's also a cocktail called Electic Kool-Aid (or Koolaid). We intend to try it at some demo party. If you want to try it yourself, here's the recipe:

  • 1/2 oz amaretto

  • 1/2 oz blue curacao liqueur

  • 1/2 oz peach liqueur

  • 1/2 oz melon liqueur (midori, melloni...)

  • 1/2 oz cherry brandy

  • fill with 1/2 sweet and sour mix

  • fill with 1/2 cranberry juice

  • 1 splash grenadine syrup

Pour ingredients into a Tom Collins glass filled with ice, launch STS-02: Electric Kool-Aid. Repeat until drunk.
2 comments|post comment

Bitmap fonts [20 Jun 2007|08:20am]
In Game Studio Express 1.0 refresh release there's new feature that was obviously missing from it: font support.

You can use any truetype font installed on your development PC by creating and importing a XML document via the content pipeline. What GSE does in the background is that it converts the truetype font into a bitmap (the resolution depends on the font size specified) which then can be rendered to screen using SpriteBatch.DrawString. This way it's fast to render (since ttf's tend to generate quite many polygons) and you don't have to spread the original .ttf file along with your game / demo. Naturally you'll lose the precision of ttf's.

While implementing a simple frame rate counter and time display, i found this handy tool called  Bitmap Font Maker Utility Plus. What it does is the same as GSE does in the background: converts ttf into bmp. It's based on the XNA team's Bitmap Font Maker Utility, added with support for outlines and drop shadows. Then you can import the bitmap into GSE spritefont just by selecting the Font Texture content processor. This enables you to use any custom font your gfx artist has created. Just make sure you have the magenta marker color around the letters and that the letters are in right order (starting with space (#32) followed by succeeding letters in ACSII / Unicode order).
1 comment|post comment

XNA performance [15 Jun 2007|01:34pm]
I don't consider myself as a true coder, but more like a designer/graphician/coder hybrid or whatever you'd like to call it :). I just use code as a tool to achieve the effect I wish to see on screen, rather than doing the same with tools made by someone else (some animation software for example).

As I see coding as the necessary evil, I'll usually choose the easiest way to do something. That has led me to using pretty much un-extended OpenGL for quite a while. I'm still not using any vertex/frame buffer objects, because I'm lazy and display lists or normal glDrawElements gets the job done. So I'm pretty much used to dealing with vertex and polygon counts around a few hundred thousand or so.

To test the XNA and/or XBOX 360 fillrate and geometry processing power, i crafted a spikeball ;) with 242 000 vertices and 429 000 triangles, put it rotating on the screen and it ran smooth as a baby, just as i expected. So i increased the amount of the objects rotating in the screen to 4, then to 10 (still running about 60 fps) and finally to 50. The last one was the point where things were starting to run slow (that's 12.1 million vertices, 21.4 million triangles).

So I must say I'm really positively surprised about the GPU power the XBOX 360 has. Currently the effect has about 4.8M vertices and 8.6M triangles with a vertex shader doing 9 sines per vertex, and a pixel shader doing calculations (plus another pixel shader for post processing) and it runs without any notable slowness.

I think you're going to see a lot more polygons on the screen with 360 compared to previous STS demos :)
4 comments|post comment

Getting started [14 Jun 2007|09:36pm]
[ mood | blah ]

First post from yours truly.. Tried getting started on the Xbox 360 demo tune today, not much results to brag with. I had some basic sound elements edited and laid out beforehand, so I was expecting to get started with some more inspiring stuff than coming up with a working sound set for bass/rhythm section etc. First results are definitely not too encouraging, it's once again going to take hours and hours to get anywhere near something even semi-satisfactory.

For this Xbox 360 release I'm planning on using a more flow-based approach instead of the usual "graph/plan out a skeleton of the whole song first" I've used when making the previous releases. You know, just start laying elements down from the beginning without too much planning and see where it builds from there. Several hours of placing bits and pieces around and I'm just totally getting lost in a mess that seems to be branching out in too many directions and wrecking all inspiration I had to boot with.

As it turns out, trying out a different work flow is definitely _NOT_ a good idea at least today :/ .. Oh well, maybe give this current sketch a few days and then see if I can figure out which elements to focus on in order to pull things together a bit.

-- Man With No Alias

post comment

Out of memory issue solved ... shaders and others on their way [14 Jun 2007|12:59am]
There was actually two things i did wrong with the vertex data. First of them, as Gargaj pointed out, is the use of non-static class. Instantiating makes no sense when you're having the class just to contain data. My bad.

The other one (which actually solved the issue before making the class static) was a problem with XNA memory handling (i'd say it's their fault but some might think differently). Having all the vertices as "new Vector3(float, float, float)" was apparently hogging a lot more memory than it should (since Vector3 is only, or should be, a light struct). So i changed it to a regular array of floats and everything was fine.

After the 3d was running ok I made a shader that renders depth values as colours, since XNA doesn't have the capability to read zbuffer back to a texture (or that's what Shawn Hargreaves from XNA framework development said on MSDN forums). I think that is strange and even stupid since the Xbox 360 GPU should be capable to do that. There's also the Depth16 and Depth24 surfaceformats for Texture2D, but using them for resolving rendertarget produces the same result as a normal texture (=colours). Anyhow, some cool stuff from z-values are going to be made (not DOF effect).

After the shader stuff is ready, next up is a test with a bit more geometry data (100k vertices or so). Let's see how XNA handles that :)
1 comment|post comment

Out of memory exception [13 Jun 2007|11:04am]
First attempt to import some basic 3d models into XNA.

Since the XNA content pipeline is less or more a black box for me and I really don't enjoy learning what other people's code does, I decided to go the old way and preprocess the geometry to static C# arrays that can be directly included in the executable.

The vertex array looked something a bit like this:

public static Vector3[] vertices={
  new Vector3( -34.4842987f, -10.8710003f, 17.3239002f),
  new Vector3( -19.2481995f, -12.6113997f, 17.3239002f),
} ;

With about 7000 vertices (plus Vector2 texture coordinates) and 14000 faces the thing crashed with out of memory exception. Maybe the problem is with the use of "new Vector3", instead of just putting the data as static floats first, or maybe i have some stupid memory hogging piece of code i didn't notice. The crash occurred when instantiating the class that contains the static data, which points towards problems in XNA memory management. I'll have to test again today without using the Vector3 and Vector2 structs.

I hope we can solve this issue since if 7k vertices is a problem for XNA, doing any procedural 3D would be almost impossible, which would suck big time. Using the .x and .fxb formats isn't out of the question but i'd really prefer doing it my way :).

Posted by Medicine Man
5 comments|post comment

PLAY! and Siggraph [11 Jun 2007|11:48am]
We have received a couple of requests about showing our demos on public events.

PLAY! A Video Game Symphony is a world tour playing classic video game tunes with full orchestra and choir. They might (or might not) show parts of our demos as background visuals during their shows. They're on tour now, so go see them and let us know if they featured us.

Demoscene Outreach Group with Paul Debevec is planning a demoscene presence at the world's largest computer animation festival Siggraph. They will be showing our demos Aeon Flux and Electric Kool-Aid in their "Best of demoscene" show/booth/presentation (or whatever it is they're planning).
1 comment|post comment

Current projects [11 Jun 2007|11:28am]
There are a couple of projects we're working with currently:

- Intel demo competition 2007 (http://intel.de/demoscene)
- XBOX 360 demo with XNA (http://msdn.microsoft.com/xna/)

The intention is to blog about the progress of these projects (mainly the 360 project) and maybe future projects too.
3 comments|post comment

[ viewing | most recent entries ]