pouët.net

pouet - new platforms

category: general [glöplog]
Random question on the topic: For my Solskogen entry I picked-up "Oric" as a platform, but it obviously only works if you have this particular "Oric MCP40 Printer".
In a similar way, there are all these C64 demos that require the "REU" extension to work.

Perhaps we could use something to specify what particular extensions/peripherals are necessary to run the demo, like this amiga demo requires FAST ram, this STe demo requires the 10 megabytes hacks, this Oric demo runs only on floppy (not tape), etc...
added on the 2016-07-19 09:54:03 by Dbug Dbug
Dbug: I guess that's what the system Gargaj is working on is all about:

BB Image
> In a similar way, there are all these C64 demos that require the "REU" extension to work.

does Commodore 64 platform needs to be subdivided?

:-D
added on the 2016-07-19 16:18:19 by lvd lvd
Quote:
@psonice: "Platform: iOS" seems fitting?


Yep, that'll do. This new requirement thing might be useful to narrow it down :)
added on the 2016-07-19 18:32:47 by psonice psonice
@PulkoMandy, good point. I did think about his prods when making my comment, but wasn't quite sure how to classify them. If we had tags, we could use a platform like Atmel that you suggested but a tag for Arduino, since such things would use Arduino bootstrapping and not run on a default standalone Atmel chip.
<goes to prod, types> "Requires a REU with 512kb ram" <posts>

Ah I see this demo requires a REU with 512kb ram.

Of course this requires the uploader to be bothered to document their own prod, but then so would tagging it as well.
added on the 2016-07-19 20:42:24 by 4mat 4mat
Imagine you go to scene.org file archive and download all releases for the party - where will all your tags go?
I will repeat myself 10th time: use .nfo file and best of all - it is also included in a package.

To be fair, what you could do is maybe define a common .nfo file structure, also maybe make it possible to parse it for search algorithm (if there is any). It's tricky though, because it should not interfere with all those ascii art there.
added on the 2016-07-19 21:34:38 by tomkh tomkh
The idea of putting information in the nfo is not stupid, and it does not have to be at the top, could just be anywhere in the file with some identifier to make it easier to parse.
added on the 2016-07-19 22:45:30 by Dbug Dbug
What you gonna do then with all already existing NFOs (tens of thousands)?...
added on the 2016-07-20 00:03:05 by lvd lvd
lvd: many of those older .nfo/.diz etc.. have hw requirements already, but it's a valid point.

It's well-known that both folksonomy (democratic/collaborative tagging) and more fixed/hierarchical taxonomy have pros and cons. Obviously, like some people have already said, if you allow adding any tag it get messy pretty soon e.g. tags become simply inconsistent. And for fixed - "fix me beautiful" ;)

I suggested that maybe we should define a common structure for .nfo files, but as you say, now I see that it's also not the best idea.

It's really not an easy problem - I would really love to find out some better ways of creating taxonomies myself.
added on the 2016-07-20 00:46:21 by tomkh tomkh
Apart from selecting best way of taxonomying, it is also an interesting question: how would all those already existing prods sorted according to new rules (if any)? It is by itself seems to be gigantic work (of course much less problems with newly adding prods).
added on the 2016-07-20 14:50:58 by lvd lvd
All parties and compos should be canceled until this taxonomy thing has been sorted out.
added on the 2016-07-20 17:55:31 by yzi yzi
yzi: lol, obviously whole tagging discussion is derailing the topic which is new platform proposals I believe.

My two cents to the actual topic: it seems more sense to me to have...
platform: Wild, Type: Animation/Video, not the other way around, thanks!
added on the 2016-07-20 18:03:24 by tomkh tomkh
yzi, that's not helpful, people release outside compos as well. All demomaking has to be halted instantly!
Obviously yzi is joking though ;)

Generally, it would be nice if nfos became popular again. Any requirement deviation from selectable platforms could be in there, as 4mat hints.
added on the 2016-07-21 00:43:35 by Photon Photon
Odroid icon that could theoretically be added for this:
BB Image
But to be honest, perhaps it's pointless to add a separate icon for every single possible manufacturer of these kind of boards - perhaps even Raspberry Pi is superfluous. Wouldn't it be better to just have an icon for 'ARM SoC'? Or even just 'SoC' since there's MIPS stuff too.
added on the 2016-08-12 23:20:44 by Trilkk Trilkk
hmm..

