Wobble by CRTC
screenshot added by Marq on 2010-04-06 19:41:00
platform :
type :
release date : april 2010
release party : Breakpoint 2010
compo : wild demo
ranked : 7th
  • rulez 28
  • is ok 16
  • sucks 0
popularity : 0%
  • rulez 0.64
  • cdcs 1
alltime top: #2653
added on the 2010-04-06 11:39:14 by ltk_tscc ltk_tscc

popularity helper

increase the popularity of this prod by spreading this URL:

or via: facebook twitter google+ pinterest tumblr


Youtube prz !
added on the 2010-04-06 11:50:54 by panic panic
i second that. video please.
cdc added on the 2010-04-06 12:09:13 by moqui moqui

Also, I spent a couple of hours trying to build a proper CD image - the instructions were a bit wrong on the README. Specifically (in the Makefile):

a) 1ST_READ points to a file that's on a hardcoded path in the coder's machine.
b) demo.bin isn't included as a file on the archive, but after spending quite some time on the makefile (I still don't understand them :)), I concluded that demo.bin is in fact 1st_read.bin.

So, if you want to make a CD of it, remove the hardcoded path and make a copy of 1st_read.bin with the name of demo.bin and then run make. I wasted a CD on this (moar coasters!) before thinking of using cdr/w :)

For those that can't be bothered, I created a CDI image and uploaded it here. I only tested it in the NullDC emu and it works properly. Will test it on my real DC when I can.
rulez added on the 2010-04-06 14:23:08 by すすれ すすれ
Oh yeah, NullDC link
added on the 2010-04-06 14:24:06 by すすれ すすれ
Sorry guys, but the DC is capable of so much more...
Designwise it didn't get me either, piggy for the effort
Good enough.
rulez added on the 2010-04-06 15:30:48 by xernobyl xernobyl
I would agree with Hopper, interesting code but what a lack of design...
But I'm so happy to see a DC prod that I would have been happy to watch a Metalvotze joke demo :)
rulez added on the 2010-04-06 15:41:03 by Shazz^TRSi^MJJ Shazz^TRSi^MJJ
im with hopper.
dunno if its the emu, but had a lot of glitches here !
Must ... thumb up ... Dreamcast ... products!
Seriously, this is not bad. Music and effects work together fairly well but it all looks too simple to be impressive and grafitti greetings logos are nice until they become pixelated, which is definetly easy to prevent on a Dreamcast.
Hope to see more from these guys on the Dreamcast, but for this time, it's a (smiling) piggy.
added on the 2010-04-06 18:59:07 by Paranoid Paranoid
I spent like 2 damn hours trying to get NullDC to run this demo flawless and I have come to the conclusion that it doesn't so I just filmed my goddamn crap tv running the demo on my dreamcast , so enjoy this "telesync" ;)


Filmed out of love so have mercy on the quality.

added on the 2010-04-06 19:59:01 by Tong Tong
rulez added on the 2010-04-06 20:32:43 by Agilo Agilo
Sorry about the coasters :-(. I kinda wrote the instructions in a hurry. Umm... so yeah, I know it could have been quite a lot better, but just getting it moderately finished enough to show on the big screen in time for the party was hard enough for me!

FWIW, I was trying to show a few effects which haven't been done much -- at least with the free tools -- on the Dreamcast. I.e. (fake) phong highlighting (in one pass!), render-to-texture (for the flame effect), nice environment mapping, and bump mapping. The Voronoi effect is kind of easy on pretty much any 3D hardware, I suppose. I guess I don't really do design :-p.

Thanks to ggi for the CDI image and Tong for doing a video grab! I can't do much better than that very easily myself, though I have a TV card I could try I guess. The BP orgas have a *very* good quality video (i.e. the one shown during the compo), but I don't know if they're planning to upload that anywhere.
added on the 2010-04-07 01:55:39 by puppeh puppeh
added on the 2010-04-07 02:49:57 by T$ T$
This looked cool for the Dreamcast, at least the half I have seen because the streamer stopped during that moment and I lost everything.
rulez added on the 2010-04-07 13:38:26 by Optimus Optimus
And yey, more demos from dreamcast. I might be able to watch this in my portable treamcast too I think.
added on the 2010-04-07 13:38:54 by Optimus Optimus
instant thumb up! sega + supreme ntm sample
rulez added on the 2010-04-07 23:40:07 by moqui moqui
awesome, the fire/smoke effect thing near the end looked damn nice, nice to hear some dubstep aswell, and my dreamcast just got horny for you guys, respect :)
rulez added on the 2010-04-07 23:47:58 by keito keito
I guess I'll have to trust the guy who sat next to me during the compo about how hardcore some of this stuff is - then again I liked what I saw anyway :)
rulez added on the 2010-04-07 23:49:11 by Alpha C Alpha C
Smokelife have some more stuff to listen to at http://soundcloud.com/smokelife by the way, if you like the soundtrack!
added on the 2010-04-08 11:59:06 by puppeh puppeh
One must question why pouet added another youtube link (http://www.youtube.com/watch?v=CChfCHvGCe0) that was ripped from my youtube link http://www.youtube.com/watch?v=g2PyYxI_An8
added on the 2010-04-08 12:18:24 by Tong Tong
I watch the video now again. So many cool effects for the dreamcast. Love the voronoi stuff. Also there is phong (fake?), envmap, bump map and great fireball thing. Cool!

added on the 2010-04-08 12:22:31 by Optimus Optimus
Nice enough + Platform = Thumb
rulez added on the 2010-04-08 12:39:00 by xeron xeron
rulez added on the 2010-04-08 15:59:29 by stfsux stfsux
you know how to please me!
rulez added on the 2010-04-08 22:16:45 by Bobic Bobic
Nice demo.

This demo was made with the free library KOS, which still receives updates.

The only way to get something 100% like Sega may have is to use a Sega Dev Kit, which uses a non free, non open-source Katana library. Sega isn't giving out the devkits, or licenses for it anymore. Anyone who does use one is using pirated material.
added on the 2010-04-09 13:19:15 by E.J. E.J.
rulez added on the 2010-04-09 13:40:13 by Queen_Luna Queen_Luna
added on the 2010-04-10 09:22:45 by Emod Emod
Yay, a new Dreamcast release!
Fire/smoke:ish effect in the screenshot looked very good.
rulez added on the 2010-04-10 11:58:12 by Sdw Sdw
This looks like a mediocre mid-00s pc demo, compiled on a fanboi platform.

I'm not familiar with the tools used, so I might be wrong here and it maybe was more work than it looks like, but regardless, it's not something I enjoyed watching either way.
added on the 2010-04-10 12:43:31 by tomaes tomaes
Well, being a former dreamcast developer I was not very impressed by what I saw on screen, but just for the sake of not wanting to complain without basis I took the time to download the KOS source code. Based on what I checked, you would not have got much more from the official SDK, possibly the 1st party developers had direct access to the sound and device hardware - but that's not a significant advantage for demo making.

So yes the KOS lib gives you access to the processor intrinsics (sincos seems to be the only one missing), there is support using store-queues, there is decent support for the various list of primitives (opaque, transparent and punch-through), and the code seems to do a decent job at handling the DMA and tile accelerator.

So from what I can see, you had about the same stuff as I had to use (Kamui), and well, this demo does not seem to use any of the specificities of the dreamcast like the volume modifiers or the per pixel perfect translucency sorting.

Now that you know how the dreamcast work, that you have a working SDK, makes some thing cool, and you will get my thumb up on the next one :)
added on the 2010-04-10 16:40:48 by Dbug Dbug
I had no idea that the dreamcast had so many cool features in hardware. I knew it was a tile renderer, but some of this is very interesting:

(from http://msdn.microsoft.com/en-us/library/ms834190.aspx

As triangles are sent to it, the Dreamcast hardware 3-D chip does not render the triangles scan line by scan line. Instead, it stores the triangles in video memory as they are sent. Once the entire scene has been collected, the hardware sends all triangles to the screen tile by tile, not triangle by triangle.

Every tile is 32 x 32 pixels. For each tile, the hardware selects the pixels that intersect the tile and retrieves for each pixel the closest triangle to the camera (viewport). Then this pixel is rendered to the screen by following the process of completing the interpolations, reading the texel, and so on. Thus, every pixel on the screen is actually rendered to the screen buffer only once. Other 3-D hardware systems render every pixel as often as that pixel is recovered by a triangle, but not the Dreamcast hardware.

By using this method, the hardware is not limited by the fill rate. No matter how many triangles recover a single pixel, that single pixel is rendered only once. Therefore, with the Dreamcast hardware, you don't need a Z-Buffer, because only the closest triangle is rendered.

In addition, with the Dreamcast hardware, you don't need to clip the triangles to the screen viewport, so there is no need for clipping tests and calculations. This is because the hardware renders graphics tile by tile. As a result, you don't need to test primitives, nor do you need to break up primitives into smaller primitives that fit on the screen.

The Dreamcast hardware does have to do several passes to render transparency, which slows down the rendering process a little. However, during that process, the hardware sorts the transparent triangles automatically, so your game engine does not need to sort them. Because your game engine doesn't have to do the memory manipulations that come with sorting, it avoids disturbing (slowing down) your 3-D pipeline. Even if the polygons intersect, there won't be any artifacts because the translucency sorting is done for each pixel by the hardware.

Not all transparent modes need several passes. The 5551 (Punch Through) mode does not need to combine the most recently rendered pixel with the pixel previously rendered to the screen buffer because 1 bit of alpha channel does not allow any degree of translucency. Such triangles are rendered with the same speed as opaque triangles—in a single pass.

Another feature of the Dreamcast hardware is that it has SH4 native operations that are fully supported by a set of intrinsics. The ones that we use the most are the dot product and the reciprocal square root. One special function that computes the sine and cosine of an angle is also very useful for character animation and camera movement calculations.

You can also apply the following Dreamcast hardware features to each pixel the hardware renders to the screen:

* Use a special surface mode to perform realistic bump mapping.
* Use a special texture mode (VQ compression) to complete texture compression with an 8:1 compression ratio plus 2 KB of overhead for the codebook.
* Test the on-screen pixel with a set of volumes, and apply a specific operation to the pixels inside or outside of the volume (color modification, transparency, or the texture ID). This makes shadows, lighting, and other special effects easy, and it doesn't break up the 3-D geometry pipeline.

Sounds like a lot of untapped potential for a demo.
added on the 2010-04-10 19:15:36 by trixter trixter
Yeah, all those things are probably true... I wanted to try to do something with the modifier volumes and/or cheap shadows, but I ran out of time :-p. Maybe next time (if there is one, heh).
added on the 2010-04-10 19:35:21 by puppeh puppeh
You could also use the VMU as a part of the demo, to display stuff on them while the demo is running :)

If you use VQ texture you can have a lot more textures in memory at the same time.

trixter: the article your pasted is globally correct, but there are still some things to consider: You need to do the near clip on the strips, and when you generate strips you don't want the longest possible strips (in my experience 6 to 15 triangles is the optimal size) because the final rendering performance is dependent on the number of tiles covered by the bounding rectangle occupied by the projected stripe.

So if you try to get very long stripes by using fancy libraries, you get the risk of having the bounding box of the stripe to cover the whole screen, which will force the PVR to check every single damn tiles. It's also increasing the memory requirements.

One of the most important things, is to not forget swizzling the textures, it has a huge impact on the performance (Mip-mapping as well, don't use non mip-mapped textures if you can). And don't use anisotropic filtering if you don't need it, it's a performance killer.
added on the 2010-04-10 20:16:17 by Dbug Dbug
Nice enough. Work a bit on the design next time and you'll have a nice DC demo. =) Liked the greetings part. Won't say anything about the music though. ;)
added on the 2010-04-10 20:31:53 by StingRay StingRay
I did actually use VQ textures (the skybox & building textures are VQ-compressed), but I didn't realise using long strips could be counterproductive -- interesting, thanks!

