Poll

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

Author Topic: OpenGL ddk  (Read 65441 times)

miturbide

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1154
    • View Profile
    • OS2World
Re: OpenGL ddk
« Reply #90 on: 2010.12.22, 16:45:22 »
Excellent !!
http://svn.netlabs.org/repos/gl2/

Thanks for your effort Demetrious.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #91 on: 2010.12.22, 20:39:32 »
No problem, I hope I've gotten the ball rolling. I'm also looking for anyone who'd like to help contribute.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2034
    • View Profile
    • A.I.BuiltPC - using OS/2 Warp Server & eComStation for Custom Web and Database Solutions
Re: OpenGL ddk
« Reply #92 on: 2010.12.23, 10:03:22 »
I may have missed it, but what build environment & compiler are you using?
|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #93 on: 2010.12.23, 18:13:12 »
I may have missed it, but what build environment & compiler are you using?

OpenWatcom 1.8 on Win7, but I'm about to move it to OpenWatcom 1.8 on eCS 2.0.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

abwillis

  • Sr. Member
  • ****
  • Posts: 325
    • View Profile
Re: OpenGL ddk
« Reply #94 on: 2010.12.23, 20:19:39 »
The glpipeline.dll will need to be renamed unless requiring the use of win32k.sys.  At some point a restriction in DLL names was put into place allowing only 8.3 naming (something to do with allowing a smaller memory usage).

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #95 on: 2010.12.24, 21:37:20 »
Wow, I had no clue. Thanks for letting me know, I'll work out a shorter name for all of my DLLs that are out of compliance.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #96 on: 2010.12.28, 02:39:30 »
It's been awhile since I've spoken, so I'll speak now. I'm still here. It's the holiday season, so I'm kinda busy with family holiday stuff. I'm also in the process of leaving the military, so things are kind of busy. I'm weighing a lot of important life decisions right now, but I'm still committed to GL/2, among other OS/2 projects. Currently, I'm working on the pipeline & figuring out how to use TinyGL as the library with as least modification to the code as possible. My current attempt uses TinyGL as the main processing, but embedding it within a framework that covers some of the bases that TinyGL doesn't. It's also how I plan to embed profiling & other systems within GL/2. Memory management will also be very important. Which is why I have started the process of porting my AGPGART driver to OS/2. Code will start flowing into Netlabs. Also, I've started working on AL/2, which is a port of Chris Robinson's OpenAL/Soft library to OS/2. It's going to use OS/2's multimedia framework as a backend. There are also a few other projects that I'm not ready to speak about. Stay tuned!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #97 on: 2011.01.03, 21:06:56 »
Ok, so here's a quick update.

