• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

OpenGL ddk

Started by tj81, 2009.11.07, 18:17:06

Previous topic - Next topic

Which is more important to you for OpenGL?

High precision rendering
4 (19%)
Sacrificing precision for render speed
6 (28.6%)
A balance between the two (IF possible)
11 (52.4%)

Total Members Voted: 0

craigm

I'm so excited to hear that this is moving forward, I think OpenGL support for eCS is so important to the OS's health as a viable platform. Thank you!

demetrioussharpe

Quote from: craigm on 2010.12.03, 22:17:15
I'm so excited to hear that this is moving forward, I think OpenGL support for eCS is so important to the OS's health as a viable platform. Thank you!

Thanks for your enthusiasm towards this project. That's the kind of feedback that keeps me going when I think my tank's on 'E' for the night; it's greatly appreciated!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Things have been a bit slow for the past few days. It's the holiday season & I'm also winding down my Army career, so it's safe to say that 'Real Life' issues have drained quite a bit of my time. However, here's a small update:

-I've received the info necessary to host this project on Netlabs.
-I've been in the process of updating my commiting tree with code from my sandbox tree.
-When the commiting tree is completely up to date & I've pushed all of the code to sourceforge, I will do a final svn checkout to make sure that my tree is correctly revisioned. That's when I will commit it all to Netlabs & shutdown the sourceforge tree.
-I have successfully built the GLU library as a lib file & included it into the OPENGL.dll project file.
-I have added a GLU function pointer table within PGLContext. This will make it much easier if there comes a time in the future when another GLU library, that's more robust, is created.
-My PGL is almost feature complete with IBM's PGL. Here's the summary of what needs to be finished:

---pglWaitPM() currently has no way to check to make sure that the presentation manager is finished drawing to the viewing area of the window before it returns.
---pgl_internal.[c|h] needs functionality that allows PGL to be able to subclass the window & service specific window messages. It also needs an internal clean up system to register to the Exit system. This will allow PGL to do clean up regardless of whether a program was ended  normally or by force.
---pglUseFont() still needs to be implemented.
---pglUsePMBitmapFont() was depreciated by IBM, so my implementation is well within reason by just returning FALSE. However, I'd like to go ahead & implement it properly for indirect contexts anyway.
---pglMakeCurrent() when a context has been bound to a window for the first time, pglMakeCurrent() needs to attach cleanup routine to program, subclass the window to allow handling of specific window message, get window bounds, & set the viewport to bounds values.


So, I'm a long ways off from where I've started. I've also gained a few ideas for additions to PGL that will not use the standard 'pgl' API format, but will still prove themselves valuable. One such idea is to insert a thin portion of a profiling system within PGL. There would also need to be companion portions within the pipeline & the video driver. This will not only allow me to better understand the choke points through the entire system for a total implementation optimization effort. It will also give developers more insight into which pathways their apps are spending the majority of their time in. Work on this may or may not be started before I start fleshing out the actual pipeline.

I'd like to thank everyone who's given me their support. I will continue make summary reports as time permits.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Ben

The OS/2 community really, is a marvel in that it is still so solid... yet so small... as is the OS itself.

This is a testament to the quality of its original design and its implementation. With regard to that aspect of it, IBM did an outstanding job.

I personally, still love the power and the ease of use, the way that programs still fit snugly into their own, respective, folder and thus, are completely transportable; Simply archiving and unarchiving of said folder onto whatever machine, and creating a Program Object for it is enough; All done. How many other OSes can claim that?

Still, it would be wrong to say that OS/2 hasn't suffered the fate of an orphaned child having been in too many foster homes; it's now an amalgam of many different-and-varied, ideas and is the bastard child that everyone loves to feel fickle about. But still there is the core pseudo-family that will not give up on it! And keeps it alive and mostly healthy.

But some appendages have become atrophied and at risk of becoming vestigial; And despite Darwin's unprovable and wildly speculative, claims about things becoming, evolutionarially, vestigial for a reason, in my opinion, this can never be good and certainly isn't now.

To continue, it's hardly necessary to say it, but your infusion of fresh, and powerful, blood has been quietly hoped for. And I,  though I am only one, represent, (if unofficially), a train of others who are holding their breath wondering if it isn't all just a little bit too much to expect, and too good to last... for some future thoughts are more pleasant than others. And there have been many er... attempts... in the past... accompanied by many powerful words!

However... while your words are many, they are quickly followed by aggressive, and positive, action... (which is potentially, one of the finer characteristic of military training).

