• 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

Saijin_Naib

Nice. Forgive the possibly noob question, but what will the end result of this be?

A OpenGL software renderer, or possibly an OpenGL hardware renderer?

demetrioussharpe

Quote from: Saijin_Naib on 2010.10.26, 21:36:57
Nice. Forgive the possibly noob question, but what will the end result of this be?

A OpenGL software renderer, or possibly an OpenGL hardware renderer?

Questions are always good! The end result will be hardware rendering with a software rendering fallback if the drivers haven't been written for your video card yet.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Saijin_Naib

That is fantastic! This opens up the door for a ton of Linux and windows software (running with Odin/WINE) to work, as well as many academic applications.

Now for cards supported by SNAP (which has hardware accel, correct), this OpenGL implementation you're writing would interface with that?

demetrioussharpe

Quote from: Saijin_Naib on 2010.10.26, 21:51:18
That is fantastic! This opens up the door for a ton of Linux and windows software (running with Odin/WINE) to work, as well as many academic applications.

Now for cards supported by SNAP (which has hardware accel, correct), this OpenGL implementation you're writing would interface with that?

To be honest, I don't know all that much about SNAP from a coding & organizational standpoint. My code will talk directly to GRADD drivers through the VMAN interface, however, basic GRADD drivers will have to be modified in order to understand what the GL/2 driver is asking for. Unless you have an updated GRADD driver, you won't be able to take advantage of hardware accelerated GL/2. Once I start working on the first hardware drivers & get it up & running, I'll have the API for the communication between the GRADD & GLRASTER.dll. But that's a bit down the road for now. Right now, there's the matter of getting GLPIPELINE feature complete (including GLSL support), completing OPENGL.dll, creating an installer, & figuring out what I want to put into config.sys.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

DeviceCreateBitmap()
DeviceDeleteBitmap()
DeviceSelectBitmap()
GetBitmapBits()
SetBitmapBits()

These 5 functions are PM hooks that will either be implemented by the PM display driver or fallback to the PM if the driver does not implement them. Does anyone know more about these functions? I'm wondering if I should just use these functions for GL buffers, or continue to view them as fallbacks. If the driver implements them, then they should already be accelerated, if not, then it would be any different from normal software buffers. The only difference would be the fact that there's less code to right & we'd be able to use GL/2 without modifying GRADD drivers.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

warpcafe

Hi demetrioussharpe,

there are only 2 persons I know of who have experience in "native DDK" stuff with regards to graphics AND who are still more or less active in developing software for OS/2|eCS are either Ruediger ("Rudi") Ihle the author of Emperoar ... or Peter Koller, the author of Maul publisher.
Rudi is also active here on OS2World.com ... perhaps either one of them can give you more insight on the internals of graphics stuff or have "better" documentation - but I'm not sure.

HTH,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

demetrioussharpe

Quote from: warpcafe on 2010.10.30, 16:26:47
Hi demetrioussharpe,

there are only 2 persons I know of who have experience in "native DDK" stuff with regards to graphics AND who are still more or less active in developing software for OS/2|eCS are either Ruediger ("Rudi") Ihle the author of Emperoar ... or Peter Koller, the author of Maul publisher.
Rudi is also active here on OS2World.com ... perhaps either one of them can give you more insight on the internals of graphics stuff or have "better" documentation - but I'm not sure.

HTH,
Thomas

Thanks for the reply. I've stubbed out the interface between the pipeline & the raster. The direction that I'm going is for driver implementers to implement the raster interface if they just want to reuse the TinyGL pipeline or to implement the pipeline with it's own raster (as one set package if necessary). If implementers have a better pipeline that's more integrated with the hardware, there's no problem at all. OPENGL.dll will focus on loading just the pipeline, so there's no need to worry about using the included raster interface. The raster interface is most useful with the included pipeline. Does anyone have any additional insight 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!

demetrioussharpe

