Supporting thread for the Porting AbiWord (http://www.os2world.com/content/view/341/71/) bounty. The original and old bounty thread can be found here (http://www.os2world.com/cgi-bin/ultraboard/UltraBoard.cgi?action=Read&BID=83&TID=165&SID=).
Quote from: miturbide on 2007.05.17, 04:26:53
Supporting thread for the Porting AbiWord (http://www.os2world.com/content/view/341/71/) bounty. The original and old bounty thread can be found here (http://www.os2world.com/cgi-bin/ultraboard/UltraBoard.cgi?action=Read&BID=83&TID=165&SID=).
This is quite an old bounty, is it still wanted?
I've tried now and the to use Abiword with Odin. Latest try, for some half year ago, I could get the program going and open a document. I think it was very crash prone and buttons were missing and so on, but I was very surprised that it worked that much. Abyword is a nice lightweight program, I would guess it is still wanted.
Quote from: melf on 2011.05.11, 15:56:30
I've tried now and the to use Abiword with Odin. Latest try, for some half year ago, I could get the program going and open a document. I think it was very crash prone and buttons were missing and so on, but I was very surprised that it worked that much. Abyword is a nice lightweight program, I would guess it is still wanted.
Must it use Odin? If it's possible to do a native version, is that acceptable?
I guess everyone agrees that using ODIN is no benefit in itself and a native version would certainly be preferable. However, I wonder if one really urgently needs Abiword if a recent port of OOo and many good (though older) OS/2 native workd processors are around (like Describe, Papyrus etc.)
If looking for bounties, why don't you open a new one? I personally would rather be willing to sponsor something like an update to SNAP graphics driver to a selected number of current chipsets (1 desktop, 1 mobile). Including multiscreen cababilities and 2D acceleration, maybe rotation (even if not dynamic, as PM cannot chnge resolution on the fly).
Quote from: Andi710 on 2011.05.11, 19:14:14
I guess everyone agrees that using ODIN is no benefit in itself and a native version would certainly be preferable. However, I wonder if one really urgently needs Abiword if a recent port of OOo and many good (though older) OS/2 native workd processors are around (like Describe, Papyrus etc.)
If looking for bounties, why don't you open a new one? I personally would rather be willing to sponsor something like an update to SNAP graphics driver to a selected number of current chipsets (1 desktop, 1 mobile). Including multiscreen cababilities and 2D acceleration, maybe rotation (even if not dynamic, as PM cannot chnge resolution on the fly).
Within this coming year, the old OS/2 video driver interface should become obsolete. Refer to the OpenGL thread (http://www.os2world.com/forum/index.php/topic,1940.msg19520.html#msg19520 (http://www.os2world.com/forum/index.php/topic,1940.msg19520.html#msg19520)) & the GL/2 page (http://svn.netlabs.org/gl2 (http://svn.netlabs.org/gl2)) to understand why.
Quote from: demetrioussharpe on 2011.05.11, 18:16:50
Quote from: melf on 2011.05.11, 15:56:30
I've tried now and the to use Abiword with Odin. Latest try, for some half year ago, I could get the program going and open a document. I think it was very crash prone and buttons were missing and so on, but I was very surprised that it worked that much. Abyword is a nice lightweight program, I would guess it is still wanted.
Must it use Odin? If it's possible to do a native version, is that acceptable?
No this was not a wish, just a comment of maybe questionable value ;)
Quote from: demetrioussharpe on 2011.05.11, 19:42:43
Within this coming year, the old OS/2 video driver interface should become obsolete. Refer to the OpenGL thread ...to understand why.
That's interesting news indeed Dee.
From the other thread on this topic I thought that you were building,
(GL/2 as), an addition to the video system, not a complete replacement.
Just how extensive is this?
...in
layman's terms please... :)
Quote from: Ben on 2011.05.11, 20:42:24
Quote from: demetrioussharpe on 2011.05.11, 19:42:43
Within this coming year, the old OS/2 video driver interface should become obsolete. Refer to the OpenGL thread ...to understand why.
That's interesting news indeed Dee.
From the other thread on this topic I thought that you were building, (GL/2 as), an addition to the video system, not a complete replacement.
Just how extensive is this?
...in layman's terms please... :)
Well, basically, SNAP & GRADD are wrappers that are used to plug a particular brand of video drivers into the OS/2 video subsystem. They do the heavy lifting of actually talking to the OS/2 video driver interface. The scope of GL/2 has kind of grown to include the whole video driver system. As it relates to 2d, SNAP, GRADD, Panorama, & any other video driver framework are replaced with 1 driver that takes the commands from the REAL video driver interface & translate them into OpenGL commands. From that point, these commands are processed the same as other OpenGL commands in the 3d framework.
Quote from: demetrioussharpe on 2011.05.11, 21:01:32
Well, basically, SNAP & GRADD are wrappers that are used to plug a particular brand of video drivers into the OS/2 video subsystem. They do the heavy lifting of actually talking to the OS/2 video driver interface. The scope of GL/2 has kind of grown to include the whole video driver system. As it relates to 2d, SNAP, GRADD, Panorama, & any other video driver framework are replaced with 1 driver that takes the commands from the REAL video driver interface & translate them into OpenGL commands. From that point, these commands are processed the same as other OpenGL commands in the 3d framework.
OK.
If communications have been successful then you are telling me... us... that GL/2 is
not a replacement for SNAP,
(et al), in that they,
(or anything equivalent, past, present or future), will be
completely obsolete; Unnecessary.
So, OS/2 will
no longer need video drivers from a card-specific POV?
Is that correct?
Quote from: Ben on 2011.05.11, 22:10:02
Quote from: demetrioussharpe on 2011.05.11, 21:01:32
Well, basically, SNAP & GRADD are wrappers that are used to plug a particular brand of video drivers into the OS/2 video subsystem. They do the heavy lifting of actually talking to the OS/2 video driver interface. The scope of GL/2 has kind of grown to include the whole video driver system. As it relates to 2d, SNAP, GRADD, Panorama, & any other video driver framework are replaced with 1 driver that takes the commands from the REAL video driver interface & translate them into OpenGL commands. From that point, these commands are processed the same as other OpenGL commands in the 3d framework.
OK.
If communications have been successful then you are telling me... us... that GL/2 is not a replacement for SNAP, (et al), in that they, (or anything equivalent, past, present or future), will be completely obsolete; Unnecessary.
So, OS/2 will no longer need video drivers from a card-specific POV?
Is that correct?
Driver specific cards will still be necessary, but they won't be of the same type as SNAP or GRADD. They'll be 3D drivers, the api will be easier to cope with, & most of the data that's necessary for porting them could be taken directly from the DRI/DRM guys. Either way, driver development will be easier in any ways; but the benefits should dwarf all of the negatives.
Quote from: demetrioussharpe on 2011.05.11, 23:54:06
the api will be easier to cope with
How do you know ?
Quote from: demetrioussharpe on 2011.05.11, 23:54:06
most of the data that's necessary for porting them could be taken directly from the DRI/DRM guys
That's actually the crucial part. The important questions for me are:
1.) Is DRI/DRM considered as something that is going to stay alive for while or is there a chance that in a half year the Linux guys find something else more "kewl" ?
2.) Is this DRI/DRM API stable or will it change every two weeks or so ?
3.) Does DRI/DRM support a significant number of chipsets on the market ?
4.) Is the majority of source code for DRI/DRM available or is it usual that hardware vendors deliver the most interesting parts in form of object files only ?
5.) Is DRI/DRM tightly integrated into the Linux/Unix or whatever OS it was originally developed for ? I.e. does it use features that the OS/2 kernel does not support and that are hard / impossible to implement correctly.
Given the limited human resources we have, the original source code (Linux ?) should be compilable for OS/2 without major changes. IMHO, just using the source code as reference documentation to write specialized OS/2 drivers is still too much effort.
Furthermore: why do you want to replace the GRADD architecture ? Both, SNAP and Panorama are GRADDs themselves. Why can't your proposed "2D Driver/GL Client" be a GRADD as well ? If you drop GRADD, you either have to also drop WINOS2 (not a problem for me, but others might feel different) or create a separate "GL Client" for this.
BTW, your drawings suggest, that PMGRE.DLL calls into GRADD.SYS. That's not true. PMGRE.DLL (which is only a forwarder into PMMERGE) doesn't know anything about GRADD.SYS. This driver is just a helper for VMAN.DLL, which provides services (map memory, set MTRRs) to the GRADDs (SDDGRADD, VBE2GRAD, GENGRADD, MGAGRADD, M64GRADD, S3GRADD etc..) and controls their loading. These services could even be used by the 3D driver, given that I see no reason why it can't be a GRADD as well that just provides a different set of functionality. The PM "display driver" used by any GRADD-based system is GRE2VMAN.DLL, which is actually a rather thin translation layer between PM's GRE functions and the GRADD/VMAN API. In order to support WINOS2, there are two other translation layers - one for seamless and one for fullscreen windows sessions - so that in the end all drawing goes through the same unified interface defined by GRADD. This includes the possibility for a GRADD driver not to implement certain functionality and let the framework emulate it by means of SOFTDRAW.DLL.
Quote from: rudi on 2011.05.16, 11:34:11
How do you know ?
Because, this isn't my first time writing drivers or using driver APIs.
Quote1.) Is DRI/DRM considered as something that is going to stay alive for while or is there a chance that in a half year the Linux guys find something else more "kewl" ?
It doesn't matter if they switch to something else or not, the code that's available is still available regardless of their API. GL/2 isn't a DRI/DRM interface. DRI/DRM is just where current drivers already exist, so if there's something that needs to be researched where else would you expect to look??? Besides, it's not just the Linux guys who use DRI/DRM, other (less volitile) *nix derivatives also use it.
Quote2.) Is this DRI/DRM API stable or will it change every two weeks or so ?
Once again, it doesn't matter. The code that we need isn't in the driver API, it's in the parts of the driver that actually do the setup & rendering.
Quote3.) Does DRI/DRM support a significant number of chipsets on the market ?
Significantly more with 3d acceleration than we currently support right now, considering that we currently have ZERO hardware 3d acceleration. And why would 3d acceleration be so important compared to the 2d acceleration that we have partial support for? Because the 2d drawing can be subsumed by the 3d support.
Quote4.) Is the majority of source code for DRI/DRM available or is it usual that hardware vendors deliver the most interesting parts in form of object files only ?
Available. The only major vendor not supporting it is nVidia & that's 1 vendor out of 3 major vendors. With the other 2 major vendors being AMD & Intel, we're still doing pretty good with the number of available devices.
Quote5.) Is DRI/DRM tightly integrated into the Linux/Unix or whatever OS it was originally developed for ? I.e. does it use features that the OS/2 kernel does not support and that are hard / impossible to implement correctly.
Moot point, GL/2 isn't DRI/DRM & never will be.
QuoteGiven the limited human resources we have, the original source code (Linux ?) should be compilable for OS/2 without major changes. IMHO, just using the source code as reference documentation to write specialized OS/2 drivers is still too much effort.
Hmmm....the old 'it's too hard' complaint. It's funny how you're complaining, but I'm the one who's actually writing the code.
QuoteFurthermore: why do you want to replace the GRADD architecture ? Both, SNAP and Panorama are GRADDs themselves. Why can't your proposed "2D Driver/GL Client" be a GRADD as well ? If you drop GRADD, you either have to also drop WINOS2 (not a problem for me, but others might feel different) or create a separate "GL Client" for this.
The snapshot of SNAP that I've seen shows no indication of being a GRADD driver. Actually, it seems to be quite the opposite, though I could be wrong. And even if it was a GRADD driver, so what? It's still a crappy interface & it's not even the real OS/2 video driver interface, it's a wrapper. How do I know? Because I have the 2d driver DDK that IBM released initially & it covers both GRADD & the original video drivers. Also, no my 2D Driver/GL Client isn't a GRADD driver, it's based on the real IBM video driver interface, which GRADD is a wrapper around. WinOS2 is also a moot point. Look, it's time to move on out of the 90's. We have to be willing to advance. Honestly, WinOS2 is a henderance anyway & needs to be replaced with full Win32 & Win64 replacements. And even if those replacements aren't available for quite some time. It's not even an issue, since the compositing layer is supposed to be able to support multiple clients. It's not really an issue to add a client for the WinOS2 subsystem. Sure, it's hard to get people to do the work, but stop trying to piss on the one's who're actually doing it. Or you'll find yourself left in the past, like the last version of OS/2 that was produced & sold by IBM.
Furthermore, I'm going to need you to pay more attention to what's going on. It's not as if all of the info isn't out there available. Also, I've made my diagrams & source code freely available (which I didn't have to do). I also make a serious effort to give updates in the OpenGL DDK thread. If you disagree with my plans, then fine; but if you're not doing something to help progress things, then get out of the way.
QuoteBTW, your drawings suggest, that PMGRE.DLL calls into GRADD.SYS. That's not true. PMGRE.DLL (which is only a forwarder into PMMERGE) doesn't know anything about GRADD.SYS. This driver is just a helper for VMAN.DLL, which provides services (map memory, set MTRRs) to the GRADDs (SDDGRADD, VBE2GRAD, GENGRADD, MGAGRADD, M64GRADD, S3GRADD etc..) and controls their loading. These services could even be used by the 3D driver, given that I see no reason why it can't be a GRADD as well that just provides a different set of functionality. The PM "display driver" used by any GRADD-based system is GRE2VMAN.DLL, which is actually a rather thin translation layer between PM's GRE functions and the GRADD/VMAN API. In order to support WINOS2, there are two other translation layers - one for seamless and one for fullscreen windows sessions - so that in the end all drawing goes through the same unified interface defined by GRADD. This includes the possibility for a GRADD driver not to implement certain functionality and let the framework emulate it by means of SOFTDRAW.DLL.
Ok, let me stop you right here. First, if I had every single part of the GRADD architecture listed, I'd end up with a diagram that's far too complicated. You may not realize it, but I draw these diagrams in MS Paint. MS PAINT!!! How detailed would you expect a diagram to be when it's created in MS Paint??? My diagram gives an overall picture of what's going on. It doesn't matter if GRADD.SYS is communicated to directly by the PM graphics engine. The point is, by the time it's all said & done, the rendering ends up in the GRADD subsystem. And if you didn't know, VMAN.DLL & GRE2VMAN.DLL are both part of the GRADD subsystem & as are the list of backend drivers that you've listed (SDDGRADD, VBE2GRAD, GENGRADD, MGAGRADD, M64GRADD, S3GRADD etc..)
I know that I don't know everything about graphics, but I know my shit. It sounds like you're too close to the code, so much to the point that you're in love with it. Well, guess what? Unless you're going to write an advanced rendering system for OS/2 to push it into the future, sit down & shut it. It's hard enough to work on such a task without people (who're doing nothing) trying to tell me why my path is doomed or that I don't know what I know. Has it ever occurred to you to just see where this is all going? I mean, you're sitting here wasting time asking me about stuff that I've already put out in a forum thread that's already created for this particular subject. It seems as though you're sole purpose is to cast doubt on my work. If your goal is to troll, then do so elsewhere, the OS/2 community is already beaten & battered enough. We don't need any more torment & FUD.
QuoteHmmm....the old 'it's too hard' complaint. It's funny how you're complaining, but I'm the one who's actually writing the code
You said that the old OS/2 video driver interface should become obsolete within a year. So let's see...
QuoteThe snapshot of SNAP that I've seen shows no indication of being a GRADD driver
SNAP divides the driver in an OS dependent part (the shell driver that on OS/2 is a GRADD) and a hardware dependent part contained in *.BPD files. BPD stands for "Binary Portable Driver", which means that these *.BPD files can be used unchanged on any OS that runs an x86 CPU and that has a matching shell driver. If you have only looked at the latter, then you clearly see no relationship to GRADD.
QuoteIt's still a crappy interface & it's not even the real OS/2 video driver interface, it's a wrapper
It may be crappy and it is a wrapper. However, the question (which I'm not answering) is whether it is good enough to reach the goal with minimal effort or if it is required to kick it out for real technical reasons.
QuoteWinOS2 is also a moot point
I said that I don't need it. But I cannot tell about others.
QuoteI've made my diagrams & source code freely available (which I didn't have to do)
If you want to get people involved, then you better do so.
QuoteIt seems as though you're sole purpose is to cast doubt on my work. If your goal is to troll ...
I'm trying to get an idea of what you are doing. But it looks like you only want replies from non-technical people that say: "Ohh, ahh - here comes the new Messiah".
Quote from: rudi on 2011.05.17, 09:37:43
You said that the old OS/2 video driver interface should become obsolete within a year. So let's see...
Even if it takes longer than a year, at least I'm doing something about the situation, what're you doing?
QuoteSNAP divides the driver in an OS dependent part (the shell driver that on OS/2 is a GRADD) and a hardware dependent part contained in *.BPD files. BPD stands for "Binary Portable Driver", which means that these *.BPD files can be used unchanged on any OS that runs an x86 CPU and that has a matching shell driver. If you have only looked at the latter, then you clearly see no relationship to GRADD.
Are you dense? I never said that SNAP was a GRADD driver. Actually, I said the opposite. The only thing that SNAP & GRADD have in common is that they're wrappers around the true video driver interface. If you go back & reread what I wrote, you'll see where I wrote that "The snapshot of SNAP that I've seen shows no indication of being a GRADD driver. Actually, it seems to be quite the opposite, though I could be wrong", which was in response to you calling it a GRADD driver. Stop trying to put words in my mouth.
QuoteIt may be crappy and it is a wrapper. However, the question (which I'm not answering) is whether it is good enough to reach the goal with minimal effort or if it is required to kick it out for real technical reasons.
If you're not bothering to write any code that gives 3d support & makes 2d support rather trivial, why do you care either way? I could understand if you were planning on writing some code. It won't even matter if your goal was to start a project that rival's mine, at least you'd be doing something. At this point, you seem to be doing nothing but trying to shoot down someone who's bothered to actually do something about the current situation.
QuoteI said that I don't need it. But I cannot tell about others.
You brought it up, so I addressed it. Obviously, you brought it up for a reason, so don't get all butt-hurt when I address it.
QuoteIf you want to get people involved, then you better do so.
I really don't care if people get involved or not. I started the GL/2 project not expecting people to want to join. Let's be honest, this is the kind of work that no one really wants to do. If there were people who wanted to get involved on a coding level, a project would've been started before I started GL/2. I do my diagrams in order to keep people informed, so they don't think that the project's dead. The last thing we need is a project that raises up people's hopes, & then dies out.
QuoteI'm trying to get an idea of what you are doing. But it looks like you only want replies from non-technical people that say: "Ohh, ahh - here comes the new Messiah".
Cut the BS. If you really want to get a true idea of what I'm doing then visit the project page, look at the code in the svn repo, read & chat on the OpenGL ddk thread, hell you can even email me personally. That's how you get an idea of what I'm doing. Attacking me is NOT the way to get an idea of what I'm doing. Trying to make it look as though I don't know what I'm talking about is the surefire way to piss me off. If you have real questions or something useful to contribute, then I'm here & I'm willing to talk about it; I'm really not a bad guy. But I have very short patience for being pissed on. I'm not the new Messiah, I never claimed to be. I'm just a guy who's sick & tired of things being the way they are & opted to sit down & start writing code, instead of bitching & moaning about it. If you're so technical & all-knowing, what are you contributing to the fight?
Although I can't judge the technicalities I think it's fantastic that Demetrious take on the challenge to build a 3D video driver for eCS. Even if his efforts shouldn't reach the whole way, I'm sure it will bring us closer to the goal. To help him, constructive support and encouragement is the better way.
Hi,
full agree with Melf! I am wondering - is there no way to get these two (Demetrious/Rudi) together to join their experiences? Rudi wrote such a usefull software like Emperoar TV and helped me out in many situations with his deep technical knowledge. Demetrious effort here seems to me - as am not technical skilled at all - a good way to do something to overcome this Driverproblem. I really like the idea and I do appreciate his work!
Well, in the past I was involved in some "hard discussions" as some may know, regarding eCS 2 and so on. But I have to admit - in the end it lead to nothing if it just came to bashing each other. And I have to admit as well that I was at least as "guilty" about this as the others involved there.
As I can understand that Demetrious is sensible on his project and Rudi might want to get deeper information about it - in the end it should not lead to such a kind of discussion. Personally I will give eCS 2.1 a try on my modern Hardware as well - without any reservations - why not ? And if it runs good I will use it and replace "my version" of OS/2 Merlin, and I will make some more videos about it on youtube.
There are only a few OS/2 - eCS people left. Do not let us going on to separate ourselves more and more.
I wish the WebCam driver for OS/2 would work today so that there might be the chance to talk "face to face" to each other - alike Skype. I guess this would calm down these kind of discussions and one could answer in "real time".
I'd really like the idea both of you could join your knowledge!
Hi all,
in order to go even more OT ... ;) Sigurd, what about Uwe Hinz: His USB experimental board (and his experience of course!) can perhaps help to find out more on the USB webcam stuff? Basically, we just need a reference model of a USB webcam. Maybe one that runs on a "commonly used" USB chipset?
Cheers,
Thomas
Hello,
As mentioned by Sigurd, it seem as if Rudi is interested in your work Demetrious and if it affect they way his software can display TV broadcasts to the screen in a similar fashion to the present or if it has to be redesigned. Both of you have knowledge in each field and your combined efforts to bring us improvements are very welcome. Demetrious, you seem to have a very good overview of how you intend to design it. To me, GRADD seemed to expose a stable and mature interface that wouldn't change to the software depending on hardware. Is it possible to get a design that let software do things as before or do we need to recompile/redesign them to use with GL/2? What software may be affected and what preparations do we need to make?
Demetrious, your work has inspired me to see if I can try something out with OpenGL.
Hmm, it's quite easy to use the examples on the net with OpenWatcom + GLUT + 3D OpenGL, whish I had more knowledge how to write something real and large, like the 3D modelling tool I've looked for. OW doesn't have the required lib files for those "new" opengl,glut and raster.dl1, raster.dl2 & raster.dl3 files that come with eCS 2.x
//Jan-Erik
HOLY CRAP!!
I just read the thread from the start and my conclusion is... STOP IT!
Rudi, Dee, please stop argueing. You make we wanna cry!!
You two are one of the handful of developers and tech savvy folks that we still have around, for god's sake.
If that discussion leads to both of you being upset and perhaps demotivate both of you I will personally come over your both places to stick some magic tape around your heads! ;)
Why can't we all just sit and wait to see how Dee is doing? Heck. Instead, we waste time talking about "what could be"...
I mean: Assuming nothing happens at all if it wasn't for Dee's work... then why bother him? If there wasn't him working on it there would be no one working on it - we have nothing to lose! And if he works on it but doesn't succeed for whatever reason: Nothing lost either compared to what we have now.
The point is: We can only "win" if we let him work on the stuff. And the same is true for Rudi.
The scaring part here is that for once it's not the users bashing on developers (like what happens usually).. but it's the developers argueing amongst each others. This is something we can't afford. If we lose 2 developers that's almost like losing 10% of all remaining developers for OS/2 and eCS. And looking at the more technical focus of what you 2 guys are doing it's like losing ALL remaining developers in that area. So please: BE FRIENDS AGAIN! :))
Cheers,
Thomas
Quote from: warpcafe on 2011.05.17, 16:12:10
Why can't we all just sit and wait to see how Dee is doing? Heck. Instead, we waste time talking about "what could be"...
I mean: Assuming nothing happens at all if it wasn't for Dee's work... then why bother him? If there wasn't him working on it there would be no one working on it - we have nothing to lose! And if he works on it but doesn't succeed for whatever reason: Nothing lost either compared to what we have now.
O.K, O.K, I shut up. I fully agree with Mr. Sharpe in the statement "The last thing we need is a project that raises up people's hopes, & then dies out". He did a sufficiently good job in the first part to capture my attention. The answers now have lowered my interest level to zero. So nothing is lost. I hope the project will produce something useful before part 2 takes place.
So Long, and Thanks for All the Fish.
Quote from: warpcafe on 2011.05.17, 15:49:45
Hi all,
in order to go even more OT ... ;) Sigurd, what about Uwe Hinz: His USB experimental board (and his experience of course!) can perhaps help to find out more on the USB webcam stuff? Basically, we just need a reference model of a USB webcam. Maybe one that runs on a "commonly used" USB chipset?
Cheers,
Thomas
OT regarding Webcam:
The driver is under construction and makes good progress. But I am not involved in the current stage. Some information is given here http://svn.netlabs.org/usb/timeline
I may take part again later, if the developers want me to.
I guess it really looks promising!
Quote from: jep on 2011.05.17, 16:00:44
Hello,
As mentioned by Sigurd, it seem as if Rudi is interested in your work Demetrious and if it affect they way his software can display TV broadcasts to the screen in a similar fashion to the present or if it has to be redesigned. Both of you have knowledge in each field and your combined efforts to bring us improvements are very welcome. Demetrious, you seem to have a very good overview of how you intend to design it. To me, GRADD seemed to expose a stable and mature interface that wouldn't change to the software depending on hardware. Is it possible to get a design that let software do things as before or do we need to recompile/redesign them to use with GL/2? What software may be affected and what preparations do we need to make?
I would love for him to be interested in my work. However, it seemed as though he was more interested in attacking me & trying to discredit me instead. This really was an argument that I would've rather not have been a part of, but I'm not the kind of person who takes very kindly to such attacks, especially when I'm trying to accomplish something that's not been attempted before & being completely open about my approach & what I'm doing. To me, he seemed to be quite a bit hypocritical.
As for GRADD, I have many reasons for dropping it as a fundamental part of my framework. Sure, it provides an abstraction that doesn't change regardless of which hardware is installed into the system. But the same can also be said for SNAP & Panorama. The fact of the matter is that there are quite a few gains from dropping support for GRADD & going to a full 3d framework. I'll list a few of them:
1). No synchronization issues between the 2d & 3d components.
2). 2d can be implemented quite easily by using 3d primitives.
3). GRADD isn't open sourced, so the implementation is basically frozen; we get a new start with GL/2.
4). It's not easy (or recommended) to attempt to shoehorn an implementation into a framework that wasn't originally designed to handle it.
And that's just off the top of my head.
My plan is for GL/2 to be largely non-invasive. You should not have to change any of your software or do nothing to prepare for it. The framework should just plug into OS/2 without causing too much of a disturbance.
QuoteDemetrious, your work has inspired me to see if I can try something out with OpenGL.
Hmm, it's quite easy to use the examples on the net with OpenWatcom + GLUT + 3D OpenGL, whish I had more knowledge how to write something real and large, like the 3D modelling tool I've looked for. OW doesn't have the required lib files for those "new" opengl,glut and raster.dl1, raster.dl2 & raster.dl3 files that come with eCS 2.x
Don't stress yourself out, you have plenty of time. GL/2 probably won't be feature complete until sometime next year (I hope!). If you really want to build something large, then you'll have plenty of time to work your way up to it. I'm sure that there will be quite a few things that will need to catch up with the latest version of eCS. There are lots of things that OW needs to catch up on, but I'm sure that OW will progress the way we need it to. I'm not sure what's necessary for the raster.dll files, but the opengl & glut dlls should eventually be replaced with GL/2's versions & when that happens, I'll be sure to release the .lib files for them. If I don't, then it means that I probably forgot & need to be reminded.
Quote from: rudi on 2011.05.18, 08:21:19
Quote from: warpcafe on 2011.05.17, 16:12:10
Why can't we all just sit and wait to see how Dee is doing? Heck. Instead, we waste time talking about "what could be"...
I mean: Assuming nothing happens at all if it wasn't for Dee's work... then why bother him? If there wasn't him working on it there would be no one working on it - we have nothing to lose! And if he works on it but doesn't succeed for whatever reason: Nothing lost either compared to what we have now.
O.K, O.K, I shut up. I fully agree with Mr. Sharpe in the statement "The last thing we need is a project that raises up people's hopes, & then dies out". He did a sufficiently good job in the first part to capture my attention. The answers now have lowered my interest level to zero. So nothing is lost. I hope the project will produce something useful before part 2 takes place.
So Long, and Thanks for All the Fish.
I wasn't trying to run you off or drop your interest in the project. I just wanted you to stop bashing me. What I'm trying to do isn't easy. Attempting to tear me down isn't going to make it any easier. If you think I'm on the wrong path, then fine, I can accept that with no problems. But there's no reason for us to be at each other's throats & there's plenty of room in the OS/2 community for both of us. At this point, I think that the only way I'll be able to prove to you that my approach is solid is for me to continue working towards the intended outcome & perhaps you'll be able to see it with your own eyes.
Hi guys!
Snap is dead, panorama is crapp. What else did gradd gave us? (please, please don't mention here any ancient drivers for ancient video cards like matrox - it's 2011 - and I won't collect garbage to assemble my next pc.... but rather will go to shop to buy some 3d accelerator instead (there are nice 3d games out there, fullHD videos and support for gpu acceleration in major browsers as you might know already...)
So give me one reason to vote for gradd.
The solution proposed by Demetrious - 3d accelerated driver for os/2 - may give us some cool possibilities - 3d api, compositing manager, alpha compostiting (you know - even smartphones have it now) - so new look and performance to os/2.
So, again - give me one reason to bother with gradd? Nostalgia? Dos sessions? Win-OS/2 sessions? (rotfl)
cheers
Hi boys,
I wouldn't like to move the flame forward, but I just can't keep it to myself.
Quote from: osw on 2011.05.18, 12:22:18
So give me one reason to vote for gradd.
The solution proposed by Demetrious - 3d accelerated driver for os/2 - may give us some cool possibilities - 3d api, compositing manager, alpha compostiting (you know - even smartphones have it now) - so new look and performance to os/2.
So, again - give me one reason to bother with gradd? Nostalgia? Dos sessions? Win-OS/2 sessions? (rotfl)
Please note that I'm following GL/2 with great hopes, and I'm absolutely not against its chosen directions, I just simply don't understand why would one want to throw out GRADD.
GRADD is a general Graphics Adapter Device Driver architecture, which was designed with an exceptional extensibility in mind, meaning that it was (it is) prepared for every existing and future feature of a graphics card. Even more, one can create filters to modify how an old GRADD device driver works.
Adding 3D capabilities to an existing OS/2 system which uses a GRADD-based video driver would just mean one more GRADD module/driver to be installed. So, a 3D driver would nicely fit into the modular GRADD architecture.
The bigger problem I see is the fact that the OS/2 Presentation Manager and all the graphical OS/2 applications use the GPI API to draw something on the screen. If an application asks for a circle to be drawn, it has to be boiled down to the graphics card somehow, right?
Now, when IBM decided to throw out the old video driver architecture, and introduced the much more clear GRADD architecture instead, they have written the "transition layer" which connects the GPI API with the GRADD drivers (gre2vman.dll, anyone?), so the old OS/2 PM applications did not have to be changed, they ran without modifications on the new video driver architecture.
I'd just like to point out that, in case the whole GRADD architecture is going to be thrown out, somebody will have to write a new transition layer, which will be quite a huge work, including a lot of gray and undocumented areas of the OS/2 PM API. Combining this with my non-understanding why GRADD does not fit for GL/2, I just don't see why was this path chosen.
Again, I'm absolutely not against GL/2's current plans and directional decisions (anyway, who I am to be?), these are just my thoughts on the case.
And please let me have one more sentence: as I understood Rudi's posts, I think he was also quite interested in GL/2, and tried to understand some of the decisions (having similar problems like me) to be able to help... too bad that some misunderstanding or miscommunication or whatever came into the picture...
Doodle
Everyone that has ever used the Internet knows that text is a crappy means of communication and is highly subject to interpretation. And there is not a person using the internet that has not misinterpreted a message, sometimes grossly... the latter of which I am not saying has happened here... I merely point out that this is a common occurrence in all things textual and online.
Writing as a means of communication, is also highly influenced by one's mood at any given point... whether they are having sex regularly, and depending on how good a mood their significant other is in, are both contributing factors, but hardly singular influences. :D
If everyone could write exactly what they were thinking, thus ensuring complete and perfect communications, then we all would be professional writers.
But fact of the matter is, very few here are professional writers.
Throw into this mix the fact that most people just skim through any given post, skipping 1/4-3/4 of the words thus further slurring the tone and intention of the writer. Understandably, we all have limited time to spend, and reading on a monitor is difficult under the best of circumstances... which seldom occurs.
Plus, tone of voice, body language, intonation and inflection are not transmitted at all. Period. This is a large part of any real-life conversation and cannot be omitted without undue, unwelcomed, and undesirable, consequences.
I think every single human being that has OS/2 and is following this thread, wants a new video subsystem for OS/2 or at the least, some major improvements to the existing one, that would ease the ability to use, (and help the development of), new video cards.
I offer as a suggestion, (since it is not my position to say or suppose more), a reset -- a jump backwards into the previous flow of things-- munificently laying aside any accidental, miscommunication and proceeding ahead with good intent and a best hopes for everyone... simply ignoring previous irrelevancies, pointing no fingers, (except to scratch one's head in deep thought), and moving this project forward...
...for not one, single person here would not benefit from such a step, Dee, Rudi and those of us around the periphery who are sending good vibes, yet cannot actively participate due to the wrong skill set, and/or not being directly, (potentially or otherwise), involved.
I understand that I am stating the obvious, but sometimes apocatastatis, (look it up you lazy bastards! 8) ), is required, and the dust blown off so that a certain thing can shine clearly and be correctly perceived.
If this expedition fails to reach the summit, let it not be said that it died the death of... one cut... but that it died the death of one thousand!
Quote from: Doodle on 2011.05.18, 13:04:46
Please note that I'm following GL/2 with great hopes, and I'm absolutely not against its chosen directions, I just simply don't understand why would one want to throw out GRADD.
GRADD is a general Graphics Adapter Device Driver architecture, which was designed with an exceptional extensibility in mind, meaning that it was (it is) prepared for every existing and future feature of a graphics card. Even more, one can create filters to modify how an old GRADD device driver works.
Adding 3D capabilities to an existing OS/2 system which uses a GRADD-based video driver would just mean one more GRADD module/driver to be installed. So, a 3D driver would nicely fit into the modular GRADD architecture.
I think that the number one thing that most people are missing is the fact that I'm throwing out ALL 2d drivers, not just GRADD. Quite frankly, their services will no longer be required. Sure, frameworks like SNAP & GRADD were great in their heyday. However, things have changed quite a bit. By throwing them out, not only do we get to bypass some possibly nasty issues concerning having a 2d component & a 3d component both attempting to render their data to the screen; we also don't have to worry about compatibility & variable levels of support for the 2d driver. That one 2d driver that will come with GL/2 in it's final implementation should be the last 2d driver ever written for OS/2. Most modern video cards have started getting rid of the 2d portions & rendering it all with 3d anyway, so it's pretty much a moot point. Creating 2d drivers for these devices will be pretty much just as complicated as writing a 3d driver anyway, so we all might as well get ready for the switch.
QuoteThe bigger problem I see is the fact that the OS/2 Presentation Manager and all the graphical OS/2 applications use the GPI API to draw something on the screen. If an application asks for a circle to be drawn, it has to be boiled down to the graphics card somehow, right?
Now, when IBM decided to throw out the old video driver architecture, and introduced the much more clear GRADD architecture instead, they have written the "transition layer" which connects the GPI API with the GRADD drivers (gre2vman.dll, anyone?), so the old OS/2 PM applications did not have to be changed, they ran without modifications on the new video driver architecture.
The pure fact that gre2vman.dll exists gives a hint to what's really going on. Basically, all you really have to do is implement what gre expects you to & everything's fine. At the very least, implement the mandatory functions & return the rest back to the gre to be simulated until you're able to provide them yourself. Nothing really changes from the PM's point of view, because the PM only knows about the gre & the gre is expecting to talk to a driver. It doesn't really care if the driver is GRADD, SNAP, or a chubby chick sitting on the moon eating graham crackers, just as long as those functions are implemented.
QuoteI'd just like to point out that, in case the whole GRADD architecture is going to be thrown out, somebody will have to write a new transition layer, which will be quite a huge work, including a lot of gray and undocumented areas of the OS/2 PM API. Combining this with my non-understanding why GRADD does not fit for GL/2, I just don't see why was this path chosen.
GRADD needed transition layers. All GL/2 needs is one 2d->opengl driver.
QuoteAnd please let me have one more sentence: as I understood Rudi's posts, I think he was also quite interested in GL/2, and tried to understand some of the decisions (having similar problems like me) to be able to help... too bad that some misunderstanding or miscommunication or whatever came into the picture...
It's quite possible that I've over reacted to his post & read into it things that may not have been there. I could be wrong & he might actually have been interested in GL/2. Either way, I've apologized to him & I hope this incident doesn't run him away. As for everyone else, I also apologize you. This has, undoubtedly, been a huge distraction & was really completely OT, as this is a thread about porting Abiword. Hopefully, we all can move forword & focus on the true goals of this community -keeping OS/2 alive & growing the community.
Quote from: Doodle on 2011.05.18, 13:04:46
I wouldn't like to move the flame forward, but I just can't keep it to myself.
hello doodle,
you are welcome. We are here to discuss different kind of topics, thats why NOBODY should get crazy or rought in case different views come up. Enlightened people can comment their point of view here. First of all GRADD is not a driver its an architecture, IBM switched to GRADD to implement graphics drivers in a more easy way. We are all happy that demetrioussharpe started the GL/2 project ... to be continued.