yagl Freebasic port 0.0.7 ( win32 mingw c/fb )

marzec · Last edited by marzec on Feb 09, 2006 12:58; edited 10 times in total

hello,

last night i was a bit bored and thought that making the gfxlib a standalone library for use in any other language is a good idea. after getting rid of all dependencies on the fb runtime library i succeeded in compiling, linking and using the library on windows and linux.

now there's a couple of questions as i haven't fully investigated the sources yet ( well i touched every file at least once, but i didn'T boughter to check out the implementational details of all of them :) ).

1) is the library fully thread safe?
2) apart from the decompression of the font data, is there anything the gfxlib would need to be 100% initialized? i couldn't find any real indications that there's something else needed besides fb_hSetupData()
3) is there a possibility to select a specific driver? in the set_mode function i spotted a funky loop that would select a driver. i didn't have a closer look yet.
4) i completely commented out the initialization of the hooks as they should not be needed in a non freebasic context. does this have any sideeffects i didn't think of?
5) i'm not quiet sure about it but i think i saw that the library is using dirty rectangles to update the screen. i'm not very familiar with this concept, could you explain it in the context of gfxlib2 and what i should look out for when i want to use double buffering?

i'm planning on writting a simple c wrapper around the library to hide the naming on some of the argument lists as they are not all needed for what i have in mind. i will then continue and write a c++ wrapper around this that will manage other stuff like surfaces ( bitmaps, sprites you name it ) and the input devices in a more object oriented way.

my main intention is to build a small and easy to use library that can compete to sdl to some extend. actually something in between sdl and tinyptc would really be a nice thing to have and the gfxlib2 seems to fit those needs just perfectly.

i know a lot of questions can be answered but investigating the source further. the problem is that i don't have a whole lot of spare time to work on this little project so any direct answers from lillo would be appreciated as they would avoid me having to dive through the source ( which is nice and clean though so it's not a pain in the ass actually :p ).

the current barebones sources without wrapper can be found at http://ratatoskr.dragonhill.cc/temp/simplegfx.rar. i used the 0.14 rtlib release from the site as fiddling around with cvs was to much of a hazzle ( not a lot of fun at 3am in the morning heh... )

thx for any replies

marzec · Posted: Nov 13, 2005 11:54 Post subject:

hello again,

after sorting out all kinds of confusion by studying the source code i answered all of the above questions myself :p. i got a preliminary package in the svn repository now if one of you guys ( mostly lillo ) would like to check it out:

https://opensvn.csie.org/simplegfx

anonymous checkout is allowed just grab an svn client of your choice. the whole thing is preliminary. my work isn't really a big achivement mind you, so seeing the lgpl notes in the source files might seem like a bad joke. but meh. there's a readme in the doc folder, i haven't yet given all credit that is due i guess so anybody i didn't mention please raise your hand.

i guess eric will report that one bug we found during testing the thing. it's in fb_hPutBlend4MMX. in the inner loop you miss to bitwise and the source dword with 0xffffff so the alpha byte is taken into account.

marzec · Posted: Nov 13, 2005 12:23 Post subject:

hello again,

after sorting out all kinds of confusion by studying the source code i answered all of the above questions myself :p. i got a preliminary package in the svn repository now if one of you guys ( mostly lillo ) would like to check it out:

https://opensvn.csie.org/simplegfx

anonymous checkout is allowed just grab an svn client of your choice. the whole thing is preliminary. my work isn't really a big achivement mind you, so seeing the lgpl notes in the source files might seem like a bad joke. but meh. there's a readme in the doc folder, i haven't yet given all credit that is due i guess so anybody i didn't mention please raise your hand.

i guess eric will report that one bug we found during testing the thing. it's in fb_hPutBlend4MMX. in the inner loop you miss to bitwise and the source dword with 0xffffff so the alpha byte is taken into account.

lillo · Site Admin

well, guess you were faster at discovering things yourself than me at replying to this message...

Anyway, nice work, but I have to say I'm not sure I fully understand your bug report about the fb_hPutBlend4MMX function. The AND you're talking about isn't there because... there is no need for it. I just assumed that when you use that blender routine, you just don't care about alpha values embedded in pixels of either source or destination bitmaps.

