pouët.net

hey, i guess we agree anyway. i know what you mean

I pretty much like your idea and that demo program you made works very well .. Just I wish the language was less c/c++-ish But nice work. as for kusma's idea of 'squeezing out as much power as possible'.. it's completly refuted by most productions I appreciated after 1996.

Optimizing is easy. finding ideas and implementing them is harder.

if you've managed to find an idea, and implement it, you might as well optimizie your implementation as well, since it's easy, right?

"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."

uhm... "forgot to build it"?
ok. so solution:
write portable code. and then simply don't forget to build it for platform xyz. problem solved!

of course, but there's a difference between optimizing your implementation, and butchering it just to "squeeze out as much power as possible" (for me the limit is when it means removing features in the implementation like ability to be live controlled, or too hardcoded computation paths)

the fact that it's easy doesn't mean its good.

and, we all meant low level optimization of course. which made sense in the old days.

ANSWER: Blitz3D

theoritically it's a good idea. In practice: i don't know. It will be good to make a production and be able to see it under almost every platform. I can't judge it without trying it. I'm downloading it right now so maybe tomorrow you'll have my comments.

Personally i tried it (the idea to make a scripting language that controls everything - however mine looks like JavaScript and it's goal was to be used more as a library for native coded programs than as a layer) and i liked the result. But i haven't gone so far :-).

A pre-try request however: it will be good to make a .tkx to .exe (win32) convertor for those who wants to make .tkx programs run in win32 without having to download the player (in other words to link the player and the .tkx file in one executable). Just for "those damn newbiez".

before i check it (i'm at a NetCafe right now and i can't view it here), good work on the Documentation :-). You wrote a lot of stuff.

And "bravo" for having the docs available for download! Most people forget this small issue... :-P

<p>
The Move and Aspirine groups has their own scriptable demomaker tool.
</p>

Many sucessfull demos were done with successive versions of it:

Micron / Ambiance 2000
Antisectic / Takeover 2000
Destroy the unappropriate ennemy / TO too
Human-M / Dialogos 2001
Opium / SOTA 2002

I invite you to download the Opium demo (opium_mov.zip), the complete demo creation suite is hidden in the package:

rename data.dat in datas.zip, unzip the archive, and uncomment the #archive = datas.dat in config.txt

Here you are ready to hack new fresh demo.

I didn't have any time for demoscene at this moment, but i could help and encourage further developpement of the tool.

I hope to come back one day...

<p>
The Move and Aspirine groups has their own scriptable demomaker tool.
</p>

Many sucessfull demos were done with successive versions of it:

Micron / Ambiance 2000
Antisectic / Takeover 2000
Destroy the unappropriate ennemy / TO too
Human-M / Dialogos 2001
Opium / SOTA 2002

I invite you to download the Opium demo (opium_mov.zip), the complete demo creation suite is hidden in the package:

rename data.dat in datas.zip, unzip the archive, and uncomment the #archive = datas.dat in config.txt

Here you are ready to hack new fresh demo.

I didn't have any time for demoscene at this moment, but i could help and encourage further developpement of the tool.

I hope to come back one day...

fli: i believe .NET comes rather close to what you intend. I would recommend you to:
- rip the MONO JIT back-end - it is somewhat optimised, and shall get better with time, and will be ported to many platforms;
- write your own support libraries - these have to be generic and small;
- you don't have to rely on the .NET bytecode format - use MONO reflection if you like.

Run-time compilation has a great future. Consider a case: many "constants" are established at the start of the application. Like, object complexity, resolution, and so on, are machine dependant. These could then be inlined and eliminated. See research to Tick C - this kind of optimisation works even well in Photoshop plugins, where the filter code gets optimised to the current canvas resolution, and this works faster with a crappy JIT than the code GCC -O2 or -O3 would produce!

-i.

midiclub, fli already did it (http://www.tkscript.de/)

midiclub, fli already did is (http://www.tkscript.de/) own engine.. why would he throw what he already did?

the TKS source has now been released! (GPL+LGPL for plugins) get it at http://tkscript.de!
(if you are not a coder you can at least look at some simple examples)

to midiclub: the TKS win32 executable including compiler+interpreter+JIT engine+basic API is **167 KB**.

http://tkscript.de