An idea...
category: general [glöplog]
Why not post hardware requirements for PC demos... Not everyone has the latest hardware or even a fast internet connection, so it might be good for those people to be able to know if they can even watch a demo before they commit to a largish download over 56k or so.
how about reading the infofiles? :P
That works. Sometimes. If there's a proper infofile and the prod was subitted in a way that would allow the infofile to be read before the whole thing is downloaded. But not everything has that...
Maybe it would be better to simply divide the PC catergories into Low-end (under 300 MHz) Mid-end (300-1Ghz) and High end catergories.
Maybe it would be better to simply divide the PC catergories into Low-end (under 300 MHz) Mid-end (300-1Ghz) and High end catergories.
Yeah it'd be damn simple.
Or maybe you could submit the nfo of the prods having it only their archive, or if there's no nfo at all put a comment to say if you managed to get the prod working.
Or maybe you could submit the nfo of the prods having it only their archive, or if there's no nfo at all put a comment to say if you managed to get the prod working.
i think a simpler 'shaders version' (none, 1.1, 2.0 eg) could do in the near future, and may be easier to mantain and add
btw shouldn't there be an appropriate "hint me beautifull" thread?
Under 300MHz? So, that's like... 1997? Those can already be found in the "DOS" category.
gus supported, gus needed, no gus support, only sb supported, only LTP supported,...
needs VGA, needs ET 4000, runs only on voodoo class, doesn't run on TNT, ATI only, PS2.0 required, ....
uses 32bit, uses MMX, needs SSE, doesn't run on AMD64, ...
needs 400 MHz, doesn't even run decent under Via C3 10000, fucks up at more than 200 MHz, ...
needs fast EDO ram, 512 MB are welcome, needs 630k and 8 MB EMS, ...
I think I get your idea. What data into the database? Even ep ended up clueless. Solve that problem properley and ps might be interested (if you offer him some free booze). ;)
needs VGA, needs ET 4000, runs only on voodoo class, doesn't run on TNT, ATI only, PS2.0 required, ....
uses 32bit, uses MMX, needs SSE, doesn't run on AMD64, ...
needs 400 MHz, doesn't even run decent under Via C3 10000, fucks up at more than 200 MHz, ...
needs fast EDO ram, 512 MB are welcome, needs 630k and 8 MB EMS, ...
I think I get your idea. What data into the database? Even ep ended up clueless. Solve that problem properley and ps might be interested (if you offer him some free booze). ;)
MadenMann:
I didn't ended up clueless:
the VER db is about effects and not hardware configurations.
coders will only submit snipets of code (usually 10 to 100 lines of code, showing the main effect algorithm in C / ASM).
A comment had to be added in a separate category or at the top of the source so people can see what are the requirements for an effect.
The problem of configuration is not a problem ps nor anybody on earth can solve with a database:
PC and more generally technology are about quick and frequent changes, so nobody can maintain a static structure with so much fields, we hence have to make choices.
Mines are mainly done, and thanks to mados, I've already done the mysql database. I'll now make the php code to use the db from a website. And I've find who will host this 2 GB database...
I didn't ended up clueless:
the VER db is about effects and not hardware configurations.
coders will only submit snipets of code (usually 10 to 100 lines of code, showing the main effect algorithm in C / ASM).
A comment had to be added in a separate category or at the top of the source so people can see what are the requirements for an effect.
The problem of configuration is not a problem ps nor anybody on earth can solve with a database:
PC and more generally technology are about quick and frequent changes, so nobody can maintain a static structure with so much fields, we hence have to make choices.
Mines are mainly done, and thanks to mados, I've already done the mysql database. I'll now make the php code to use the db from a website. And I've find who will host this 2 GB database...
face it, it's a gamble, some demos just won't run correctly, even if you have the reqs, adding driver info, precalc rituals, moonphases and whatnot to the DB is insane, the bandwidth is squeezed as it is
we had that suggestion before, but if we started subcategorizing hardware requirements we would end up needing to state all hardware requirements, as in: all graphics cards it works in, vesa/novesa, gus/nogus. would end up a multitude of suboptions that would just complicate the search/listings and force people to go through all prods already in the database and fix the info for every new subcategory added. and then do it again when a new subcategory gets added again. which pouet users simply dont bother (they dont even bother filling out the missing partyinfo ffs, how the hell are they gonna bother filling out hardware requirements properly?)
you'll prolly mention that it's already beeing done for gus,
the special ms-dos/gus category is meant for _gusonly_ prods, as in, useless to try it without a dos gus machine, and it makes sense because a _great majority_ of prods released then had these problems. listing all dos prods (gus and non gus) becomes easy with the 3 multitype possibility of prodlist.php but if you think about it for every single pc hardware specification, it would be insane to search for all pc windows prods. not impossible, and quite usefull thats true, but it would overload the prodlist.php searching engine more then it already is, and while that is planned to be enhanced or alternative creation in the todo list, im not really willing to have to do it due to diferent pc hardware specs that no one even bothers to fill out properly..
whilst i can understand the need to have explicit hardware requirements next to the prod info, if nothing else for having lists of all prods running on radeons for example, the lists system that i been implementing (which already works, but isnt beeing used yet) will allow exactly that, to have a list of all prods for ps2.0 shaders only for example. and the idea is to keep the lists admined by reliable people, created on demand for users who wish to do that extra work of upkeeping their list up to date, and given for usefull uses of lists only, (useless freedom of speech flamewar here) and on the prod.php page of a certain prod we can have all the related lists listed. so people would see a direct link to "list of ps2.0 prods" and "list of radeon only prods" and have a fairly good idea what the prod is actually about. ofcourse there is the dual problem of both having only one or a couple persons to admin (which could run the list as they like and lag valid updates or disagree upon them and stir up unwanted discussions and rival lists which would just polute the damn archive) versus having the more usefull lists open to anyone for adding/fix (which will get ppl adding wrong stuff due to not understanding internal standards which will also stir up unwanted discussions and cause requests for "someone" to fix things)
the lists system is also usable for demologies, groupaffiliations, partylists of countries, etc.
its already working (submitlist.php and editlist.php for gloperators use, submitlistitem.php for list admins and lists.php for the common users)..
but still have a long todo list for it to be optimum before spamming it into full use.. better layout, a .php for removing items from a list, update index.php, update search.php, update prod.php, update submit.php, too much for me to bother right now.
and to answer madcrow' sub/high 300mhz division suggestion: it wouldnt work. ppl would want a 1ghz division next and then conclude having actual hardware and OS system explicit would be better and it would just lead to several redoings of the wheel trying to solve the travelling without moving issue. im not maso enough to fall for it. i did it for the intro subcategoring and im still fixing those prods on a nearly daily basis. im not really in the mood to invest more time fixing a whole new league of even smaller distinctions, specially beeing sick as fuck of pouet as i am.
you'll prolly mention that it's already beeing done for gus,
the special ms-dos/gus category is meant for _gusonly_ prods, as in, useless to try it without a dos gus machine, and it makes sense because a _great majority_ of prods released then had these problems. listing all dos prods (gus and non gus) becomes easy with the 3 multitype possibility of prodlist.php but if you think about it for every single pc hardware specification, it would be insane to search for all pc windows prods. not impossible, and quite usefull thats true, but it would overload the prodlist.php searching engine more then it already is, and while that is planned to be enhanced or alternative creation in the todo list, im not really willing to have to do it due to diferent pc hardware specs that no one even bothers to fill out properly..
whilst i can understand the need to have explicit hardware requirements next to the prod info, if nothing else for having lists of all prods running on radeons for example, the lists system that i been implementing (which already works, but isnt beeing used yet) will allow exactly that, to have a list of all prods for ps2.0 shaders only for example. and the idea is to keep the lists admined by reliable people, created on demand for users who wish to do that extra work of upkeeping their list up to date, and given for usefull uses of lists only, (useless freedom of speech flamewar here) and on the prod.php page of a certain prod we can have all the related lists listed. so people would see a direct link to "list of ps2.0 prods" and "list of radeon only prods" and have a fairly good idea what the prod is actually about. ofcourse there is the dual problem of both having only one or a couple persons to admin (which could run the list as they like and lag valid updates or disagree upon them and stir up unwanted discussions and rival lists which would just polute the damn archive) versus having the more usefull lists open to anyone for adding/fix (which will get ppl adding wrong stuff due to not understanding internal standards which will also stir up unwanted discussions and cause requests for "someone" to fix things)
the lists system is also usable for demologies, groupaffiliations, partylists of countries, etc.
its already working (submitlist.php and editlist.php for gloperators use, submitlistitem.php for list admins and lists.php for the common users)..
but still have a long todo list for it to be optimum before spamming it into full use.. better layout, a .php for removing items from a list, update index.php, update search.php, update prod.php, update submit.php, too much for me to bother right now.
and to answer madcrow' sub/high 300mhz division suggestion: it wouldnt work. ppl would want a 1ghz division next and then conclude having actual hardware and OS system explicit would be better and it would just lead to several redoings of the wheel trying to solve the travelling without moving issue. im not maso enough to fall for it. i did it for the intro subcategoring and im still fixing those prods on a nearly daily basis. im not really in the mood to invest more time fixing a whole new league of even smaller distinctions, specially beeing sick as fuck of pouet as i am.
Don't want to disrupt too much, but wouldn't it make sense to be able to report what configuration this or that production _doesn't work on_ rather than what it supports? It should definitely be smaller, and concentrates on what pains users. I'd usually want to see the demos that run on my hardware, more than the demos that run on my hardware only. (unless I'm really getting pissed at everybody else at the moment ;)
i'm too young to remember, but i wonder how you were used to do when pouet was just an idea in someone's mind and there wasn't no other so complete demo-db all around. now it seems that everyone needs a "requirements db" for the pleasure of "my ass i too heavy so i need a "click me beautifull" button to find some demo for the evening". actually everyone has a dsl connection with fistful of mbits, so i think isn't a matter of "downloading ten mbs of a demo and see that it need somethingspecialandalientechnology-shader it's a kick in my arse". the actual and usefull [nfo] link should be enough for everyone who can read something like "r9800 and above only" and obviously for who may write that nfofile. not mentioning that such db will quickly become huge and outdated as hell, and that there's an immense and painfull "fill the db" task.
that's my humble, feeble and sprained opinion.
that's my humble, feeble and sprained opinion.
Though "software/hardware rendered" would be easy enough to distinguish and there wouldn't be too much prods to adjust.
again, a huge req list would be just too much hassle for everyone imho. huge database of mostly unused information.
about the new "pouet beta1" lists, i was thinking of something like that to link demology.tk here too, so I apply for betatesting =)
about the new "pouet beta1" lists, i was thinking of something like that to link demology.tk here too, so I apply for betatesting =)
ps: thx!