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...
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...
Dbug: I guess that's what the system Gargaj is working on is all about:
> 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
does Commodore 64 platform needs to be subdivided?
:-D
Quote:
@psonice: "Platform: iOS" seems fitting?
Yep, that'll do. This new requirement thing might be useful to narrow it down :)
@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.
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.
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.
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.
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.
What you gonna do then with all already existing NFOs (tens of thousands)?...
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.
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.
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).
All parties and compos should be canceled until this taxonomy thing has been sorted out.
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!
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!
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.
Generally, it would be nice if nfos became popular again. Any requirement deviation from selectable platforms could be in there, as 4mat hints.
Odroid icon that could theoretically be added for this:
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.
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.
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.
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.
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").
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").
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.
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.
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.
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.
(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!
List of Neo Geo productions on Pouet
List of demoscene-ish Pico-8 productions
Feel free to update/append those lists.
- NeoGeo 3D ! by Oxygene
- Twister in a mirror
- Eira by Resistance
- Visual Novel by trilobit
- DIFF by citavia
List of demoscene-ish Pico-8 productions
- Orbys by POD
- Duangle 2015 intro by Paniq
- PICO-8 Jam #1 Invite
- Babysteps by Dekadence
- PicoRulez by Razor1911 <- not on Pouet yet (still WIP, @rez ?)
Feel free to update/append those lists.
You forgot one
@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.
List of Neo Geo productions on Pouet
- NeoGeo 3D ! by Oxygene
- Twister in a mirror
- Eira by Resistance
- Visual Novel by trilobit
- DIFF by citavia
List of demoscene-ish Pico-8 productions
- Ad Astra by ate bit
- Orbys by POD
- Duangle 2015 intro by Paniq
- PICO-8 Jam #1 Invite
- Babysteps by Dekadence
- PicoRulez by Razor1911 <- not on Pouet yet (still WIP, @rez ?)
Feel free to update/append those lists.