YAGL - Yet Another Game Library (FB 0.20)

DaveUnit · Post by **DaveUnit** » Dec 23, 2008 20:06

Yagl can't be ported easily since it uses a lot of c++ features that aren't available in FB. Yagl would probably lose a lot of its flexibility when the port is made unless you have some clever ideas I'm not aware of.

stylin · Post by **stylin** » Dec 23, 2008 20:44

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.

Post by **Imortis** » Dec 23, 2008 21:20

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.

That was kind of what I thought. It's nice to know I'm not crazy.

DaveUnit · Post by **DaveUnit** » Dec 24, 2008 3:04

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.

stylin · Post by **stylin** » Dec 24, 2008 7:37

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..

Post by **Imortis** » Dec 24, 2008 8:13

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.

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.

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.

DaveUnit · Post by **DaveUnit** » Dec 24, 2008 13:53

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.

Eponasoft · Post by **Eponasoft** » Dec 25, 2008 5:12

The collision handler was one of the last things marzec and I talked about on IRC before he abandoned the project. We were trying to think of the best way to approach it. I guess he stopped the project before completing it, though.

Post by **Imortis** » Dec 26, 2008 1:40

@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.

Gods and Idols · Post by **Gods and Idols** » Dec 26, 2008 2:57

If you guys go ahead with this do you want access to the YAGL website in order to update it?

Post by **Imortis** » Dec 26, 2008 3:24

I hadn't thought about that. I guess we will let you know when we get to that bridge.

Gods and Idols · Post by **Gods and Idols** » Dec 26, 2008 14:36

Imortis wrote:I hadn't thought about that. I guess we will let you know when we get to that bridge.

Just give me a shout if/when you want it.

Eponasoft · Post by **Eponasoft** » Dec 26, 2008 17:51

Imortis, I'll help as much as I can. One of things I wanted marzec to do was to implement the POV control, but it didn't seem he could figure out how to work it in Linux. It's easy to do in Windows, but apparently not so easy in Linux.

Post by **Imortis** » Dec 26, 2008 19:52

I'm not sure what you mean by POV. The only thing I know of with that abbreviation is Point Of View. If you let me know what you are talking about I might have a better idea of whether or not I could do it.

stylin · Post by **stylin** » Dec 26, 2008 21:08

You guys could probably just set up something on code.google.com for a quick and easy SVN-based repository. Much less hassle than sourceforge.net, IMHO, and it comes with simple wiki and mailing list support too. (in my experience it's also lots faster than sourceforge.net)