(I did notice that transparent polys seemed to be far more expensive than I thought they should be... I suspect over-long strips are part of the reason for that. Hmm.)
added on the 2010-04-10 23:28:55 by puppeh puppeh
You can do cool things with the VQ textures. Since the dictionary part is separated from the actual texture, you can use that to do fake palletized modes, or some funky effects by patching the dictionary instead of the texture itself :)

Transparent polygons are costly, yes, so things like big alpha-blended stuff tend to be inefficient. Some of the transparent stuff can be heavily optimized. Typical examples are overlay pictures, or non squared logos, or things with a "faded border". Instead of just using a big alpha texture on one single polygon, just use two passes, the first using the punch-trough mode, the second with the full alpha texture.

When filling the DMA buffers, something worth mentioning is that if you know in advance the size of what you are sending, you can often optimize by writing backward (pre-decrement is faster that post increment), and preloading stuff using the prefetch instruction.

Should also check that your compiler aggressively uses all the registers. I know the hitachi compiler (SHC) sucked at that, but on the other hand it was stupid and just using "register float bla" would make "bla" correctly associated to a free float register, same for integer/pointers, resulting in much faster code - because the compiler can fill the delay slots :)

A last trick is to use non standard order to matrices. If instead of storing things so you get X, Y, Z as a result, you can't start the projection immediately. If you shuffle everything so you get Z out first, you can immediately compute the inverted Z, and by the time the divide is done you get the next computed value our of the matrix computation ready to be multiplied, effectively eating out the cost of the projection.

