"Naked" compos?
category: general [glöplog]
I started this discussion in the Revision 2015 compo thread, but it definitely fits better here. So let me repeat my question:
After watching several stunning 4-64k PC demos last weekend (and afterwards), I started wondering how much of the result is really coming from those few bytes. And how much is coming from OS, drivers etc.
So I wondered if something like a "naked" compo would be possible? So just the bare bone hardware (and BIOS if required). And would people even bother doing and watching that?
I definitely would, but that's maybe due to my Atari 2600 background, where we are doing exactly that (though with much, much more primitive hardware). :)
After watching several stunning 4-64k PC demos last weekend (and afterwards), I started wondering how much of the result is really coming from those few bytes. And how much is coming from OS, drivers etc.
So I wondered if something like a "naked" compo would be possible? So just the bare bone hardware (and BIOS if required). And would people even bother doing and watching that?
I definitely would, but that's maybe due to my Atari 2600 background, where we are doing exactly that (though with much, much more primitive hardware). :)
As I said before, you'd need to have a very specific computer setup as a compo machine, and the coders would require pretty much the same exact setup at home to work on, and then you haven't considered people trying to watch it at home.
There's a reason why we need drivers for computers.
There's a reason why we need drivers for computers.
Define "naked"...
- Is no OS is allowed?
- Should everything boot from a floppy/CD/usb with a custom OS?
- Can you find a suitable PC that is available for purchase, and has no variations in the hardware?
- Is no OS is allowed?
- Should everything boot from a floppy/CD/usb with a custom OS?
- Can you find a suitable PC that is available for purchase, and has no variations in the hardware?
I'm not even that fond of pants off, so naked compos sounds like a horrible idea to me :(
Sounds like a "bootsector" compo. That said, there will always be "higher functions" than the level you actually implement in. On the machine level these would be interrupts (making this possible) That's as much "cheating" as an API call on higher levels. Same thing, different scale IMHO.
I certainly would be fine with a "bootsector compo" =)
I certainly would be fine with a "bootsector compo" =)
Well FAP does carry a bootsector intro compo, that has been fairly successful.
After reading britelites last point : Regarding all the different hardware out there, to make a "naked" compo 100% fair, it had to be on a PC emulator (with unique setting for everybody). The easiest way would be Dosbox (fixed version, fixed setting), but despite ME finding that quite interesting, i doubt that such a compo would generate too much interest. Not to mention, that each emulator has its own possibilities of "cheating" Same thing, different scale ;)
We already have naked compos. PANTS OFF!
Let me repeat:
Even with bare metal you still have the instruction set which gives you something: features of a platform. So you will always have a platform with certain features and it doesn't matter whether it's hard or software. There have been some bootsector intros for x86 - but there was never interest in a real competition.
I'm not interested.
Going bootsector only creates a new platform with a different set of features.
Quote:
Longest discussion ever.
For me it's not really a difference whether the resources you use are directly provided by the hardware or whether you access them via some API (it's a feature of the platform you are using and even on the lower-end platforms you have things the hardware does for you. It's not like you start from nothing, unless your name is LFT).
As long everything used is available on the respective platform (vanilla state) - it's alright.
End of discussion.
Even with bare metal you still have the instruction set which gives you something: features of a platform. So you will always have a platform with certain features and it doesn't matter whether it's hard or software. There have been some bootsector intros for x86 - but there was never interest in a real competition.
I'm not interested.
Going bootsector only creates a new platform with a different set of features.
I am not expert enough (by far) to define the rules for such a compo. At the moment I am learning from each new answer.
For me "naked" would mean, the bare minimum required to get your demo started. For e.g. the C64 that would mean, you are not allowed to use the build in ROM (= no BASIC, kernel or character ROM) after your code has been started. So all you have is the hardware and really everything is your own code. Like I said, I am coming from a very, very old platform here and maybe ask for something impossible.
For PCs the huge hardware variations make things complicated, that's for sure. In other (even completely unrelated areas like motor sport) classification systems are common, so that a fair competition is still possible. Also in the oldskool compos the hardware used is already way more different than modern hardware. And somehow those work too. So maybe the hardware demands could be quite flexible and just use what the coders have at home. Which still is probably a problem for groups.
If the idea doesn't work for the mix modern PC hardware, then how about using already well defined platforms? Like C64, Amiga OCS... Or create such a platform for PCs now and keep it steady for a few years?
If I should come over quite ignorant in my post, that's probably true. The minimum I can hope for is, that I am less ignorant after the discussion. :)
For me "naked" would mean, the bare minimum required to get your demo started. For e.g. the C64 that would mean, you are not allowed to use the build in ROM (= no BASIC, kernel or character ROM) after your code has been started. So all you have is the hardware and really everything is your own code. Like I said, I am coming from a very, very old platform here and maybe ask for something impossible.
For PCs the huge hardware variations make things complicated, that's for sure. In other (even completely unrelated areas like motor sport) classification systems are common, so that a fair competition is still possible. Also in the oldskool compos the hardware used is already way more different than modern hardware. And somehow those work too. So maybe the hardware demands could be quite flexible and just use what the coders have at home. Which still is probably a problem for groups.
If the idea doesn't work for the mix modern PC hardware, then how about using already well defined platforms? Like C64, Amiga OCS... Or create such a platform for PCs now and keep it steady for a few years?
If I should come over quite ignorant in my post, that's probably true. The minimum I can hope for is, that I am less ignorant after the discussion. :)
Quote:
create such a platform for PCs now and keep it steady for a few years
In practice, that's what the OS + drivers are doing ;)
Quote:
In practice, that's what the OS + drivers are doing ;)
So the drivers are just an abstraction layer without adding any functionality? No predefined stuff in there which can be reused to save space?
I am asking, because from some responses to certain demos I got a different impression.
bootsector intro compos already exist, they just don't make much sense on modern pc.
modern pc compo rules specify the available OS and installed drivers. And that's what competing developers should aim for. OS compatibility issues for 4k's have always been an issue that 4k developers and compo hosts are well aware of.
modern pc compo rules specify the available OS and installed drivers. And that's what competing developers should aim for. OS compatibility issues for 4k's have always been an issue that 4k developers and compo hosts are well aware of.
JTZ:
I think that there is a already a steady discourse about what the "PC platform" is, and what not. The definition is a current state of a gigantic feedback system, consisting of sceners (which is a good thing). Making up a new such definition is even more artificial as sizecoding anyway - like forbidding ROM access, while we're at it ;)
You're free to setup and establish a new, parallel definition of "PC naked" (whatever that is), and then initiate and lead the resulting discourse. However, i would advise that you define precisely - i mean it, very precisely - what "PC naked" should be, pay attention that it doesn't overlap with existing categories, and generates enough interest. I'm not an expert on this, but i think new categories (in the scene) are not created by definition, but by diversion, and actual action. I - for example - do my best to revive the "32b" category and create the "16b" category, by actually releasing stuff ;)
In general i agree to the final conclusions, gargaj and las just made: there is already a well defined PC platform (no matter how arbitrary it looks at first from the outside, sceners agree on it in general, and the current discourse comes with it) and no matter where you move, you will end up having a "system" with "features", which are then exploited to maximize demo effects.
I think that there is a already a steady discourse about what the "PC platform" is, and what not. The definition is a current state of a gigantic feedback system, consisting of sceners (which is a good thing). Making up a new such definition is even more artificial as sizecoding anyway - like forbidding ROM access, while we're at it ;)
You're free to setup and establish a new, parallel definition of "PC naked" (whatever that is), and then initiate and lead the resulting discourse. However, i would advise that you define precisely - i mean it, very precisely - what "PC naked" should be, pay attention that it doesn't overlap with existing categories, and generates enough interest. I'm not an expert on this, but i think new categories (in the scene) are not created by definition, but by diversion, and actual action. I - for example - do my best to revive the "32b" category and create the "16b" category, by actually releasing stuff ;)
In general i agree to the final conclusions, gargaj and las just made: there is already a well defined PC platform (no matter how arbitrary it looks at first from the outside, sceners agree on it in general, and the current discourse comes with it) and no matter where you move, you will end up having a "system" with "features", which are then exploited to maximize demo effects.
Quote:
you will end up having a "system" with "features", which are then exploited to maximize demo effects.
The very core of the demoscene.
Quote:
So the drivers are just an abstraction layer without adding any functionality? No predefined stuff in there which can be reused to save space?
I am asking, because from some responses to certain demos I got a different impression.
Ah, the good old "premade textures in DirectX" argument :P No, for the most part there isn't. There may be some helper functions but for the most part intros and demos just shove out pixels or triangles through the door.
The premise for this thread is mostly wrong. Most modern small intros don't use all kinds of utility api functions. The typical raymarcher 4k will generate generate a long sound sample and ask win32 to play it (setting a few hardware registers or calling win32 is pretty equivalent - at least on amiga the former will be smaller), and then do the neccesary dx/opengl calls to run a program on the gpu every frame. Sure, this program is written in an abstracted language and not the real gpu-specific instructions (changes at every generation and between vendors), but the amount of utility constructs are quite limited (reflect(), lighten().. that kind of stuff you won't save much on).
It was another story ~10 years ago, where d3dx9.dll was constantly updated with new utility stuff you could abuse (mesh generators, text, texture shaders, subdivision surfaces etc), and general midi was somewhat accepted for sound. Then 4k intros was really an "api-ride".
Sure, these things are still available for dx9 (and lesser extent opengl, but not dx10/11 where you have to ALSO make a dx9 device to for instance extract some text gfx), but mostly not used anymore - as they have a tendency to only give you 2007 visuals ;)
...Which specific intros have inspired you to ask this?
It was another story ~10 years ago, where d3dx9.dll was constantly updated with new utility stuff you could abuse (mesh generators, text, texture shaders, subdivision surfaces etc), and general midi was somewhat accepted for sound. Then 4k intros was really an "api-ride".
Sure, these things are still available for dx9 (and lesser extent opengl, but not dx10/11 where you have to ALSO make a dx9 device to for instance extract some text gfx), but mostly not used anymore - as they have a tendency to only give you 2007 visuals ;)
...Which specific intros have inspired you to ask this?
Thanks for the reply, HellMood. I become aware, that I am largely repeating discussions of the past here. So I am bit selfish here, and try to get some extra insight from those to know. :)
From the current reactions I figure that the interest in such a compo would be pretty low. At least for modern hardware, maybe I can get some feedback from oldskoolers too.
Actually the 32b demos are part of the reason why I wondered about the impact of all that software available around.
At first glance they look completely impossible, but then you realize, that they must be very cleverly utilize other code (and/or maybe also functionality built into hardware?). Which is a true challenge on its own, that's for sure.
I suppose on a lesser extend the same is true for all size restricted demos? What I am trying to understand is, to which extend. This would help me to evaluate and appreciate the result more adequately, especially when comparing different size compos.
From the current reactions I figure that the interest in such a compo would be pretty low. At least for modern hardware, maybe I can get some feedback from oldskoolers too.
Actually the 32b demos are part of the reason why I wondered about the impact of all that software available around.
At first glance they look completely impossible, but then you realize, that they must be very cleverly utilize other code (and/or maybe also functionality built into hardware?). Which is a true challenge on its own, that's for sure.
I suppose on a lesser extend the same is true for all size restricted demos? What I am trying to understand is, to which extend. This would help me to evaluate and appreciate the result more adequately, especially when comparing different size compos.
Quote:
...Which specific intros have inspired you to ask this?
I started going through some top rated demos, to catch up in history. fr-08: .the .product is one of those. Pretty old stuff and from your answer I figure time has changed anyway.
I want to watch hi-end stuff on pc, and don't go to back to stoneage. Such discussions are pointless since dos4gw anyway.
If you want to work with limitations, use dead platforms, easy like that.
If you want to work with limitations, use dead platforms, easy like that.
... and tonight we're gonna party like it's 1699!
Quote:
If you want to work with limitations, use dead platforms, easy like that.
That's what I am doing with a lot of fun for several years now (Atari 2600, it doesn't get much more Stone Age than that one).
And I have no intention to take away (or even criticize) any hi-end demos, which I am enjoying watching about as much as you do. I am trying to make up my mind about this, understand the motivation, getting more insight. And in the process, my mind linked my Stone Age experience with today's high end and came up with the idea of combining both on hardware level. So I started asking questions here.
fr-08 is only an example because we really raised the bar re: procedural generation there. Of course people would think it was "fake". But actually all the textures, all the meshes and all the sound are generated by code we wrote. The OS is only used to get the sound out to the speakers and the triangles to the screen. I think the only two "resources" we used from the OS were the DXT compressor in d3dx.dll (and I'm not even sure we did that at all) and the Arial font which we used for the texts.
About the naked compos, I don't know. Not everyone is comfortable stripping down completely in public, and as a scene in which "doing what you yourself want" is paramount, consensus is most important. I'd rather keep my orgies to the usual places instead of losing people like Havoc in compos.
About the naked compos, I don't know. Not everyone is comfortable stripping down completely in public, and as a scene in which "doing what you yourself want" is paramount, consensus is most important. I'd rather keep my orgies to the usual places instead of losing people like Havoc in compos.
:)
computers have evolved, so did the demoscene. it's pretty lame to claim that modern stuff are not impressive (or that there is a lack of skill nowadays) because there were made using API's or shading languages that were not present in old machines.