"nemesis" <nam### [at] gmailcom> wrote:
> "Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
> > I had one thought: why not compile SDL into Java code, with runtime classes
> > and shipped-in POV4 stuff (like we have now with POV), and control the
> > generation process by the front-end, so that it is quick and transparent to
> > the user?
>
> well, I guess if we can ship a JVM with povray or expect the user to have it
> installed, my crazy idea of shipping GCC with povray or expecting the user
> to have it installed would be acceptable as well.
>
> And we'd even economize one step, as in:
> SDL -> C -> native code interfacing with native povray binaries
>
> rather than:
> SDL -> Java -> bytecode -> JNI calls to native code...
>
> but I still guess we're pulling ourselves ahead of our times since, while
> discussing SDL possibilities is nice, we have first to code infrastrucure
> in C/C++ to handle it...

Thinking of what we have today at our disposal that allows OO, modularity,
bytecode, JIT, callable user code from within the renderer, script syntax
simplicity, ease of writing a parser for it, add & enhance  features,
cross-platorm (develop and execute), cross-OS, debuggable SDL, etc ...
without re-inventing all from scratch, and that is mature enough to ensure
perennity and long-term health, I found that Java was a good thing to think
with, and could be involved in the new SDL.

Java is mature, popular, so the developpers of this new SDL would be in a
well known world, and it is likely to be a good intermediate between SDL
and the rendering engine (which does not really cause problems to develop
and optimize for speed, whatever rendering feature is implements). Our
concern is not the renderer, but the langage and related aspects.

I sketched this idea to show how Java could be utilized, and this sketch
might be re-worked several times. It was just a "pop-up". As it is on the
picture, it can implement the main features that were discussed so far. I
am still convinced that this solution/approach, or something equivalent,
can achieve what we want, and lead to a nice, simple, effective,
user-friendly, flexible SDL, compatible with current syntax, but opening
new perspectives.

If we want this new SDL, we have to collect and mix ideas, try to extract
what can be kept, and mature all this in order to get something acceptable.
The sooner we begin, the better.

Are there people here that know about development processes, software
industry know-how, or whatsoever? Their advise could be useful.


Bruno.

Post a reply to this message