And I'm officially sick and tired of trying to fight with badly-written software...

[wolfwings]

...namely a fairly eclectic software package by the name of R4. It's a suite that sucks down a line-in, and supports an akward-to-understand scripting language to generate very nice visuals.

Well, I'm tired of using it.

Downloaded LCC-Win32 today. Now I need to find a skeleton framework for accessing OpenGL from that compiler, modify that to support Linux as well, and make a tiny input-only library for reading either line-in, or the buffer-out line on a sound card. Once I have that working on Windows and Linux at the same time, I'll need some help from all your graphics-geeks out there in la-la land.

Help me write a useful language to describe video effects.

Any and all ideas will be listened to. I fully intend to focus this on supporting pixel shaders to some extent, and rendering from and to textures as much as possible. The final 'on screen' display will actually be done by simply specifying what buffer to show.

Current ideas are:
Each buffer has it's own rendering function called each frame
The language will not support forward-calls to prevent cyclic references
Buffers will have seperate 'rendering' and 'available' framerates, either of which can obviously be set to 'as fast as possible' and input-side can be set to 'match the source' as well.
Things will be bytecoded for now, newer platforms like Athlon-64 have enough registers that ByteCode is Quite Fast.

The seperate framerates will be to support things like video-capture buffers more readilly, for instance making a water effect fed from a video stream only update at the framerate of the video stream, but made available for rendering on-screen at whatever framerate the video card can process. Conversely, some effects are easier to think about at a fixed framerate like, for instance, 60fps. And you can globally 'cap' the effects stack to a certain framerate for 'as fast as possible' if, for example, you're running an LCD projector with it and want to avoid sheering effects.

Comments

[aerowolf.livejournal.com]

How many buffers should there be? I'm thinking 8. (And I'll explain why in a moment.)

For every 3D effect you want to deal with, you have a set of parameters that must be put in. I'd almost suggest a FORTH-type language for this, but I know that you're going to smack me over the head for that one. :)

Instead of individual planes or triangles or whathaveyou, create a means of putting a bunch of individual objects into "cobs" (complex objects), and then allow individual effects to be applied to those. (Are you going for a 3D translation system -- such as the ability to create an octohedron and rotate it around its X axis?)

The reason I say 8 buffers is because of something I noticed with GeForce: If you build one buffer using one set of rules, and then apply it as an effect of some kind (bump-map, alpha channel, gamma level)to another, you can create even stranger effects than if you don't.

Also, support arbitrary input sources. To change the magnitude of a change depending on the result of a low-pass filter on an incoming audio stream would make for the ability to create very interesting visualizations. The ability to change color intensity across the visible spectrum based on intensity across the audible spectrum would be fairly psychedelic. ;)

Then again, I'm describing something like the fscking DirectX set of interfaces. :P

Most of the limits will be dynamic.

[wolfwings.livejournal.com]

You should know that about me. I refuse to hard-limit things if I can avoid it. And I see no reason to limit the number of buffers the software will allow code to be defined for. Buffers, in effect, are 2D arrays of variables that you define processing steps for that can reference other buffers and have large areas of themselves set with certain values (rendered to with polygons) as well. I'm not here to dictate design of effects, or impose a limit that someone will have a valid reason to bypass in a later version, so better to design it to have a dynamic limit of 'buffers' from the first place.

I'm still at a toss-up between allowing COBs, and relying on library functions to handle processing large meshes. Trying to define a universal object format will only run into a million different problems and limitations and special-purpose functions, and I'd rather not define anything internally in the language that can be handled by a language-written library. And since it's all going to be based on OpenGL, buffers can actually be highly complex combinations of nearly-arbitrary channel lists. I'll be abusing the EXT_framebuffer_object extension, and may rely on it's existance to run.

And if your 'arbitrary input sources' request is for arbitrary audio input sources... um, that's a given. But I'm aiming for cross-platform functionality, and only trying to guarantee working with line-in, and speaker-out for sampling. If it works with others when assigned to them, great, but they're not going to be my focus. That's only for where the raw audio samples are pulledfrom. Adding a low-pass filter before using the audio input is a function of the visualization effect, NOT the core rendering processor.

I'm aiming for OpenGL-like 'minimal rendering' with an interpreted language wrapping it to enable a lot of the stuff that R4 doesn't support. I know better than to try to implement a lot of 'object formats' when I've seen what a mess trying to do that has made of DirectX, and how complicated it made the language. R4 already runs into the same problem, with over two dozen 'buffer types' for such arbitrary effects as a voiceprint effect, or loading a texture versus a solid color into a buffer for later use.

With the extension I'm focussing on though, I believe I may change the way things work slightly. Buffers will still work as before, rendererings will be defined seperately and use buffers. Rendererings will have a 'sorting order' assigned to them, and will be run in numerical order. If two rendererings have the same 'sorting order' then their order of execution is undefined and warnings will be thrown, again, to prevent any chance of circular execution logic.

And believe it or not, a FORTH-like language would have merits. I'm actually going to aim for something closer to BASIC though, myself. Make it as simple and easy to edit the files as possible.