YAGL - Yet Another Game Library (FB 0.20)
Yeah, glancing at the code there is some inheritance and virtual functions in there, but it seems those are mainly constrained to the implementation. Specifically, there seems to be only one concrete graphics device implemented, Yagl::GlGfxDevice.
You can declare, in FB, C++ classes which contain virtual functions. You can use them, provided that you comply with the ABI of the C++ compiler that compiled the source. FB name mangling follows most of the g++-3.?.? (i think) scheme, which means most C++ code compiled with that compiler can properly be referred to by name. You will have to get rid of all the 'bool' references (make then ints or whatever), and you either have to provide a factory function to get instances of those classes or manually setup the vtable. I'm not familiar with how YAGL does things, but, at least in the case of Yagl::GlGfxDevice, it is only constructed in the "C++ side" of things, so no manual vtable mess is necessary, other than to make room for the pointer to it in the class definition.
Obviously, the use of std::list in the API must be changed to something else, but, interestingly, Yagl::String can be kept, provided that the uses of std::string in its API are removed.
The library as a whole seems flexible enough, just that not too much has bee done to take advantage of that flexibility, probably lack of time, motivation, etc. But, trying to use the C++ library directly is probably too much work here, and a port might be best. FB has procedure pointers, so flexibility is not really a problem, though in it's current state, an FB rewrite that aims to keep the same flexibility might suffer from a little boilerplate, but probably only at the developer's expense, not the user's.
You can declare, in FB, C++ classes which contain virtual functions. You can use them, provided that you comply with the ABI of the C++ compiler that compiled the source. FB name mangling follows most of the g++-3.?.? (i think) scheme, which means most C++ code compiled with that compiler can properly be referred to by name. You will have to get rid of all the 'bool' references (make then ints or whatever), and you either have to provide a factory function to get instances of those classes or manually setup the vtable. I'm not familiar with how YAGL does things, but, at least in the case of Yagl::GlGfxDevice, it is only constructed in the "C++ side" of things, so no manual vtable mess is necessary, other than to make room for the pointer to it in the class definition.
Obviously, the use of std::list in the API must be changed to something else, but, interestingly, Yagl::String can be kept, provided that the uses of std::string in its API are removed.
The library as a whole seems flexible enough, just that not too much has bee done to take advantage of that flexibility, probably lack of time, motivation, etc. But, trying to use the C++ library directly is probably too much work here, and a port might be best. FB has procedure pointers, so flexibility is not really a problem, though in it's current state, an FB rewrite that aims to keep the same flexibility might suffer from a little boilerplate, but probably only at the developer's expense, not the user's.
That was kind of what I thought. It's nice to know I'm not crazy.stylin wrote:Yeah, glancing at the code there is some inheritance and virtual functions in there, but it seems those are mainly constrained to the implementation...
..FB has procedure pointers, so flexibility is not really a problem, though in it's current state, an FB rewrite that aims to keep the same flexibility might suffer from a little boilerplate, but probably only at the developer's expense, not the user's.
Well that's great that it can be done without TOO much hassle. Replacing std::string will be easy enough with fb's string. As for the linked list, doesn't fbext have a linked list class?
I really liked using Yagl back when work was still being done on it and think it has great potential since it provides so many essential features for game programming. In c++ I have to use glfw, ftgl, and freeimage to get all the features that yagl provides by wrapping similar libraries in an easy to use way.
I'm interested to see if the porting idea ever takes off. I haven't done any FB coding in awhile and haven't spent too much time looking at yagl's source yet but if the port is a collaborative effort perhaps I could be of some help.
I really liked using Yagl back when work was still being done on it and think it has great potential since it provides so many essential features for game programming. In c++ I have to use glfw, ftgl, and freeimage to get all the features that yagl provides by wrapping similar libraries in an easy to use way.
I'm interested to see if the porting idea ever takes off. I haven't done any FB coding in awhile and haven't spent too much time looking at yagl's source yet but if the port is a collaborative effort perhaps I could be of some help.
DaveUnit, fbext does have a linked list, but from what I can tell by (again) glancing at the code, YAGL uses std::list mostly for storing pointers and ints, so an array or some other home-grown solution might be easier (fbext's linked list is header-only, like a C++ template, so the dependency isn't that severe, but I don't know).
I've never used YAGL, nor had the time to check out the C-wrapper yet, so I guess I wouldn't be much help, but maybe after the busy holiday season, YAGL looks pretty easy to use..
I've never used YAGL, nor had the time to check out the C-wrapper yet, so I guess I wouldn't be much help, but maybe after the busy holiday season, YAGL looks pretty easy to use..
Actually a collaborative effort is a good idea. Split it up by sections. One person/group handle the audio files, one handle the input, one graphics, one network, etc.DaveUnit wrote:...I'm interested to see if the porting idea ever takes off. I haven't done any FB coding in awhile and haven't spent too much time looking at yagl's source yet but if the port is a collaborative effort perhaps I could be of some help.
And I thing we could, in that way, quickly have a port of yagl in FB...
The network stuff, to answer my own question from earlier, appears to be half done. Only parts are filled in.
It also looks as thought Marzec was going to include a collision handler. All it is it a virtual constructor and a virtual method at the moment, so I'm not sure what it was related to.
But if anyone wants to take on part of the job, I will do the same. I may even fiddle with it if no one wants to help, but I doubt I would get very far on my own. At least not quickly.
I could be of some help but I would definitely want someone "in charge." Given a plan of how the port is going to be done I'd be more able to contribute
As far as the stuff I know well enough to help with would be the input because it uses glfw (right?) and i use that a lot, or the graphics because I know the basic opengl that the blitting commands would use.
Would we be keeping the object oriented approach of yagl or would the port resemble the fb wrapper that we have currently?
Can fb handle things like singleton classes that yagl uses? I never knew about them before I took a break from fb so I never tried to code one.
As far as the stuff I know well enough to help with would be the input because it uses glfw (right?) and i use that a lot, or the graphics because I know the basic opengl that the blitting commands would use.
Would we be keeping the object oriented approach of yagl or would the port resemble the fb wrapper that we have currently?
Can fb handle things like singleton classes that yagl uses? I never knew about them before I took a break from fb so I never tried to code one.
@DaveUnit: I figured we could keep the OOP style of the original. As to the singletons, I believe that stylin did a tutorial on that which can be found in QBExpress. Also, graphics or input would be great for you to start on. Pick the one you are most familiar with. I was going to try to translate the sound stuff.
@Eponasoft: Any advice you would be willing to offer, would be most welcome.
@Eponasoft: Any advice you would be willing to offer, would be most welcome.
-
- Posts: 56
- Joined: Dec 15, 2008 10:24
- Contact:
-
- Posts: 56
- Joined: Dec 15, 2008 10:24
- Contact: