"Naked" compos?
category: general [glöplog]
I am sorry if I came over like that. That is clearly not my intention.
Quote:
From the current reactions I figure that the interest in such a compo would be pretty low.
Close to non existant i would say.
That is if you're talking about establishing yet another compo category only for a certain "has yet to be defined" restricted platform.
For anything else there's always been the wild compo where you can do virtually anything. See e.g. http://2015.revision-party.net/compos/other
There have been quite some amazing releases throughout the years on the most absurd and obscure platforms. So go for that instead.
Nothing wrong in negotiating a platform specification with other people (if youn find them) and having the battle at some party in the wild compo.
Quote:
I am sorry if I came over like that. That is clearly not my intention.
no excuse me if i sounded too harsh, i do understand that this was not your intention, it's just that this kind of argument comes up every now and then in the demoscene and imho it's like disrespecting the effort that has gone into some decent modern demos. after all it is a matter of evolution and progress. in some years from now a coder in a demo production may not be required at all, since all the coding may lie in premade blocks of code or something (modern demotools and commercial engines are walking to this direction), but still skills and effort will be required to make a production look and sound good on the screen.
i think the increasing complexity of modern computers vs. the decreasing time people are able to spend on productions all point in the direction that such a compo would not be very successful, although very interesting as a mind experiment.
JTZ:
As for 32b there are no API calls which "do the trick", unless you count interrupts/ports in. The closest thing would be asking the soundcard to "play a (midi) note", which is very easy but still seems to impress people a lot. And i guess this is true for a lot of the "impossible" magic : once you know how it works (technically/human perception) it is much much less impressive.
For all the categories from 32b to 4k, i would say algorithm > rest. Depending on the specific size category, there are subclasses of algorithms which do special tricks. In 32b for example, these are cellular automatons, simple fractals and procedural textures. Maybe real audio synthesis is possible in 32b too, but i didn't lay my hands on that ... yet ;)
Independent from the category, i think one keyword is "procedural" and that shows another point: if we're not talking <256b then good stuff is possible on EVERY hardware out there. Compression is merely dependent on how good the coder maps the algorithm to the hardware. Better: modifies the algorithm to be smallest/best on a given hardware.
Another "skill" which is essential mostly for sizetros is the "data/code duality" (shameless self advertising) , i don't know how crucial this is in the higher regions though.
What also came to mind when i read your last post was the "two tweets shadertoy challenge", where contestants were asked to write 280b shadercode BUT could make use of a set of some large and pretty cool textures which - in my mind - blurred the competition a lot, because it boiled down to texture magic, simple as that. Megabytes of material to use, who wouldn't do that? Heightmaps, colormaps, etc. ;) This shows another crucial skill though : "adaption". As a good demoscene coder, you make the best of what you have, no matter what it is.
As a half wrap up : It's about procedural algorithms and code reusing, well adapted.
I'm not sure, but i think that the elite coders would be capable of beating 90% of anybody out there in any category, including the one you're trying to make up, because
of the said skills. They simply opt for something else in general, which is harder/impossible in the lower regions of sizecoding. Style, atmosphere, design, synchronization, concept. I'm not saying, there is nothing of this in sizetros, but it usually prevents the unfolding of a bigger idea, the unfolding of the inner self. That doesn't mean that every extreme sizecoder is not creative, they may as well unfold their inner artist self elsewhere ;)
One thing i noticed, in general : Usually there is global surprise, when somebody gets a special achievement, does something "impossible", until most people understand what's going on - just what i said above. That doesn't render the achievement useless at all, it's rather a matter of fact, that the FIRST who does it (what ever "it" is), get's all the fame :D and the second does not. I'd not advise to be the disappointed second ;) Instead, one should give respect where it's due and move on. "Adapt", as they say. There will always be dudes who collect these "firsts", and others who don't, but that's just how things are.
This all leads to the one conclusion (for me). It's not about platforms, not about definitions, and not about who "cheats" and how to restrict that. Just about talented people throwing (procedural) algorithms at hardware, using restrictions as inspiration and having fun with the results. The rest follows automatically =)
As for 32b there are no API calls which "do the trick", unless you count interrupts/ports in. The closest thing would be asking the soundcard to "play a (midi) note", which is very easy but still seems to impress people a lot. And i guess this is true for a lot of the "impossible" magic : once you know how it works (technically/human perception) it is much much less impressive.
For all the categories from 32b to 4k, i would say algorithm > rest. Depending on the specific size category, there are subclasses of algorithms which do special tricks. In 32b for example, these are cellular automatons, simple fractals and procedural textures. Maybe real audio synthesis is possible in 32b too, but i didn't lay my hands on that ... yet ;)
Independent from the category, i think one keyword is "procedural" and that shows another point: if we're not talking <256b then good stuff is possible on EVERY hardware out there. Compression is merely dependent on how good the coder maps the algorithm to the hardware. Better: modifies the algorithm to be smallest/best on a given hardware.
Another "skill" which is essential mostly for sizetros is the "data/code duality" (shameless self advertising) , i don't know how crucial this is in the higher regions though.
What also came to mind when i read your last post was the "two tweets shadertoy challenge", where contestants were asked to write 280b shadercode BUT could make use of a set of some large and pretty cool textures which - in my mind - blurred the competition a lot, because it boiled down to texture magic, simple as that. Megabytes of material to use, who wouldn't do that? Heightmaps, colormaps, etc. ;) This shows another crucial skill though : "adaption". As a good demoscene coder, you make the best of what you have, no matter what it is.
As a half wrap up : It's about procedural algorithms and code reusing, well adapted.
I'm not sure, but i think that the elite coders would be capable of beating 90% of anybody out there in any category, including the one you're trying to make up, because
of the said skills. They simply opt for something else in general, which is harder/impossible in the lower regions of sizecoding. Style, atmosphere, design, synchronization, concept. I'm not saying, there is nothing of this in sizetros, but it usually prevents the unfolding of a bigger idea, the unfolding of the inner self. That doesn't mean that every extreme sizecoder is not creative, they may as well unfold their inner artist self elsewhere ;)
One thing i noticed, in general : Usually there is global surprise, when somebody gets a special achievement, does something "impossible", until most people understand what's going on - just what i said above. That doesn't render the achievement useless at all, it's rather a matter of fact, that the FIRST who does it (what ever "it" is), get's all the fame :D and the second does not. I'd not advise to be the disappointed second ;) Instead, one should give respect where it's due and move on. "Adapt", as they say. There will always be dudes who collect these "firsts", and others who don't, but that's just how things are.
This all leads to the one conclusion (for me). It's not about platforms, not about definitions, and not about who "cheats" and how to restrict that. Just about talented people throwing (procedural) algorithms at hardware, using restrictions as inspiration and having fun with the results. The rest follows automatically =)
Amiga demos are already practically naked. The only thing Amiga demos use the OS for is to tell it nicely to GTFO and leave the hardware in control of the demo. :)
Also, this discussion seems to be founded on the idea that demos can somehow be measured on an absolute and context-free scale. That a 4k intro is only 4k if those are the only 4096 bytes of information present in the machine. The reason that this is nonsense was mentioned earlier in this thread: when you really dive into the issue, it becomes apparent that there is no clear, fundamental distinction between hardware and software. You do know that there are many kilobytes of microcode in a 68000, right?
Demos are human creations and can only be judged as such. The impressiveness of a good 4k intro comes ONLY from the fact that the next coder was not able to produce a 4k intro that was equally good.
Also, this discussion seems to be founded on the idea that demos can somehow be measured on an absolute and context-free scale. That a 4k intro is only 4k if those are the only 4096 bytes of information present in the machine. The reason that this is nonsense was mentioned earlier in this thread: when you really dive into the issue, it becomes apparent that there is no clear, fundamental distinction between hardware and software. You do know that there are many kilobytes of microcode in a 68000, right?
Demos are human creations and can only be judged as such. The impressiveness of a good 4k intro comes ONLY from the fact that the next coder was not able to produce a 4k intro that was equally good.
Err. Someone forgot to mention register defaults, assumptions about memory layouts, present devices, and so forth. Those certainly make or break some tiny intros. :D
@tomaes, yes, i would edit this into my textwall if i could ^^
undressing the pc platform? barely possible. there's default "frameworks". i dunno if raymarchers are like that?!? GL, Context, Rect, UniformBuffer and PlaySound. that is a "naked" thing. basicly naked shaders. further there's no chance to exclude the OS. you need to communicate with the hardware. or you do plain simple software rendering. so...
imo
imo
With this idea you are going to draw pixel per pixel on modern pc.
Thanks for all those replies and especially taking the time to write them down (again, just for me :). I think, I more or less got my answers for this one.
True. Unless I am completely wrong in my understanding, those have been used in a very primitive way even on the Atari 2600 (for games). E.g. in River Raid and Pitfalll! the screen details are created from random numbers (using LFSRs).
I was aware of procedural content generating algorithms (though not in detail) being used in demos. Now I think I have to read a bit more about them to explore the possibilities.
Quote:
Independent from the category, i think one keyword is "procedural" and that shows another point: if we're not talking <256b then good stuff is possible on EVERY hardware out there.
True. Unless I am completely wrong in my understanding, those have been used in a very primitive way even on the Atari 2600 (for games). E.g. in River Raid and Pitfalll! the screen details are created from random numbers (using LFSRs).
I was aware of procedural content generating algorithms (though not in detail) being used in demos. Now I think I have to read a bit more about them to explore the possibilities.
exactly everything that kb said.
since this comes up all the time, I'll just sketch what happens in recent mercury 64k intros and what we gain from the APIs, so I can just copypaste it next time ;)
* some windows function draws fonts for us into bitmaps
* we write the generated audio data into a buffer.
* opengl functions reserve and manage textures (and other GPU memory). we fill all this memory ourselves.
* opengl functions draw single lines and triangles. those have shaders active.
* the shaders. those are pieces of ascii text that are contained in our executable and uploaded to opengl via another opengl function, where they are then compiled. coincidentally, ours do exactly what buckethead just proposed:
but on the graphics card. The shader runs once for each pixel and outputs that pixel's color. As inputs it gets a) values from the host program (like the interpolated camera position for the current time) and b) between 0 and 20 of the textures that i mentioned. Out comes another texture. Except that the last of the shaders outputs its pixels not into a texture, but onto the screen. theoretically, the textures are just for storing intermediate computation results for performance and the whole thing could be written as one function color(x,y,time) except for the fonts, but would be slower by a factor of >1000.
* inside the shaders, we can use built-in functions for very basic vector math (dot products, trigonometric functions, etc.) and for accessing textures in various ways. there is no lighten() function (as somebody implied), instead we build the lighting out of dot products etc., like everything else.
* then there's some functions to create the fullscreen window, set the resolution, hide the mouse cursor, exit the program, etc.
so. there's no draw-a-sphere or a make-a-shadow function. we have to build all functionality with shaders that we write and memory that our shaders write to and read from. there's no free "content" provided. (yeah, fonts.)
the whole thing really is a blank piece of paper and some pens. there are no API calls to make things pretty or interesting.
since this comes up all the time, I'll just sketch what happens in recent mercury 64k intros and what we gain from the APIs, so I can just copypaste it next time ;)
* some windows function draws fonts for us into bitmaps
* we write the generated audio data into a buffer.
* opengl functions reserve and manage textures (and other GPU memory). we fill all this memory ourselves.
* opengl functions draw single lines and triangles. those have shaders active.
* the shaders. those are pieces of ascii text that are contained in our executable and uploaded to opengl via another opengl function, where they are then compiled. coincidentally, ours do exactly what buckethead just proposed:
Quote:
With this idea you are going to draw pixel per pixel on modern pc.
but on the graphics card. The shader runs once for each pixel and outputs that pixel's color. As inputs it gets a) values from the host program (like the interpolated camera position for the current time) and b) between 0 and 20 of the textures that i mentioned. Out comes another texture. Except that the last of the shaders outputs its pixels not into a texture, but onto the screen. theoretically, the textures are just for storing intermediate computation results for performance and the whole thing could be written as one function color(x,y,time) except for the fonts, but would be slower by a factor of >1000.
* inside the shaders, we can use built-in functions for very basic vector math (dot products, trigonometric functions, etc.) and for accessing textures in various ways. there is no lighten() function (as somebody implied), instead we build the lighting out of dot products etc., like everything else.
* then there's some functions to create the fullscreen window, set the resolution, hide the mouse cursor, exit the program, etc.
so. there's no draw-a-sphere or a make-a-shadow function. we have to build all functionality with shaders that we write and memory that our shaders write to and read from. there's no free "content" provided. (yeah, fonts.)
the whole thing really is a blank piece of paper and some pens. there are no API calls to make things pretty or interesting.
... and that's where the circle's closing: per pixel "shading" can be done the oldschool way too, it's just horribly slow. Some iterations with some operations per pixel can give reasonable framerates in low resolution (lucy), but that's about it. And besides extreme sizecoding, there's no point in doing that, absolutely not.
I'll be a bucket of cold water then: we don't need more compos, we need more entries in the ones we already have.
and still no pic amazing
the most important component is the power supply really. you should concentrate on demo electricity.
This discussion is so... I can't find words. The idea of a "naked platform" is just one thing: the past.
We have a well defined platform of PC + Win + Drivers, I don't even see a point talking directly to the hardware.
I don't think a demo is defined by the next boring sprite renderer on some legacy refrigerator which still looks crap anyways, regardless of sprite count. We can do a gazillion of sprites on todays hardware, in HD. I don't think todays demos are about poking values into the registers of some fucked up hair dryer, but about great ideas, design, sound and nice algorithms. It's no more 1699. And with the advent of D3D12/Vulkan, let's see what the future for 4K/8K and even 64K is.
We have a well defined platform of PC + Win + Drivers, I don't even see a point talking directly to the hardware.
I don't think a demo is defined by the next boring sprite renderer on some legacy refrigerator which still looks crap anyways, regardless of sprite count. We can do a gazillion of sprites on todays hardware, in HD. I don't think todays demos are about poking values into the registers of some fucked up hair dryer, but about great ideas, design, sound and nice algorithms. It's no more 1699. And with the advent of D3D12/Vulkan, let's see what the future for 4K/8K and even 64K is.
This is totally cheating as well: http://www.pouet.net/prod.php?which=62025
Now I demand we should have "naked" browser entries, too!
Now I demand we should have "naked" browser entries, too!
I personally would like to see a regular 64k softrender compo. ;)
Go make a demo about it.
surely the answer is just make more console demos :P
notice: haven't read the thread. Don't care enough about the subject to do so.
proposed solution: If you feel that the compos ain't 'naked' enough, organize your own - so you can specify your requirements detailed enough for your taste.
rant mode: We do this as a fun-time challenge - to push the limits. I know that Texas generated a lot of heat due to the fact that we exploited samples from the sample music folder. We did however - very early, ask the organizers of the compo if this was ok - and it was, given it worked on all over on win 7 (and maybe more - don't remember but it did work on any config we tested).
So. If you say vanilla, who's to blame if you use drivers or whatever? If you do, go ahead and organize that compo! It does however raise the bar of entry a little bit higher, but for the dedicated (as most 4k makers are) it doesn't matter....?
I still remember when we planned to make texas. 4k was still a pretty easy format to deal with - as the mighty heros mentor and blueberry had released crinkler (which was for us one of two deal-breaking tools). Without those tools, we would never have bothered to give it a shot at all.
That said, I would cherish a 'naked' compo, but I would be quite curious to how many entries you would get, and how you would decide the compo rules (for modern pcs)?
I'll regret this post when sober. sorry in advance.
proposed solution: If you feel that the compos ain't 'naked' enough, organize your own - so you can specify your requirements detailed enough for your taste.
rant mode: We do this as a fun-time challenge - to push the limits. I know that Texas generated a lot of heat due to the fact that we exploited samples from the sample music folder. We did however - very early, ask the organizers of the compo if this was ok - and it was, given it worked on all over on win 7 (and maybe more - don't remember but it did work on any config we tested).
So. If you say vanilla, who's to blame if you use drivers or whatever? If you do, go ahead and organize that compo! It does however raise the bar of entry a little bit higher, but for the dedicated (as most 4k makers are) it doesn't matter....?
I still remember when we planned to make texas. 4k was still a pretty easy format to deal with - as the mighty heros mentor and blueberry had released crinkler (which was for us one of two deal-breaking tools). Without those tools, we would never have bothered to give it a shot at all.
That said, I would cherish a 'naked' compo, but I would be quite curious to how many entries you would get, and how you would decide the compo rules (for modern pcs)?
I'll regret this post when sober. sorry in advance.
At some point at Mekka Symposium, there was a compo with 2 dudes half-naked jumping into a pool, trying to catch an apple with their mouths.
That was entertaining to watch...
That was entertaining to watch...
I think live coding from Revision is the perfect example of a naked competition. The resources available are identical for the competitors. You win by human skills and nothing else.
If you need a modern naked competition platform I think you should opt for platform specific competitions, eg a shadertoy competition.
If you need a modern naked competition platform I think you should opt for platform specific competitions, eg a shadertoy competition.
Amiga was always Naked enough
