Kamujin's picture

Should we create an OpenTK Mirror?

In light of the impass we seem to be at with regard to contributing to the SVN, I am trying to think of other options. I am very reluctant to fork the code as I don't see much long term benefit from fragmenting such a small community.

As a compromise, I have been considering kanato's idea of creating an off-site mirror/branch for us to contribute to. Ideally, we could submit a unified patch to Fiddler at various intervals.
The down side to me seems that you won't get the proper credit for your commits and that Fiddler might find it more difficult to merge the code. If anyone has a better idea, please speak up.

I can set up this mirror. Would any of you be interested in contributing?

kanato, I'd really like to work with you to get the OS X support debugged/stable.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

I'll sign the "would be nice if Fiddler comment on this" list, but seriously I don't understand the drama. Is there something broken that holds you from writing applications with OpenTK?

Before OpenGL 3 drivers are available from both Nvidia and Ati I see no reason to act there either. If Fiddler hasn't showed up when the drivers are available I'll manually add the functions myself. However it will be 100x better if Fiddler adjusts the Generator tool to do this, because it is used to generate the bindings for both OpenTK and Tao.OpenGL.

But there is also a big decision coming with GL3. Forward compatible contexts.
The way I understood the manual, a forward compatible context will generate invalid-operation errors whenever you call e.g. glVertex3f(). The solutions I see for this are
a) Use compiler conditionals to compile OpenTK either against GL 2.1 or GL 3.0
b) Don't do anything at all. Let the user sort out what's allowed in GL3+ contexts.
c) completely remove legacy extensions and functions. Set GL3.0 as standard.

Sorry if this is leading off-topic, but that's the only topic I see to be concerned about.

JTalton's picture

A couple of us need the resize event working in Windows on the GameWindow.
OSX support would be great.
Serialization of Vector was requested.
I'm still waiting on the new font code... I see it crash once in a while.
Support for external gl contexts... (Either sharing OpenTK context code or passing in an external context)
I've seen a couple of other requests...

I think many of us really like OpenTK and don't want it to fall to the wayside, thus we are wondering the future/status of OpenTK. I would prefer that Fiddler shows back up. If he doesn't I'd be for making a repository that we can commit fixes to and merge back into the OpenTK repository when that option presents itself.

I don't think any of us are upset, we are just discussing options.

Entropy's picture

What JTalton said. :-)

Also, Serialization of the Vector classes isn't much of an issue if you don't mind me editing the source to add the required attributes, but the fact that I needed to do that serves to highlight the fact that OpenTK is still WIP - obviously Serialization of OpenTK objects hadn't yet been considered. And that will be just one of many details to consider in order to make OpenTK as flexible and powerful as possible.

OpenTK works, sure, but that doesn't mean we should be happy to leave it as-is.

Kamujin's picture

"Is there something broken that holds you from writing applications with OpenTK?"

Actually, there are a few things.

1) Fonts don't work on Linux
2) OS X support
3) GameWindow class implemented inconsistently across platforms.

I only see this as "drama" if my understanding of the openness of this project is wrong. Otherwise, we are supposed to talk to each other and collaborate.

With all due respect, this is not as 3 week issue. We've been trying to communicate for months. I hope you can understand that it is frustrating because I think we see potential here. If there wasn't something to what you guys have assembled thus far, no one would care.

flopoloco's picture

The real deal is that major hundreds of technical bugs must be eliminated, and features must be increased (called Toolkit for nothing :) ).

One solution is to set the current version as a historic/milestone, and then move on towards a "different" community supported toolkit SVN, playing nice with Mono and cross-platform compatibility.

Other solution is to relief Fiddler from development issues (in respect to his personal time) but ask him only to control the architecture and design of the project.

If Fiddler can authorize any of the above solutions then all would be all clear.

Entropy's picture

It's clear enough that we're all awaiting a response from Fiddler.

I'm all for respectully awaiting a response until Thanksgiving, and discussing how the future development of OpenTK will go on without Fiddler if we don't get a response by then. As Kamujin said, we care about this project, and we don't want to risk it falling by the wayside.

In the meantime, it looks like the goahead a has already been given for the OS/X development work.

kanato's picture

Two other bugs that come to mind:

* GameWindow throws a GameWindowExitException when the user clicks the close button. This is fine if you're using GameWindow.Run which catches it, but if you have your own run loop, aside from the design issues of doing something like this, you can't even deal with it nicely because GameWindowExitException is internal to OpenTK.dll. This is a serious problem for something like AgateLib which abstracts away the graphics API.

* There's no public API to create a context for a control other than the GLControl. I wrote code to include a path for doing so in OpenTK.Utilities.dll and submitted it as a patch but it was never applied. Again, problematic for something like AgateLib.

Some other features that I think would be nice for GameWindow:
* An event that is raised when the user clicks the close button, allowing for the display of a "Save before exiting?" dialog.
* Ability to set an icon for the window, rather than the default one Mono or Windows gives it.

Kamujin's picture

While we are on this topic. As per Fiddlers request, I also submitted code for a GameWindow.Run function that spins the CPU much less then the current version, yet allows for reasonably accurate frame rates in the presence of course sleep timers.

I have received no feedback on it yet.

alwin's picture

whow, stop right there! you are using the wrong approach.

svn has nice and polished tools, that's why its at the moment my prefered scm. but svn is not designed for distributed development. merging with svn sucks bigtime, i don't want to waste any developers (especially fiddlers) time with merging and resolving conflicts.

before we go down the road of multiple svn trees (please, really, you don't want this). it's much better to switch to a distributed scm. personally i would reccommend mercurial. it has momentum, used by big projects (java, opensolaris, and a lot more). its opensource, and has a pragmatic community. the down site is that the tools are not as polished as tortoisesvn, altough it's comming close nowadays.

bazaar and git are also options for dscm. there are tools for all to convert from svn. pushing back changes to the svn trees are alpha quality on all scm's. well, i can tell a lot more, and do some conversion stuff, but before that i want to know for sure it's going to be used :)

for more information about mercurial search for the presentation on google video. linus also does a presentiation on git, it's worth looking at. altough i didn't like his elitism and attacks on svn, it does explain why you want a distributed model instead of a centralized one.

SeaEagle1's picture

Well, actually I find that with SVN 1.5 branching and merging has become a lot easier. But any distributed scm I've looked at lately has the problem that they have less user-friendly clients, the working principle has a steeper learning curve and it's very hard to keep a good overview of progress and state of a project. Besides that the main repo is still SVN with limited access, so as I proposed before, it's easily possible to use SVK or Git or whatever yourself for now to keep working, it still doesn't solve the problem here namely to get Mac OS changes etc. online somewhere.

(sorry but I'm getting a bit tired of people who seem to consider dscms as the solution to all problems lately...)