csgl-users — General CsGL feedback list.

Re: [Csgl-users] Suggestion: Enums for OpenGL...

[Lloyd D. <ll...@ga...>]

Hy !!

Ben Houston wrote:

 > Hi all,
 > I notice in the OpenGL library there are functions such as:
 > GL.glGetIntegerv( int pname, int *params );
 > GL.glGetFloatv( int pname, float *params );
 > GL.glGetDoublev( int pname, double *params );
 >
 > Why not write some small wrappers

it is already done ! but i cannot make a release each time i make a 
change, this would become quickly boring !
But CVS is for this.

actually i even write a nice (polymorphic) version:
[DllImport("opengl32")]
glGetIntegerv( int pname, int[] params );
[DllImport("opengl32")]
glGetIntegerv( int pname, int* params );


as you see both point on the same version ! (and this is a valid and 
tested line). though i cannot do this for any function as, for example,
obviously glTexImage2D wouldn't be feed by a byte[].
so i have to check each function.

actually there is nice wrapper for glNormal, glVertex, glColors, 
glLightModel, glGetInteger/Double/Float

BTW if any one is willing to check each function and report me ???
(or send patch and the like ?)
(i wil update myself, just after (CVS))

there is also a wrapper for glTexImage2D, as i said, but i am not very 
happy with it.

there is also one other nice change in OpenGL (again, not yet released 
but already on CVS)

the inheritance graph is now:
System.Windows.Forms.Control
	OpenGL.GL
		OpenGL.OpenGLControl
so if you write your code in a subclass of OpenGLControl you even don't 
have to write "GL." !! (and it is perfectly backward compatible !)

that's all for OpenGL, now i am concentrating on SDL and Web Demo (for 1 
to 2 weeks)

for your other question i already had a dicussion with jan Nockeman on 
this topics and put it in the FAQ (copied below), anyway one argument is 
that this involve perfect knowledge of all constant and lot of free time 
devoted to this .... (and a lot of work) (though it has advantage), so...
how to say.. i could think to it, one day...
----------- the faq ---------------
   Difficult question with a lot of arguments and counter arguments 
which are the following

(-) One day i plan to automatically translate headers (.h) files to C# 
(.cs) files using some sort of tool i would either find or write. With 
this in mind it appear that #define should naturally be translated into 
const
(-) It is so easier to translate C code to C# code, just by prefixing gl 
const and function by "GL."
(-) It is a lot of work to manually translate all this constants and 
function. Actually i use a mix of sed & awk
(+) with enum you could easily find needed argument for a given function
(+) with enum you couldn't use value where you shouldn't

With this in mind i want to let you know that if i receive a lot of mail 
asking for an "enum version" i could plan to write one, a day. For this 
i already think to write a new class, let me say "GL2", with the same 
functions, but taking some enum instead of uint as arguments.

Re: [Csgl-users] wrappers for glGet[TYPE]v( int name, [TYPE]* params )

[Serge <se...@wi...>]

> Why not write some small wrappers for them so that they look like safe
> code:
> 
> GL.glGetIntegerv( int pname, int[] params );
> GL.glGetFloatv( int pname, float[] params );
> GL.glGetDoublev( int pname, double[] params );


This is an excellent idea (from my standpoint)!
I'm voting for it :-)
Really, all those fixed blocks make the code bloated a bit.

----
Serge

[Csgl-users] Suggestion: Enums for OpenGL...

[Ben H. <be...@ex...>]

Hey all,

One possible way to improve the OpenGL library might be to create Enums
for all the constants and makes typed wrappers for their respective
functions.

For example I have written the following wrapper code:

////////////////////////////////////////////////////////////////////

public enum Buffers {
	Color		= (int) GL.GL_COLOR_BUFFER_BIT,
	Depth		= (int) GL.GL_DEPTH_BUFFER_BIT,
	Accum		= (int) GL.GL_ACCUM_BUFFER_BIT,
	Stencil	= (int) GL.GL_STENCIL_BUFFER_BIT
}

public	void	glClear( Buffers buffers ) {
	glClear( (uint) buffers );
}

////////////////////////////////////////////////////////////////////

