Acedia's picture

The OpenTK Framework expansion project....

As an Xna / c# programmer for over 4 years I have worked with some really unique ideas and robust coding techniques. However their "cross-platform" abilities, PC to Xbox, do not help those with needs to develop games for the Linux, and Mac communities, of more dedicated users. I'm proposing to get a team together to build the OpenTK framework and expand it to match, or meet the expectations of those users that use xna that would like an alternative to just building games strictly for windows or Xbox360 based systems.

My proposal for the OpenTK framework would include better (not to say it isn't' great already) ways of getting newer programmers building OpenGL games faster and with much less work. Less than a game engine, but more robust then what is available in OpenTK already. Things like Model Loaders, Content Processors, etc.

Sample code of a Content Processor

Model myModel = Content.Load<Model>(@"Content\myModel.obj");
myModel.Position = new Vector3(0,10,0);
 
Texture2D sampleTexture = Content.Load<Texture2D>(@"Content\modelTexture.png");
myModel.Texture = sampleTexture; || myModel.Texture = Content.Load<(@"Content\modelTexture.png");

Expanding the OpenTK Framework to be more robust to include something like:

protected override void Activity(GameTime gameTime)
{
     myModel.Position.Y += gameTime.TimeinMS * 1.0f; // gameTime.TimeInMS  is the amount of time passed in miliseconds since last Update was called.
}
 
protected override void Draw(GameTime gameTime)
{
    GraphicsDevice.Clear(new Color4(0,0,0,1), ClearBuffer.Color | ClearBuffer.Depth);
 
    GraphicsDevice.DrawPrimative(myModel, DrawType.Triangles);
 
    base.Draw(SwapBuffer.True);
}

If you are interested in Helping Expand OpenTK, to be more robust and reliable for transitioning XNA programmers, you can PM me...
I will update this Thread as much as possiable with new and updated features added to a New Branch of OpenTK.


Comments

Comment viewing options

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

You'd be interested in checking out the demo branch (git) then. It has a project called OpenTK.Graphics that contains an API very similar to what you propose :)

protected override void OnRender(FrameEventArgs e)
{
    // e.Time is the amount of seconds since the last event
 
    device.Framebuffer = shadowBuffer;
    device.Program = shadowProgram;
    device.SetAttributes(0, myModel, "Position");
    device.SetAttributes(1, myModel, "Normal");
    device.SetAttributes(2, myModel, "Texture");
 
    device.Clear(Color4.Black, BufferFlags.Color | BufferFlags.Depth);
    device.DrawPrimitives(myModel, PrimitiveType.Triangles);
}

This is a pretty thin OO abstraction over raw OpenGL, but it should feel pretty familiar to XNA programmers.

The API will get its first alpha release early next month. Along with cloo (CL object-oriented) and hopefully aloo (AL object-oriented), this will likely be the focus of an OpenTK 2.0 release next year.

Although it's already usable to a certain extent, there's a *lot* of work left to do on this. The API doesn't cover anything similar to the XNA "content pipeline" either (I don't have any experience with that, so I don't know whether it's applicable here).

I'd love some feedback on this and - why not? - some help on getting it up and running. Let me know if you are interested in helping out, so I can move it to its own branch!

nythrix's picture

Being high-level tools, model loaders and content processors are parts of graphics engines, no question. They make assumptions that needn't be true for everyone. Also such an enterprise is likely to take up a large amount of coding hours. Do you feel there's need for yet another engine? How about helping out with an existing one (i.e. Axiom)?

Acedia's picture
nythrix wrote:

Being high-level tools, model loaders and content processors are parts of graphics engines, no question. They make assumptions that needn't be true for everyone.

Content processors, and Model loaders are not necessarily game engine specific, Take for instance the Picture box in Winforms, it has a content importer to know what type of file, and how to display it. Building these would only allow for easier access to making games for those looking for another way. being able to load an obj file by stating:

Model objModel = Content.Load<OBJ>(@"Content\someObjModel.obj")
is much easier and faster than writing your own custom obj importer, or trying to find on on the web, then trying to implement it to code that you have already written.

I'm not saying have a model class that provides you with Model.X = 10, etc, or Model.RotateX = Math.Helper.ToRadians(45), type senerios, I'm just talking about creating importers for specific types of model and texture objects.

nythrix wrote:

Also such an enterprise is likely to take up a large amount of coding hours. Do you feel there's need for yet another engine? How about helping out with an existing one (i.e. Axiom)?

that statement right there describes to me the amount of belief you have in this project. how much work do you think it took them working on axiom to build their engine. Don't you think it would have helped them out much more, to get things in game, without having to write custom importers, for each of their objects, if it was already written for them. More Developers would probably be happy about the importers due to the fact that they could focus more on gameplay, rather than coding in graphics support.

When using a "gaming framework", things such as content importers are big helpers to those who are going to want to switch to opengl, from dx. Just because it's built into the framework, doesnt mean that it has to be used. That being said there are tons of items in the XNA framework that dont get used on a game project, Take for Instance the Avatars. You can only use them on the xbox.

