whats up with 6 minutes precalc on demos these days?
category: general [glöplog]
why the bloody hell do all these demos nowdays take like 6 minutes precalc.. i mean ffs.. if it was an intro i could understand..
first the bauknecht demo, now the outtracks's demo.
wtf are they doing on the precalc? loading all textures to memory in the reconverting them twice and then calculating complex filters? i mean, wtf?!..
someone write a damn article on how to load stuff dynamically. 512 megs of RAM on a 1ghz machine should be enough to load 5 megs of textures/meshes and a 7meg .ogg in less then 2 minutes!! without swapping the living hell out of the HD no?
did someone forget to read the chapter about multithreading on the manual or what? O_o
am i missing something!?
first the bauknecht demo, now the outtracks's demo.
wtf are they doing on the precalc? loading all textures to memory in the reconverting them twice and then calculating complex filters? i mean, wtf?!..
someone write a damn article on how to load stuff dynamically. 512 megs of RAM on a 1ghz machine should be enough to load 5 megs of textures/meshes and a 7meg .ogg in less then 2 minutes!! without swapping the living hell out of the HD no?
did someone forget to read the chapter about multithreading on the manual or what? O_o
am i missing something!?
Agree with ya ps :(
soon it'll be 25 minutes of precalcing for a 3 minute demo
I recall some amiga intros from 98 that were really good... but they took about 15 mins precalc for a 10 min intro!!!
Maybe party organizers should show demos in full length, i.e. including the precalc phase. Then the duration of the precalc would perhaps have an effect on the people's voting, which might make democoders think about a bit of precalc-speed-optimizing.
adok please go shopping
adok: at the gathering all demos and intros were shown with precalc (we ran everything live)
i think the outracks demo precalcs the fractal object.
i think the outracks demo precalcs the fractal object.
winden: 15 minutes in 98 were slightly acceptable, 5 minutes in 2005 are not. :)
acctually, adok is for once right (wtf).
when we showed demos live (as tg supposedly did this year aswell) the max 3 or 5 min where acctually WITH precalc, and if you had long precalc.. well, you where doomed before the demo started.. I remember people fiddling with all kinds of "cpu friendly" effects to be able to precalc stuff in background.. but oh well :)
when we showed demos live (as tg supposedly did this year aswell) the max 3 or 5 min where acctually WITH precalc, and if you had long precalc.. well, you where doomed before the demo started.. I remember people fiddling with all kinds of "cpu friendly" effects to be able to precalc stuff in background.. but oh well :)
Yep, long loading times suck. Coders, please don't compress the textures at loading time or load meshes from XML with DOM and full schema validation (boo! :))
well yeah, it shouldn't be impossible to have some stuff running while you load new stuff in the background.
or make loadtros instead of the fucking loading bar.
or make loadtros instead of the fucking loading bar.
yeah, even rasters are enough.
I thought you quit nosfe?
I thought you quit nosfe?
we showed all pc demos live at bp, including full precalc (okay, minus the first second or so which you usually missed because of beamer mode switching :)
the bauknecht demo loaded for about 10 seconds on the compo machine. anything else is most probably a bug.
the bauknecht demo loaded for about 10 seconds on the compo machine. anything else is most probably a bug.
@Lord Graga: (shhh ! sh|_|t.up, he forgot to quit ! don't remember him >_<)
i dunno what's up with those loading bars nowadays. back in the days on the amiga we precalced while running another effect, or showing a picture so nobody would notice... well i guess noone cares anymore... :)
Showing things while loading is still next to impossible on the PC. You could think that the last ten years of OS development would allow using the HD and the GPU simultaneously (as, surprise, the almost same hardware in form of the Xbox is perfectly able to do), but still you can't load anything without everything else becoming somewhat choppy. And trying to load textures with d3d/opengl in one thread while rendering in another is also a baaaaaaad idea.
The other thing is that demo coding has become somewhat complex in the last years, and getting loading times small is a heap of work. The game i'm currently working on is able to load about 50 megs of level/texture data in less than eight seconds, but I know how much time went into the offline processing tool chain that made this possible - time the common demo coder just doesn't have nor wants to have. You can consider yourself lucky if there's a "system coder" in your group who loves to do that boring stuff instead of writing actual demos ;)
One tip though: USE FUCKING MEMORY MAPPED FILES AND DON'T COPY THE DATA AROUND LIKE TEN TIMES BEFORE YOU ACTUALLY USE THE STUFF. Yeah.
this is eg. how my game code loads textures for a level:
* open a mmaped file with all textures at once in it (all already DXT compressed or in whatever other format)
* call d3ddev->CreateTexture() a few hundred times and memcpy the single textures once (or convert them if the graphics card sucks ass, but this part can be easily neglected for demos nowadays)
* Close the file
This takes two seconds for 20 megs of texture data on a current PC. And if I try this the second time (and the stuff is still in the cache), you don't even NOTICE the upload.
So...
The other thing is that demo coding has become somewhat complex in the last years, and getting loading times small is a heap of work. The game i'm currently working on is able to load about 50 megs of level/texture data in less than eight seconds, but I know how much time went into the offline processing tool chain that made this possible - time the common demo coder just doesn't have nor wants to have. You can consider yourself lucky if there's a "system coder" in your group who loves to do that boring stuff instead of writing actual demos ;)
One tip though: USE FUCKING MEMORY MAPPED FILES AND DON'T COPY THE DATA AROUND LIKE TEN TIMES BEFORE YOU ACTUALLY USE THE STUFF. Yeah.
this is eg. how my game code loads textures for a level:
* open a mmaped file with all textures at once in it (all already DXT compressed or in whatever other format)
* call d3ddev->CreateTexture() a few hundred times and memcpy the single textures once (or convert them if the graphics card sucks ass, but this part can be easily neglected for demos nowadays)
* Close the file
This takes two seconds for 20 megs of texture data on a current PC. And if I try this the second time (and the stuff is still in the cache), you don't even NOTICE the upload.
So...
I think that the outracks demo (no kelvin) is calculating a 500k polygon mesh using marching cubes on a 4d juliabrot..
(but I suppose one could have 'cached' the mesh into a '3ds' file, a large one indeed, but highly compressable).
Loaders with 'animation' can be made (well, at least a 'chunky' animation) by simply putting a callback function inside all your 'loadjpg / load3ds ...' each one progressing the rendering x amount of time - depending on the load of the operation. Ofcourse problem is to be found with big operations such as 'load .ogg' .. Planet risk has a very similar approach...
(but I suppose one could have 'cached' the mesh into a '3ds' file, a large one indeed, but highly compressable).
Loaders with 'animation' can be made (well, at least a 'chunky' animation) by simply putting a callback function inside all your 'loadjpg / load3ds ...' each one progressing the rendering x amount of time - depending on the load of the operation. Ofcourse problem is to be found with big operations such as 'load .ogg' .. Planet risk has a very similar approach...
On gba, you can have an interrupt firering every frame - It's easy to make it draw something while loading.
My GBA demo took 5 seconds to precalc. It irretates me, but it would cost quite a bit of ROM size to make it take less.
My GBA demo took 5 seconds to precalc. It irretates me, but it would cost quite a bit of ROM size to make it take less.
kb.. lets see.. 50meg... i thought 512MB was absolute minimum today..
so.. fire up a 25meg ZIP instead into memory, decompress and load it via a nice memory stream object and voila, no need to access harddrive..
afterall, its the harddrive thats slow when loading stuff and not the cpu/gpu/memory.
so.. fire up a 25meg ZIP instead into memory, decompress and load it via a nice memory stream object and voila, no need to access harddrive..
afterall, its the harddrive thats slow when loading stuff and not the cpu/gpu/memory.
we're the fucking scene. do stuff realtime.
megadelux: if you become HDD limited, it's pretty good by then.
I think kb's point was - and I want to second that - don't do excess memory copies. Store as much as possible in native formats. That would mean: store textures as dds (not png); store vertices direcly like they would be laid out in a vertex buffer (not 3ds), use mmapped files for nearly everything, don't parse dozens of megabytes of textual data, etc.
I think kb's point was - and I want to second that - don't do excess memory copies. Store as much as possible in native formats. That would mean: store textures as dds (not png); store vertices direcly like they would be laid out in a vertex buffer (not 3ds), use mmapped files for nearly everything, don't parse dozens of megabytes of textual data, etc.
NeARAZ: This is all well and good, but where was your demo at BP? :)
why should people still use callbacks for animated loading screens? use multithreading damnit
Works perfectly fine on older PCs (animation might be chunky, but you know how that goes), works perfectly well con any (very common) Hyperthreading processor...
... and definitely works like a charm on multiprocessor systems :)
*AND* it's easier to code :)
Works perfectly fine on older PCs (animation might be chunky, but you know how that goes), works perfectly well con any (very common) Hyperthreading processor...
... and definitely works like a charm on multiprocessor systems :)
*AND* it's easier to code :)
sagacity: uhm, well, aaah, you see... we thought about doing demo for BP, but, oh well... (you get the point)
Jcl: not so easy if both threads try to use the gfx hardware. At least you have to guarantee exclusive access...
Jcl: not so easy if both threads try to use the gfx hardware. At least you have to guarantee exclusive access...
NeARAZ: it's as easy as making a context not being the screen for one thread and the other one for the animation... we're talking about a loading screen here :)