does DOS platform needs to be subdivided?
category: offtopic [glöplog]
nosfe: logic that it is not possible to see emulator setups on pouet should mean that the admins and creators/developers of pouet wants people to watch demos on youtube is a totally unfair proclamation and an unvalid argument.
Demoscene is a sparetime project for most people, and they should do the things within the demoscene that they prefer the most, or they think is most fun.
I taket it that developing pouet features isn't that much fun - at least that's my personal opinion. Then again, I use pouet on a regular basis, and I'm happy that SOMETHING is here instead of being upset about what's NOT here - shit there are many things that are not here :)
Demoscene is a sparetime project for most people, and they should do the things within the demoscene that they prefer the most, or they think is most fun.
I taket it that developing pouet features isn't that much fun - at least that's my personal opinion. Then again, I use pouet on a regular basis, and I'm happy that SOMETHING is here instead of being upset about what's NOT here - shit there are many things that are not here :)
After reading a few of these threads, I've come to the conclusion that there's an easy solution.
Volunteer to actually do what you're asking for or STFU. :)
Volunteer to actually do what you're asking for or STFU. :)
psnoice: that's basically what I think too - I jut didn't want to start a negative discussion right away.
yeah, i don't mean to be too harsh. Some discussion on this kind of thing can be helpful.
It's just that splitting up the pouet database and re-writing the front end to match (which is probably more work than it should be from what I've heard :) is going to be quite some work. And then you have the problem that there's many thousands of demos that will need putting in the right group, most of that work is going to be manual labour, often the nfo won't specify the hardware exactly so you'll need to test it...
Which is why things like this are often discussed but it's super rare that there's any action at the end.
If you think it's a good idea and you're prepared to do the actual hard work on the other hand..
It's just that splitting up the pouet database and re-writing the front end to match (which is probably more work than it should be from what I've heard :) is going to be quite some work. And then you have the problem that there's many thousands of demos that will need putting in the right group, most of that work is going to be manual labour, often the nfo won't specify the hardware exactly so you'll need to test it...
Which is why things like this are often discussed but it's super rare that there's any action at the end.
If you think it's a good idea and you're prepared to do the actual hard work on the other hand..
I don't think the categories should be split up. But some extra metadata would be nice (even if it is non-searchable for the time being).
Eg, if users could tag prods with a CPU requirement, supported sound/videocards etc.
That shouldn't be all that intrusive to the database.
I'd help tagging a number of old DOS prods, if the option was there.
And, if there is a tagging mechanism, then I agree that DOS/GUS might as well be merged with DOS, and all the DOS/GUS prods just tagged with GUS instead.
The DOS/GUS category half makes sense because some prods simply don't work without a GUS. On the other hand, what poor excuse for a retro-scener are you anyway if you even try to watch demos without a GUS in the first place? The GUS is the most scene-worthy PC peripheral ever released!
Eg, if users could tag prods with a CPU requirement, supported sound/videocards etc.
That shouldn't be all that intrusive to the database.
I'd help tagging a number of old DOS prods, if the option was there.
And, if there is a tagging mechanism, then I agree that DOS/GUS might as well be merged with DOS, and all the DOS/GUS prods just tagged with GUS instead.
The DOS/GUS category half makes sense because some prods simply don't work without a GUS. On the other hand, what poor excuse for a retro-scener are you anyway if you even try to watch demos without a GUS in the first place? The GUS is the most scene-worthy PC peripheral ever released!
Quote:
i find it sad that pouet is not even trying to do that. but i guess the pouet admins want that people only watch demos from youtube.
first off, there's no "admins". there can be only one. (wolololo)
secondly, while i'm particularly hurt by that accusation, on a more higher level, i think the state of pouet's current db structure is common knowledge, and any "upgrades" on it would just make it worse to eventually clean the whole thing up. we've made reasonable headway with the 2.0 edition in the last two months (more on this later) and i have a few ideas on having sub-platforms or at least parametric distinction could be implemented (i.e. is a windows demo dx9, dx11, opengl, is an amiga 500 demo ocs or ecs, is a mobile phone demo series 60 or symbian, is a vic20 demo expanded or unexpanded, etc etc etc) but these things take time.
a reasonable compromise most of the time is to take a look at the nfo file; most of the time the requirements are written there clean and clear.
Quote:
it would be helpful if there would be a demoscene db that would actually have proper info for what kind of hardware/emulation would be good to run the demos in realtime.
Yes. That would help but you can't blame pouet.net actual design if people don't care about upload an nfo file that explain those requirements.
I mean, eventually Gargaj can add a great tag system in the future and, still, there will be lazy people who will forget to use it properly.
Quote:
@gasman asked "does ZX Spectrum platform needs to be subdivided?"
I'm pretty sure I didn't, but never mind :-)
I considered the whole "platform capabilities / requirements" business in some early draft of Demozoo, but reached the conclusion that doing it "properly" would send us down a rather deep rabbit-hole of complexity (attaching capabilities to platforms; defining orderings so that 286 < 386 < 486... except when it isn't; distinguishing between absolute requirements vs nice-to-have features vs not-strictly-required-but-the-demo-will-look-really-shitty-without-them; requirements that differ between different releases of the same prod; boolean operations for things that need a Voodoo3 AND a SB16 OR a GUS) so I've decided it's a battle I'm not going to fight, yet. You can get some of the way there with simple free-text tagging, though.
It sounds like this *is* exactly the sort of thing the MEGA folks are trying to tackle - see Indica's seminar from Revision.
Yes, I definitely would not try to be 'clever' in assuming that newer platforms are automatically backwards compatible (eg adding Amiga AGA to all OCS/ECS prods, or adding 386 to all 286 prods etc).
They may be compatible, then again, they may not. I think that's a risk the user will have to take for him/herself.
I think just listing one CPU/chipset on which it is SUPPOSED to work, is the proper way.
The same can probably be said for rendering API/shader version. Newer versions are generally backwards-compatible, but just listing the lowest version that works should be enough information.
Soundcards are a different case, since generally they are interchangeable (they are just competing products, rather than older vs newer iterations of a similar technology). So in that case all should be listed.
They may be compatible, then again, they may not. I think that's a risk the user will have to take for him/herself.
I think just listing one CPU/chipset on which it is SUPPOSED to work, is the proper way.
The same can probably be said for rendering API/shader version. Newer versions are generally backwards-compatible, but just listing the lowest version that works should be enough information.
Soundcards are a different case, since generally they are interchangeable (they are just competing products, rather than older vs newer iterations of a similar technology). So in that case all should be listed.
I'm so fucking tempted to start posting manure pics in threads like these, seriously, I can hardly hold myself back... With all due disrespect, please keep your "brilliant improvements" to yourselves unless you can also come up with a feasible plan to correctly add all the new variables to entries in the existing database, and how this much bigger dataset should be maintained and moderated. Please do keep in mind that maintaining the current dataset is already a pain in the butt, and that you will be laughed at for suggesting that moderation is not necessary.
Quote:
But the general solution here, would be some requirements management, either by user tagging (assisted by nfo-file parsing upfront) or some other req-list system, that would likely need constant maintenance. I'm sure Gasman and the demozoo people have that kind of stuff on their long to-do list, but pouet with all its internal and external inconsistencies is probably the wrong place to ask for it. :)
I like Tomaes' idea of maybe devising a "parsable" .nfo file through standardized tags. It would also bear the advantage of not heavying too much the burden on the admins.
I founded MobyGames, where tech specs are broken down to this detail, and even *I* think this DOS subdivided topic is incredibly stupid. What the balls?
BTW prods already put tech specs in .nfo files, just go look at them. No need to rewrite thousands of .nfo files!
BTW prods already put tech specs in .nfo files, just go look at them. No need to rewrite thousands of .nfo files!
Yeah, no need to subdivide DOS any further (GUS is enough).
@trixter: I did not know that you are one of the founders of MobyGames, that's cool ;-)
@trixter: I did not know that you are one of the founders of MobyGames, that's cool ;-)
First of all: what Havoc said. Go fuck yourselves you bunch of deluded counterpragmatic shitbags.
Having said that, I think Nosfe's idea is very nice: a sort of specification on how to run a specific prod. DOS is DOS, let's not clutter the database with more (sub)categories than we already have.
Having said that, I think Nosfe's idea is very nice: a sort of specification on how to run a specific prod. DOS is DOS, let's not clutter the database with more (sub)categories than we already have.
Just found a relevant Scali blogpost dating from 2012 entitled The Windows command prompt is *NOT* a DOS prompt!. Of particular interest is a remark by nickysn which summarizes well this issue in my opinion :
On a side note part of Scali's response to Nickysn seems incorrect :
Because under the hood and besides ring-0 thunking 386 prohibition (circumventable through selector cloning as demonstrated by such as Barry Kauler), MsDOS until Win98 is a real Dos. Even on latest service pack XP you can access this real DOS as so :
As for the impression, and only the impression that DOS was abandoned somehow along the way for some games/demos ceased to function properly whilst windows versions augmented : it is not the shell maker's fault that the full set (read compatibility) of OPL and legacy xga or Vesa modes specifications were dropped by motherboard manufacturers emulating wrongly. It is quite independent.
Also, somewhat related, although DOSBox seems popular amongst most users, my tests in other domains have indicated Bochs with dos 6.22 image for example to be more reliable than DOSBox.
Quote:
nickysn says:
May 24, 2012 at 7:52 pm
Yes, you are absolutely correct. However, think about it from the user point of view. What’s the difference between, say, Windows 98′s “MS-DOS Prompt” and Windows 2000/XP’s “Command Prompt”? There are more similarities than differences:
- both have the same UI
- both support roughly the same commands
- both can run MS-DOS applications
- both can run console Win32 applications
- both allow you to start Win32 GUI applications from the command line
- both support extensions, that aren’t available under plain DOS, like long file names
Yes, there are a differences under the hood – Windows 98 is running COMMAND.COM as a shell, which is a DOS executable and is actually the default MS-DOS shell, while the NT-based versions of Windows are running cmd.exe, which is a native Win32 console application, etc. However, from a user POV, nothing really changed to justify the name change and I guess that’s why people kept calling it “DOS prompt”. Of course, nowadays it’s a little stupid to call it that way, since, as you have pointed out, on 64-bit versions of Windows you can’t even run DOS programs in it anymore.
On a side note part of Scali's response to Nickysn seems incorrect :
Quote:
DOS has been gone for so long (since XP in 2002 it was completely gone
Because under the hood and besides ring-0 thunking 386 prohibition (circumventable through selector cloning as demonstrated by such as Barry Kauler), MsDOS until Win98 is a real Dos. Even on latest service pack XP you can access this real DOS as so :
Quote:
fasm %1.asm
pause
%SystemRoot%\SYSTEM32\command.com /P /C
echo g=256|debug.exe %1.com
As for the impression, and only the impression that DOS was abandoned somehow along the way for some games/demos ceased to function properly whilst windows versions augmented : it is not the shell maker's fault that the full set (read compatibility) of OPL and legacy xga or Vesa modes specifications were dropped by motherboard manufacturers emulating wrongly. It is quite independent.
Also, somewhat related, although DOSBox seems popular amongst most users, my tests in other domains have indicated Bochs with dos 6.22 image for example to be more reliable than DOSBox.