First of all, sorry, I don’t have yet any screenshot .
Summary: If you haven’t followed the post about changing the GUI to QT (here), I’m trying to do an OpenGL rendered playfield, so we can boost Synfig.
I’ve a few (well, just one for now) questions.
Should I maintain the old playfield as an option? Or if anyone want the old (or the new) just have to compile again? I’ve just sneaked a bit in the code, and it’s VERY GTK dependent.
I want to maintain the old playfield as an option, and make playfields as options (just in case someday we add a DirectX one, for example), but that means changing A LOT of things (well, maybe just only the renderers and the workarea, but that’s a lot of files, maybe 8 without the headers). Don’t know if that’s intended / wanted / tolerated, etc…
P.D. I don’t know if that post has to be here. If not, kindly moderator, please move
I think that the best option for the moment is to keep the old playfield and add the new one using environment variables like #ifdef STUDIO_USE_OPEN_GL bla bla. Probably it would make the code more unreadable but it should keep it functional. Also it would allow to use the old playfield for the output render because, as I mentioned in the other post, it might be possible that OpenGL doesn’t render accurately all the effects to the final output and we have to continue using the old renderer.
Exactly. Optional renderers would be the good choice.
Regarding to the modification of a lot of files I think that it would be good if you use the git repository that dooglus (our only and main developer) keeps for large modifications. Currently we (he mainly) are doing a bone system in synfig. You should be able to use that repository to keep track of large chunk of files and also to allow others to pull from it and test the branch in other machines. Once the modification looks fine it would be a big commit (stashing it first) to svn. Unfortunately dooglus’s hardware is mostly dead so he barely can connect to internet lately and the bones development has been momentary discontinued.
I don’t know if you have a good hardware but dooglus was using my pc (quadcore 2.66 GHz 8 GB RAM, that has Ubuntu amd64 installed) remotely for quick compiling and testing. We have made a binary of synfig and synfigstudio for each 3 or 5 commits so we can find quickly where the bug was introduced in the past. I’ll be glad to share my resources with you too.
I believe that there is a open account for guests in the repo to allow others to commit changes. Try that first, before start doing any code.
Hey,
I’ve been talking to dooglus and he told me to allow you to push to git repo.
Just open an account here: repo.or.cz/m/reguser.cgi
and email dooglus to let him know your username to allow it to write on synfig repository.
Yes, that’s the way I’m doing it right now. And yes, the code IS more unreadable (at least the renderers, that have a few nested ifdef’s), but I think I can add it as an option when I’ve finished with it, so no problem here .
Ok, thanks a lot! Also, I mostly prefer using GIT than SVN . It’s way better (in my humble opinion), and you can commit offline. Great!
Wait-wait-wait! Is it images produced by synfig renderers?
I guess now I know why genete was silent lately - you talking with Uiomae about code?
Uiomae, that’s great!!! Superb!
I’m doing a “development update”. This is the current state of the renderer:
Don’t you like the new ducks? I LOVE them
Anyway, I’m progressing to add OpenGL as full renderer. As dooglus told me, it’s better to add some functions to the layers to render with OpenGL instead of the current renderers. Currently, there is a “Layer::accelerated_render()” function called for every layer. I’m going to add “Layer::opengl_render()” for each of them too. But previously, I’m going to rename “Context::accelerated_render()” and call it “Context::render()”, because it iterates over layers and call the needed methods, but this time it’s going to call “Layer::accelerated_render()” or “Layer::opengl_render()” depending on selected renderer. I’ve already added a variable to Target base object to store the current renderer, and an option to the CLI to select the renderer. Option in studio it’s on its way!
Anyone has another different / better idea? Maybe questions? Thanks in advance!
Amazing work!
This will push Synfig towards the end users so much, because it will become WYSIWYG app! No need to wait for render to see final result in motion!
Hi again. I wanted to know what card do you have in order to focus the new features a bit. Also, I need to know the capabilities of your card. So, in order to do that, I need one of this things:
If you run Linux:
Run the glxinfo utility, and send here the output. To do that, you can do in the console: “glxinfo > glxinfo.txt” and attach here the glxinfo.txt file
Run the glewinfo utility. To do that, install the package glew-utils (in Debian based systems, at least) or glew (in Fedora systems, thanks Zelgadis) and run “glewinfo > glewinfo.txt”
If you run Windows:
Run the glewinfo utility. Install the glew package (search on Google for the glew webpage) and run “glewinfo > glewinfo.txt” on a console.
If you run MacOSx:
I don’t really know about this one, but I think glew also works on MacOSX.
Anyway, just attach the files and say what system are you using.
For the OS : Debian unstable. More or less up to date. Well, maybe less (if you want to know the version of a specific package, ask ^^) 2.6.22-1-amd64 glewinfo.txt (114 KB) glxinfo.txt (10.2 KB)
.
(at least the renderers, that have a few nested ifdef’s), but I think I can add it as an option when I’ve finished with it, so no problem here 
.