thinking that it might make sense to specify a json format for demo metadata. create a small page to generate it from clicking a few things, and then integrate that same functionality directly into partymeister, etc.

so all zips of releases start coming with a demometadata.json file, listing platform, sub-platform specs, authors, etc. either supplied by the authors, the party management system or later updated by random glopers to follow spec format providing as much standardized structured info as possible.

after the format being specified sites like pouet, demozoo, scene.org, csdb, etc could just look for it on the zip and follow the specs to display the info as they see fit.

not sure if it hasn't been considered before.
added on the 2016-08-13 13:40:40 by psenough psenough
Firstly: xnfo. Has anyone ever used it? What makes you think a JSON-ish reinvention of it will be more successful?

Secondly: "how are we going to get people to fill this data in?" is not the problem that needs solving here. There's more than enough spare human-power on the scene to do whatever data entry is deemed useful / necessary. I know this from the crazily industrious people I work with on Demozoo... On the other hand, placing the admin burden upon the people who are making the demos and preparing the release packages - often under extreme deadline time pressure - is pretty much the least efficient strategy possible.

The problem we really have to solve here, I think, is defining a schema that A) is both flexible and structured enough to represent the information we're interested in, and B) can cope with incomplete data (i.e. distinguishes between "this demo does not require platform feature X" and "this demo has not yet been classified as needing platform feature X or not").
added on the 2016-08-13 14:53:50 by gasman gasman
Pico-8? Don't know if it should be its own platform, but I'd at least consider it, as there are quite a few demos around already.
added on the 2016-08-13 19:13:04 by tomaes tomaes
didnt know about xnfo. although now that you mention it and i check the website, i recall pouet had an xnfo.php export / syndication, not sure if that was put in place by analogue or gargaj, but i recall it's name and i guess i never realized it was an actual standard.

about the xml vs json, json is more in.

i'm not a large fan of reinventing the wheel, so following xnfo would be nice. but it clearly hasn't been properly adopted by the community, or people would be using it seemlessly by now.

regarding putting more issue on makers: if it was more properly integrated / adopted on the current scene portals and party compo managment systems it would just be generated based on the usual information filled out. and others could contribute to fill it up with deeper grain of detail.

not sure how deeply (in terms of platform information) the xnfo spec goes, or if you're using it to share prod info between demozoo or pouet, but it could be a more obvious solution for sub-categories.

if current xnfo version doesn't have enough specified structure to give proper detail, next step would be to discuss and spec a revision to include such info? ofcourse it would be inglorious work if it wouldn't get adopted, so some scene politics would be in order to get the top portal admins / party orgas to agree on using it and help specify it.

keep getting flashbacks from all the useless work put into specifying vrml, x3d, collada versions that never really got properly implemented. wouldn't want sceners to be wasting their time improving a metadata spec that doesn't actually get used.
added on the 2016-08-13 21:58:06 by psenough psenough
A new if somewhat yet unsatifactory way of running 16-bit code on x64 :

(reposted here from my blog without links)
News
22/08/2016 NTVDMx64
Relevant work by Leecher1337/Dose this week publishing a ported NT4's Insignia Solutions' SoftPC 32-bit protected mode NTVDM emulation to Windows10 enabled by previous NT4 source code leak, OpenNT forum and Stephanos' combined efforts. NTVDMX64 enables running 16-bit DOS code on an AMD64 architecture x64 Long compatibility mode WoW64. Initially reserved for VAX VMS, DEC Alpha and the Mips architectures, Microsoft's compilation would default to Virtual 8086 mode for X86 - once the sourcecode was made available to the public Leecher1337/Dose was able to force the SoftPC 32-bit emulation even for X86 thus making it de facto runnable for X64's compatibility mode, notably on Windows 10. Read more mitigations here. You may find a fresh compiled NTVDM for x64 here. Use at your own risk for it requires a WoW64 "on-the-fly" code injection known as Heaven's Gate.
Cool, if this works it will definitely save me a lot of time. I'll try it tonight!
added on the 2016-08-23 20:10:37 by trixter trixter
List of Neo Geo productions on Pouet


List of demoscene-ish Pico-8 productions


Feel free to update/append those lists.
added on the 2016-09-04 16:46:09 by fra fra
added on the 2016-09-04 17:35:17 by 4mat 4mat
@4mat Oh, right! Sorry!!! :/

List of Neo Geo productions on Pouet


List of demoscene-ish Pico-8 productions


Feel free to update/append those lists.
added on the 2016-09-04 17:41:34 by fra fra

login