Aside from this, well, what to say... While I like your work, I can't hide the fact I'm a bit sad/nostalgic. I dedicated energy to develop a fast, tiny, standalone and multiplatform gfx library for FB because I wanted FB to have it as an exclusive not available elsewhere... In other words, to bring more people to the FB bandwagon also because of it. Anyway, guess this is the fate of (L)GPL software, isn't it ;)
Keep it up, at least TinyPTC can be worried by the enter of gfxlib as a standalone gfx library in the realm of the C gfx libs...

In closing, some suggestions:
1) Modify your setMode function so it's more clear for the user; maybe splitting it in different functions and adding a title parameter (for window title) would be nice. Something like:

1000101 · Hero

marzec · Posted: Nov 13, 2005 17:20 Post subject:

i already thought you'd not like the idea, and as i already stated my work is marginal on that thing. i haven't yet posted about it anywhere else other than here and some ppl in #badlogic know. i seriously don't have any problems with not making it public and completely respect your point. so speak the word and i keep it closed, no biggy.

i did this mainly because i wanted a small, fast and easy to use 2d library for smaller applications i'm about to do. sdl just doesn't cut it, tinyptc doesn't have enough functionality ( mainly the primitives are missing ) and allegro... well is allegro ( i know you are affiliated with it, but frankly the interface is messy ).

on the current state of it: this is just a very preliminary interface/wrapper if it even deserves that name. i wanted to make it fully oo, with the core being a singleton providing the primitive functions plust state setting functions and another class for surfaces with a possible internal callback function in case the screen depth changes so the surfaces would be converted to the proper bpp.

on the "bug": as far as i understand it, the gfxlib will use the 4 byte blender function in the case of 24 and 32bpp. now if i have a colorkeyed 24bpp bitmap and throw that at the put method it will just work, provided the unused 4th byte in the color keyed pixels is not set to 255. it is not really a bug it's just an assumption that might surprise some users ( at least it did surprise me and caused me to debug through the asm source heh ). the function should not take the 4th alpha mask byte into account imo, but it's no bug perse.

on the suggestions: yes i'm not very happy the way setMode works but at the time of writting i didn't really care as i wanted fast results. the cursor based print is not a bad thing imo, all i have to do is make it draw without destroying the background ( on a side note: why don't you have a transparent print as standard? backwards compatibility is a nice thing but in that case it's a bit overdone imo ).

and in closin: as pointed out in the first paragraph i really don't have a big problem to not work any further on this. i could write something similar around tinyptc, but i would need to write all the primitive functions myself, the same goes for the blitters. this was the main reason i didn't use tinyptc in the first place. but as i know that you put a whole lot of time and sweat into this library i'm probably only using it for private projects if that is fine with you.

lillo · Site Admin