// NOTE: the available options for source alpha are slightly different
//  from the options available for dest alpha.  Thus the enums
//  are a real big help here to remind you which ones are valid where.
public enum AlphaSource {
	Zero			= (int) GL.GL_ZERO,
	One			= (int) GL.GL_ONE, 
	DestColor		= (int) GL.GL_DST_COLOR, 
	OneMinusDestColor	= (int) GL.GL_ONE_MINUS_DST_COLOR, 
	SrcAlpha		= (int) GL.GL_SRC_ALPHA, 
	OneMinusSrcAlpha	= (int) GL.GL_ONE_MINUS_SRC_ALPHA, 
	DestAlpha		= (int) GL.GL_DST_ALPHA, 
	OneMinusDestAlpha	= (int) GL.GL_ONE_MINUS_DST_ALPHA,
	SrcAlphaSaturate	= (int) GL.GL_SRC_ALPHA_SATURATE
}

public enum AlphaDest {
	Zero			= (int) GL.GL_ZERO,
	One			= (int) GL.GL_ONE,
	SrcAlpha		= (int) GL.GL_SRC_ALPHA,
	OneMinusSrcAlpha	= (int) GL.GL_ONE_MINUS_SRC_ALPHA, 
	DestAlpha		= (int) GL.GL_DST_ALPHA, 
	OneMinusDestAlpha	= (int) GL.GL_ONE_MINUS_DST_ALPHA, 
	SrcColor		= (int) GL.GL_SRC_COLOR, 
	OneMinusSrcColor	= (int) GL.GL_ONE_MINUS_SRC_COLOR 
}

public void glBlendFunc( AlphaSource src, AlphaDest dest ) {
	glBlendFunc( (uint) src, (uint) dest );
}

////////////////////////////////////////////////////////////////////

I don't know about you but sometimes I have problems remembering which
constants can be used with which functions.  Using enums instead just
makes it a little easier for me to write code correctly the first time.

Kind regards,
-ben houston
4th Year Cognitive Science/Neuroscience
Carleton University, Ottawa, Canada
( be...@ex... / 613-266-0637 )

[Csgl-users] wrappers for glGet[TYPE]v( int name, [TYPE]* params )

[Ben H. <be...@ex...>]

Hi all,

I notice in the OpenGL library there are functions such as:

GL.glGetIntegerv( int pname, int *params );
GL.glGetFloatv( int pname, float *params );
GL.glGetDoublev( int pname, double *params );

Why not write some small wrappers for them so that they look like safe
code:

GL.glGetIntegerv( int pname, int[] params );
GL.glGetFloatv( int pname, float[] params );
GL.glGetDoublev( int pname, double[] params );

Here are the wrappers that I am using:

namespace GL {

[...]

unsafe void glGetIntegerv( int pname, int[] params ) {
  fixed( int* pParams = params ) {
    glGetIntegerv( pname, pParams );
  }
}
unsafe void glGetFloatv( int pname, float[] params ) {
  fixed( float* pParams = params ) {
    glGetFloatv( pname, pParams );
  }
}
unsafe void glGetDoublev( int pname, double[] params ) {
  fixed( double* pParams = params ) {
    glGetDoublev( pname, pParams );
  }
}

[...]

}

It just makes them to much easier to use from C# code when you don't
have to resort to unsafe code.

Kind regards,
-ben houston
4th Year Cognitive Science/Neuroscience
Carleton University, Ottawa, Canada
( be...@ex... / 613-266-0637 )
 

[Csgl-users] Re: VB.net & CSGL,... need some informations

[Lloyd D. <ll...@ga...>]

Hello !

mmhh.. i am not sure i understand you well.
i don't not know exactly what is a TypeLib... is it some kind of 
resource file to describe COM interface ?
if it is that (or not) what could be typelib style DLL ?

oh i understand. you main concern is: it is tiring to write "GL." in 
front of each function, is there a way to avoid this ? am i right ?

