Horde3D

Hi new to horde and Looks as I'm going to start using this engine for my next project. One thing I always do when I start using a new engine is start making classes. Like a general screen class with GLFW functinos. But wanted to ask if there are any global efforts first. No need to reinvent wheels.

Not sure what you want to do, but is GLFW itself not enough modularization for you screen class?

There are a few users here who are building class libraries on top of Horde:

viewtopic.php?f=4&t=266
viewtopic.php?f=4&t=466

Hi.

Who are those users?

I am trying to create a simlar class-framework on the Smtalltalk-side using VisualWorks (VW). I'm studying and then slowly removing the GLFW window-manager functions and replacing them with VW's event system, and further linking each event to the appropriate callback in GLFW. Utlimately, I want to get as much of this C/C++ code into the Smalltalk as possible. Reading/writing and debugging in Smalltalk are much more accurate and fluid than in C++.

There will have an OpenGLWindow instance in VW that can create the needed rendering context and 24-bit WinDIBSection for in-memory rendering and swapping. I already have most of this working from the previous framework I use. The window starts the engine as it opens, or the model to be rendered starts it as it goes to render itself.

I am trying to determine how to create the various resources needed and how best to model them on the Smalltalk-side. I do not want to duplicate the scenegraph in Smalltalk. An object model that knows how to create H3D-compatible XML-representations and pass them through API functions to create the scene and to attach model-, light-, and camera-nodes seems to be the correct approach. Suggestions?

Shaping

Well you may be right. call me old fashion but dumping a bunch of code in the main and app files is not my cup of tea. Now granted theses are just examples ( kignt, Chicago ). But I like to set things up more like this for example..

examples:




Cleaned up


Yeah nothing fancy here... I mean if they dont change much why not put it in classes? And there would be a wrapper or add on h and cpp files that we all could share and reuse in any game we make. Then we could make other wrapper files for certain functions that get used a lot. Like a input class for keyboards, mice and joysticks ( unless that is already done ).

But like you said maybe I will come to see that this engine already has enough modularization. I'm still working on the editor for now..