1000101: ah, now I get it. Didn't think about that particular case for transparent pixels... :P
I will put the fix in CVS soon.
About the conversion functions: those are not needed for blit conversions, but for windowed modes... Some system configurations (combination of OS and video card) only allow to create a hardware surface to be attached to a window, if such a surface uses the same pixel format currently in use by the desktop (i.e. the system doen't supply automatic conversion). This means that if say, user desktop is running at 24bit BGR and user program requests 16bit RGB, gfxlib has to manually convert between the two to display frames properly. Since gfxlib was built to support only 8, 16 and 32 bpp internally, but it needs to support all possible desktop pixel formats to allow it to work in any condition, all those blitters you see in libfb_gfx_blitter.c and libfb_gfx_blitter_mmx.s are needed.
While in fullscreen mode, usually conversion is not needed as the system has really set the mode you requested, and that's another reason fullscreen mode is usually slightly faster (this is true in Windows but not true under Linux: X11 infact does allow to change resolution on the fly but not color depth, so color conversion is needed also in fullscreen mode)

marzec: really, I decided to put gfxlib under LGPL and developed it as part of an open-source project like FB. So you can do whatever you want with the code as long as you give credit and you generally respect the license. I'm fine if you decide to continue with your project and release it to the public.
About the transparent print support: I decided not to include support for it because the PRINT statement handling is already a mess in the FB parser... supporting an additional parameter for optional gfx-mode transparency would have made it even messier, which noone wants. An additional statement would have worked well, but adding yet another new keyword repulsed me, so I thought leaving the functionality as an external routine coded in FB itself would have not hurted, and then you had the gfxPrint routine found in gfxlib.txt.

marzec · Posted: Nov 14, 2005 9:46 Post subject:

in that case i'll continue to work on that little thing and i think it would be a good idea if you'd somehow check the results every now and then and give suggestions :p provided you find the time.

thx

marzec · Posted: Nov 23, 2005 16:09 Post subject:

after a couple of days on and off on the thing i put together a first version that is actually useable.

http://opensvn.csie.org/gamelibpp

the gfxlib is now part of a gamelib that features a networking library and a threading library. i guess it's as easy to use as possible in an oo context. i still haven't included the joystick functions and the setMode method is still a bit unintuitive. but meh check it out :p i already wrote a couple of sample applications, one being an online chess game http://ratatoskr.dragonhill.cc/temp/ochess.rar

it also lacks documentation for now ( though the netlib and threadlib is fully doxygen documented ) but that will come in the next revision. i also plan on adding a sfx module so it would be an all in one solution we'll see...

cha0s · Site Admin

gimme mp3 link.

marzec · Posted: Nov 24, 2005 15:27 Post subject:

wha??? http://ratatoskr.dragonhill.cc search there for mp3s

marzec · Posted: Nov 26, 2005 3:33 Post subject:

a new day a couple of new additions. altough the gfxlib way of using fonts is somewhat funky i decided to include the freetype library with the gamelib. well that'd done :p. it's far from being perfect yet ( antialiased vector fonts look like crap when small ) but it works. the user can now either create a font object and print a string with that font, or call the printing method without passing a font then it falls back to the std gfxlib font. fonts can be resized and get cached, you can draw with any color you want.

i also got rid of the pthread-win32 port dependency ( one goes the other comes... ) and everything is based on native os solutions now.

i also added joystick support, querying for screenmodes and an easier to use setScreenMode version that now only needs width, height, bpp and wheter or not the application should go fullscreen.

the library now weights in at roughly 720kb plus another 300 kb or so for the needed dlls by freetype. i tried linking freetype statically but that bloated the lib to 1.7mb :p. i guess 720kb is still not that bad considering what's in there.

the last thing i want to add is a sound module probably based on openal or on bass whatever fits my needs better.

everything works on both linux and windows still. for those who'd like to check it out, get tortoise svn and download from the above mentioned link http://opensvn.csie.org/gamelibpp ( redundancy is funky .. ). every suggestion is welcome especially from lilo :p

marzec · Posted: Dec 04, 2005 2:56 Post subject:

the first incarnation of the library is done now.

it features

+ 2d gfx via fbgfxlib2 ( thx to angelo )
+ networking library based on tcp ( for now )
+ input via mouse, keyboard, joystick (thx to fbgfxlib2 )
+ threading library
+ 3d soundmodule via openal
+ memory leak detector in debug mode ( written by Wu Yongwei )

the samples showed one memory leak within the library so far that i fixed, of course they are not representative and more tests are needed to be able to tell how stable this library really is.

concerning the testing of it it would be great to have some ppl actually use the library in their projects. i could write a c wrapper around it ( though this would neglect some of the features that are funky oo only ) but it would be still usable to a 95% degree. if somebody here is interested in a c wrapper ( that means it would be useable in fb ) just leave me a line and i'll possibly hack something together in the next week. sadly swig doesn't fit my needs as it would be to tedious to correct it's output so i'd have to do it by hand.

for those interested in the source you can find it at https://opensvn.csie.org/gamelibpp. it still needs a finishing touch and the soundmodule is barely tested yet but it *should* work. the library and examples can be build on win32( you'll need mingw ) and linux ( you'll need a couple of dev libraries installed see readme ). i will probably create an official site when i'm done cleaning up stuff with proper documentation and instruction

thx again to lillo for providing the gfxlib2

marzec · Posted: Dec 04, 2005 19:36 Post subject:

k, after bein named a thief on another forum i think i have to contribute back to fb in order to wash my name clean. writting a c-wrapper around it is not a hardtask but a tedious one so i'd love to have somebody that would help me a little. i think that especially the sound and networking module of yagl could contribute to fb pretty well. so if anyone is up to help me write a c-wrapper just leave a message here.

marzec · Posted: Dec 05, 2005 16:11 Post subject:

ok i just finished the complete doxygen documentation of the library what a $%#@ of work you can find the preliminary version of it here
http://ratatoskr.dragonhill.cc/public/projects/yagldoc/index.html it should give you an idea of how yagl is designed and how it works. the documentation is still not perfect and a matter of change of course

now i have to write a user guide and a few short tutorials on the matter plus code more sample applications and tests...

i'm still in search for ppl that would like to contribute to the c-wrapper thingy of the lib.