I've started on the pipeline code. I've decided to just completely ditch TinyGL. In the end, there was just too much bullshit there to deal with. Not that the codebase is bad, it's just created to serve the author's purpose, which is different from mine. I'm sure that it served it's author's purpose very well, however, it would be a bit of a pain to get it to do what I want it to do, so I gave it the pink slip. What I've settled upon is a C/C++ framework. Basically, you call into the library with C-styled functions, because that part is procedural. But, that code calls C++ style code, because the actual pipeline is based on objects (where there's a benefit). For instance, each particular stage of the pipeline is an object. These stages are then strung together to create actual graphics pipelines. In the current implementation, there're 3 different pipelines: Fixed Function, Programmable Function, & Device Supplied. Now, the Programmable Function pipeline won't be usable until we get support for the GL Shader Language, which I don't expect to get until sometime after there're more people, than me, contributing. Afterall, look at how many people contribute to Mesa3D & they still don't really seem to have a full handle on GLSL. After we get support for GLSL, the Programmable pipeline will be used if there is no Device Supplied Pipeline AND the Context indicates that there's a shader program in use. This leaves the Device Supplied pipeline & the Fixed Function pipeline. If the driver supplies a pipeline, then that pipeline is used regardless of what else is available. If there's no Device Supplied pipeline, then there Fixed Function pipeline is used. There's also a Pipeline class which manages which pipeline to use & controls most things pipeline related. In addition, the glraster.h file has been pushed down into the pipeline's include directory & renamed to gldevice.h. It's also been expanded by adding an object for managing the actual device driver. This will encapsulate all of the device driver functions into one easy to manage area. The Context object handles the actual OpenGL API. It's easily going to be the largest class, because of all of the OGL state that has to be stored & managed, and also because of the large volume of functions it contains. It contains the OGL API as static functions. As such, the actual data that these functions have to work on must be sent to them as arguments; they cannot access the data to their own class directly unless that data is static. In addition the the OGL API, it contains sections allocated for self management functions (such as the ability to reset itself at each glBegin), self management data, and anything that revolves around the pipeline that's attached to it. Soon, there will be a section designated to the windowing system which will contain buffers & viewing area coordinates.

Most of the code, that I've just spoken about, has already been uploaded into the Netlabs repo. If you're inclined to do so, go check it out. I'd love to have more set of eyes overlooking my work anyway; all code needs to be audited!

Also, the Sourceforge repo has not been updated at all & it's deletion is imminent. If you're still checking that codebase, stop; that's a zombie repo.

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

ivan

  • Hero Member
  • *****
  • Posts: 593
    • View Profile
Re: OpenGL ddk
« Reply #98 on: 2011.01.03, 21:15:21 »
No complaints or gripes from us just thanks that you are prepared to go to the trouble of doing this for OS/2.  As I said before, if you want testing done on several setups just let me know, we have machines ranging from a 486 up to Athlon II x4 - all AMD though.

ivan

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #99 on: 2011.01.03, 21:45:37 »
That's just a tag line that I use to solicit feedback. We usually end our After Action Review meetings with it. If no one speaks up, then that means that we can go ahead & end our meeting. ;) BTW, thanks for the offer. When it's ready for testing, you'll definitely know about it!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #100 on: 2011.01.04, 01:25:20 »
For all of the gamers who may have a bit of technical knowledge, I'd like to post a query. Which is more important to you personally, high precision rendering or sacrificing precision for render speed?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

magog

  • Jr. Member
  • **
  • Posts: 90
    • View Profile
    • Personal Homepage (Ports, Development,...)
Re: OpenGL ddk
« Reply #101 on: 2011.01.04, 03:53:55 »
After I now read the complete thread and with the basic knowledge of OpenGL plus the different implementations out there I have to say good that you ditched TinyGL. It's outdated stuff and more or less abandonware.
Keep in mind: A full OpenGL implementation is not something a small group could even pull off let alone a single person. On the other side there is also the big problem, who is going to implement something in the graphic drivers so this can be used at all. Even SciTech had problems here (they were ATI development partner)...but there are quite some open source drivers out there (but not for the latest hardware - still AMD did some progress in this area).

So what can be used?
As a full OpenGL implementation is out of question what about a subset? OpenGL ES v1.1 or the newer v2.0 version seem to be a good idea. This is what you can find in the smartphones based upon different ARM chips (TIs OMAP3xxx and OMAP4xxx, Apples A9, etc.). The devices like the Palm Pre (Plus; 2), iPhone (3GS; 4) or the Pandaboard/Beagleboard-xM (ARM based developer mainboard everyone you can buy for round about $150) have an 3D accelerator like e.g. the nVidia Tegra or the PowerVR SGX 5x0 (embedded into TIs OMAP processor). All those smartphones now use OpenGL ES v2.0.
http://www.khronos.org/opengles/
http://en.wikipedia.org/wiki/OpenGL_ES

I can't really answer the question what framework to use. For the application developer common frameworks are:
  • SDL (has also a 3D part and uses OpenGL if available) and there is an eCS and OS/2 port available!
  • Mesa3D (uses software rendering and if available also hardware accelerated 3D) at least an older eCS and OS/2 port is available (done by SciTech)!

Mesa3D brings it's own implementation and hardware implementation as far as I know and OpenGL ES v1 and 2 can be used.
This looks interesting but there is a high learning curve involved. The other "problem" is the usage of more linux/unix stuff. Drivers might use DRI2 or something else.
As I'm not into that area someone needs to look into it...seems to be Dee or someone else who as already some background and can at least some advice (e.g. the former SciTech gang: Kendall Bennett, Steve Wendt, Michal Necasek).

For the driver part:
The guy(s) who did the Panorama driver have also a driver (port) for the R100 and R200 chipsets (R100 = ATI Radeon 7000...7500; R200 = ATI Radeon 8500...9250). It would be a good idea to get in touch with the developers using the ecomstation.ru website or Roderick Klein (Mensys.nl): http://en.ecomstation.ru/projects/panorama/
Question is: Is the code for those drivers available somewhere? Would be good to get the 3D stuff actually working.

As stated above it might be possible to port more applications based upon SDL or directly Mesa3D as OpenGL (ES) implementation. With the limited acceleration and the latest progress on Java 1.6 even Mindcraft (http://www.minecraft.net/) - which is a Java 3D application - might be working later.

There is a lot of work involved to pull this off even with only OpenGL ES! Everyone should be aware of that.

Edit: There might be some typos left...I should be sleeping since 3 hours which doesn't really help typing. ;)
« Last Edit: 2011.01.04, 03:58:28 by magog »
Regards,
Juergen
*** Java Movie Database - http://www.jmdb.de/

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #102 on: 2011.01.04, 08:24:34 »
After I now read the complete thread and with the basic knowledge of OpenGL plus the different implementations out there I have to say good that you ditched TinyGL. It's outdated stuff and more or less abandonware.

I didn't drop it because of it's age or state of maintainership, i dropped it because I didn't agree with it's implementation in regards to a true GL implementation.

Quote
Keep in mind: A full OpenGL implementation is not something a small group could even pull off let alone a single person. On the other side there is also the big problem, who is going to implement something in the graphic drivers so this can be used at all. Even SciTech had problems here (they were ATI development partner)...but there are quite some open source drivers out there (but not for the latest hardware - still AMD did some progress in this area).

It's a lot easier to pull off than you think. People get wrapped up into thinking there's one set way to do it, but that's not true. In fact, the difficulty actually comes from deciding just how you WANT to do it. Even with the specs, there's a lot of leeway in regards to the actual implementation. The fact of the matter is that the basic rendering pipeline is fairly well understood. In fact, it's just basic algebra & geometry; the very same that was learned in high school. It's not as if I have to create a completely new spec; all I have to do is create an implementation that follows the spec. I'm also a firm believer that sometimes having too many developers is just as bad as not having enough. In regards to hardware, I doubt that the majority of users are running OS/2-eCS on top of the line systems. We can get away with OpenGL on cards that are a few generations behind. Afterall, that's better than what we currently have.

Quote
So what can be used?
As a full OpenGL implementation is out of question what about a subset? OpenGL ES v1.1 or the newer v2.0 version seem to be a good idea. This is what you can find in the smartphones based upon different ARM chips (TIs OMAP3xxx and OMAP4xxx, Apples A9, etc.). The devices like the Palm Pre (Plus; 2), iPhone (3GS; 4) or the Pandaboard/Beagleboard-xM (ARM based developer mainboard everyone you can buy for round about $150) have an 3D accelerator like e.g. the nVidia Tegra or the PowerVR SGX 5x0 (embedded into TIs OMAP processor). All those smartphones now use OpenGL ES v2.0.

A full implementation is not out of the question. If the *nix guys can roll a full implementation, then there's no reason why we can't do the same. There's no compelling reason to force ourselves to reuse the *nix guys' implementation. The important stuff is actually in the hardware drivers anyway. I've also learned from experience that I don't enjoy assembling a *nix development environment, just to use a *nix project on a non-*nix system. I have better things to do than to bang my head up against that wall. :) I also see no reason to drop down into the ES version of the standard. GL/2's target is for a full implementation. Consider GL/2 as OS/2's equivalent to Mesa3D.


Quote
I can't really answer the question what framework to use. For the application developer common frameworks are:
  • SDL (has also a 3D part and uses OpenGL if available) and there is an eCS and OS/2 port available!
  • Mesa3D (uses software rendering and if available also hardware accelerated 3D) at least an older eCS and OS/2 port is available (done by SciTech)!

Quite a bit of GL/2's framework has already been written.

http://svn.netlabs.org/repos/gl2/

Quote
Mesa3D brings it's own implementation and hardware implementation as far as I know and OpenGL ES v1 and 2 can be used.
This looks interesting but there is a high learning curve involved. The other "problem" is the usage of more linux/unix stuff. Drivers might use DRI2 or something else.
As I'm not into that area someone needs to look into it...seems to be Dee or someone else who as already some background and can at least some advice (e.g. the former SciTech gang: Kendall Bennett, Steve Wendt, Michal Necasek).

Yeh, I've already banged my head up against that wall with another non-*nix system; lesson learned!

Quote
For the driver part:
The guy(s) who did the Panorama driver have also a driver (port) for the R100 and R200 chipsets (R100 = ATI Radeon 7000...7500; R200 = ATI Radeon 8500...9250). It would be a good idea to get in touch with the developers using the ecomstation.ru website or Roderick Klein (Mensys.nl): http://en.ecomstation.ru/projects/panorama/
Question is: Is the code for those drivers available somewhere? Would be good to get the 3D stuff actually working.

I'm in contact. ;)

Quote
As stated above it might be possible to port more applications based upon SDL or directly Mesa3D as OpenGL (ES) implementation. With the limited acceleration and the latest progress on Java 1.6 even Mindcraft (http://www.minecraft.net/) - which is a Java 3D application - might be working later.

All of those projects (except Mesa3D) still require an OpenGL implementation underneath them in order to use 3d, whether it's hardware or software.

Quote
There is a lot of work involved to pull this off even with only OpenGL ES! Everyone should be aware of that.

So very true! I've lost count of how much code had been written & I'm not even halfway finished!

Quote
Edit: There might be some typos left...I should be sleeping since 3 hours which doesn't really help typing. ;)

Trust me, I know the feeling!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #103 on: 2011.01.04, 08:36:32 »
Back to the question I posted earlier; I think that maybe I should explain things a bit:

OpenGL consists of tons of functions, many of which are redundant. There are many functions groups who's sole difference is merely the grouping of the data & the size type of the data. While this allows application developers a lot of leeway in the way they choose to use the OGL API, it my place a slight burden on the OGL implementer. In order to mitigate this a bit, I've decided to funnel these API groups into a core set of functions that will be the main workhorses of the API, with all variant functions feeding into the core functions. This requires me to make a decision on the underlying size of the data & the implementation of the core functions that operate on this data. It would be far too easy for me to decide to store all of the data as 64-bit floating point data that's double precision & create a complement of conversion functions that convert to/from doubles to/from all of the other size types. However, I wanted to give the OS/2 community a chance to weigh in on the decision. Since many of you are not programmers, I decided to make the decision a bit simple - more precision or faster rendering. I'm fully aware that low-end systems (486, pentium, & pentium 2) will mostly likely have some of the worst performance using GL/2; this is to be expected.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

melf

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 606
    • View Profile
Re: OpenGL ddk
« Reply #104 on: 2011.01.04, 11:26:45 »
Hi demetrioussharpe,
just some words of appreciation. Like others I've seen your postings since several weeks, and I've held my breath until know. I don't understand what you technically are talking about,but I very much appreciate what you are doing, and not the least, your attitude. Wish you all luck with this work. Whatever happens it's a great and appreciated effort you do. Thanks!
/Mikael