I can use DosLoadModule(), but I guess there's no way to unload modules from a running system. There seems to be no signs of DosUnloadModule() or something similar.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: demetrioussharpe on 2010.10.30, 21:31:02
I can use DosLoadModule(), but I guess there's no way to unload modules from a running system. There seems to be no signs of DosUnloadModule() or something similar.

Nevermind, I'm supposed to use DosFreeModule().
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Does anyone know of an opensource 3d rendering library? Something very small & light. I only need something that can plot points, lines, & triangles. It needs to output to a generic buffer. It needs to be in C (not C++ or anything else). And preferably licensed under BSD or some other non-viral license. The drawing system for TinyGL is incomplete & I really don't have all year to be dicking around trying to create a whole new system when there's probably one that suits the need already out there. This will form the basis of the software renderer for GL/2. Until I can find a suitable replacement, I'm going to halt work on the software system & move over to pgl (OPENGL.dll) & then shift over to the hardware driver. I should probably go ahead & push the software driver out into it's own project. Maybe GLSOFTRASTER.dll.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

warpcafe

Hi,

you are so much more into this topic than anyone else around I guess... so forgive me if I'm telling rubbish, also you may already have checked them out on the internet, but anyways... FWIW, here's what I found. Perhaps it helps or gives a starting point for further searches:

http://sourceforge.net/projects/glide/
http://www.ogre3d.org/about
http://www.genesis3d.com/index.php   (looks abandoned though)
http://g3d.sourceforge.net/
http://lightfeather.de/content.php?content.10

Some (if not most) of the above are C++ though. Sorry, I didn't check in detail before posting.
Anyway... HTH,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

cytan

#56
Don't forget that CAIRO has already been ported to OS/2 and written in C. But it's 2D.

cytan

demetrioussharpe

Quote from: warpcafe on 2010.11.09, 12:01:16
Hi,

you are so much more into this topic than anyone else around I guess... so forgive me if I'm telling rubbish, also you may already have checked them out on the internet, but anyways... FWIW, here's what I found. Perhaps it helps or gives a starting point for further searches:

http://sourceforge.net/projects/glide/
http://www.ogre3d.org/about
http://www.genesis3d.com/index.php   (looks abandoned though)
http://g3d.sourceforge.net/
http://lightfeather.de/content.php?content.10

Some (if not most) of the above are C++ though. Sorry, I didn't check in detail before posting.
Anyway... HTH,
Thomas

Thanks for the response. I've looked at most of them & they are a bit too big. Truth be told, my biggest hickup is line drawing. I need a line drawing algorithm that can optionally interpolate the color between 2 points, the z component between 2 points, & is capable of doing both at the same time if necessary.

Quote from: cytan on 2010.11.09, 14:31:21
Don't forget that CAIRO has already been ported to OS/2 and written in C. But it's 2D.

cytan


I've been looking at Cairo, but I'm not sure that I'm completely comfortable with the MPL license. I know that the LGPL license can also be used for it, but I'm not really comfortable with the possible code pollution that could cause the rest of the code to be sucked into LGPL land.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

#58
 IBM's spec for pglSwapBuffers  states:

"The window specified by hwnd does not have to be currently bound to an OpenGL context; it needs only to have been bound at some point. This function has no effect on a PM window that has never been bound to an OpenGL context. "

I'm changing this a bit. Since a context can only be bound to one window at a time, the window specified by hwnd MUST be currently bound to an OpenGL context. If it is not, then pglSwapBuffers is a no-op. This should not cause too much of an issue, since pglSwapBuffers should be called to swap the buffers of a window that contains the current context. Afterall, why would you swap the buffers of a context that isn't current? Also, my implementation stores the buffers in the context, not in the window. Even if there are applications that rely on the specified behavior, I doubt that there are many of these apps that're going to be relevant going forward. If anyone has any issues or reservations about this change, please let me know.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Does anyone know how to copy a font into a bitmap? The GPI functions seem to be missing that functionality lol
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!