pouët.net

btw, i forgot to put the "exit if no ps1.1 found" bit in (late night partycoding again..), so if you have rubbish gfx hardware, god knows what'll happen.. =)

oh, make sure you dont have d3d debug runtimes on like stefan, it's an easy way to make it run veeery slowly.

main reasons for bad performance otherwise would be a slow cpu (the realtime synth likes a reasonable amount of power, less than 2ghz cpus can struggle) and a lack of fillrate - i got a few large rendertarget/full frame processes going on. although that really doesnt explain why a 2.8 with 9600 would be running slow, it ran well on less. mmm.

oh well. =)

shifter: it runs at a respectable framerate (above 30fps, not what i'd call very very slow) on my laptop with radeon 9000 mobility, and ran perfectly (full framerate throughout) on my home machine with a geforce 6600gt and the other machines tested on with geforce6-level cards. just checked it on my work machine too (which has a gf5700, renouned for being a pile of poo) and again, it worked at full framerate (vsync rate) throughout.
these days i set all the rendertarget sizes etc to be the appropriate resolution so it looks good on a typical, but good, gfxcard, which i would say is today a 9800 or gf6600. that means that here we have a 1024x1024 shadowmap that is applied quite a lot of times to give a blur. switching that shadowmap to a lower res makes it run fine on my laptop (and probably most low-end cards too), but makes it look worse, so i prefer to make it look better. (fuck the poor :D)

this is the technically simplest 64k i did in ages. the only likely bottlenecks are:
- cpu usage. all the machines i tested on have a good cpu, mix of amd and intel (at least 2ghz), i simply dont have access to a slower one. the music uses some power, although less than in che or death&taxes. some of the fx use a bit of cpu - i.e. they actually use cpu AT ALL this time - but not an unreasonable amount, it should be comfortable on any modern machine. and guess what, i actually did optimise the code.
- fillrate. there's no complex shaders or anything on the geometry, and no complex geometry either, so the only possible gpu killer left is the fillrate abusing fullscreen fx, namely edge detect and the shadowmap. this is where my radeon 9000 suffers, it really doesnt like applying large rendertargets to the screen. but again, on any decent gfxcard (like, 9600 or so i guess) it should be fine, and i'd rather have something that is nicer looking.

so. seeing as it worked perfectly well on so many tested machines, and there's nothing really risky here, i can't really give a reason why it should run badly when you used such "modern" machines to run it on (unless your definition of modern is 5 years behind the rest of the world). unless it's to offer a usual bullshit excuse like upgrading your drivers, or unless you were so stupid as to run it on d3d debug runtimes. maybe (it's quite possible) there is some stupid bug in the code which makes it incredibly slow on a certain config, i dont know - but i havent been able to get it to manifest itself on any of the 6 or more machines i tested it on.

perhaps if you give some details as to these machines you ran it on, it might help me find the problem.

to your "optimisation" comment - blow it out your ass. perhaps you should think to yourself, just maybe, "they actually know what they are doing, most other people said it ran smooth, maybe there is something funny going on here". cos as you should know, telling a democoder to optimise their routines could be one of the most insulting things to say to them. if i could sue for libel, i would ;)

noouch, aren't you quite the sherlock :)