Should gfx library be improved, in newer version?
Quote:
Its not a very good practice to change language every time there is a newer version out.
Its not a very good practice to change language every time there is a newer version out.
I am referring to adding functionalities to an existing command , It might cause conflicts to my existing freebasic programs. Adding libraries is fine if that is your opinion, and your opinion does not mess up my codesI don't really understand this opinion. FreeBASIC isn't a standardised language, it's a new language. The language should improve with each new revision. Is adding major features like UDT properties OK, but not adding a new library routine?
Last edited by roook_ph on Jun 01, 2010 10:59, edited 1 time in total.
It won't break your code if one could writeroook_ph wrote:I am referring to adding functionalities to an existing command , It might cause conflicts to my existing freebasic programs. Adding libraries is fine if that is your opinion, and your opinion does not mess up my codes!
Code: Select all
BLOAD "myfile.png", bufferCode: Select all
BLOAD "mylargefile.bmp", bufferBload will never load pngs, deal with it. Use fbpng.
Why do you need to bloat the language with a bunch of specific things like loading PNGs or JPGs when you can just as easily build a library to accomplish this. This is the reason FB is so great. It may not do everything, but what it does it does well, and it gives you the tools to make it do more. Improvements that address compatibility with libraries is one thing, but adding a bunch of stuff that can be done with libraries doesn't make much sense to me.1000101 wrote:Bload will never load pngs, deal with it. Use fbpng.
-Vince
...because IMHO the BMP-only restriction is 1990-style - simply old-fashioned. ;-)vdecampo wrote:Why do you need to bloat the language with a bunch of specific things like loading PNGs or JPGs
I know fbpng. On the German FB portal we have an entire tutorial just on loading and saving PNGs but I think the current ways are more complicated than necessary.1000101 wrote:Bload will never load pngs, deal with it. Use fbpng.
An open source programming community doesn't need to be more conservative than the Pope himself. Just my two cents. ;-)
I don't see any restrictions, if one is willing to put some effort into coding a solution.Sebastian wrote:...because IMHO the BMP-only restriction is 1990-style - simply old-fashioned. ;-)
-Vince
Implementing transformation matrices in the PUT command should not be difficult:
http://en.wikipedia.org/wiki/Transformation_matrix
It could be done with no change to the syntax, because it would only require to add four optional parameters.
It would allow rotations, scaling and shearing in an easy way, making MultiPut unnecessary.
http://en.wikipedia.org/wiki/Transformation_matrix
It could be done with no change to the syntax, because it would only require to add four optional parameters.
It would allow rotations, scaling and shearing in an easy way, making MultiPut unnecessary.
Only four more parameters to push onto the stack? Well why not add a clipping volume, ROPs, post render effects, pre render effects, etc, etc. Maybe we can break 1MB on the amount of crap you aren't doing that's getting pushed onto the stack so people can be lazy and just use PUT for everything!
No.
Don't be lazy, quit $#@$& that bmp's are from the 90's (because they are actually from the 70's). The only reason we have things like BLoad to begin with is QB compatibility and imo it should be dropped altogether for external libraries which do specific tasks like fbpng or maybe even fbbmp for bitmaps, fbjpg for jpegs, etc.
In any event, only newbs want this crap added bloating fb even more for no good reason.
No.
Don't be lazy, quit $#@$& that bmp's are from the 90's (because they are actually from the 70's). The only reason we have things like BLoad to begin with is QB compatibility and imo it should be dropped altogether for external libraries which do specific tasks like fbpng or maybe even fbbmp for bitmaps, fbjpg for jpegs, etc.
In any event, only newbs want this crap added bloating fb even more for no good reason.
-
fernando.inf
- Posts: 28
- Joined: Mar 10, 2009 1:41
Well apparently I said + what should I suggested a functionality, and ended up creating a big confusion!. I apologize!
analyzing the posts, I experienced that + is right, if implement all features directly into gfxlib FB, end up making it too heavy, and many people would not use everything, just some funcionalidadades, then I think it is best to use libs outside it, as fbpng and etc ...
When I talked about support for ms-dos have been abandoned, DRV said I left the maintenance of the same (am I right?).
And also feel shortage of help and resources for ms-dos, since the DOS forum is not busy, and I think most of the staff that came up was FreeBASIC because it is the basic language + similar as possible with that many people used Qbasic for years, even just for a hobby as I, despite already having done commercial application in it.
Sorry for bad english. :)
analyzing the posts, I experienced that + is right, if implement all features directly into gfxlib FB, end up making it too heavy, and many people would not use everything, just some funcionalidadades, then I think it is best to use libs outside it, as fbpng and etc ...
When I talked about support for ms-dos have been abandoned, DRV said I left the maintenance of the same (am I right?).
And also feel shortage of help and resources for ms-dos, since the DOS forum is not busy, and I think most of the staff that came up was FreeBASIC because it is the basic language + similar as possible with that many people used Qbasic for years, even just for a hobby as I, despite already having done commercial application in it.
Sorry for bad english. :)
1000101 wrote:In any event, only newbs want this crap added bloating fb even more for no good reason.
Maybe my point has been misunderstood:
1) I agree that support for more graphic formats should not be integrated in FBGFX: there are too many formats (PNG, JPG, TGA, animated GIF, TIFF... and why not PIC? or LBM? or PCX? Or PCD?). To mess with other graphic formats, there are dedicated libraries, APIs, and much more.
2)Adding more commands won't bloat anything: the additional code won't be linked to your program, unless you use new commands (the library is made of several .o files, and only ones that are needed will be linked in the final program)
3) I believe that some features (in particular scaling, rotations, and maybe even pixel-perfect-collisions) are general-purpose, and they should be featured by a generic graphic library.
FBGFX should respect the basic philosophy: even a beginner should be able to use it, doing almost everything: when a faster/more specialized library is needed, fbgfx can be disabled.
I'm suggesting that because, in current situation, if you want to develop a game in FB, you can either use fbgfx (but too often your game will look like you've made it in qbasic), or use some other library (but, if so, where is the advantage of using freebasic and not c++?). A common criticism on FreeBasic is "it's actually C (or C++) with a BASIC syntax"; that's because, even if FreeBasic itself is a very good language, easy and powerful, if you have to use system APIs, or to load a lot of include files (for pixel-perfect collision, for rotations, for sound...) it won't be beginner-friendly anymore.
@Printchard:
I believe that my suggestions actually are "BASIC" functionalities (because they might come in hndy in a "basic" program). And they won't limit advanced programming in any way.
You can call it FreeBasic Deluxe, but... why not?
How about we forget about adding a heap of new problems onto the library and fix the existing problems first? There are still unresolved tickets in the tracker. Spend more effort on ways to resolve those before we worry about adding new tickets to the tracker.
I'd like to try my hand at fixing some of these issues. Anyone care to help a noob get started?1000101 wrote:How about we forget about adding a heap of new problems onto the library and fix the existing problems first? There are still unresolved tickets in the tracker. Spend more effort on ways to resolve those before we worry about adding new tickets to the tracker.
What I'm asking for specifically is the steps required to test a fix (Download source, compile tools) and the steps to submit a fix (or patch).
I'll try to get this done by myself, but I thought I'd ask here as well.
No: every software has bugs. Noboby ever fixed all bugs of a program, because when you fix one, other come out. You could spend you entire life fixing them (fighiting agains bugs that normal users will never encounter)1000101 wrote:How about we forget about adding a heap of new problems onto the library and fix the existing problems first? There are still unresolved tickets in the tracker. Spend more effort on ways to resolve those before we worry about adding new tickets to the tracker.
If you don't add new features before all bugs are fixed, you will never add new feature, and you will wait forever.