|
Wobble by CRTC
[nfo]
|
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||||||
|
popularity : 66% |
|||||||||||||
alltime top: #3143 |
|
|||||||||||||
|
||||||||||||||
added on the 2010-04-06 11:39:14 by ltk_tscc  |
||||||||||||||
popularity helper
comments
Youtube prz !
added on the 2010-04-06 11:50:54 by panic 
i second that. video please.
Platform!
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.
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.
Oh yeah, NullDC link
Sorry guys, but the DC is capable of so much more...
Designwise it didn't get me either, piggy for the effort
Designwise it didn't get me either, piggy for the effort
Good enough.
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 :)
But I'm so happy to see a DC prod that I would have been happy to watch a Metalvotze joke demo :)
im with hopper.
dunno if its the emu, but had a lot of glitches here !
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.
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.
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" ;)
http://www.youtube.com/watch?v=g2PyYxI_An8
Filmed out of love so have mercy on the quality.
http://www.youtube.com/watch?v=g2PyYxI_An8
Filmed out of love so have mercy on the quality.
Cool!
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.
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.
hm....
This looked cool for the Dreamcast, at least the half I have seen because the streamer stopped during that moment and I lost everything.
And yey, more demos from dreamcast. I might be able to watch this in my portable treamcast too I think.
instant thumb up! sega + supreme ntm sample
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 :)
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 :)
Smokelife have some more stuff to listen to at http://soundcloud.com/smokelife by the way, if you like the soundtrack!
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
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!
Nice enough + Platform = Thumb
SEEEGGAAAAAAAAAAAAAAAAA!
you know how to please me!
Nice demo.
This demo was made with the free library KOS, which still receives updates.
@Hopper
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.
This demo was made with the free library KOS, which still receives updates.
@Hopper
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.
SEGGGGGGGGAHHHHHHHHH
OOOOOOOOOOKISH
Yay, a new Dreamcast release!
Fire/smoke:ish effect in the screenshot looked very good.
Fire/smoke:ish effect in the screenshot looked very good.
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.
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.
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 :)
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 :)
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
Sounds like a lot of untapped potential for a demo.
(from http://msdn.microsoft.com/en-us/library/ms834190.aspx
Quote:
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.
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).
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.
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.
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. ;)
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.)
(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.)
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!)
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!)
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...
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...
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
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
IV MY PEOPLE !
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!]
Very inspiring since i'm also messing with KOS (even got a USB <-> serial interface attached to my DC.)
[Thx for the source puppeh!]
usually i would thumb up a DC release blindly, but this is just way too simple..
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.
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.
SEEEGAAAAAAAAAAAAAAAAAAAAAAH
incoherent design but had it's moments. f.e. the flame thing was cool enough to get a thumb
thx for video :D
i really love the flame effect
what waffle sid.
thumbs up
what waffle said
Great stuff, really
wow
I don't thumb-up because of the music...
I thumb it especially because of the music.
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!
Cheers!
Would have used the different music, but it is my personal opinion.
UP and would like to see sth more on that great console!
Cheers!
Nice!
For the platform, and also the cool effects.
For the platform, and also the cool effects.
I can't believe we made a demo for the dreamcast! how crazy are you exactly?!
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.
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.
Quote:
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!
Don't like the design, unusual platform or not.
A NTM sample in a demo ❤️
CDI image again, please?
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 !