View Full Version : opengl
Petr, I got some books on opengl from the library. Hope it helps me visualize how it all works :)
Also in glut, I think they have routines for handling the mouse, is that available in tbgl or is that the type of stuff you will add next?
Hope your studies have gone well and you are having a good holiday times!
I have been reading up on Delphi and just got opengl for a change before I go back to more Delphi. So laying low and enjoying the Florida weather and studies.
Petr Schreiber
30-12-2006, 12:12
Hi kryton9,
yes, GLUT has some stuff to handle it.
I think it was handled using glutMouseFunc or something like this. I can add something similar to TBGL arsenal :).
Regarding my studies expressed in game encryption: I have ran through all the level, gained access cards to the doors of rooms containing level final bosses. Now I have whole January to slay them :).
I hope to finish TBGL 0.1.8 ( just decent, already announced changes plus some tiny functions ) before fight starts ;D.
Enjoy the holidays,
Petr
P.S. If you'll find some of the OpenGL books interesting, please post here names/labels and I will try to allocate them in local library :)
Petr, that is really funny about comparing the work to playing a game :) Did you ever see the animated tv series "Reboot"? Reading your reply reminded of something you might see on that show. Good luck with the level bosses, that is great that an update will be coming. Hopefully by then I will know more.
I know how to use your tbgl fine samples and can use them, but I don't have an understanding of how it(opengl) works, hopefully once I get through these books I will. If they are good I will write more about them. I guess we will know if they are good or not-- if I learn anything :)
Petr, some quick thoughts... and perhaps you have thought of this after some of your readings.
It seems Microsoft in Vista is not going to provide opengl support. The users will need to download opengl from ATI or Nvidia.
In other programming forums I see mention that for those asking, opengl or directX, the answer is for future windows based systems directx is the way to go.
Eros already mentioned that thinBasic is and will be geared to Windows type pc's for sometime to come, so it just seems to me that we should switch to directx.
I have no idea what that means we have to do. I am going to start looking into that tommorrow. I stopped reading the opengl books, they just confused me more. Since opengl runs on so many platforms the instructions were just confusing to me. I got a rough idea that the core opengl is low level and all the higher level functions come from libraries or toolkits and extentions. But I sort of in the back of my mind think of directx as the way to go.
I will report what I find out. Let me know your thoughts on this if you have the time.
Petr Schreiber
01-01-2007, 12:45
Hi kryton9,
sadly, I think I missed ReBoot :(
As I am browsing the web, it seems it was/is quite famous TV series, my brother said, that it even was on TV in our country. I doubt I was watching it, more probably I was pushing cars on the carpet in that time ;D.
Regarding OpenGL and Vista :)
There were some rumours about layering OpenGL over Direct3D, even restrict it to version 1.4...
There was a petition ( many ) sent to Microsoft and 3d card manufacturers to not do such a thing.
Today I can say the situation is the same as in any previous Windows.
If you don't install drivers for your card ( Catalysts for ATi, ForceWare for NVIDIA, ...) the OpenGL will be in software mode, as Windows will provide the 1.1 software emulation. This was in any Windows before, this seems to be in Vistas too.
But if you install the drivers, as you do until now ( first thing you do when you buy your shiny new hot Radeon or GeForce is to install drivers from bundled disk ... ), it is ok and it depends how high OpenGL standard the 3D card provides.
If you have some time for reading, here is official Microsoft story:
Graphic API on WinVista (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Graphics_APIs_in_Windows_Vista.asp)
... and if you don't have, let me quote part of this document:
OpenGL
Windows Vista provides the same support as Windows XP for OpenGL, which allows video card manufactures to provide an installable client driver (ICD) for OpenGL that provides hardware-accelerated support; note that newer versions of such ICDs are required to fully support Windows Vista. If no ICD is installed, the system will fall back to the OpenGL v1.1 software layer in most cases.
So the future does not seems so dark now, what do you think :)
I must admit the features of new DirectX are very nice, still, as Microsoft says older-than-DX10 application will run DX in wrapper mode, I'm not sure if it is wise now to learn Direct API from old tutorials, as it seems DirectX 10 is something very very different. Also, next year 2 new OpenGL releases are announced, which will bring some new hot stuff.
The reason I do OpenGL is not that I hate DirectX, but both APIs work on very different principles and the OpenGL way seems more natural to me.
Also, I want to upgrade my TBGL website during 2007 and fill it with articles and tutorials in range from beginers to higher stuff. Good my father gave me his HP320LX "palm", he said he has no longer use for it, I say I can type the text for the pages any time, in any place. Yahoo :)
I'm very sorry you are confused from the OpenGL books. But I think if you will remember it works like "state automat", it is enough for any work. You just switch some state changes like texture yes/not, light yes/not, pass some polygons and that's it !
TBGL simplifies ( or tries to ) all the little bit tricky stuff and does some garbage collection.
Hope you will not leave OpenGL in 2007, before the true fun starts ;)
Bye,
Petr
thanks for the your well put thoughts Petr. What you says does make my mood better today and more positive going forward with opengl!!
That is great that your Dad gave you his hp, you will love having something so small and so powerful with you all the time. Enjoy it as I am sure you will.
I constantly look for a device that is affordable, programmable and portable as those HP's. A notebook is nice, but not small and long lasting enough for what I would like. And those that are the right features cost huge amounts of money. It doesn't makes sense that a device about 1/4 the power of $600 notebook costs $1200 to $2100. Then they wonder why these devices aren't catching on :)
Petr Schreiber
02-01-2007, 19:03
Hi kryton,
yes, portable devices are quite expensive today. And their programmability is also not very accessible stuff, especially if you want to stay with free tools :(
If you have some ideas for TBGL articles, please list them here, and I will try to write something about it when I'll have time. I'd like to rewrite even some yet existing TBGL tutorials as they contain some stuff which can be done better now.
Bye,
Petr
Petr, I can make a list and give you more work than you want. But before that it would help me to get a good understanding of what can currently be done with tbgl, and what is soon coming. If you could what would be neat is maybe list the type of games that could be made with what tbgl offers now and maybe what sort of games could be made with coming features. That might make it easier.
I know you don't want to speak on the videos but even a nice video with you showing examples and explaining what is going on would be a very a neat introduction and having voice commentary would really help.
Another option is to say ok here is the official opengl specs, tbgl does 80% or 90% of these and maybe just correlate it that way.
Sorry I can't be more specific as I still don't grasp all that opengl can do and where other libraries take over. I will keep reading and hopefully I will get the picture sooner or later.
This just occured to me as I write this, maybe saying what I would want to be able to do would make it easier to see if it is possible.
I basically love the sort of interface we saw in the Spore Creature editor and in that one video (sorry forgot the name and link) where they had the sliders on the graphics screen overlayed on the actual 3d world. That is the controls are overlayed on the 3d world. The interface and world are almost one. All of this relies on heavy mouse and keyboard input routines that work quickly and well. This also means having a way to have layers of graphics like that, expanding menus(graphical ones however) and control panels that collapse and expand quickly and seamlessly over the world with transparent backgrounds and can register the mouse over these areas.
On another note, I was thinking of how in Blender they did their controls. They mention they are all opengl controls and can be zoomed in and out and moved about easilly. Which is true, but how in the world do they know where the mouse is when the control size can change so much and in location as well. The control must be giving its location and size somehow dynamically in an event system I would think and then the mouse can react to onhover and onclick events etc. At least that is my guess.
If you ever played with stuff written by Kai Krause ( http://en.wikipedia.org/wiki/Kai_Krause) his interfaces had a dramatic effect on me. ever since seeing his programs I saw that we were freed from the windows controls and the world of imagination and creativity could be used to do rigid things in an artistic way. I always dreamed of making my apps behave as his. Hopefully this will give you some ideas and maybe explain what we can and can't do at the moment and what is coming.
In the meantime a video on thinEdge terrain would be great!!
Petr, I came home today and decided to step back and see if I can see the overall picture for opengl. After looking at various sites, of course wikipedia gave a great overview: http://en.wikipedia.org/wiki/OpenGL
Looking over all the available passed projects I can see why I was so confused. But what struck me here is in the section: Associated utility libraries
Especially after skimming through them PLIB and OpenSceneGraph look interesting, of course there is also SDL along with glut. It seems that we should pick one of these type of libraries to further focus and capabilities, so would like to hear your thoughts on that too.
Petr Schreiber
03-01-2007, 13:42
Hi kryton9,
thanks for your post!
I will now try to answer all your questions :)
On the first place I must express clearly TBGL vs. OpenGL status.
TBGL does not cover 90% of latest OpenGL 2.1. In fact it does not cover even all parts of original OpenGL...
This is for very simple reasons:
Make programmer feel safe when using TBGL
All features provided in this module use the core, very basic functions of first releases of OpenGL I know run on even very old cards I had the pleasure to test :) This includes Matrox G200, the real 3D grandfather, also Radeon 7000 and GeForce 2 MX.
Proved in battlefield functions
As I do OpenGL stuff for some time, I have some "my precious" features, which I use very frequently and find them necessary. Many of them were used in my little games and even serious work, again tested on wide variety of computers ( thanks to friends/victims of experiments from high school ;) )
This "coders digest" :) should help you to not get lost in sea of all OpenGL API calls. Or at least not so fast ;).
I must say during work on TBGL module I have learned more than in the years before. This is also because I don't want thinBASIC to have weak module distributed with it :) and because of very important feedback from thinBASIC forum I get from you, Eros, Roberto ... you know them :)
This is why the first TBGL release was not the last.
Different than "just OpenGL"
Although TBGL was born as a wrapper, thanks to Eros later amazing work on DECLARE statement and other stuff I think it is no longer needed to continue TBGL in the OpenGL duplicating way.
Complete OpenGL API should be accessed using header files I think.
( this reminds me of my promise about C header 2 thinBASIC include file - I am working on it ! )
TBGL in future releases will concentrate on the "hard stuff" not present in OpenGL, as already is texture loading, model handling and animation. And of course any thing revealed during development of our thinBASIC game engine!
Also I consider thinEdge development very important too. I want to make it better, faster, accessible to both beginners and old pardals ;D.
As I understand thinEdge is still not for everyone ( which makes me sad but I know why so I can work on it ), I will provide separate OBJ 2 M15 converter for users of other tools.
Your question regarding "what games can be designed using TBGL" is quite tricky ;D. I will try to go now from history to today and say yes/not why, hope it will be understandable :). Note: I am leaving out Amiga and consoles stuff as I had no real experience with it, so it would be ridiculous to simulate any knowledge of it :).
8bit and automates era
All stuff - Pong, Space Invaders, Asteroids ... I think I can say all of this stuff can be done 1:1 in TBGL and thinBASIC, also in even more graphic quality and engine complexity.
DOS era games
Haha - first trouble would come ... if the current TBGL in development would not solve it ;). I think at least in the first half of 90's most of DOS games was 2D. And if I speak of 2D games I must mention sprites. As you know sprites are images with some color usually specified as transparent so you could simulate non-rectangular objects. In current TBGL 0.1.7 you would need two images to do this job - bitmap picture and it's mask. Also some hard stuff to do with blending setup. If nothings goes go terribly wrong, next TBGL release will bring support for TGA images which means support for alpha channel. This will do the masking job. More elegant then "transparent color" technology as the colors and alpha are independent. It already works, I am testing it now. Of course, I will try to bring PNG support too as it has some extra features over TGA ( mainly the file size ), but this is little bit sound of future as I am now learning about the file format.
In DOS games the importance of mouse was quite big, especially in my favorite adventure games and later first person shooters too. I'm now inventing the most suitable way to implement it in TBGL ( it can be done using classic thinBASIC GetMessage stuff, but I'll try to make it even easier.
Resume: DOS class games are trickier but should not be such a problem with hopefully forthcoming next version of TBGL.
Windows games
Hmm, very diverse world the Windows games are :)
From the graphical point of view, there is not such a problem as was with sprites. One thing I would like to add and I know it is possible is to detect if user clicks with mouse on complex 3D object. It could be done using some hard math, or ... sure, OpenGL provides support for this too! So this is another high priority task to bring to TBGL in some easy way, it will be using some simplified half-wrapper functions in future releases.
So my answer on your question is : If you want you can already create almost any kind of game with graphic presentation using thinBASIC now, but in some cases you can face complicated mathematical problems. If you will be patient, some of this problems will be solved in future releases of the module.
Regarding thinEdge terrain tutorial, thanks! I will work on it and show basic "Modifier" tool uses on examples. First I want to finish TBGL and its documentation, to not have too many open "working threads".
Hope this post was helpful ( and not too long to pass through as I am watching it :) ).
Thanks a lot,
Petr
P.S. Ha! I forgot to talk on Spore editor ... one word - amazing! I will try to comment more on it when I'll arrange it in my head - maybe on TBGL website article :)
P.P.S. Kai Krause seems to be interesting person, I didn't know he is behind this interface experiments. I will try to find out more.
Petr Schreiber
03-01-2007, 14:04
Few more things...
you can get some information extra from official OpenGL wiki (http://www.opengl.org/wiki/index.php/Main_Page) maintained by some gurus :)
Regarding GLUT, I used it when I started with OpenGL but I have left it long time ago. I used it along with GLAUX because I did not know how to load textures, create torus :) and other stuff. This I am learning while my work on TBGL now and so it has some educative impact on me :). Of course it is reinventing the wheel from my side, but I want to have maximal control of how the stuff works inside.
About PLIB and OpenSceneGraph I can tell very little.
PLIB seems to have some nice features, but I think there is nothing that can't be managed by some work on TBGL. I must say I am little bit affected in negative sense by Flight Gear ( PLIB based ) game, which is extremely GPFing on my PC.
Maybe it would help if you could list what exactly you found interesting in OpenSceneGraph, PLIB ... and I could say you then - "yes, piece of cake" or "sure, we need this library as I can't handle it" or "you can do it using TBGL this way ...".
Bye,
Petr
Petr thanks for the great answers. I see where my confusion was, tbgl is not a 1 to 1 opengl translation but your way of bringing graphics creation to thinBasic via an opengl foundation. I had noticed how much easier many things were compared to straight opengl that you had done, but it never clicked in my head of your objective. I am very excited in that in a way, tbgl is a game engine in itself as you bring on these powerful additions, tga and png support, mouse handling etc.
As one impatiently waiting for these new features, I would say forget documentation right now and go with bringing in these new features, then we will have a solid foundation to see the limits and bottlenecks as we try to do complete user interface and game interaction with users.
I looked at png file format and it is beyond me to figure out how to make it work in thinBasic or TBGL. I see that opengl already has tga importing features so that should be easier for you, so my recommendation is:
1. Bring TGA support in first
2. Mouse handling as best as you can to get us started, it can be fine tuned later
3. PNG support
4. Make Mouse handling as good as possible
5. Start Collision Detection
6. Start of Physics
7. Start of Advanced Shaders
8-... then fine tuning all the started features
Then do documentation.
If you want to get more people started with TBGL and probably a lot easier than doing documentation would be a nice video series of vtms like the ones done for Blender by the Tuft's University, where each video is relatively short going over each topic in a nice fashion. I was going to try to make them and let you correct me, but I don't want to waste your monthly bandwidth on watching my videos trying to explain stuff you know :)
Anyways I now have a better understanding of tbgl in relation to opengl and an idea of your efforts in upcoming releases, and I am very happy with all that you mentioned.
I will try to tackle png, I already tried but had no idea how to go about doing it. Could you share your code that you used to convert bmp to tbgl? I know I don't have powerbasic but it might give me an idea of how you did it and I coudl try doing the same thing in Delphi with png?
Oops forgot how young you are... pushing cars on the carpet when reboot was on :) That is when Kai was releasing very advanced interfaces that were revolutionary. I will try to find some images of the interfaces, but of course they were animated and even cooler when interacted with them:
http://www.graphics-abc.com/convolv.jpg
http://thor.info.uaic.ro/~sergiu.dumitriu/hci/L3/img/metacreations5.png
http://www.designer-info.com/images/pkpt6d.jpg
http://www.edition3.com/blog/metacreations-soap.jpg
As you can see all very different and wonderful!!
I've been looking at various sources to see if I can understand how to use png and to help somewhat with the massive job you are doing Petr.
This is the best thing so far I found that wasn't overly confusing to me, although I don't know how to use it for our purposes, but it might be a quick way as you have a better understanding of all of this stuff.
http://www.wyatt100.freeserve.co.uk/download.htm
if you download glpng.zip (302k) it has a nice html file that explains what it does and gives examples. So far the easiest looking I have seen. Hope it helps.
I will keep experimenting with it to see if I can figure it out, but I don't have much hope to be able to do so :)
Petr Schreiber
04-01-2007, 12:42
Hi kryton9,
I can't omit documentation :) And in fact, it will not be too much work for me, maybe except the new light setup functions. But these are quite wrapper like so I can be inspired by OpenGL docs.
Thank you very much for your PNG investigation, the link you posted is exactly what I needed. It will take some time as I see the amount of code. Just for fun here is how the BMP loading is done in TBGL:
FUNCTION tbglInt_LoadBMP( TexName AS STRING, TexNum AS LONG, TexFilter AS LONG ) AS LONG
REGISTER i AS LONG, j AS LONG
LOCAL SrcPath AS STRING
SrcPath = thinBasic_GetRunTimeInfo("SCRIPT_PATH")
IF INSTR(TexName, ":") = 0 THEN TexName = SrcPath+TexName
TextureList(TexNum) = UCASE$(TexName)
LOCAL n AS LONG
LOCAL bmfh AS BitmapFileHeader
LOCAL bmih AS BitmapInfoHeader
LOCAL nWidth AS LONG
LOCAL nHeight AS LONG
LOCAL nDepth AS LONG
LOCAL nTexSize AS LONG
LOCAL nColors AS LONG
LOCAL colors() AS c_BGRA
LOCAL diff AS LONG
LOCAL nTexData AS STRING
LOCAL pTexData AS BYTE PTR
LOCAL pTex AS BYTE PTR
LOCAL sTex AS STRING
IF LEN(DIR$(TexName)) = 0 THEN
TBGLError $ERR_TEXTURENOTFOUND + $CRLF+ "File : "+TexName
FUNCTION = %TBGL_FATAL_ERROR
EXIT FUNCTION
END IF
' Loading file
n = FREEFILE
OPEN TexName FOR BINARY AS #n
GET #n,, bmfh
IF bmfh.bfType <> 19778 THEN
TextureLoadingError:
TBGLError $ERR_TEXTUREBADFORMAT + $CRLF+ "File : "+TexName
CLOSE #n
FUNCTION = %TBGL_FATAL_ERROR
EXIT FUNCTION
END IF
GET #n,, bmih
nWidth = bmih.biWidth
nHeight = bmih.biHeight
nDepth = bmih.biBitCount
' Calculate the size of our texture
nTexSize = nWidth * nHeight * (nDepth \ 8)
' Calculate the number of available colors
nColors = 1
SHIFT SIGNED LEFT nColors, nDepth
IF nDepth < 8 THEN
TBGLError $ERR_TEXTUREBADFORMAT + $CRLF+ "File : "+TexName
CLOSE #n
FUNCTION = %TBGL_FATAL_ERROR
EXIT FUNCTION
END IF
' Load the palette for 8 bits per pixel
IF nDepth = 8 THEN
DIM colors(nColors)
GET #n,, colors() RECORDS nColors
END IF
' Load in the actual pixel data that makes up the texture
GET$ #n, nTexSize, nTexData
CLOSE #n
' Calculate the size of this texture once converted to 32-bit RGBA
diff = nWidth * nHeight * 4
' Change format from BGRA to RGBA
IF nDepth = 8 THEN
' Point to the data we loaded in
pTexData = STRPTR(nTexData)
' Allocate memory for our texture
sTex = SPACE$(diff)
pTex = STRPTR(sTex)
IF nHeight > 0 THEN
j = 0
' Count backwards so you start at the front on the texture
FOR i = 0 TO diff - 1 STEP 4
' Transfer the data
@pTex[i ] = colors(@pTexData[j]).r
@pTex[i + 1] = colors(@pTexData[j]).g
@pTex[i + 2] = colors(@pTexData[j]).b
@pTex[i + 3] = 255
INCR j
NEXT i
ELSE
' Texture parser for a forward texture
j = nTexSize - 1
' Count backwards so you start at the front of the texture
FOR i = 0 TO diff - 1 STEP 4
' Transfer the data
@pTex[i ] = colors(@pTexData[j]).r
@pTex[i + 1] = colors(@pTexData[j]).g
@pTex[i + 2] = colors(@pTexData[j]).b
@pTex[i + 3] = 255
DECR j
NEXT i
END IF
ELSE
' Allocate memory for our texture
pTexData = STRPTR(nTexData)
sTex = SPACE$(diff)
pTex = STRPTR(sTex): IF pTex = 0 THEN EXIT FUNCTION
IF nHeight > 0 THEN
j = 0
' Count backwards so you start at the front of the texture
FOR i = 0 TO nTexSize - 1 STEP 3
' Transfer the data
@pTex[j ] = @pTexData[i + 2]
@pTex[j + 1] = @pTexData[i + 1]
@pTex[j + 2] = @pTexData[i ]
@pTex[j + 3] = 255
j = j + 4
NEXT i
ELSE
' Texture parser for a forward texture
j = diff - 4
' Count backwards so you start at the front of the texture
FOR i = 0 TO nTexSize - 1 STEP 3
' Transfer the data
@pTex[j ] = @pTexData[i + 2]
@pTex[j + 1] = @pTexData[i + 1]
@pTex[j + 2] = @pTexData[i ]
@pTex[j + 3] = 255
j = j - 4
NEXT i
END IF
END IF
' Assign an OpenGL handle to this texture
' glGenTextures 1, lpTexture(TexNum) not needed here, done before
glBindTexture %GL_TEXTURE_2D, lpTexture(TexNum)
IF TexFilter > 2 THEN TexFilter = 2
IF TexFilter < 0 THEN TexFilter = 0
SELECT CASE TexFilter
CASE %FILTER_NEAREST
glTexParameteri %GL_TEXTURE_2D, %GL_TEXTURE_MAG_FILTER, %GL_NEAREST
glTexParameteri %GL_TEXTURE_2D, %GL_TEXTURE_MIN_FILTER, %GL_NEAREST
glTexImage2D %GL_TEXTURE_2D, 0, 3, nWidth, nHeight, 0, %GL_RGBA, %GL_UNSIGNED_BYTE, @pTex
CASE %FILTER_LINEAR
glTexParameteri %GL_TEXTURE_2D, %GL_TEXTURE_MAG_FILTER, %GL_LINEAR
glTexParameteri %GL_TEXTURE_2D, %GL_TEXTURE_MIN_FILTER, %GL_LINEAR
glTexImage2D %GL_TEXTURE_2D, 0, 3, nWidth, nHeight, 0, %GL_RGBA, %GL_UNSIGNED_BYTE, @pTex
CASE %FILTER_MIPMAP
glTexParameteri %GL_TEXTURE_2D, %GL_TEXTURE_MAG_FILTER, %GL_LINEAR
glTexParameteri %GL_TEXTURE_2D, %GL_TEXTURE_MIN_FILTER, %GL_LINEAR_MIPMAP_LINEAR
gluBuild2DMipmaps %GL_TEXTURE_2D, 3, nWidth, nHeight, %GL_RGBA, %GL_UNSIGNED_BYTE, @pTex
END SELECT
' TBGL internal rebind to avoid texture mess and confusion in code
IF LastBindedTexture >= 0 THEN glBindTexture %GL_TEXTURE_2D, lpTexture(LastBindedTexture)
FUNCTION = %TEXTURE_LOAD_SUCCESS
END FUNCTION
I must say this code is not whole mine, it is adapted public domain code from PB forum ( credits go to Bryan Flick if I remember correctly ).
So first I get the RGB data from file ( some extra effort must be done with 256 color bitmaps ), convert them to RGBA, then I do the OpenGL "registration" of a texture, which specifies how it will be rendered.
You can see here some parts where the loaded texture is writed to internal TBGL texture manager list. This serves to avoid loading of the same texture twice when loading for example two models with some same textures later.
Also, if you first load your user textures ( for effects ...) you must not be afraid any loading of models will overwrite them with their own stuff.
Part which is also handled automatically in TBGL is the generation of 256 texture "slots" on startup and their automatic cleanup on the end ( not visible in this procedure ).
Your suggestion regarding TBGL development seems very good to me, I'm just disagreed with "quickdone" functions improved later. I am afraid it could lead to situation, when TBGL module will have 0.5 MB with only 50% of functions really usable. For example due to my not very wise decision how to design TBGL_CreateWindow ( not possible to specify resolution of window in windowed mode ) I will provide TBGL_CreateWindowEx in new TBGL which fixes this problem, but I still have to include old function to provide backwards compatibility. The same applies to current TBGL_SetupLightSource, which is usable in very limited way ( setting just ambient part of light, I must had slept very little when "inventing" this :( ).
I must say I'm quite looking forward to developing the collision and physics part, as it could bring more fun to TBGL :)
As I am thinking of it ... Would you like to test the TBGL preview ? We could develop the quickdone ( mouse... ) function to "final" state during the tests and then document the final version in TBGL help. This will make you see the new features as one of the first persons, so no big waiting :) and it could lead to improving the quality of module.
TGA is sadly not natively supported by classic OpenGL, but I have found code which will do it for me after few modifications.
To make long story short, I have TGA textures working at home as you can see on the attached image from next TBGL.
Please note the 3D "chunks" are just TGA alpha mapped texture on basic TBGL_Sphere shape. You can also see 2 light sources - green and red - put on opposite sides. If you watch the image carefully, you can see the light is applied in 2 side mode on objects too, so one polygon can have different light(s) applied on each side depending on light position. I know the image looks quite confusing at first sight but if you study it for a while it should be clear.
Regarding your idea with videos, I would love to see them! My internet provider under pressure of business enemies :) raised the month limit quite up, so I think it would not be such a problem for me at it would really help me ( and save time to do other stuff ).
Thanks a lot,
Petr
P.S. I remember the interface from Bryce, I liked it a lot ( it was some early demoversion, but still very nice )
Petr, thanks for the reply and the glimpse of whats to come with that jpg. That is really cool.
I need to run out but wanted to reply before I did. YES, I would love to be a beta tester to the latest version as you make them to tbgl!!!
Also, about backward compatibility, I would just dump the old routine and replace it with a new one. The window and light creations will be just a line or 2 and anyone could go and update their programs easier. It will make a it a lot easier for new people coming not to figure out what to use. My personal opinion, if it was a routine that would be nested in many places of code, that is another matter, but for such 1 to 2 line procedures I don't think anyone would mind making the change to the new procedure.
I will write more when I get back and after I study your bmp routine, thanks in advance!!
Wow that bmp loading stuff looked scary. I don't know how you ever figured it out. I guess png and all the other formats are yours, they are beyond me :)
Petr Schreiber
05-01-2007, 16:38
Hi kryton9,
I am happy you accepted the betatesting !
I will send you some things to test as soon as I get it together ;)
Your thinking about the "outdated" functions sounds reasonable.
Problem is that they are in almost all scripts, and could make some people which will by trying thinBASIC feel, it is buggy, messy ... I think I will put in help file strong recomendation ( in color, wow :) ) to not use them any longer,
and then I will drop them ( with intense announcement ) later.
Thanks,
Petr
That sounds really logical and it will be easy to see which one to use, great idea!!
How do you like your HP Palmtop?
Petr Schreiber
06-01-2007, 11:53
Hi kryton9 :),
HP-320lx is perfect. Typing of long texts, scheduling app... really good.
Even the batteries live ~long if you have 2 sets of rechargable ones, which you just swap after some time it is ok.
What is sad is the lack of possibility to program it. I have even tried Squeak for SH3 ( cpu ) release but it GPFed :(
But as Pocket Excel is there, lot of stuff can be done using it.
Regarding TBGL, I make some changes, please see more in betatesters report PM :D
Bye,
Petr