the answer is, sadly, no ! (at last in C#)
in C# each function/constant should belong to a class (or sruct or enum)
so you always have to write "MyClass." my function...

......
let me think ....
... i just have an excellent idea ! with your help !
GREAT ! ............

if i change my inheritance graph to the following

MyNamespace.MyView :
	OpenGL.OpenGLControl :
		abstract OpenGL.GL :
			System.Windows.Forms.Control

i stay perfectly compatible with existing code BUT, now, in MyView i 
don't have to write "GL."
in front of each method ! (as i am a subclass), this would be great, 
planned for next release...

RE: [Csgl-users] glGetFloatv( GL_MODELVIEW_MATRIX, pMatrix) problems...

[Ben H. <be...@ex...>]

Hey Lloyd,

I actually found out the problem and I wrote off a little email to
Sergey about it:

>Thanks Sergey for helping me narrow down the problem. :-)
>
>I found the problem.  By mistake I was calling glGetFloatv() between a
>glBegin() and a glEnd() block.  I guess you can not get the modelview
>matrix during that period.  Oops...

I'm not to worried about more control over a context or having multiple
contexts at the moment.  Although it still  may be a good idea. :-)

Cheers,
-ben houston
4th Year Cognitive Science/Neuroscience
Carleton University, Ottawa, Canada
( be...@ex... / 613-266-0637 )
 

> -----Original Message-----
> From: csg...@li... [mailto:csgl-users-
> ad...@li...] On Behalf Of Lloyd Dupont
> Sent: Sunday, September 09, 2001 5:46 PM
> To: Ben Houston
> Cc: csg...@li...
> Subject: Re: [Csgl-users] glGetFloatv( GL_MODELVIEW_MATRIX, pMatrix)
> problems...
> 
> Hello,
> 
> Serge should be right: gl context is thread dependant and this could
be
> your problem.
> 
> But you find here an interesting issue. Maybe i should allow more
> control on a gl context ? i do not plan to use multiple context for
one
> windows (except if strongly asked with good argument)
> 
> Ok it is a good idea, i plan (for next coming release) a new method in
> OpenGLControl which set its gl context to be the current one of this
> thread, this could help you.
> 
> By the way there is some drawback in doing this:
> 1. you should avoid writing from multiple thread...
> 2. i don't exactly know the intern of event management but i believe
> each window could have its own thread, in this case, changing the
> current gl context for a given thread could impredictibly mix your
> painting...
> 
> Anyway, it is a good idea, planned for soon.
> 
> _______________________________________________
> Csgl-users mailing list
> Csg...@li...
> https://lists.sourceforge.net/lists/listinfo/csgl-users

Re: [Csgl-users] glGetFloatv( GL_MODELVIEW_MATRIX, pMatrix) problems...

[Lloyd D. <ll...@ga...>]

Hello,

Serge should be right: gl context is thread dependant and this could be
your problem.

But you find here an interesting issue. Maybe i should allow more
control on a gl context ? i do not plan to use multiple context for one
windows (except if strongly asked with good argument)

Ok it is a good idea, i plan (for next coming release) a new method in
OpenGLControl which set its gl context to be the current one of this
thread, this could help you.

By the way there is some drawback in doing this:
1. you should avoid writing from multiple thread...
2. i don't exactly know the intern of event management but i believe
each window could have its own thread, in this case, changing the
current gl context for a given thread could impredictibly mix your
painting...

Anyway, it is a good idea, planned for soon.

Re: [Csgl-users] glGetFloatv( GL_MODELVIEW_MATRIX, pMatrix) problems...

[Serge <se...@wi...>]

Hmm, maybe your problem relates to threading?
I only succeeded with reproducing such behaviour (zero matrix) when
GetModelViewMatrix() was invoked from the thread other than thread that
deals with OpenGL calls (specifically it was called from the
Invalidate/Update thread).
In other cases everything seems to work as expected.
I believe, OpenGL context is thread-bound, so maybe that's the problem.

----
Sergey



----- Original Message -----
From: Ben Houston <be...@ex...>
To: <csg...@li...>
Sent: Sunday, September 09, 2001 1:45 PM
Subject: [Csgl-users] glGetFloatv( GL_MODELVIEW_MATRIX, pMatrix) problems...