the Fiddler's picture

Just a note here that OpenTK is not a game framework and doesn't actually aspire to be one itself. By design, OpenTK is closer to SDL or SlimDX rather than XNA. Axiom is even further away.

That said, I can certainly appreciate the need for higher level tools and frameworks. Several people have already written addons that can simplify a number of tasks (textures, text, model loaders) and it might be nice to collect them under an umbrella "framework" project (test them, make sure they work, they are simple to use, their APIs fit together etc).

This is not something I am willing to implement by myself at this point in time (managing 50MB of source code is more than enough :)), but it is certainly something that can be developed by the community. If at some point it becomes apparent that the goals of the framework and OpenTK are aligned, the projects can merge. However, until then it will be much easier (not to mention agile!) to develop the framework outside the core library.

In fact, this is how Cloo and Gloo are being developed (both are projects that may be merged into core once mature enough).

nythrix's picture

Content processors, and Model loaders are not necessarily game engine specific, Take for instance the Picture box in Winforms...
You have a point there. However, such a model is more complex than a buffer filled with pixels and its representation in memory doesn't necessarily fit everyone. An engine working with rasterization expects a very different 3D model representation than one targeting raytracing. For the later, triangle strips make no sense. In fact, such an engine might be better off with parametric surfaces (personal experience). Can you provide such a flexible solution? Besides, we all know how much flexibility and speed talk to each other...

If by "this project" you mean the framework then yes, I'm sceptical. If you're talking about OpenTK then I have to disagree with you. Belief in this project led me to a very close cooperation recently ;)

Don't take this the wrong way. I'm just not convinced entirely. However, should you succeed, I'll be the first to congratulate.

Acedia's picture
the Fiddler wrote:

I can certainly appreciate the need for higher level tools and frameworks. Several people have already written addons that can simplify a number of tasks (textures, text, model loaders) and it might be nice to collect them under an umbrella "framework" project (test them, make sure they work, they are simple to use, their APIs fit together etc).

I would be more than happy to Get an OpenTK "Gaming" framework together and test, retest, and orgainize it all together making, kind of a standardized "OpenGL" gaming framework for the OpenTK community.
I do have other things on my plate at the moment as i have two game projects going at once, with possiably another on the way. So to start it might take some to get it going, but if there are others looking, and willing to help. I'd be more than happy to take on such a large side project.

flopoloco's picture

Check your PMs, I sent you something. :)

Icefox's picture

Sorry to resurrect this topic, but it seems like an interesting and useful idea. However, I also have a couple worries about the scope and architecture of a "gaming framework", since that can cover pretty much anything from math to networking...

I'm not sure exactly what you have in mind for the structure of this Acedia, but I feel like it would be best to structure such a framework not as a single library or integrated system, but as a pile of parts that developers can choose from as they wish. I'd imagine something somewhat like SDL's plugin libraries; a pile of useful parts that share the same base, but are (and this is important) unrelated to each other. This seems like it would both make the framework easier to use (you don't need to understand a whole world model to use one part), develop for (you don't have to make sure your tools play nicely and fit into the whole model, and you can update your own plugin without having to go through some master repository or something), and organize (everybody maintains their own plugin, you just have to coordinate).

On the whole, I think it sounds like a very useful idea though. If I had to choose between trawling Google, and going to some part the OpenTK website to find a list of handy add-ons listed and distributed in a consistent way... :-) The Projects page is good, but my idea for this would be more specific and use-oriented. Alas, I don't have the time for a big side project... yet... but I might be able to handle part of one.

Acedia's picture

Well after a couple of weeks of a hectic work schedule, between doing a GDD, a Game, and a Networking project for another team. I finally got around to starting the base structure of what i had in mind.

@Icefox:

I know I haven't said much about how i believe this project should go, However That was my plan to begin with. There are several awesome libraries already out there, but alot of them do things differently, but work the same, maybe someone has been coding a Networking project using a specific library, or even there own, I shouldn't be the one to say that. Hey your using this framework, so you have to use this Networking library. However i do believe in providing a Complete package. Something that has Networking, Audio, Animation, etc. support built in, if you don't want to use them, then your more than happy to use plugins of your choosing.

Just like in Xna they provide a Networking api, however your free to use any Networking library of your choosing.

The basics of what i'm trying to achieve here, is to provide a few things, Familiarity, Ease of Use, while trying to unify Game development using OpenTK.

Acedia's picture

After doing some work on the Game class today, I noticed that when going to my Linux environment that somethings have to be changed (coding wise). So i'm probably going to need some help from someone, or a couple of people to be able to change the code a little bit to work in those environments.

Things like my Components, and GameWindow class need to be changed, because for some reason they don't do what i was intending them to do, at least in Linux. I have noticed that in Linux the position of the window is always in the Top right corner. I don't know enough about linux, and it's "window" system, to do anything about it. However I have the beginnings of a Game class that Sets up window with Update and Draw Callls. I want to work on a couple of more things like the GameTime class before I release something to the public.