an open and extensible demo environment?
category: general [glöplog]
this message was written for the "c++, a wicked language thread" so you might want to look there first.
this message is about custom extensions but i think it might be wise to start a new thread
(short summary for the impatentient: i've developed a "c++" like scriptlanguage+API that can
be used to create portable scene productions (and other related stuff). i'd like to share it with you
; i.e. open the source but first of all i'd like to receive your feedback.
for the non-coders: its a demo runtime environment ("tks") that allows portable executables which make the
platform decision a matter of personal taste. (once the runtime has been ported to many different platforms).
java has been tried for that but it failed because
a) it's too fat (>10mb for java+3d) b) it's not meant for demos c) it's too much of a hazzle to use it
(java is a real programming language that has a really strict syntax)
first of all: right, polycounts are rather stupid, the "effect" is what counts, no doubt on that. (in reply to mad)
some thoughts of mine
1) if the scriptcode resembles "c" you can easily c'n'p your code from/to "c"/"c++" with only a few changes
2) if the portable "executable" contains the source code and the "runtime" contains a compiler we can keep the files
really small; you can "encode" your source (remove all comments, blanks, choose identifiers with least possible
length) to make it unreadable (resp. as small as possible) if you really want that
3) there are dozens of script languages for many different purposes.
"multimedia" usually means huge piles of data (images, audio..) which are expensive (in terms of cpu time) to
work with; i.e. the runtime simply can't be fast enough
the tks runtime is quiet fast and the compiler gives you a good control over the code that is generated / executed
4) in terms of the API there are at least two different approaches to this kind of scriptlanguage+API engines:
a) have a big fat api that covers everything the user possibly wants (e.g. Director, Flash, Alambik, Anark..).
choose a very simple language or use "graphical programming" (e.g. Virtools, VVV).
advantage: easy to maintain, maybe even for "non-coders".
just call make_kewl_demo_effect(), tweak some sliders and be happy
drawback: everything looks the same (the "API" accelerated effect, if you can follow me)
make_kewl_demo_effect() reduces to gosub bananas
more complex logic results in a screen full of boxes and wires (also hard to analyse)
b) choose a "c" like language, have a lightweight and extensible API and grant more freedom to the programmer
advantage: flexibility, working in a possibly familiar environment (syntax, editors..).
you _can_ write my_kewl_demo_effect() yourself.
drawback : there's no "make_kewl_demo_effect()" APIcall, you'll _have_ to write it yourself.
this might be a bit harder for beginners who want big results with little effort
(the "blender" effect (no i don't mean that 3d software)).
5) in terms of the native<->scripted code integration there are also at least two different approaches
a) write a regular native program that embeds a script language (e.g. Lua)
advantage: traditional; the script language is just an addon and most of the app. is
developed using a "native" language (e.g. "c"). typically used by "AAA games"
drawback : to run such an application on a different platform the entire application has to be rebuilt
which can be very hard. the developers have to be aware of the different platform when they release their app.
b) write a scripted program that uses regular native extensions
advantage: you could develop on e.g. amigappc and still ppl were able to watch the app on windows although
the developers didn't especially care for that particular platform.
drawback : the native extensions have to be open source otherwise you'll get into the same portability trouble
tks (my scriptengine) trys to follow the second approach.
languages like perl/python surely produced an incredible number of extensions but "plugins may kill portablity".
the basic perl/python distribution doesn't suit the needs of "realtime" graphics artists (yak i mean sceners) at all.
many language features of php/perl/python are very nice for webprogramming but don't help you with "realtime"
programming at all.
i'm absolutely aware that "portability" is something that most sceners don't care about (although it sometimes
even makes a difference which flavor of windows you're running..) but which is rather important in respect
to the huge variety of computer hardware in use today.
consider the following:
you write a plugin containing a single "my_kewl_demo_effect()" function in native code and forget/don't manage
to compile it on an operating system you don't have access to but which is generally supported by the engine.
the plugin would destroy the whole idea of portability, even if it just generates random numbers.
on the other hand, it can be *very* handy to replace a scripted function by a faster "c" version
(consider a bones engine where you need to write a simple loop that interpolates ~4 weighted nodes for each
vertex)
the only answer to the plugin portability problem was to force the GPL for all plugins but problems still arise:
what if the author used inline asm or even an exotic assembler to build the plugin?
what if the author doesn't want to use the GPL because she/he licensed 3rd party source codes?
at least half of these problems can be solved at source level..
i'm tending to use the "force GPL for plugins" approach because it encourages authors to only put the essential, time
critical stuff into the plugins (which are then very compact and have few dependencies, may be even pure iso-c(++) which
is easy to compile on other architectures). a library of "standard" plugins could provide individual solutions
the engine will be released under the "PERL artistic license" so you won't have to deal with a black box.
noone wants a demo system that FUBARs an hour before the deadline.
however, releasing some of your code snippets in return won't turn you into a pinguin loving linux troll (just kidding)
maybe this is all bullshit; maybe the scene is all about source-hiders, show-offs, mine-is-more-colorful-than-yours and
stupid flamewars and such an community effort is not wanted at all but i thought i'd give it a try hoping that
some of you will understand
if anyone here has a valuable thought on this topic you are welcome to participate!
this message is about custom extensions but i think it might be wise to start a new thread
(short summary for the impatentient: i've developed a "c++" like scriptlanguage+API that can
be used to create portable scene productions (and other related stuff). i'd like to share it with you
; i.e. open the source but first of all i'd like to receive your feedback.
for the non-coders: its a demo runtime environment ("tks") that allows portable executables which make the
platform decision a matter of personal taste. (once the runtime has been ported to many different platforms).
java has been tried for that but it failed because
a) it's too fat (>10mb for java+3d) b) it's not meant for demos c) it's too much of a hazzle to use it
(java is a real programming language that has a really strict syntax)
first of all: right, polycounts are rather stupid, the "effect" is what counts, no doubt on that. (in reply to mad)
some thoughts of mine
1) if the scriptcode resembles "c" you can easily c'n'p your code from/to "c"/"c++" with only a few changes
2) if the portable "executable" contains the source code and the "runtime" contains a compiler we can keep the files
really small; you can "encode" your source (remove all comments, blanks, choose identifiers with least possible
length) to make it unreadable (resp. as small as possible) if you really want that
3) there are dozens of script languages for many different purposes.
"multimedia" usually means huge piles of data (images, audio..) which are expensive (in terms of cpu time) to
work with; i.e. the runtime simply can't be fast enough
the tks runtime is quiet fast and the compiler gives you a good control over the code that is generated / executed
4) in terms of the API there are at least two different approaches to this kind of scriptlanguage+API engines:
a) have a big fat api that covers everything the user possibly wants (e.g. Director, Flash, Alambik, Anark..).
choose a very simple language or use "graphical programming" (e.g. Virtools, VVV).
advantage: easy to maintain, maybe even for "non-coders".
just call make_kewl_demo_effect(), tweak some sliders and be happy
drawback: everything looks the same (the "API" accelerated effect, if you can follow me)
make_kewl_demo_effect() reduces to gosub bananas
more complex logic results in a screen full of boxes and wires (also hard to analyse)
b) choose a "c" like language, have a lightweight and extensible API and grant more freedom to the programmer
advantage: flexibility, working in a possibly familiar environment (syntax, editors..).
you _can_ write my_kewl_demo_effect() yourself.
drawback : there's no "make_kewl_demo_effect()" APIcall, you'll _have_ to write it yourself.
this might be a bit harder for beginners who want big results with little effort
(the "blender" effect (no i don't mean that 3d software)).
5) in terms of the native<->scripted code integration there are also at least two different approaches
a) write a regular native program that embeds a script language (e.g. Lua)
advantage: traditional; the script language is just an addon and most of the app. is
developed using a "native" language (e.g. "c"). typically used by "AAA games"
drawback : to run such an application on a different platform the entire application has to be rebuilt
which can be very hard. the developers have to be aware of the different platform when they release their app.
b) write a scripted program that uses regular native extensions
advantage: you could develop on e.g. amigappc and still ppl were able to watch the app on windows although
the developers didn't especially care for that particular platform.
drawback : the native extensions have to be open source otherwise you'll get into the same portability trouble
tks (my scriptengine) trys to follow the second approach.
languages like perl/python surely produced an incredible number of extensions but "plugins may kill portablity".
the basic perl/python distribution doesn't suit the needs of "realtime" graphics artists (yak i mean sceners) at all.
many language features of php/perl/python are very nice for webprogramming but don't help you with "realtime"
programming at all.
i'm absolutely aware that "portability" is something that most sceners don't care about (although it sometimes
even makes a difference which flavor of windows you're running..) but which is rather important in respect
to the huge variety of computer hardware in use today.
consider the following:
you write a plugin containing a single "my_kewl_demo_effect()" function in native code and forget/don't manage
to compile it on an operating system you don't have access to but which is generally supported by the engine.
the plugin would destroy the whole idea of portability, even if it just generates random numbers.
on the other hand, it can be *very* handy to replace a scripted function by a faster "c" version
(consider a bones engine where you need to write a simple loop that interpolates ~4 weighted nodes for each
vertex)
the only answer to the plugin portability problem was to force the GPL for all plugins but problems still arise:
what if the author used inline asm or even an exotic assembler to build the plugin?
what if the author doesn't want to use the GPL because she/he licensed 3rd party source codes?
at least half of these problems can be solved at source level..
i'm tending to use the "force GPL for plugins" approach because it encourages authors to only put the essential, time
critical stuff into the plugins (which are then very compact and have few dependencies, may be even pure iso-c(++) which
is easy to compile on other architectures). a library of "standard" plugins could provide individual solutions
the engine will be released under the "PERL artistic license" so you won't have to deal with a black box.
noone wants a demo system that FUBARs an hour before the deadline.
however, releasing some of your code snippets in return won't turn you into a pinguin loving linux troll (just kidding)
maybe this is all bullshit; maybe the scene is all about source-hiders, show-offs, mine-is-more-colorful-than-yours and
stupid flamewars and such an community effort is not wanted at all but i thought i'd give it a try hoping that
some of you will understand
if anyone here has a valuable thought on this topic you are welcome to participate!
:maybe this is all bullshit; maybe the scene is all about
:source-hiders, show-offs, mine-is-more-colorful-than-
:yours and
:stupid flamewars and such
indeed.
:source-hiders, show-offs, mine-is-more-colorful-than-
:yours and
:stupid flamewars and such
indeed.
okok maybe i should have added the good ol [sarcasm]
tag
seriously, i've tried to consider the fact that demo=competition
..were e.g. 8/16 bit demos worse just because the source was practically available (the effects had to be so small in code size that you could easily disassemble and "look how its done") ?
8]
tag
seriously, i've tried to consider the fact that demo=competition
..were e.g. 8/16 bit demos worse just because the source was practically available (the effects had to be so small in code size that you could easily disassemble and "look how its done") ?
8]
fli: you where kindof flamed at csipd when you posted this, you will be that here to you know..
can't see any reason to flame me, i'm here to *give* something to you, not to take something away.
my activity has always been more focused on tools
(although i've been writing some intros back on amiga)
this tool might help some of you; if you can't see
the "benefit" just leave it aside
anyone that wants to contribute is welcome
my activity has always been more focused on tools
(although i've been writing some intros back on amiga)
this tool might help some of you; if you can't see
the "benefit" just leave it aside
anyone that wants to contribute is welcome
fli: well... I think it's a good idea :)
hey sofokles: actually it isn't just an idea, it's something you can download (the source will be released soon-- and this time i mean it :)
it still heavily depends on collaboration since it is a
rather huge project that i can hardly do all by myself
(let aside the fact that i would then be a sucker
and dominator)
it still heavily depends on collaboration since it is a
rather huge project that i can hardly do all by myself
(let aside the fact that i would then be a sucker
and dominator)
One thing i would suggest you to *think* a lot about is what primitives you can add in your language to implement synchronization, and event sequencing. A killer language would really shine by offering intuitive mechanisms to define such in parallel to the actual effect code.
that's _exactly_ the point
i've thought about that on from the beginning but the actual implementation needs a lot of improvement.
it has been really an unbelievable amount of work to get where the project is now..
currently there is a Movie class that can interface with script code
and can be sequenced using up to 256 channels. it's undocumented, maybe finished at least untested
and will surely be subject to change. (and there's no graphical editor for it)
a general concept of the engine is to have scripted classes which interface with c++ classes
the concept will work for video as well as for audio
basically, a scripted class becomes a generator which is controlled by a float array which in turn is controlled
by a sequencer.
the first few elements of the float array are "standard" controllers which are understood by all
generators (e.g. position/size/rotation.. for video, volume/pan/freq.. for audio)
the rest is user defined and depends on your scripts
this means a programmer will be able to code her/his own my_kewl_demo_effect() and "arrange" it in a sequencer.
it also means that she/he will be able to write (modify) a softsynth and use it in the same sequencer.
i've also planned a kind of markup language, similar to html but more simple (and extensible), which will be used
to create screen layouts (user interfaces).
it may also be used as a kind of diskmag engine (imagine a diskmag where the the pages can contain
realtime effects; without the need for something like "activex" :P )
last but not least (i've spent many years programming sequencers..) i promise you a real nifty
sequencer which hasn't been done before that way (hohooo..)
it will be real freaky, the concept is finished and when i'm not hax0ring perl scripts i'll try to get
a working prototype up and running asap
the sequencer (video/audio) will be written using the scriptlanguage; the source will be open so everyone
has the opportunity to customize it.
greetz
bastian ("fli")
p.s.: these are real *big* words and it may take some time to do all that, in the meanwhile just play around with the
script engine and please send me some feedback (either + or -)
(it seems to be some kind of social phenomena that most ppl just play spectators) just drop me a mail, i won't spam
:)
i've thought about that on from the beginning but the actual implementation needs a lot of improvement.
it has been really an unbelievable amount of work to get where the project is now..
currently there is a Movie class that can interface with script code
and can be sequenced using up to 256 channels. it's undocumented, maybe finished at least untested
and will surely be subject to change. (and there's no graphical editor for it)
a general concept of the engine is to have scripted classes which interface with c++ classes
the concept will work for video as well as for audio
basically, a scripted class becomes a generator which is controlled by a float array which in turn is controlled
by a sequencer.
the first few elements of the float array are "standard" controllers which are understood by all
generators (e.g. position/size/rotation.. for video, volume/pan/freq.. for audio)
the rest is user defined and depends on your scripts
this means a programmer will be able to code her/his own my_kewl_demo_effect() and "arrange" it in a sequencer.
it also means that she/he will be able to write (modify) a softsynth and use it in the same sequencer.
i've also planned a kind of markup language, similar to html but more simple (and extensible), which will be used
to create screen layouts (user interfaces).
it may also be used as a kind of diskmag engine (imagine a diskmag where the the pages can contain
realtime effects; without the need for something like "activex" :P )
last but not least (i've spent many years programming sequencers..) i promise you a real nifty
sequencer which hasn't been done before that way (hohooo..)
it will be real freaky, the concept is finished and when i'm not hax0ring perl scripts i'll try to get
a working prototype up and running asap
the sequencer (video/audio) will be written using the scriptlanguage; the source will be open so everyone
has the opportunity to customize it.
greetz
bastian ("fli")
p.s.: these are real *big* words and it may take some time to do all that, in the meanwhile just play around with the
script engine and please send me some feedback (either + or -)
(it seems to be some kind of social phenomena that most ppl just play spectators) just drop me a mail, i won't spam
:)
..or you could just use demopaja.
(and fli; demosceners have attentionspans like dead pigeons - try to keep your posts shorter if you want someone to read them :)
(and fli; demosceners have attentionspans like dead pigeons - try to keep your posts shorter if you want someone to read them :)
"it's something you can download"
erm, where? (ok, maybe it's hidden somewhere in your post...)
nice idea, lot of work... but i don't think sceners will use it too much...
erm, where? (ok, maybe it's hidden somewhere in your post...)
nice idea, lot of work... but i don't think sceners will use it too much...
http://tkscript.de
sorry about the long bla-blub-schwafel text you'll find more at my site x)
deemage: in a way, it's also just another color in the palette of engines
sorry about the long bla-blub-schwafel text you'll find more at my site x)
deemage: in a way, it's also just another color in the palette of engines
Forget demopaja. Use videotracker!!!
I read on the download site: "the linux version is currently missing the MiniFMOD XM music module player which will probably be replaced by the fxmp library soon."
I'd suggest libmodplug instead [http://modplug-xmms.sourceforge.net/#download]
I'd suggest libmodplug instead [http://modplug-xmms.sourceforge.net/#download]
Complex solutions for simple problems are a waste, but do what you feel like doing. Just don't get mad when people are not as excited about it as you are.
Honestly, I don't want to script, I want to point and click. Much more intuitive.
the mod player problem will probably be one of the first extensions i was talking about.
jare: show me a more simple solution. it does not exist yet. java and c# are the only things that come close (and they are really complex)
sagacity: me too. that's why i'm going to write a gui :)
jare: show me a more simple solution. it does not exist yet. java and c# are the only things that come close (and they are really complex)
sagacity: me too. that's why i'm going to write a gui :)
why not just have a abstraction layer, and a simple gui where you can place your effects written with the abstraction layer, much like demo paaja ??? this seems like a waste of time.
why not just write portable code? <g>
writing portable code ? that's what i suggested with an abstraction layer, but if you mean writing code in ansi c without no platform specific optimizations etc. i doubt you will get the speed you want. anyhow, beer time.
_: yes, the engine and the custom extensions have to be written in a portable way (e.g. in iso c/c++)
pantaloon: a basic concept of the engine is that only the building blocks are written in native code (if native code is required at all).
if the entire demo is writting in a portable way but the authors forgot to build it for platform xyz then the
portable code doesn't help you at all.
the clue is that the compilation is done in the runtime,
i.e. "JIT"
pantaloon: a basic concept of the engine is that only the building blocks are written in native code (if native code is required at all).
if the entire demo is writting in a portable way but the authors forgot to build it for platform xyz then the
portable code doesn't help you at all.
the clue is that the compilation is done in the runtime,
i.e. "JIT"
we are making demos, damnit! superportable scriptingsystems removes the entire point; to squeeze out as much power as possible. who cares about other platform than x86+windows anyway?
kusma: i don't agree about benchmarks being the entire point of the scene. just think of music disks, slideshows, games, diskmags..
finally even a big fat blockbusting demo could be made by adding some native extensions to the language API.
if the extensions were open source they'd (possibly) be portable (most ppl use standard "c"(++) anyway))
finally even a big fat blockbusting demo could be made by adding some native extensions to the language API.
if the extensions were open source they'd (possibly) be portable (most ppl use standard "c"(++) anyway))
actually, benchmarking is to messure the SPEED of the computer (a really geeky thing to do), while democoding is about optimizing (such as all your sexy and cool heroes do). two completely different things.
lol :) then pls explain "to squeeze out as much power as possible"