> Hey all,
>
> First off.  Thanks Dupont for this amazing library!  I've been using it
> for a week now and I have about 100kB of code dependent on it. :-)
>
> Second, I seem to be having a problem with either with my C# code or the
> OpenGL library.  I wrote the following code in C# to get the contents of
> the modelview matrix from OpenGL but it doesn't seem to work:
>
> <code>
> unsafe float[] GetModelViewMatrix() {
> float[] elements = new float[16];
> fixed( float* pElements = elements ) {
> GL.glGetFloatv( GL.GL_MODELVIEW_MATRIX, pElements );
> }
> return elements;
> }
> </code>
>
> All the values I check in the arrays "pElements" and "elements" seem to
> be zero -- whether I check then within the fixed code block or outside
> it.  I am positive that the current modelview matrix in OpenGL is not
> all zeros.
>
> Thanks for any help...
> -ben houston
> 4th Year Cognitive Science/Neuroscience
> Carleton University, Ottawa, Canada
> http://www.exocortex.org/~ben
>
>

[Csgl-users] glGetFloatv( GL_MODELVIEW_MATRIX, pMatrix) problems...

[Ben H. <be...@ex...>]

Hey all,

First off.  Thanks Dupont for this amazing library!  I've been using it
for a week now and I have about 100kB of code dependent on it. :-)

Second, I seem to be having a problem with either with my C# code or the
OpenGL library.  I wrote the following code in C# to get the contents of
the modelview matrix from OpenGL but it doesn't seem to work:

<code>
unsafe float[] GetModelViewMatrix() {
	float[] elements = new float[16];
	fixed( float* pElements = elements ) {
		GL.glGetFloatv( GL.GL_MODELVIEW_MATRIX, pElements );
	}
	return elements;
}
</code>

All the values I check in the arrays "pElements" and "elements" seem to
be zero -- whether I check then within the fixed code block or outside
it.  I am positive that the current modelview matrix in OpenGL is not
all zeros.

Thanks for any help...
-ben houston
4th Year Cognitive Science/Neuroscience
Carleton University, Ottawa, Canada
http://www.exocortex.org/~ben

 

[Csgl-users] Web demo

[Lloyd D. <ll...@ga...>]

Ok, the problem was, for whose who want to know, like in java , you 
cannopt mix host with "C# Applet" and i try download it from brinkster
in a page hosted by sourceforge...

ok, ok, i had to write a little ASP page on brinkster for coming
example (and i have already a volunteer as i do not personally know
ASP).

all of this to say:
go to web demo page now !

http://csgl.sourceforge.net
or http://csgl.sourceforge.net/demo.html

good week end..

[Csgl-users] errata

[Lloyd D. <ll...@ga...>]

woups, ... excuse for the abusive announce,...
the web demo work perfectly locally (though the DLL is on the web) but
don't work well on the web....

i have to investigate more, it seems....

Anyway code is better and i strongly advice you to check CVS.

[Csgl-users] late news

[Lloyd D. <ll...@ga...>]

i just add a "web demo" page. now there is just one demo and
prerequesite could be awkward, if anyone has idea ? want to improve the
process ?
But this should be nice !
check it now: http://csgl.sourceforge.net

there is lot of cleaning in the library, stil not available as a ".tgz"
tarball but you should chech cvs, obviously a (minor) released is
planned soon (1 or 2 weeks)

particulary SDL video code begin to become nicer and i am thinking to
implement SDL sounds code.

[Csgl-users] Re: csgl SDL names

[Lloyd D. <Llo...@wa...>]

> I was just coding and I had some ideas:
>
> In the SDL wrapper you have names like SDLKey, SDL_Rect etc.
> But I think it should be Key, Rect etc. Why?
> Because thats what namespaces are for. Its enough that they are in the
> SDL namespace.
> Look, if you wouldn't do "using SDL" it would be SDL.SDLKey etc.
> That is not necessary in my opinion.

i agree except for a few problem i will comment at end.


> Also the constants, there a lots of it, should be just in the SDL
> namespace directly.
?? what do you mean ?
i cannot write (as far as i know)
namespace foo {
	const uint BAR = 0;
	...
}
could i ?

> Make for example a class "Events" with static constants like
> SDL_QUIT, SDL_KEYUP... you know.. but rename them to QUIT,
> KEYUP.
> Because SDL.Events.QUIT is cleaner than SDL.SDL_QUIT.

