BlueMonkMN's picture

OpenTK / Source / Utilities / Fonts

I just updated all my local code from SVN and noticed that the font implementation has been moved to a separate project? Will this be the final architecture, or will fonts be merged back into the OpenTK library when implemented?

The real reason I'm posting, though is because of an error in compiling this code:
class Glyph : IPackable<Glyph>
and this code:
static TexturePacker<Glyph> pack;

The errors are:
'OpenTK.IPackable<OpenTK.Graphics.Glyph>' is inaccessible due to its protection level

and

'OpenTK.TexturePacker<OpenTK.Graphics.Glyph>' is inaccessible due to its protection level

It looks like it's complaing because TexturePacker and IPackable are internal to the OpenTK assembly and are being referenced by the Utilities/Fonts assembly... or am I compiling this wrong?


Comments

Comment viewing options

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

Is this Mono or .Net? OpenTK.Utilities can see internal members of OpenTK (InternalsVisibleTo attribute). This is strange, since a checkout compiles cleanly here.

Try build distclean then rebuild - old object-code might be confusing the build.

BlueMonkMN's picture

Sorry, I haven't been using the included build scripts because I prefer to manage OpenTK in the same environment as the SGDK2 project -- Visual C# 2008 Express. So I've been manually generating Visual Studio projects for the code that I've downloaded to try to compile them. I scanned the code quickly for an "InternalsVisibleTo" attribute, but didn't see any at first glance. I didn't look very hard. Have you considered providing Visual Studio project files for those of us using Visual Studio Express?

Edit: I just noticed there's a documented build command in the OpenTK delivery to build VS2005 project files, I'll try that.

the Fiddler's picture

Edit: I just noticed there's a documented build command in the OpenTK delivery to build VS2005 project files, I'll try that.

That's the way for now.

I plan to move to msbuild (.sln) completely once Nant and MonoDevelop support it natively (should happen within the next few months). A VS2005 solution will act as the "master" script, and Nant, VS2008 and autotool targets will be generated from that prior to each release.

I am not a lawyer, but according to the MIT/X11 license you are free to include OpenTK in your project -- as long as you distribute a copy of the OpenTK license. However, I'd advise against doing that at this point: OpenTK is still too volatile, and syncing with updates will soon become a serious pain. It might be better to wait for the 1.0 release and/or look into merging the dlls.

BlueMonkMN's picture

I'm still not clear on why the text output functions were moved to a separate assembly. Are they going to remain in a separate assembly?

objarni's picture

IIRC, I think the rationale was the following:

1) OpenTK.dll should be as close to the "native libraries it wraps" as possible (close to OpenGL/AL that is)
2) All other functionality (model loaders, fonts, utilities in general) that actually build upon that is going into Utilities

I remember one reason being that the utilities functionality is bound to be a lot more volatile (bigger development effort in the long run -- that is higher maintenance cost).

A simple heuristic to decide whether some functionality 'A' should be inside OpenTK or OpenTK.Utilities, is

"Does 'A' wrap/rename already existing functionality (OpenTK), or add new functionality (OpenTK.Utilities)".

One "exception" is the math routines -- but the GL/AL wrappers use them so they are really at the heart of OpenTK actually. Making them stable/non-volatile is therefore important. After all, they are vector/matrix/quaternion routines aimed at 2d/3d computer graphics, so they should "freeze" quite soon.. (I guess)

Fiddler: Please correct me where I'm wrong or missing something.

the Fiddler's picture

No, you are quite correct.

By keeping the size and scope of the core library down, we make it more maintainable in the long run. It's also easier to add functionality this way (e.g. a vorbis decoder which really does not belong to the core).

Once the core is stable, development will shift to add-on functionality.