your decision on gfxlib and OpenGL

lillo · Post by **lillo** » Jan 31, 2006 8:38

Since this is so yet undecided, I'll let you decide what is the best route to go about it.
For those who don't know what I'm talking about, please use this thread as reference:

http://www.freebasic.net/forum/viewtopic.php?t=2745

From what I've seen it seems there's a slight bias towards not doing it, however with this pool an official response should come. As for me I do see reasons for both adding it and not adding it, that's why I'm using a pool to get the final decision.

Z!re · Post by **Z!re** » Jan 31, 2006 9:45

[Content removed at author's request]

arenth · Post by **arenth** » Jan 31, 2006 10:28

Meh I think it should be done, at the very wors't people who don't like it, won't use it, and people who do like it will.

lillo · Post by **lillo** » Jan 31, 2006 10:30

@Z!re: I meant glitches in the semantics... since the target would be to fit an old-skool software 2d library on top of a modern API like OpenGL, some compromises in the semantics have to be done, like forcing 2 pages only, need for FLIP, implicit textures handling, etc.

marzec · Post by **marzec** » Jan 31, 2006 11:27

well i think it is still not the worst idea. but as i replied in the original thread ( which you didn't answer btw :p ) there's a lot of problems concerning speed, memory consumption and the like. i think a clear list of pro and cons would give people a better impression of what to expect from that lib and what not.

Z!re · Post by **Z!re** » Jan 31, 2006 12:58

[Content removed at author's request]

PlayerOne · Post by **PlayerOne** » Jan 31, 2006 13:01

Well, the cons mostly seem to be the fans of YAGL, which might not make them the most impartial. On the other hand, maybe the rest of us don't know enough about it or haven't seem the need for it.

Personally, I can only see it as a good thing. At the moment it doesn't make too much sense that you can set a GL mode and not use the other gfx commands on it. It seems to me that even a partial implementation would be an improvement on that.

L_O_J · Post by **L_O_J** » Jan 31, 2006 13:11

PlayerOne wrote:Well, the cons mostly seem to be the fans of YAGL, which might not make them the most impartial. On the other hand, maybe the rest of us don't know enough about it or haven't seem the need for it.

Personally, I can only see it as a good thing. At the moment it doesn't make too much sense that you can set a GL mode and not use the other gfx commands on it. It seems to me that even a partial implementation would be an improvement on that.

cough SDL cough SDL.... AFAIK SDL let you set the SDL_OPENGL and then leave you to do your thing with OpenGL (NOT SDL), except for input, cd-rom, sound, etc.

I agree with Z!re, this is not about YAGL being beaten by GFXLib. I personaly like YAGL, but a little unsatisfied with it, so I try to do similar GL backend using FB with GL, and the past few days have been real joy and fun. I learn a LOT about OGL by doing this backend stuff.

and have you ever think, FB is supposed to be a General Purpose programming language, and NOT YET ANOTHER BLITZ BASIC LIKE COMPILER (pray to god that not going to happen).

one of the most hard thing to learn about OpenGL (generaly speaking) is the initialization and GFXLib have take that burden, by sticking it in SCREEN ,,,, GFX_OPENGL. and I lillo for that.

Z!re · Post by **Z!re** » Jan 31, 2006 13:14

[Content removed at author's request]

Aquarius · Post by **Aquarius** » Jan 31, 2006 13:15

I think GFXLib should be software only. For OpenGL I just use SCREENRES with GFX_OPENGL and OpenGL library. Sure it's not as easy as QBasic statements, but it's not THAT hard either. Actually OpenGL is quite easy to use for 2D graphics. The only thing I miss is a kind of PRINT statement working in OpenGL screen mode.

Nodtveidt · Post by **Nodtveidt** » Jan 31, 2006 13:16

PlayerOne wrote:Well, the cons mostly seem to be the fans of YAGL, which might not make them the most impartial. On the other hand, maybe the rest of us don't know enough about it or haven't seem the need for it.

Call me a yagl fanboy, but I think this idea isn't a good one.

marzec · Post by **marzec** » Jan 31, 2006 13:22

L_O_J wrote:I personaly like YAGL, but a little unsatisfied with it, so I try to do similar GL backend using FB with GL, and the past few days have been real joy and fun. I learn a LOT about OGL by doing this backend stuff.

i'm sorry and i know this is offtopic, but could you elaborate why you are unsatisfied with yagl? maybe we could discuss this on the yagl thread on this forum or on the "official" yagl forums. i appreciate any feature requests and critics

lillo · Post by **lillo** » Jan 31, 2006 13:31

@marzec: don't worry, I'll reply to the old topic just after writing this... :) (I just felt like closing that thread and opening the pool since I was too much unsure and wanted to hurry up the decision)

@z!re: you have good points there. Still, if the additions to support GL primitives can be reduced to a few (~10) extra Kbytes, and if the support can be added in a proper way without too many hacks, it may be worth it. Not sure this is feasible though, guess one has to try to find it out. Keeping the low footprint in mind, a seamless GL primitives support would be almost natural for gfxlib. Expecially since gfxlib is already part of FB - the language, being derived from QB, needed a compatible gfx module - the change if done with these premises should be completely transparent to the enduser, with the only visible change of more speed in higher res modes. I don't see how this relates with your fear of bloating FB... Let it be clear that I'm agaist bloat too, and that's why if I decide to go on with this project one of the goals will be to be as tiny as possible - I've always tried to fight bloat and reduce the generated EXE size since I joined FB development...

@PlayerOne: the current gfxlib GL mode makes a lot of sense already... It allows to set up a GL context to play with, so you can directly code using OpenGL in a multiplatform way. See the NeHe tutorials ported to FB in the examples/GL/NeHe directory.

L_O_J · Post by **L_O_J** » Jan 31, 2006 13:31

marzec wrote:
L_O_J wrote:I personaly like YAGL, but a little unsatisfied with it, so I try to do similar GL backend using FB with GL, and the past few days have been real joy and fun. I learn a LOT about OGL by doing this backend stuff.
i'm sorry and i know this is offtopic, but could you elaborate why you are unsatisfied with yagl? maybe we could discuss this on the yagl thread on this forum or on the "official" yagl forums. i appreciate any feature requests and critics

sorry V1c or lillo of whoever ppl that incharge of administrating this forum, I want to OOT a bit.

@ marzec : I'm sorry OK, pls forgive me, about my unsatisfaction toward YAGL is not a matter of speed, but feature so you keep up the work, it's trully a YET ANOTHER GREAT LIB :D, OK, peace.

marzec · Post by **marzec** » Jan 31, 2006 13:44

@l_o_j lets move this to the yagl thread :p

@lillo i guess the point of zires post was not so much that the exe size will increase by 10kb but more about the fact that you will not gain any speed increase for the drawing primitives, even worse they will be slower than the current software primitives. also, caring for the exe size but not caring for redundant storage of bitmaps in ram and vram seems a bit confusing to me. this will be bloat that is noticeable at runtime, not at download time... also, i don't see any way to make the gl backend work like the software backend. so i can't explain why you say that if you implement it that the enduser will only notice an increase in speed. this is not true as there is no way to make the gl backend work 100% like the software backend ( see put buffer issue etc. ).

i again want to clarify that i'm of course biased and i should probably keep myself out of this discussion.

your decision on gfxlib and OpenGL

Should gfxlib support primitives in GL mode?

your decision on gfxlib and OpenGL