?? there is already something like this, no ?
SDL.SDL_EventType enum, no ? (with SDL.SDL_EventType.SDL_QUIT value)
(in file SDLEvent.cs)

though i agree than SDL.SDL_EventType is long and it is acceptable,  
as csgl for SDL is so new to shorten this to SDL.EventType(.SDL_QUIT)

> Then you have a class Keysyms with all those SDLKs like SDLK_ESCAPE.
> And a class with all modifiers.
> ............

it is also alrady the case, no ? (or i made a mistake yesterday !)  
don't you have a class:
enum SDL.SDLKey with value like SDLK_ESCAPE ?

+-+-+-+-+
here is the points i want to discuss with you: i agree to change  
classname (for example it is very resonable that SDL.SDLKey becomes  
SDL.Keys), but i have trouble changing constant (such as SDL_QUIT)  
name because i want to provide easy porting of existing C-code. (so i  
am reluctant to make SDL_QUIT becoming QUIT, except with strong  
argumentation and experiment (as i do not practice csgl-SDL right now  
it has to be your code))

By the way (for const/#define) you could argue there is so many  
unhomogeneous constant and function and that, unlike OpenGL, where  
you just have to prefix by "GL.", you would have to work (just to  
give an example : different enum would be prefixed by different  
name), i don't know (i don't work on it enough), anyway it was my  
idea (i am open to discussion)

i want also the porting made in such a way that the process could be  
automatized one day, all #define in a .h becoming const in a class  
(named, probably, as the file), enum becoming enum, .... symbol name  
keeps constant to help easier port from C to C#

because less you think during the port, rigter and easier to  
maintain with later version it would be.

so now, you know (i hope my english is understandable enough) my  
main concern.
i am not very concentrate on SDL now (more on opengl) so my idea are  
probably less clear than you so i am waiting for your opinion

> If you think that I'm right but that I should do it: ok no problem.
mainly i would say,
	from the philosophical point of view: if you could explain  
me what <<systematic>> work you would do to provide an <<easier>> to  
use API, i agree.
	from practical point of view: if i well understand you, my  
const are already ordered as you suggest (no ? so it is ok here !)  
and my class are really too long so it is totally ok to shorten  
them... (and integrate your work in csgl)

hopes this mail, thoug long, is clear enough ?
waiting for you, cheers,
lloyd.

BTW i cc this post to csgl-users mailing list as there is a few  
users now but they could be interested...
(note for them, there is a basic SDL version which feature my draft  
version integrated since yesterday night)

[Csgl-users] torus

[Serge <se...@wi...>]

Hello there,
I'm attaching slightly updated version of CSGL torus sample (there is a tiny
inefficiency removed). it's in torus.cs
torus2.cs is a slightly modified version, it precalculates vertices/normals
upfront rather than doing this in real-time.
Generally, the original version seems more clear, so I think it's better to
use it.

> i see that ASM version seems a bit faster, snif, but i don't see what i
> could do to improve this.
Although I haven't noticed any speed differences between ASM/C# versions
myself, here is some ideas why such difference could happen.
Generally, I don't think that's because of hand-written assembly vs. CIL
code. Of course assembly code more effective - it uses fsincos instruction
in the inner loop, which is faster than fsin/fcos pair emitted by JIT; it
stores
intermediate results in FPU registers instead of local variables etc.etc.
But I don't think these differences has major influence on performance (most
of the time is probably spent in OpenGL itself).
(BTW, native code produced by JIT can be seen by generating native image
with ngen and disassembling it, or simply in .NET debugger).
Looking at performance monitor I noticed that C#/CSGL version spends far
more time in the kernel, and so as number of context switches increases
dramatically.
Note: C# code uses separate thread for Invalidate/Update loop and Assembly
version calls InvalidateRect in the message dispatching loop.
Aslo WinForms probably spawns several more threads for its own needs.

Maybe I'm wrong with that, but it seems that Windows.Forms apps are rather
resource-agressive.
But again, I haven't noticed any visual speed differences myself between
C#/Asm versions (and I believe that any possible differences are not due to
the language itself).

Have fun,
Serge

[Csgl-users] ede

[Lloyd D. <ll...@ga...>]

ce

[Csgl-users] test

[Lloyd D. <ll...@ga...>]

lkjl