For the frame-buffer, did you use the 16 or 24 bit mode? Internally all the tile blending is done in maximum definition, and the result is then converted/dithered to 16 bit if you enabled 16 bit frame buffer, and frankly the difference in visual quality is not worth wasting texture memory for a 24 bit frame-buffer. (plus it's slightly faster).

Oh, last question, in KOS do you have support for 2V and 3V latency modes? In a demo the 3V mode would be optimal, because you can use VSync and still amortize the cost of frames that are longer than others without dropping the VBL. (In a game it's a bit annoying because it adds latency in the controls, but in a demo, go for it!)
added on the 2010-04-11 10:49:46 by Dbug Dbug
More interesting stuff, thanks... I was using GCC 4.4, which should be quite capable of optimising nicely for the SH4. There isn't direct support for intrinsics -- there's only inline asm, and since GCC doesn't really understand the vectors or matrices supported on the Dreamcast's specialised SH4, you're stuck with fixed registers for the operands of ftrv & friends. But, it seemed like the PVR was the bottleneck for framerate rather than the CPU, so that's somewhat moot. (Also, as long as you only use a single inline asm per loop iteration, you probably don't lose anything to register shuffling, to a first approximation).

I'm not entirely convinced about the non-standard matrix-order trick, tbh: if you're doing more in your vertex-submission loop than just transforming data and blatting it to the PVR (or a DMA buffer), e.g. doing per-vertex lighting or whatever, then does saving a handful of cycles for the transformation really make that much difference?

The demo uses a 16-bit framebuffer (I'm not sure if 24-bit framebuffers even work with acceleration out-of-the-box with KOS). And, there's no support for tweaking frame buffering, I don't think, unless you rewrite significant chunks of stuff yourself: you're stuck with 2V (I think, using your terminology). So you either have 60fps, or 30fps, or 20fps...
added on the 2010-04-11 13:21:33 by puppeh puppeh
What I call 3V mode is when you double buffer the DMA queues, and when the PVR side is also double buffering the TA data. By doing that you almost never have to stall the render for graphic primitives to arrive, and you don't have to wait either for the DMA to be done before you send data for the next frame.

Concerning the optimization, I found out that in my case I was slowed down by the DMA transfert, not by the CPU or by the PVR itself.

One of the big improvement I got was when I stopped using the hardware culling and instead do the visibility testing myself. By doing that I managed to write/send about 1/3rd less primitives to the DMA. I also had to do the near clipping of my stripes (in a game you can't really control what the user's doing), so I needed all the CPU I could, so yeah saving cycles when transforming was kind of important :)

(For the landscape I even did 2d "cone of vision" clipping to limit even more the amount of stuff to send to the dma)

About GCC I don't know, never used it. It's not that trivial to optimize for the SH4, things like immediate values being stored as pc relative data chunks you have to jump over is not that a common architecture :D
added on the 2010-04-11 14:55:19 by Dbug Dbug
rulez added on the 2010-04-11 21:26:31 by bLa bLa
I was very surprised to see a Dreamcast demo at BP.
Very inspiring since i'm also messing with KOS (even got a USB <-> serial interface attached to my DC.)

[Thx for the source puppeh!]
rulez added on the 2010-04-12 09:09:39 by Jae686 Jae686
usually i would thumb up a DC release blindly, but this is just way too simple..
added on the 2010-04-12 11:56:36 by toxie toxie
Dbug: oh, I understand what you mean about 3V mode now: yeah, KOS supports that (or something very similar), calling it simply "DMA" mode. But, not all the effects in the demo (particularly the fire) worked when I tried to use that -- probably user error -- so I had to turn it off.

I did implement my own near clipping (needed for e.g. the building fly-through), though no more geometry culling than that (there's not really that much geometry in my demo, heh). I'll keep those optimisations in mind if I ever do DC programming again, for sure :-).

Incidentally, the BP team have uploaded their ultra-nice video grab of the demo here now.
added on the 2010-04-12 14:31:14 by puppeh puppeh
rulez added on the 2010-04-15 16:31:48 by nekomono nekomono
incoherent design but had it's moments. f.e. the flame thing was cool enough to get a thumb
rulez added on the 2010-04-15 20:53:15 by waffle waffle
thx for video :D
rulez added on the 2010-04-18 17:44:09 by panic panic
i really love the flame effect
what waffle sid.
rulez added on the 2010-04-18 18:27:29 by comankh comankh
thumbs up
rulez added on the 2010-04-18 18:44:13 by zefyros zefyros
what waffle said
rulez added on the 2010-04-19 02:41:10 by wullon wullon
Great stuff, really
rulez added on the 2010-05-01 11:36:18 by Maturion Maturion
rulez added on the 2010-07-22 12:46:45 by abscess abscess
I don't thumb-up because of the music...
added on the 2010-08-17 19:30:52 by RaHoW RaHoW
I thumb it especially because of the music.
rulez added on the 2011-03-18 22:14:19 by jack-3d jack-3d
Fat dope stuff! The efx are nice, except the wall graffiti tee-ups which are not too pro, but the demo is really nice.
Would have used the different music, but it is my personal opinion.
UP and would like to see sth more on that great console!
rulez added on the 2011-08-18 00:26:03 by sim sim
For the platform, and also the cool effects.
rulez added on the 2012-01-06 17:14:34 by Romain337 Romain337
I can't believe we made a demo for the dreamcast! how crazy are you exactly?!
rulez added on the 2013-04-02 11:28:15 by megmeg megmeg
piggy because of the dubstep
also kinda poor graphics
and badly assembled, wasnt able to run it in any emulators or burn it easily
thanks for the one dude that posted a cdi image.
added on the 2014-01-13 03:33:12 by webodan webodan
piggy because of the dubstep
also kinda poor graphics
and badly assembled, wasnt able to run it in any emulators or burn it easily
thanks for the one dude that posted a cdi image.

the dubstep was ok for the time it was made, guess it's down to taste really.

This was the 'first' demo CRTC ever made and all done by just one coder.

We should have a thread for people to show first demos!
added on the 2015-11-23 20:43:30 by megmeg megmeg
Don't like the design, unusual platform or not.
added on the 2015-12-18 11:22:31 by Kylearan Kylearan

submit changes

if this prod is a fake, some info is false or the download link is broken,

do not post about it in the comments, it will get lost.

instead, click here !

[previous edits]

add a comment