whats up with 6 minutes precalc on demos these days?
category: general [glöplog]
Ithaqua: in that case prefer GL_GENERATE_MIPMAP_SGIS if GL_SGIS_generate_mipmap extension is available.
If i had to do a demo (i may do a demo someday, eventually) i'd rather include everything inside the .exe as resources or just plain binary files instead of having to load separate files/zips.
Also performances killers are memory allocations: the more, the slower.
If i had to do a demo (i may do a demo someday, eventually) i'd rather include everything inside the .exe as resources or just plain binary files instead of having to load separate files/zips.
Also performances killers are memory allocations: the more, the slower.
Maybe people should use an installer that does all the -> nmap / ->dxt conversions ONCE, so that the demo loads fast every time. It would however increase disk space, I guess - but the size limit is for release archives anyway, so I don't see a problem there.
i'd rather watch most demos by doubleclicking the .exe within the .zip and know there's no shit wasting my diskspace afterwards
The plain exe still can cache the generated stuff on your hdd on the first run...
The chacing does work, but remeber the "demo must not write to hdd" rule.
talking about mipmap creation taking time is fucking clueless. it is one of the fastest thing (about factor 20x faster to dxt compression for example). generate mipmaps extensions (and d3d flag) are generally a BAD thing for performance. Only use it for dynamic textures because otherwise, whenever the texture goes to agp memory the mipmaps are discarded and recreated when they get swapped in.
talking about mipmap creation taking time is fucking clueless. it is one of the fastest thing (about factor 20x faster to dxt compression for example). generate mipmaps extensions (and d3d flag) are generally a BAD thing for performance. Only use it for dynamic textures because otherwise, whenever the texture goes to agp memory the mipmaps are discarded and recreated when they get swapped in.
@hitch : i believe it depends on how much mem do you allocate, because i have coded some algo which creates dynamic twodirectional lists of a pretty much amount of elements and does some heavy calculation on them ( actually object intersection algo ) and it still managed to run at ~300-400 fps on my machine.
eh forgot to insert `every frame` thats it.
new fame -> new lists
new fame -> new lists
Quote:
generate mipmaps extensions (and d3d flag) are generally a BAD thing for performance. Only use it for dynamic textures because otherwise, whenever the texture goes to agp memory the mipmaps are discarded and recreated when they get swapped in.
Sounds like a valid point but why would they be swapped in ? Agp memory exhausted ?
And if it's fast enough to be used for dynamic textures, why is it "BAD thing for performance" if the swapping doesn't occur ?
the__m: stuff like globalalloc and co. are slow (heapalloc may be faster) and i would rather allocate a block of memory for 10 or 100 entries at a time and use it to the full before allocating another block instead of calling a local/globalalloc each time i want to add a member into a linked list.
So if all of this is so fast: "whats up with 6 minutes precalc on demos these days ?"
I think kb has a point there with loading making things chop. I've noticed a bizarre effect: When an IDE drive is active, the system feels sloppy - even tho i'm using BusMaster DMA transfers and the CPU meter is showing like 2% or less. So i have a feeling that the CPU meter is not able to pick up the kind of lag that an IDE device causes.
Also when using SCSI, this kind of lag is not there! Even with slow scsi harddrives the system never gets this weird lag! I admit i don't know everything about the PC's puny architechture, but it seems to me like there's some kind of problem with IDE while SCSI works very well.
Also when using SCSI, this kind of lag is not there! Even with slow scsi harddrives the system never gets this weird lag! I admit i don't know everything about the PC's puny architechture, but it seems to me like there's some kind of problem with IDE while SCSI works very well.
if people are starting to precalc spherical harmonic lighting or similar in demos, the loading time will go through the roof. =)
(and the data is rather large, so it's not ideal to store it either)
(and the data is rather large, so it's not ideal to store it either)
realistic lighting is for wussies anyway. how about making them demos fun to watch instead?
is there a rule somewhere that says you cant do both? =)
JULIA TURDS ARE SOOO PRETTY.. NOT
Ithaqua: storing all mipmaps only take up 1.333x as much space as storing only miplevel 0... AND it give you more control.
kb: unless i've missed out on something big, mmaped files don't work too well with compressed datafiles. (hey, you need somewhere to decompress to; memory). sure, the archives themselves can be mmapped, but atleast i use unrarlib, dunno what it does.
i think unrar excracts all files to c:/temp folder or similair and then loads them from there.. prety much a fucked up library in general iirc.
As smash said, when people start to use techniques that involves alot of data you either have 2 ways to go, store it on disk (the way to go for games) or calculate it at load time (the way for demos). There is really no way out of this, however i guess coders can do alot to their loading routines and how they handle reads from files etc.
If the precalc is extremely low, chances are high that the demo/intro run out of memory... using 200 or 300MB RAM is not that rare, and page swapping is likely to kill loading speed almost entirely.
E.g., on my last-century machine, the Bauknecht demo loaded in a couple of seconds with 512MB RAM
Hint: a large swap file (at least 1GB minimum) is likely to speed things up as well ;)
E.g., on my last-century machine, the Bauknecht demo loaded in a couple of seconds with 512MB RAM
Hint: a large swap file (at least 1GB minimum) is likely to speed things up as well ;)