Whichever way that Fate follows, I'd like to say a thoughtful "thank-you" for your efforts. My skills are not in programming so I can only stand outside the work area and applaud; and I am applauding now.

Thank-you.

demetrioussharpe

I've gotta admit, that was quite an overwhelming post! I suppose, I'm used to the actions of 1 person being mostly dismissed at a local level & usually unnoticed at a global level. Such is the way it is in military life. This feels largely new to me. Thanks for your kind words!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Ok, it looks like I've hit a little snag. I'll be the first to admit that I don't know a whole lot about using SVN. I've been able to get along by using TortoiseSVN, since I've been doing the actual development on my Win box. Now, it's time to push the GL/2 repo over from sourceforge to netlabs. I'm at a complete loss at how to accomplish this with all of my version info & commit history intact. Is there anyone keeping track of this forum topic who knows how to accomplish such a thing? Any help would be greatly appreciated!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

diver

i'm not sure if it's easy to have history and such intakt.
but best would be you ask in #netlabs channel on irc.freenode.net

regards
Silvan

demetrioussharpe

Adding pglGetProcAddress() to the pgl layer. Windows users know it as wglGetProcAddress(). It allows developers to use new functions that are not in the system's default OpenGL installation, but are included either in a chip-specific implementation or as an extension.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Here's an update:

- The codebase at sourceforge is at revision 39.

- Work's in progress to insure that revision 39 is brought up on netlabs.

- I've sent the rsync drop to Adrian as a tarball via email.

- I've reorganized the split between the GL library & the hardware driver; there's no longer a pipeline/raster split, it's all pipeline with the split being lib/hardware; all of this now lives in the pipeline directory, since all drivers that'll be part of the default install will interface to this library. All of this is in my local repo & will be committed once netlabs' repo is up.

- PGL will look for 2 environmental variables; most likely, the names will be GLDEFAULTLIBRARY & GLALTERNATELIBRARY. These variables must be defined in config.sys for usage. GLDEFAULTLIBRARY is the GL library that's part of this DDK & must never be changed. GLALTERNATELIBRARY is the library used if a hardware-specific GL library needs to be loaded. PGL will look for GLALTERNATELIBRARY first & if it's not defined, then PGL will fall back to GLDEFAULTLIBRARY.

- GLDEFAULTLIBRARY will look for 2 environmental variables; most likely, they will be named GLSOFTRENDERER & GLHARDRENDERER. GLSOFTRENDERER will be the software driver that comes with this DDK. It's not a must that it's not changed to point to another software implementation, but I'll ask that it not be changed. If someone comes up with I ask that they contribute to the official codebase. GLHARDRENDERER will point to the hardware driver for the currently installed videocard. As such, it should be changed each time the hardware changes. I am considering doing a massive hardware renderer that uses the correct card-specific routines depending on which card is installed.

I know that some of what I just posted kinda goes without saying, I just wanted to go ahead & write those things down anyway just to make my intent official.

Comments, concerns, gripes, or complaints?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

David McKenna

<Comments, concerns, gripes, or complaints?>

  Only to thank you for this exciting (and important IMHO) contribution to eCS! I'm really looking forward to being able to use it.

  Thanks!

Regards,

Dave McKenna

Sigurd

Quote from: David McKenna on 2010.12.15, 14:23:26
<Comments, concerns, gripes, or complaints?>

  Only to thank you for this exciting (and important IMHO) contribution to eCS! I'm really looking forward to being able to use it.

  Thanks!

Regards,

Dave McKenna

So do I!

demetrioussharpe

#86
Thanks for the support guys, it really means a lot!

Does anyone know how to find out if the PM & GPI pipelines have finished drawing everything in their pipeline?

Also, while I'm waiting for netlabs, I've started working on the library's gl rendering pipeline.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

It really means a lot to us! It's the few highly dedicated people like you, Remy, the eCoSoft and Firefox Teams, Paul and others that are helping keep things going for this community, and your work is definitely appreciated!!!

No luck on the books yet, btw (haven't forgotten about you). I do have at least two more boxes I have to get out of storage though. I suspect they may be in one of them (since I have yet to find any of my OS/2 programming references - and I suspect I packed them all in the same place). I am hoping I'll find them in the upcoming week... been swamped with work though, and haven't managed to dig the last few boxes out.

Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

No worries, I suspect that we've all been swamped, especially at this time of year.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

The GL/2 codebase is on Netlabs now. The sourceforge repo will be deleted in the coming weeks. More to follow. Stay tuned for new OSWorld topics, also.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!