Can I enquire whether the 3D capability of GLBasic really IS limited to triangles? I need to be able to manipulate quads as well as triangles you see :)
huh? 2 triangles are one quad!? :)
(http://www.ericchadwick.com/portfolio/glossary/examples/tri_quad_hexagon.gif)
Right, you actually create two triangles, and there is no way to create a quad directly.
Using the 'X_OBJADDVERTEX' command, you would specify the four corners of the quad (top-left, top-right, bottom-left, bottom-right for example) and it will automatically create two triangles.
Then use 'X_OBJNEWGROUP' to lift your 'pen' to begin your next triangle/quad.
Just to note X_OBJSTART has only one mode (triangles) but STARTPOLY has 3 (fan,strip,triangles).
More simply, plotting four points as a "Z" is makes a quad like "|Z|" not "[ ]". :whistle:
Yup, 2 triangles make a quad, sortof, but I was hoping that I could easily retain the connection between quads-in-file to quads-in-GLBasic. The numer of workarounds to achieve what I wa shoping to do are getting unmanageable (I've been basically absent from programming for over a decade and was hoping GLBasic would be a simple re-entry for me). I currently have, as a starting proposition, these workaround routines on my "todo" list:
Wavefront .OBJ importer
Wavefront .OBJ exporter (where although the vertices and UV co-ords may have changed, everything MUST be exported in the same order as it was imported)
.JPEG importer
.JPEG exporter
(because it seems GLBasic JPEG support is flakey)
...and I'm not entirely sure about how well GLBasic will cope with being able to read in 10's or even 100's of thousands of lines from a text file to perform the .OBJ importing.
But now would need to add "managing quad to triangle translation", before I can get anywhere near actually trying to write the utility/ies that I'm interested in :(
Quads-to-triangles isn't much, perhaps, but it's adding to my list of concerns that this isn't the language for me. I should re-evaluate where I'm heading, or at least how I'm going to get there. Thanks for the help! :D
I'm not too sure of the details of what you are converting.
But, you don't have to worry about triangles if you already have quad coordinates.
Just create a 'CreateQuad()' routine and pass it the four corners, and add the four vertices of the quad, and it will create a quad for you, consisting of two triangles, but you don't have to worry about creating two triangles as GLBasic will do this for you.
Just make sure you add them in the proper order (ie. top-left, top-right, bottom-left, bottom-right).
Being new to game programming myself, I find GLBasic extremely easy to use, and very intuitive to what I want to achieve. I've tried other game programming languages, and it doesn't get any easier than GLBasic, for both 2D and 3D.
I'd say give GLBasic a try, and if you have any problems / questions, the GLBasic community if very knowledgeable and willing to help.
Good luck
I must admit that the apparent helpfulness and friendly attitude of the community is one of the things that appealed to be about GLBasic. It's a definate "selling" point, though I'm a bit surprised that there aren't more "canned functions" ready to go in the "shared code snippets" forum. I rather expected to find a homebrew JPEG solution there and didn't.
To further expand on what I want to do... there isn't much of a "game" aspect except for writing the programs :) in-use the programs would be more utilities than games. Here's some of my objectives:
At the extreme low end of what I want to achieve there would be a simple box in Wavefront Alias .OBJ format and a simple texture in any format. I'd want to be able to "render" an othagonal view of the original cube at screen resolution, change the coordinates of the vertices at will, and "render" the cube either with texture or as some kind of wireframe at both screen and high resolutions (probably up to say 4096 pixels by 4096 pixels). The "wireframe" view could be an issue as I couldn't just use "switch to wireframe now" if the quads have changed to triangles - I'd have to build a seperate model, at a guess, that would LOOK like the same quads model, but in wireframe. This seems hinky :(
Perhaps I could forgo the wireframe view, maybe. Although then I'd be making compromises on capability to suit the language instead of finding a language and/or improving my skillset to suit the problems.
At the extreme high end I'd want to be able to do that and more (like selecting which "groups" and/or "materials" from within a .OBJ file to work on) on .OBJ files of which a typical example would have:
# NumVerts/NumTVerts/NumVNormals/NumFacets 68498/70769/0/66830
# NumGroups/NumMaterials 63/30
in 206,529 lines(over two hundred and six) of text-based .OBJ file (including comments). The .OBJ files cannot be assumed to end in a consistent manner (i.e. some .OBJ files may end in a CR, while others end in a CR+LF combination. There may be a variety of line endings, I haven't checked - there's too many possible sources of .OBJ file!).
At this higher end I'd HAVE to be able to use JPEG files, reliably, as well as .PNG and .BMP.
One of my thoughts had been to write a .OBJ reading routine and offer that up in the "code snippets" forum if I get it working, but as I always seem to be short on time I was reluctant to spend TOO much time on GLB if I am going to end up using VisualBasic or Python.
For the record, GLBasic appeared to be the easiest route to a clean .exe that doesn't require others to set up any runtime environment. The simplicity of setup, both for programmer (me) and user (probably mostly me!) seemed better than (say) freeBasic or VisualBasic. I LIKE "lack of hassle", but these little niggles (like JPEG still not working, so on and so forth) dent my confidence. Maybe I'll put a bit more work/effort in though because, as you say, the community is welcoming and knowledgeable. These features may be of huge help as I try to dust of the coding portion of my brain!
I'd dearly love to avoid just writing the parts that Poser or DAZ Studio can't do for me in Python/QT Script - self-contained programs appeal to me much more.
Thanks :)
I couldn't sleep, so I thought I'd slap together a first pass at opening a text-based .OBJ file and displaying it line by line, then screen by screen, then parsing it a little deeper...
{snip}
Now, there's a lot missing - I haven't declared my types, or even quite decided if I'm going to just dump comments or try to preserve them somehow (ditto with the material commands, though it seems likely I will try to retain those one way or another) much less made any attempt to parse the individual parameters for each command.
As a sample TINY .OBJ file (rather than the thousands-of-lines-strong file I've tested this against quite happily) I'm using something like:
# NumVerts/NumTVerts/NumVNormals/NumFacets 8/16/6/6
# NumGroups 1
# Original File Name "Cube 03 (normals).obj"
v -1.00000000 -1.00000000 1.00000000
v -1.00000000 1.00000000 1.00000000
v 1.00000000 -1.00000000 1.00000000
v 1.00000000 1.00000000 1.00000000
v 1.00000000 -1.00000000 -1.00000000
v 1.00000000 1.00000000 -1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000 1.00000000 -1.00000000
vt 0.50000000 0.66666669
vt 0.75000000 0.66666669
vt 1.00000000 0.66666669
vt 0.75000000 0.33333334
vt 1.00000000 0.33333334
vt 0.25000000 0.66666669
vt 0.00000000 0.66666669
vt 0.00000000 0.33333334
vt 0.50000000 1.00000000
vt 0.25000000 1.00000000
vt 0.50000000 0.33333334
vt 0.25000000 0.33333334
vt 0.25000000 0.00000000
vt 0.50000000 0.00000000
vn 0.00000000 0.00000000 1.00000000
vn 1.00000000 0.00000000 0.00000000
vn 0.00000000 0.00000000 -1.00000000
vn -1.00000000 0.00000000 0.00000000
vn 0.00000000 1.00000000 0.00000000
vn 0.00000000 -1.00000000 0.00000000
g Cube
f 4/1/1 2/6/1 1/12/1 3/11/1
f 6/2/2 4/1/2 3/11/2 5/4/2
f 8/3/3 6/2/3 5/4/3 7/5/3
f 2/6/4 8/7/4 7/8/4 1/12/4
f 6/9/5 8/10/5 2/6/5 4/1/5
f 3/11/6 1/12/6 7/13/6 5/14/6
The .OBJ file format is a little loose, so I'm going to have to take care of situations where texture coords are misisng, or normals are, but the basic framework seems to be coming together for the reading in of actual files.
Does anything look hinky? Does anyone see an obvious pitfall that I'm heading towards? For example, while that .OBJ was crafted largely by hand to meet pre-defined criteria, I can't predict the order of the vertices or facets in .OBJ files in general - I'm quite nervous about the idea of trying to turn the quads into triangles so that they display as quads both when textured and wireframe - especailly as I must be able to output the model with vertex and facet orders intact.
Thanks,
Cliff :)
PS it's nice to be messing around with BASIC again. I've missed it for all those little bits of code that I could have done with over the years - just to make life a little more interesting.
It would be cool have the data stored in a object group tree then matrix pushed so that mulit-texture maps can be used. Currently, only one object file can be imported which means only one texture, when originally two were assigned. A UVMap viewer/editor also has been discussed on the forum.
Ouch - only one texture map/image per model? Thanks for the heads-up - I definately need to manage more than that, and other aspects of material/texture definition (like different diffuse colour even when using the same texture map). It's looking like actually displaying .OBJ files at random is going to be a bit of a chore. Of course, if GLBasic can itself be improved/extended then that would be even better. In the meantime I'm having fun fiddling around.
A UV Map viewer/editor? One of the things I have in mind to do would be sortof related to that, though far from a full editor and probably not included in a lot of editors. A bit of an offshoot. An actual editor would be lovely - I'll have to search for that thread and read up :D I would certainly want to be able to apply a texture to a model that was itself in the same shape as the UV map, and "render" that (with ambient lighting and othogonal projection) to produce an exact 1:1 copy of the texture. Not a brilliant goal, but much easier to understand than my full goal in THAT direction :)
Try to import a .obj with 2 textures as it can't be done! :blink: The mesh needs to be exported from a 3D editor (currently) with each separately assigned texture and 3d object, which is a hassle if there are existing, complex models. I think it's an important function and cooler if run-time-able.
I have not peeked into .obj files yet. :bed: Can objects be simply filter imported by texture id?
Well, technically anything can be done - so long as you're willing to write it!
As displaying is technically not at the top of my list, I'm considering trying to include a function within the type of "facet" that draws the facet using GLBasic, and only that facet. The facet type would be one of the members of type "3dmodel" which would call each facet one at a time... this would avoid having to work out reasonable "strips" from the 3D model and would get around at least the lack of support for multiple textures, but I suspect would be rather slow. Perhaps we shall see.
As for the .OBJ format, in theory every facet (triangle, quad, or dreaded n-gon) could be part of a different group to the one before and after it, AND a different material to the facet before and after it AND a different material to the other members of that group.
In practise things tend not to be QUITE that bad. However, quite a lot of files have fragmented groups and/or material zones.
I can't find my favourite reference to the .OBJ format right now, so here's a quick summary.
Ignoring advances which most programs (certainly those I use) don't support, .OBJ files have the following properties:
1. A Vertex cloud. This colleciton of points may be stored in consecutive lines or may be fragmented throughout the file. I have never knowingly encountered a .OBJ file where a facet refers to a vertex which comes after the facet definition, but I am not sure this is dissalowed either. the "shape" of the 3D model could be seen by displaying these as dots/spheres, in a rough hazy way. the vertex order is implied by the order the vertices are found in the text-based file.
2. Optionally a Vertex Texture co-ordinate cloud. this often has a different number of points. In theory it's a 3-coord cloud like the vertex, just (u,v,w) instead of (x,y,z) but I have never seen a VT cloud that uses the w parameter. the shape of the UV map could be seen by displaying these co-ords in a roucgh, join-the-dots kind of way. As with the V cloud, the VT vertex order is implied by position (NOT line number within the file).
3. Optionally a Normal table. The Normal position within tth eNormal table is implied by order found in the text file.
4. A facet table, which comprises integer indexes to the V cloud/optionally an index to the VT cloud/Optionally an index to the N table. Use of facet order is rarer than vertex order, but still happens - and is important to me, personally.
Obviously, vertices are reused by several faces - which is presumably at least part of the reason they are stored in a seperate table, rather than storing each facet as a direct (x,y,z) coord using floats. I have never knowingly seen (noticed!) a "face" line which has a VT or an N at one vertex which didn't have them at all vertices, but I suppose it's possible to do that.
Additionally:
5. At any line, the current "group" (arbitrary name of a collection of facets) or current material - by name - can be changed. And/or changed back. Also the "material library" can be changed (this holds a definition of the materials, their ambient colour, diffuse colour etc.). I have never noticed a .OBJ file that used more than one material file, but it seems to be a theoretical possibility. Since this would allow for materials of the same name with different definitions, I currently plan to ignore this possibility and hope it never hits me in the face.
6. There's an extra version of groups that I have not researched yet - smoothing groups. It would be a good idea for me/us to support these if I/we can, but they are a LONG way from being vital to MY intended use/s.
None of the tables (or attributes like "groups" or "smoothing groups" or "materials") have to be stored on consecutive lines. As 3D modellers tweak the model, adding here, deleting there, changing group and material zones, the tables tend to become fragmented. The more the model is worked, the more fragmented it becomes. One semi-useful tool could be simply to re-order the model to be better optimised (e.g. ordered by material first and then by group name, or by group name and then material) so that it loads faster in most 3D programs and is also passed to render engines more efficiently. As I say, I have a number of little utilityish functions I'd like to try out.
I've written a crude .OBJ viewer in the past to make it easier to see where there were certain technical flaws in the mesh, using C or C++ (I don't recall which - probably a hackily-coded version of Borland C++). I don't think I even approached handling textures at the time though, and I don't know where my source is... but the file format is easy enough that I should be able to do it using BASIC - especailly as reading lines of text from a file is platform agnostic regarding line endings (this makes life easier as .OBJ files are platform agnostic too). I'm very willing to attempt a "community .OBJ reader", as in sharing my code, but I will probably need help displaying the model and probably odd things I haven't thought of - like I hadn't thought to check GLBasic could apply more than one texture to a model!
Oh - the amount of white space between parameters (the number of spaces) is undefined. It could be one, but equally it could be five. Some programs expect 1 space and crash on loading certain .OBJ files. Ooops!
I'm quite pleased at the apparent speed of the GLBasic-produced code thus far - it nips through reading the 7.61MB test .OBJ file quite quickly, so I now run through the file in two passes - the first pass simply counts the number of vertices, VTs, Normals etc. so tha tI can redimension arrays to hold the tables just once, before populating them on the second pass. I expect this to be better on memory management, not redimensioning the tables every line or even every n lines of .OBJ file.
Hey dude, so textures are too complex? If you can't work it out then I have not hope. :zzz:
I doubt it. We'll see :)
I should have referred to some .OBJ file format reference instead of doing it all by memory - in the code above I have assumed the command "n " for normals. This should have been "vn". Hopefully I'll find some time in the next few days to start interpreting individual commands. The .OBJ file format as I intend to use it isn't complex.
Slightly updated code, moving away from my previous prefixes for variable types and trying to use GLBasic postfixes. Plus I've added some types for actually holding 3D data. Thanks to Moru and Jaywat pointing me to SPLITSTR I've started to populate a 3D model in memory from .OBJ files instead of just skimming through the files. I'm also still ignoring actual materials for the present, as I'm less bothered about multiple materials than just about anything else for now.
I am, however, tempted to see if I can draw a dot cloud in 2D to at least partially verify that the model is loading correctly. Possibly even a dot cloud for the UV Template/map as well. Hmmm - I've got to look at the 2D graphics capability sooner or later...
I'm also trying to apply GLBasic techniques as I come across them - like using INC A instead of a=a+1
Well, it looks like the dot cloud is loading in correctly :D
(http://i52.tinypic.com/wi5b1k.png)
and so is the UV Map:
(http://i56.tinypic.com/3167odj.png)
(this is the 7MB plus .OBJ that I'm using as one of my reference .OBJ files).
Alright! Should be easy from here. :good: Can I suggest breaking the code into usable and readable functions so I can test it easily? For example, passing the file-name (to) and point array (from).
Quote from: matchy on 2010-Sep-02
Alright! Should be easy from here. :good:
Errr, no. I started at the easier bits and am working towards harder as I familiarise myself with GLBasic and get used to coding again (this is my first GLBasic program - I was reading the Help Tutorial and got down to "The First Game" but was bored so decided to jump in and see some action before I return to the tutorials). I'm sure other board members would appreciate it if I learnt some more GLBasic ;) Facet tables are harder work to decode (they have an indetermiante number of parameters), and the way I intend to handle groups, "useMtls" and "MtlLibs" is a little bit fiddly.
Quote from: matchy on 2010-Sep-02Can I suggest breaking the code into usable and readable functions so I can test it easily? For example, passing the file-name (to) and point array (from).
Yup, you can. Functions are planned, so there will be a "main" that gets the filename and then calls "bSuccess% = LoadOBJ(filename$, MyModel)" or something similar. I only got as much time to play today as I did because it's my birthday, so my family give me leeway and my clients have to have an expensive problem to be able interrupt me!
Ideally, I'd return to the tutorials soon so that I can relearn more about BASIC and learn GLBasic specifics.
I'll test it when it's in LoadOBJ(filename$, MyModel) format!
I hope to get time to play around with interpreting some of the other data - USEMTL, Group, perhaps MTLLIB statements in a few hours, when I see the potential for some uninterrupted time :)
Took a while to get there, but here's the next evolution of this little puzzle. It's still a bit untidy as I'm still a bit rubbish at this, but I may well tweak it some more here and there - it's a tad slow so I'm reluctant to split it out into calls that are called thousands of times rather than using inline code, but we'll see what I think of it after I print it out for the first time and can see it all at once instead of on this teeny netbook screen.
I've tested it - on PC - with multiple .OBJ files from different sources and it seems to work pretty well...
I've started putting functions in the .OBJ type where/when it makes sense to me - such as when trying to add a face to the model.
I'm a bit torn as to whether to investigate if I'll be able to write a JPEG import routine, or hope that someone - including Kitty Hello - will do it so I should proceed more with using 3D to display the model better and/or interpreting .MTL files (with .OBJ files you often get .MTL files which actually define the materials used). I'll think on.
Would be easier to read code between the [ code ] and [ /code ] tags :)
Would be nice if the JPEG problem could be sorted out...
When I previewed the CODE tags here it lost all leading white space IIRC, but I've given it a go and the white space seems to be back after posting. Also fixed a minor bug and added in a "Beep" sound (you'll need a beep.wav in the Media folder to run this as-is now).
The last 2D graphic reader I wrote was for GEM .IMG format - and that's so long ago I can't even recall what the CPU or OS involved were, much less the language. But we'll see - in the short term actually working in 3D would be more interesting to me than working on a 2D reader.
OK, I think it's looking good. the project is now split into two .gbas source files so that I can split away the "LoadOB" functionality from the "show/test" program that uses it.
The show/test module does nothing now but fetch the filename, call LoadOBJ, then display a UV dot cloud, UV wireframe, Vertex dot cloud then Verted wireframe in order. Oh - and it loads a sound so that it can beep at you when it's finsihed drawing each screen (the first one can take a while as it's got to read in the model first).
(http://i56.tinypic.com/2zhejgi.gif)
The display code takes no notice of what platform it's running on, or the scale of the model - it's just a quick dirty hack to show you how (that) the model works, on a Windows PC. If anyone wants to address that and tweak it so that it takes account of the size of the model, I'd appreciate it - and you should know that the minimum and maximum X,Y and Z parameters of the model are stored in the model object for that kind of purpose.
The LoadOBJ module contains the type definitions and functions including LoadOBJ, so it should be relatively self-contained. I plan to extend it as I go, but basic functionality should be there now - although materials still have no info so far beyond the material name.
I suspect my next avenue of experimentation will drive me insane as I try to display the model in 3D on a free trial copy of GLBasic ;)
Your program will run for around 5 minutes, so plenty of time to view any problems =D
Oh, I suspect I can cause more problems than THAT! LOL. But it should be fine for a start, when I get around to trying it :)
Quote from: MrTAToad on 2010-Sep-06
Your program will run for around 5 minutes, so plenty of time to view any problems =D
Actually, with one of the 2 models I'm trying to use, it seems to be timing out before I can properly see the model :( So I'll have to use the simple cube for now and come up with an alternative, simpler "complex" model (my model isn't 40mb but it is taking several minutes to convert for GLBasic)
:( :( :(
Well, based on the latest screen captures:
(http://i54.tinypic.com/fjomq0.png)
(http://i51.tinypic.com/1zedo3d.png)
personally I would say it is going very well - I see no reason beyond GLBasic reliance on hardware capability (like video card RAM for sprites/textures) that I shouldn't get pretty good WAVEFRONT .obj support, even with quads (which both those models use) and multiple texture maps.
I have just come across a model that uses smoothing groups, so I plan to add support for that, and possibly lines as well, to the .OBJ loader, but otherwise things that I know areoutstanding include:
1 .mtl support to read in the definitions of multiple materials (OBJ files use them, and objects WILL display in GLBasic with multiple textures, no problem - I have 2 possible routes, one tha tlooks likely and one that is certain).
2 .jpeg support - I'm putting this off in the hopes that Kitty Hello will write jpeg support before I feel compelled to attempt it.
3 Auto texture map resizing to occupy a "2 to the power of" dimensions regardless of source image resolution. My, that seems SUCH a limited range of bitmaps sizes - it is "2 to the power of" rather than "integer to the power of 2" though, isn't it? (hoping to be contradicted here, really).
4 use of PolyVector to display uv texture rather than dot cloud or uv wireframe.
5. sort out a way to do wireframe model rendering - showing quads, not triangles (at this stage that seems fairly trivial).
6. Some kind of GUI to various features would be nice.
plus probably misc. ease-of-use enhancements and suchlike. In no particular order except, as I keep saying, I'm postponing any .jpeg effort in the hopes of having that functionality land in my lap without significant effort at my end.
Now-I should probably go do some "work" and hope I can hack at some code later. I quite fancy playing with POLYVECTOR - it already looks like the answer to one of the problems which set me on the journy to finding a language I can live with :)
Having solved the initial queries - "can GLBasic do quads and jpegs" (no, do it manually, no - do it manually!) this thread is probably running out of usefullness so I should probably post in a new thread when I have a new question!
Thx
mars_chaos89 wants to display a 3D model of a plane, possibly from .obj format.
tq for your help....i try to copy down the coding and download the library file...
but when i try to compile the program there is some error which i dont know how to fix it....
"3d viewer v3(objfile).gbas"(52) error : wrong argument type : TYPE OBJModel is not declared
or maybe i havent call the library yet.how to call the library?..i just put it in the same folder as the project...
Did you add the library to your project?
(Right click in the 'File' pane and select 'Add' and browse to the library file).
i tried adding the library put this message popup saying that "loadobj.gbal is glbasic library that cannot be edited"...
Did you try compiling again since you tried adding the library?
I think that was just a warning that you can't edit a library file, but it was still added.
Here's the help file info on this: (but "open file" I think is wrong, and it should says "Add File")
QuoteIf you want to have multiple source files for your program, open your project in the editor and click on the "files" tab at the bottom of the right pane.
Right click it in the right hand pane, and select either "New file" to create a new file for your project, or "open file" to include an existing file.
GLBasic library files (.gbal) can also be added in this way.
it is added...the error popup not when i add the file but it happen when i try to build it...
Quote from: mars_chaos89 on 2010-Sep-17
it is added...the error popup not when i add the file but it happen when i try to build it...
....? I'm on tinterhooks here!
or maybe i added it wrongly here...next time i upload the snapshot for you guys to see it...
Here - in the animation attached - I have created a new project and pasted in the main part to MarsOBJ ;)
If you try building that, the build will fail :(
However, if you switch to the "Files" tab and right-click to bring up a context-menu, you can select "Add File". Add the LoadOBJ GLBasic library that I provided - as shown - and then try compiling. You will get a couple of warnings:
*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.8.044 SN:1fd6eb1b - 2D, WIN32
"MarsOBJ.gbas"(0) warning : note : TYPE OBJModel is not declared
"MarsOBJ.gbas"(0) warning : note : TYPE OBJModel is not declared
"MarsOBJ.gbas"(41) warning : Demo mode: This command would require "GLBasic SDK premium" : X_OBJSTART
which are a GLBasic issue (which will hopefully be resolved soon) but the build will complete, and you can run the program :D
(http://i55.tinypic.com/vg1pxy.gif)
i try to compile it again...but it's still happen....huhuu :(
[attachment deleted by admin]
I am sorry, but I cannot read anything in that screenshot.
i try to upload it again
[attachment deleted by admin]
Ah! Well that central "cannot be edited" message is reasonable and not something to worry about. That syntax error mentioned in the debug window though (line 74?). That's odd. Sadly, my code has changed significantly since then so it would be effectively impossible for me to track down why it might be giving that error for that line. Curious indeed :(
Your best bet is probably to try and push forward with the *.ddd format for your model, as that is the format directly supported by GLBasic. One thing to bear in mind - tick the "1 Frame" tick box in the 3D file converter.
Quote from: mars_chaos89 on 2010-Sep-20
tq cliff.... :good:
or maybe i can give the file that i downlaod from you...maybe u can see what is the problem...
I would appreciate it if you would remove that attachment, as I have from my post. In any case it is an uneditable GLBasic library files - you can't edit it, I can't edit it, it isn't editable. I can't see what's on line 74!!!
ok cliff...sory