Synthclipse - GLSL demo development environment based on Eclipse IDE.

Hi folks,
In last couple of months I’ve been developing Open Source GLSL demo development environment based on Eclipse IDE, called: Synthclipse.
Its main purpose is to help making GLSL demos but it’s kind of Java gaming related since it is written in Java and can be used as ordinary GLSL editor (for your games, of course :slight_smile: ).

I’ve finally released version 0.1.0 of the Synthclipse.
Here’s the web site: synthclipse.sourceforge.net

And here’s a screenshot:

More screenshots you can find here.

Now this is something really awesome.
PITA I can’t download it, since my internet-connection crashes every 2-5 Megabyte of data-volume.
(And the ‘resume download’ functionality of Firefox and FreeDownloadManager doesn’t work)

I really want this.

  • Longor1996

I’ll try out some of my Fragmentarium scripts once I’ve got this set-up.

There is Fragmentarium importer that can help you: Just choose from the main menu “Synthclipse -> Import… -> Fragmentarium Creation…”.

Will check this out. But could you add a more direct download link? It is quite annoying…

You mean to Eclipse with already installed Synthclipse plugin-ins? I’m planning to but I was thinking that for version 0.1.0 with not all features implemented (like recording) it would won’t be necessary.

Current “installation” is that problematic? Maybe I should reconsider releasing one archive file…

No, no, just the fact that you have to go through several sites to just download thet .zip. Just a personal opinion that downloads should be more direct.

Oh man, this is awesome! Thanks :slight_smile:
Is there any way to load in obj files to test out post processing effects?

Unfortunately it isn’t possible to use 3d models in current version of Synthclipse.
I’m planning to add scripting support to Synthclipse in future. With it such things would be possible.
But it won’t be soon, maybe 6 months from now, since I have couple of things to implement before scripting.

Okay some initial feedback. I’ve only looked at a couple of my 2D fractals so far. Later I’ll look at some 3D fractals and then some realtime targeted stuff. One of the fractals is this:

http://www.java-gaming.org/?action=pastebin&id=840

So (I’m sure this isn’t news) the progressive rendering could do with some work. Also the rendering goes wonky if rendering window gets resized.

Random thoughts:

  1. Assuming you’re parsing GLSL, then allow for constants to have UI elements (like uniforms).
  2. Print out the rendering time
  3. Engine generated quasi-random provided as a uniform. Say a vec4 where the values are updated once per progressive frame.

Keep up the good work. :wink:

This is great! I was actually looking for some rudimentary glsl support a couple of days ago. Taking it for a spin later.

Didn’t find a changelog however (noticed 0.1.1 is released) - would be nice to have it on the page somewhere; unless I just missed it.

Edit: Any chance the codebase will migrate to github? It would make contributing easier imo.

2D direction support.

Ad.1. Would you like this because uniforms have some (little) performence penalty? Maybe I should implement uniform locking like in the Fragmentarium. It basically replaces uniforms with constants.

Ad.2. FPS counter isn’t sufficient or do you mean rendering time in progressive mode? Of course I could add this feature. (maybe tomorrow).

Ad.3 This will be possible when I implement scripting support.

As of 2D rotation component I will start implementing it today :slight_smile:

Added changelog to http://synthclipse.sourceforge.net/changelog.html.

I’m already using git on sourceforge. Contribution to Synthclipse shouldn’t be more diffcult than in github.

Thanks for the feedback guys!

Yeah, maybe it’s just my personal aversion to SF; not a biggie regardless.

Hadn’t heard Beat Bizarre before; pretty sweat stuff!

For non-realtime, say rendering a procedurally generated movie slight performance difference can really add up. For realtime (coupled with nanosecond rendering time) it allows for a more accurate estimation of how much GPU budget a given implementation is consuming. Having a variable as a constant opens up more optimization to the backend than a uniform. Additionally it’s slightly less runtime overhead.

Personally I’d slightly prefer: [icode]const float foo; // //! slider[0,.5,20][/icode]. The idea is “what you write is what you mean” and it’s purposefully invalid GLSL. This is only a minor point however. Some other thoughts in this direction are: Having a command-line interface coupled with your future scripting support to allow exporting from the internal format to some (potentially custom) format used by the target application.

For realtime, FPS stands for Freaking Pointless System (of measurement). What you really want is ns/frame and/or ns/fragment. FPS numbers are too course grain and the inverse time nature makes it very misleading. Consider 200 fps. Gosh that’s fast! Except it isn’t if your targeting 60 fps for everything. It’s 30% of your total GPU budget. And 100 fps is 60%, 80 is 75%…see what I mean. It’s much easier to think in linear things.

Scripting support is even more awesome.

Nice.

@junkdog
Yeah, Beat Bizzare is pretty cool.

@Roquen

I’ve implemented Direction 2D Tool:

and added frame time to the Rendering View:

As of constants with Uniform Controls, I’ve put it on my TODO list.

Synthclipse 0.1.2 is redy for downloads.

I’ve decided that I will implement scripting in the first place, since it is the most desired feature. Any suggestion about scripting functionality and language?

I’m thinking about using Python since it has good OpenGL support and can be easly used with Java (Jython) and with C++
(I need it for my Synthclipse Player), but I don’t know if Jython is fast enough.

I was considering also JavaScript because it is everywhere and fast JVM based engine - Nashorn - is coming out soon. Moreover I have expirience with JavaScript-C++ interoperability using Google V8 engine.
But if I would use JavaScript I would have to port part of Desktop OpenGL API to this language… This could take too much time.

What do you think guys?

You could use java. :slight_smile: I don’t see any reason to use a dynamically typed language, but I don’t know what your vision for scripting is.

Scripting Languages I can think of:

  • Jasic (BASIC)
  • Rhino (JavaScript)
  • Jython (Phyton)
  • Nashorn (JavaScript)
  • DCPU-ASM (Assembler)
  • A ‘Graph’ based Scripting-Language?

I still wan’t to download this.

Have a nice day.

  • Longor1996

+1 for java or simply loading class-files and providing a api-jar, so everybody could use any language that compiles to jvm bytecode.

Yeah and use classloaders and you get the ability to unload and submit update versions at runtime. The C++ other tool could load HotSpot and then there will be no issues related to using different runtimes.