Hey hey hey! Settle down, kids...that goes for you Z!re and you v1ctor too.
If people don't like the idea, then they're going to SAY that they don't like the idea...plain and simple. If you don't want honest opinions, then don't ask for them. When the opinions you get do not match your expectations, there's no need to get all huffy about them. Granted you're always going to have some people who are less than elegant in their comments (*cough*Z!re*cough*), but that's really no reason to start throwing "contribution weight" around. Know when to use your pride and when to pack it in for the day.
Z!re: don't be so negative and condescending. It makes you look bad and it makes us yagl users look like assholes.
v1ctor: stop taking these things as personal attacks. I've seen this several times over the past year and a quarter...you get all huffy when someone disagrees. It's unbecoming...just take it with a grain of salt and be cool, ok?
No one likes to see this kind of infighting here, so all of you, settle down already!
your decision on gfxlib and OpenGL
That's not exactly me taking it personal, i only posted about the FUD and marzec assumed i was talking about his messages, the last message from Z!re, known by not been exactly polite in her opinions, was a quotation about what i said with an ironic reply, and before that she replied to Angelo with a "While you're adding random crap to FB anyways,[...]".
You know, this is not IRC, if people want to get some heat discussions, feel free to join #freebasic and anyone used to flame wars may find it funny to watch.
And no, blinding votes based on FUD are not just about opinions, that's pure manipulation. Did you see me saying anything about how better a new backend would be so people could be influenced by my opinion? I don't think so, and i could start to do that now, but i won't.
You know, this is not IRC, if people want to get some heat discussions, feel free to join #freebasic and anyone used to flame wars may find it funny to watch.
And no, blinding votes based on FUD are not just about opinions, that's pure manipulation. Did you see me saying anything about how better a new backend would be so people could be influenced by my opinion? I don't think so, and i could start to do that now, but i won't.
-
Sterling Christensen
- Posts: 142
- Joined: May 27, 2005 6:13
Your proof: lillo is one of the developers of AllegroGL. He coded the MacOSX port. You can view the source code online here, or download the source for 0.2.4 here.Z1re wrote:If he already had a openGL library he could show us, that used all the techniques he talks about but has no proof of, then I'd be all for adding it..
AllegroGL adds OpenGL acceleration to Allegro, which is a software 2D lib like gfxlib. It allows you to mix OpenGL calls with (transparently OpenGL accelerated) Allegro calls much like lillo is proposing for gfxlib.
AllegroGL is also a double dependency...Allegro and then OpenGL, both of which are external. gfxlib at the moment is intrinsic to FB and requires no non-standard dependencies. In addition, this would only work in Windows and Linux, unless someone wanted to use something like mesa3d for DOS...so the cross-platform capability of gfxlib would be affected unless a DOS version was also available. That's two strikes against gfxlib's original purpose, and that's why I said no to this idea. If this was to be developed *externally*, then great...it would be a good addition to FB's growing library list. But to make it *canon* isn't a very good idea.
SC...there is nothing but concept at this point...and please, don't do the contribution weight tossing thing, it's irritating. I could go on for hours about the large number of people who have made major contributions to projects, and about an equal number of people who have ported libraries and applications to other platforms. But it's pointless rabble-rousing that is nothing more than an ego stroke.
SC...there is nothing but concept at this point...and please, don't do the contribution weight tossing thing, it's irritating. I could go on for hours about the large number of people who have made major contributions to projects, and about an equal number of people who have ported libraries and applications to other platforms. But it's pointless rabble-rousing that is nothing more than an ego stroke.
So lillo is Angelo Mottola (gee I hope I spelt that right)! That chalks up another credibility point for him, as he's the author of QuickBASIC's DirectQB library.
I'm still unsure about all this. There's no OpenGL for DOS. Does this mean that the feature will be emulated under the OS? Oh, and not all of us have 3D accelerated graphics cards, so that's something to consider too.
I agree with the concept of 100% transparency for this, but again, the documentation should make it clear that functions in it belong to the new feature, much like the how vbcompat statements appear in the offline CHM.
Would it be possible to make this as a library separate to gfxlib? It'd make it safer for testing, and it could always be changed in a later version of FB to be automatically linked once its ready.
Is there a clear-cut benefit to implementing this? I thought gfxlib already supported OpenGL (where supported).
I'm still unsure about all this. There's no OpenGL for DOS. Does this mean that the feature will be emulated under the OS? Oh, and not all of us have 3D accelerated graphics cards, so that's something to consider too.
I agree with the concept of 100% transparency for this, but again, the documentation should make it clear that functions in it belong to the new feature, much like the how vbcompat statements appear in the offline CHM.
Would it be possible to make this as a library separate to gfxlib? It'd make it safer for testing, and it could always be changed in a later version of FB to be automatically linked once its ready.
Sorry, that was my fault. I was the one who asked about the whole "FUD" thing.v1ctor wrote:That's not exactly me taking it personal, i only posted about the FUD and marzec assumed i was talking about his messages, the last message from Z!re
What server?feel free to join #freebasic
Is there a clear-cut benefit to implementing this? I thought gfxlib already supported OpenGL (where supported).
OpenGL doesn't require an accelerated, it simply benefits from it. The drivers have been included automatically since Windows 95, even if your graphics card sucks.
GfxLib can set up an OpenGL window for you at present, but actual drawing functions are not available. This would actually let you use PSET, LINE, etc in OpenGL mode.
100% transparency means no new keywords to document. All this hubbub is about a backend - the part invisible to the end-user.
GfxLib can set up an OpenGL window for you at present, but actual drawing functions are not available. This would actually let you use PSET, LINE, etc in OpenGL mode.
100% transparency means no new keywords to document. All this hubbub is about a backend - the part invisible to the end-user.
-
Sterling Christensen
- Posts: 142
- Joined: May 27, 2005 6:13
OK, I'll start a list of common misconceptions here:
1. This would make Gfxlib require OpenGL, and thus make it not run well on DOS
False and false. Gfxlib is designed to support multiple backends. The DOS VGA/VESA backend is already peacefully coexisting with the Windows DirectX backend and X11 Linux backend - it can coexist with one more. The OpenGL backend probably wouldn't be available in DOS, but that's OK because (I'm guessing) DOS would still have the same old VESA backend.
False. As marzec pointed out, several things are likely to be slower including pset, point, and possibly (depending on how they're implemented) elipses and drawing to offscreen buffers.
3. This would use twice as much memory for sprites
True (but only technically). Total memory usage (including video memory usage) would be x2 for sprites. But the system memory usage on computers with video cards and that of other backends would be the same or about the same. This is assuming sprites would be stored both in memory and in textures.
4. It would behave EXACTLY like the other backends
False. Almost, but for example, lillo seems to be considering making SCREEN[UN]LOCK lock the screen for raw OpenGL commands, instead of for peek/poking (which would be awkward anyway due to the need to copy the entire screen from video memory when SCREENLOCK is called etc).
5. This would be based on AllegroGL, and thus would make Gfxlib require Allegro
False and false. That was only an example to show lillo knows what he's talking about (good grief I'm kinda sorry I brought it up). Avoiding external dependancies was one of the reasons lillo replaced my SDL-based gfxlib, he's not about to make gfxlib2 depend on Allegro now.
(more will be edited in as I see them)
1. This would make Gfxlib require OpenGL, and thus make it not run well on DOS
False and false. Gfxlib is designed to support multiple backends. The DOS VGA/VESA backend is already peacefully coexisting with the Windows DirectX backend and X11 Linux backend - it can coexist with one more. The OpenGL backend probably wouldn't be available in DOS, but that's OK because (I'm guessing) DOS would still have the same old VESA backend.
2. This could only be good - hardware acceleration is always fasterlillo wrote:the GL backend would never be used as the default one, but you'll still need to specify a flag to SCREEN to use it. Then if you do so, you have to accept the pros and cons of the mode speed-wise.
False. As marzec pointed out, several things are likely to be slower including pset, point, and possibly (depending on how they're implemented) elipses and drawing to offscreen buffers.
3. This would use twice as much memory for sprites
True (but only technically). Total memory usage (including video memory usage) would be x2 for sprites. But the system memory usage on computers with video cards and that of other backends would be the same or about the same. This is assuming sprites would be stored both in memory and in textures.
4. It would behave EXACTLY like the other backends
False. Almost, but for example, lillo seems to be considering making SCREEN[UN]LOCK lock the screen for raw OpenGL commands, instead of for peek/poking (which would be awkward anyway due to the need to copy the entire screen from video memory when SCREENLOCK is called etc).
5. This would be based on AllegroGL, and thus would make Gfxlib require Allegro
False and false. That was only an example to show lillo knows what he's talking about (good grief I'm kinda sorry I brought it up). Avoiding external dependancies was one of the reasons lillo replaced my SDL-based gfxlib, he's not about to make gfxlib2 depend on Allegro now.
(more will be edited in as I see them)
How much he's contributed doesn't matter - you misunderstand. I was arguing that lillo is capable of what he's proposing.Nodtveidt wrote:SC...there is nothing but concept at this point...and please, don't do the contribution weight tossing thing, it's irritating.
Last edited by Sterling Christensen on Feb 02, 2006 9:34, edited 24 times in total.
So if I'm reading right, this will allow OpenGL functions in the OpenGL mode that is available in gfxlib, right? Systems that can't use OpenGL will have these functions emulated in some form, so that they're operationally equivalent, right? Or am I way off?
It's just that it hasn't been made 100% clear what exactly is being proposed.
To my understanding, the current situation is that although screenmodes can be made to use OpenGL, only non-OpenGL graphical commands are available. Is this move to add OpenGL commands, or is it to accelerate the existing commands using OpenGL?
It's just that it hasn't been made 100% clear what exactly is being proposed.
To my understanding, the current situation is that although screenmodes can be made to use OpenGL, only non-OpenGL graphical commands are available. Is this move to add OpenGL commands, or is it to accelerate the existing commands using OpenGL?
-
Sterling Christensen
- Posts: 142
- Joined: May 27, 2005 6:13
Wow you're right I couldn't find that anywhere. I coulda sworn lillo said something like that. I'll edit the list. Sorry about that.Z!re wrote:False and False, cause noone said any of the things you list.Sterling Christensen wrote:lillo has already said the OpenGL backend would not be the default, that it would be optional.
@tunginobi the backend will only do this:
implement LINE, PSET, POINT, CIRCLE, PUT and all other gfx primtives based on opengl and therefor "accelerate" them. no new opengl related commands will be introduced ( according to lillo and v1c ) so it is basically just a switch in backend that will be transparent to the user ( no new keywords same functionality ) but noticeable in speed increase. if opengl is not accelerated on the plattform the application is started on then you will either receive an error when trying to switch to the gl backend or the gfxlib will fall back to the software backend by default. that's about it.
implement LINE, PSET, POINT, CIRCLE, PUT and all other gfx primtives based on opengl and therefor "accelerate" them. no new opengl related commands will be introduced ( according to lillo and v1c ) so it is basically just a switch in backend that will be transparent to the user ( no new keywords same functionality ) but noticeable in speed increase. if opengl is not accelerated on the plattform the application is started on then you will either receive an error when trying to switch to the gl backend or the gfxlib will fall back to the software backend by default. that's about it.
My apologies for not replying to all these posts yet; I'm not ignoring this thread, it's just I've been pretty busy the last couple of days and I'm still busy today (I'm writing this from work). As you can realize it takes a lot of time to reply decently to all these past messages, and I hope to find this time later today or tomorrow at most.
EDIT: found the time to at least debunk this:
EDIT: found the time to at least debunk this:
Wrong. Here's what I said earlier in this thread:Wow you're right I couldn't find that anywhere. I coulda sworn lillo said something like that. I'll edit the list. Sorry about that.
To turn on the GL backend you'll have to explicitely set a flag to SCREEN, otherwise normal software mode would run. I was hoping this was clear enough at this point but eventually it was not... seems either some of you didn't read this thread carefully (as well as the other one about this topic - no offence intended), either I badly communicated my intentions so far. Probably a bit of both. I'll try to rephrase my intentions later when I find the time. Let it be clear that I haven't got a single line of code written yet because I first wanted to discuss the technical feasability with people who do know what they're talking about (marzec, L_O_J and many others here) and reactions of the community to the possible addition. It's a bit sad so far it seems I failed at getting a polite costructive discussion, despite the good start of this thread and the many nice replies contribuited.lillo wrote:Yes, drawing single pixels will always be slower in hardware than in software. But then consider that the GL backend would never be used as the default one, but you'll still need to specify a flag to SCREEN to use it. Then if you do so, you have to accept the pros and cons of the mode speed-wise. It'd just be a more possibility that it may suit your application needs.
i guess you should start off another thread even though that seems messy. this thread and the other one drew to much attention on flamebaiting. create a thread where people can cleanly discuss
+ features of the new backend
+ limitations
+ improvements
+ implementational details
if this thread has a clear outcoming ( interface changes, known sideeffects, etc. ) redo the poll where you state all the gathered information in a compact and final manner to get rid of all the uncertainty.
just my two cents.
+ features of the new backend
+ limitations
+ improvements
+ implementational details
if this thread has a clear outcoming ( interface changes, known sideeffects, etc. ) redo the poll where you state all the gathered information in a compact and final manner to get rid of all the uncertainty.
just my two cents.