View Full Version : Bonus for tB 1.4.0.1, 9th of July release
Petr Schreiber
09-07-2007, 08:33
Hi all,
guess what new toy you get with this thinBASIC preview ?
I have converted latest version of glext.h, so we should be able to work with OpenGL up to version 2.1 ( till now we sticked with 1.1 ). This header is part of thinBASIC installation under name thinBASIC_GLEXT.inc.
What does that mean, which features are available ? Lot of :)
Starting with classic extensions as multitexturing, antialiasing ... and finally ending with vertex and fragment ( pixel ) SHADERS !
As this stuff is quite new even to me, samples below are very very basic. I must thank to Eros for great help with converting some GLSL ( OpenGL Shading Language ) declares.
Most of the shaders are stolen from LightHouse 3D tutorials, which look like good source to me.
There are few shaders "mine" too as a bonus, but they are not that good as I was just experimenting :)
If not anything else, please have look at "toon" as it shows very ellegant technique of producing "comix" like output, and mine "madDeform" which shows bit of power of vertex shaders.
All this is possible thanks to Eros again, as he introduced DECLARE SET ADDRESS.
So few important facts on the end :) :
- there might be errors in the headers, as well as names of many parameters won't tell you anything ( C declares are sometimes brief, containing just datatype and not "name" ). I will update it according to specs when I'll have time
- You must bind all the functionalities dynamically using DECLARE SET ADDRESS and prototypes from header ( see samples )
- To run GLSL you need at least OpenGL 1.5 card. As I realized, even my old Radeon 9600 can do it
- Nice materials for study:
-- http://www.opengl.org/documentation/glsl/
-- http://www.opengl.org/sdk/docs/man/
-- http://www.lighthouse3d.com/opengl/glsl/
- To check where you can run which extension ( invaluable ! )
-- http://www.delphi3d.net/hardware/allexts.php
So have fun, beware bugs ... as usual :)
Bye,
Petr
UPDATED DOWNLOADS ENABLING GLSL EVEN FOR OPENGL 1.5
ErosOlmi
09-07-2007, 08:50
Thanks a lot Petr for this massive work on new OpenGL include files. I'm pretty sure it will give a lot of power to new scripts.
As you mention, the new functionality DECLARE SET ADDRESS will open a new set of options. Mainly now thinBasic is able to define functions and sub prototypes. Just DECLARE a function or a sub without indicating any external library and thinBasic will interpret it as prototype. Later, at script runtime, you will be able to connect a function prototype to a process address known only at run-time (like you can see in Petr's examples). From that point the new function will be ready to be used like a normal function.
Also in this case, it is all new, so please be patient and in case you find any bug please send us script examples. Working with process address expone to easy GPF because there are no filters and control by the interpreter. The only thing thinBasic can do is to check if address is equal to zero or not. If zero script is aborted, but if not it has to assume it is a valid address pointing to a procedure having the declared parameters sequence and type.
Have fun
Ciao
Eros
Michael Hartlef
09-07-2007, 10:58
Hi Petr,
looks like very nice samples and new functionalities. I think I'm out of the game here with OpenGL 2 but I'm not 100% sure if my graphic chip will fall backwards. I will check it out when I'm back home.
One thing that confuses me is this DECLARE SET ADDRESS thingy.
I had the imagination that we could allready declare functions that are part of an external DLL like the Windows API . So why was this DECLARE SET ADDRESS needed for you?
Michael Hartlef
09-07-2007, 11:19
Never mind, I think I know now why. This way you can dynamically handle if a function exist.
ErosOlmi
09-07-2007, 11:29
Mike,
to be able to call an external function, thinBasic needs to know the process address of the function. That is the basis (I know, you already know those stuffs but worth to mention ;) ).
Till now there was just one kind of declares in thinBasic: explicit. In explicit DECLARE you intruct thinBasic about a new external function, the library where it is stored and the alias name (the name the function has inside the library). What thinBasic does when it encounter an explicit declare is to load that library (if not already loaded), search for the alias and get from that library the address of the function. All must be known at the DECLARE time. More or less is like making STATIC DLL LINKING.
There are some functionalities that are not known at script run-time. For example you do not know the name of the library. So how to do? till now you have no chance in thinBasic. Now you can declare a prototype of the function and later assign to this prototype the address you have.
A prototype is nothing more than a DECLARE but without LIB and ALIAS. Later, when you will know the function process address, you will assign to address to the protoype using DECLARE SET ADDRESS. From that point your prototype will be able to behave like a normal function. This is like making DYNAMIC DLL LINKING
In OpenGL I think (but Petr can be more precise) the problem of those new functionalities is that you do not know in which DLL functions are present but only the driver knows it. I suppose is a problem of GPU standards. So they have developed special functions that giving the function name will give back the procedure address without knowing the LIB name. Here Microsoft explanation: http://msdn2.microsoft.com/en-us/library/ms537568.aspx
Because extension functions are not exported by OpenGL, you must use wglGetProcAddress to get the addresses of vendor-specific extension functions.
In any case the option to call dynamically external procedures open the road to many other options like CALL DWORD ... functionality of Power Basic that give extreme power to the advanced users. We will see.
Hope I was right explaining all.
Ciao
Eros
Petr Schreiber
09-07-2007, 12:50
Hi,
yes, I think the reasons were explained perfectly, you just never know where OpenGL advanced functionality is ( different cards, different driver DLLs ... ).
Mike, I pray your GeForce does OpenGL 2.0 :-[. Official web says yes (http://www.nvidia.com/page/pg_20030311316029.html), but as FX series were a bit problematic ... I keep my fingers crossed. Twice.
When in troubles, I think even OpenGL 1.5 should support it, simiarly to multitexturing using function+"ARB".
Let me know please, I will do tests on ( now ) brothers Radeon9600 with old drivers which provide just ogl 1.5.
It would be sad to miss shader fun, as it is powerful tool.
Thanks,
Petr
Petr Schreiber
09-07-2007, 13:28
Hi guys,
OpenGL 1.5 - our kind friend too!
Just replace function in sources with this if you have downloaded it yet, I have updated also the downloads !
sub GLSL_Shader_Initialize()
type tGLSLShader
Program as dword
vertex as dword
fragment as dword
end type
' -- Here we easily check for function handle and assign it to declares
dim HglCreateShader as dword = GetOpenGLProcAdress("glCreateShaderObjectARB")
declare set address glCreateShader, HglCreateShader
dim HglShaderSource as dword = GetOpenGLProcAdress("glShaderSourceARB")
declare set address glShaderSource, HglShaderSource
dim HglCompileShader as dword = GetOpenGLProcAdress("glCompileShaderARB")
declare set address glCompileShader, HglCompileShader
dim HglCreateProgram as dword = GetOpenGLProcAdress("glCreateProgramObjectARB")
declare set address glCreateProgram, HglCreateProgram
dim HglAttachShader as dword = GetOpenGLProcAdress("glAttachObjectARB")
declare set address glAttachShader, HglAttachShader
dim HglLinkProgram as dword = GetOpenGLProcAdress("glLinkProgramARB")
declare set address glLinkProgram, HglLinkProgram
dim HglUseProgram as dword = GetOpenGLProcAdress("glUseProgramObjectARB")
declare set address glUseProgram, HglUseProgram
dim HglDeleteShader as dword = GetOpenGLProcAdress("glDeleteObjectARB")
declare set address glDeleteShader, HglDeleteShader
dim HglDeleteProgram as dword = GetOpenGLProcAdress("glDeleteObjectARB")
declare set address glDeleteProgram, HglDeleteProgram
dim HglDetachShader as dword = GetOpenGLProcAdress("glDetachObjectARB")
declare set address glDetachShader, HglDetachShader
dim HglGetShaderInfoLog as dword = wglGetProcAddress("glGetShaderInfoLog")
if HglGetShaderInfoLog <> 0 then
declare set address glGetShaderInfoLog, HglGetShaderInfoLog
dim HglGetProgramInfoLog as dword = GetOpenGLProcAdress("glGetProgramInfoLog")
declare set address glGetProgramInfoLog, HglGetProgramInfoLog
else
HglGetShaderInfoLog= wglGetProcAddress("glGetInfoLogARB")
declare set address glGetShaderInfoLog, HglGetShaderInfoLog
dim HglGetProgramInfoLog as dword = GetOpenGLProcAdress("glGetInfoLogARB")
declare set address glGetProgramInfoLog, HglGetProgramInfoLog
end if
end sub
Thats perfect I think, we can use quite old graphics to play with shaders !
Bye,
Petr
Michael Hartlef
09-07-2007, 14:18
Thanks Guys,
i'll check it out later.
Sadly the first Two Examples wouldn't work on my Ancient Graphics Card. :(
One of these Days I'm going to have to buy a new Computer. :D
Petr Schreiber
09-07-2007, 14:44
Hi matthew,
I am sorry to hear that :(. As you probably know I am now running on onboard NVIDIA QUADRO NVS 210s / GeForce 6150 LE ( = lowest end of series ), and samples run at perfect framerates.
Radeon 9600 had no problems too...
If you pick any ATi or nVidia from mid-stream you should not make a mistake.
Bye :'(,
Petr
Have to run now, but WOW. That is just awesome. I can't wait to get back home and go through the code. You even had time to make some shaders, how did you guys do all of this? I feel like I am dreaming. Thanks so much again. This is just tooooooo awesome!!!
Michael Hartlef
09-07-2007, 18:58
Ok, multitexturing works, but not the shader stuff. I admit, I run a 44.x driver right now. Will install my new one.
Petr Schreiber
09-07-2007, 19:00
Hi Mike,
I use ForceWare 86.04 if it helps, without any problems ( and it is old ).
Bye,
Petr
Michael Hartlef
09-07-2007, 19:10
Ok, after installing 84.71, it works. Great job Petr.
Btw, with Notebook chips, you can't just use every driver. I think the 84.71 is the latest I can use, the newer ones will give me the BSOD.
Petr Schreiber
09-07-2007, 19:26
Victory ;D,
drivers can be dangerous, I know. I tried to use current one, but I got half framerate ( it assumed full 256 MB, although I had set up just 128 ).
I am very happy it works for you !
Bye,
Petr
I can't believe 10 years have passed since this thread started. Now we have inexpensive cell phones that can run and do all of this stuff, just amazing. Even maybe more so, is that you can run this stuff in a browser.
I will study these files and see if perhaps I can get the noise functions in shader form, then it should be super fast.