Thought this topic needs a separate thread.

I think this graphics library is mature enough to be released to the public. I've added a copy to the file sharing repository. You can also find a copy here:
http://rasmus.anthin.se/program/eng/fx-gl.txt
Swedish: http://rasmus.anthin.se/program/fx-gl.txt
Don't be intimidated by the long text file. Most of it is only documenation of the library procedures. The code listings are relatively small. I've tried as much as possible to reuse the registers to supply the programmer with as much free and untouched register memory as possible.
Affected registers are stated for each procedure in the documentation.

Here's a short example on a function surface plotter that uses COGL:


Prog "GLINIT"
0->@:-4->L:4->R:-2->B:2->T:-1->N:1->F:Prog "GLORHTO"
0->@:1.5->A:-1.5->B:1.5->C:0->D~F:0->X~Y:1->Z:Prog "GLLOOKAT"
Mat P*Mat V->Mat M
'LIMITS
-5.001->A:5->B
-4->C:4->D
.2->E:.2->F
Int ((D-C)/F)+1->@:Prog "GLINITV"
1->r:Prog "GLINITL"
'RENDER
Rad:File1:0->@
For A->G To B Step E
G->X:0->r
For C->H To D Step F
H->Y:r+1->r
G->Mat X[1,r]:H->Mat X[2,r]:f1->Mat X[3,r]
Next
Prog "GLPRJMAP"
Prog "GLFSTRIP"
Next

Try with f1 = sin(X^2+Y^2)/(X^2+Y^2) for a nice surface.

This grapher is not as "automatic" as Roy F.A. MacLean's 3D-grapher, but with this plotter you can view the surface from any direction via the GLLOOKAT procedure. So applications become easy to program (hopefully), small in size and powerful.

Enjoy.

Edit: Updated the links and the sample program.

it's a shame you didn't put it into the right format
Porting this to 9860's font in the FA124 will be complicated...
I've tried it already, however, it does not seem 9860's compatible, it needs a few changes... perhaps you could post the .cat, or .fxi?
You see, most people want imediat results, they're not much into copying text...

Sorry forgot...
Congratualations, keep it going

Yes you are absolutely right. Problem is, my home built link isn't working and my GNU/Linux -system can't find my USB port. This means I have to code the CAT files by hand. I guess I could do that now that I know people are interested in this library .

Now, about that 9860. I have no idea what differs 9860 from 9850, but I'm sure it won't be totally impossible to make a port for the 9860 and the like.


Edit: *sigh*. It is really painful to make the cat-file by hand. Anyone knows any token reference for the cat-format?

Nevermind
CAT uses the same font as g1r ( I think )
However, I ported it to g1r already
If you want I can upload it ( or convert it to cat, thank to FA124)

However, it is not yet fully working, plenty of matrix problems...
Some of them are actually tottaly impeditive, at least in 9860 for instance:
You initialize the all using matrices as 4*1, however, X matrice needs plenty more for coordinates, the sample program you used the rotating cube uses somethin like Mat X[19,3]
even if you manually dimension the X matrice, then you have a problem, first line in GLPRJMAP
Mat M*Mat X->Mat Y
Mat M is 4,1
Mat X is 19,3
Mat y is 4,1
So, I tried to change them all into 19*3 matrices and instead of running the CUBROOT or whatever the porgram is called so it wouldn't go through GLINT to put the matrices at 4*1 again
Yet It gives me Dimension Error
There are some things who need serious revision
I m going to atempt to get it working for my calc...

Good news, the program you posted on this very topic with that function(sin/x2....) actually worked out, and with a few touches it presented a graph the result was somthing like a very odd line, no surface whatsoever,
and the program spent an awfull lot of time drawing points in top of the other's, the line just apeared on screen instantly however until the nice casio "working square" disapeared in the right top of the screen it took some time, and the lists 5 and 6 have 41 entrys each

was this suposed to be so?

No need sweat over typing text into calculator.
My Casform program can be used to convert text into .cat
Just paste the text into Casform, select the options, press convert and then paste the result
into FA-123 or FA-124 or FX-Interface from where you can save it as .cat or .g1m or .fxi

Although if you find any bugs then please let me know, so they can be fixed.

When pasting text into Casform, you have to be a bit sensible about what you paste.
e.g. it will recognise various styles of comments and program titles used in CTF or
various other text files on the web, but some styles won't be recognised, in which case
the comments or headers would need to be cut from the text manually.


Casform can be downloaded from
http://members.lycos.co.uk/rfam/casformindex.html

It does work Brilliantly
I was unware of the existance of such program. I've seen one who converted from fxi to cat or somethin glike that.
Great Job

Hmm.. the dimensions you've got there are all wrong.
All matrices you see in GLINIT should be 4x4 identity (unit) matrices. I.e. matrices with all zeros in it except for the diagonal elements which are ones. It is imperative that they are like that, otherwise it won't work properly.
The reason the matrices are 4x4 and not 3x3 is that 4x4 matrices allows for translation. As for the vertex matrix Mat X, as a consequence of the transformation matrices being 4x4, Mat X must be 4xN in order to make the matrices compatible. The rotating cube (using line strips) has dim{Mat X}=dim{Mat Y}=4x17.
That is:



Nope. It should look just like a sin(blabla)/blabla surface looked upon from an oblique angle.

The number of entries are correct however.
I think the display problem has to do with the projection matrix and the transformation matrices.
Your total transformation matrix Mat M should look like this:

If your M matrix differs from the one above, then it might be related to the GLINIT problem.


Ah, thanx Roy! (nice to see you here on the forum btw).
This is just what I needed, and it runs in wine too!! Excellent!
I'll play with it tomorrow.

Yap it did worked out my mistake, sorry
Stupid error copying the text

No problemo. Good thing it happened on the "client" side and not on the "server" side.
So I presume the demos are working fine for you now, do they?
Did you have to do some tweaking to make it work for your 9860-device then?

In the graph-program, note that the span between the left and the right clipping planes should be twice as big as the span between the top and bottom clipping planes in order to preserve the aspect ratio. Furthermore, the clipping planes (in orthographic mode of course) can be used to zoom out and zoom in on interresting parts of the function surface, but then you need to alter the xy-limits too.

Roy:
I didn't succeed in converting text format commands into CAT-format commands. I'll try with mom's windows computer and see if that works better.
Also, I miss the possibility to see how many bytes the program occupies, but perhaps that's what FA-122 is for. I'll try to do some investigation in this.

Yes. You need to start a new item, new program in FA-122/3/4 to save the file.
Casform just puts the text into a format which can be pasted into FA-122's program editor.

Hmm.. it seems your converter didn't quite work for me. However I typed the code in using FA-122 and hopefully I haven't made any typos.
So some feedback on how linking goes is highly appreciated.
COGL is available here as usual:
http://rasmus.anthin.se/eng/9xx0_programs.html

Btw, I'm working on a 3D tank game which uses COGL. I'm a bit stuck with the collision detection though.

Edit: I'm sure your converter works fine. I realized that I didn't pay attention to what you said .

Hmm... that's weird. About three days ago or so I uploaded a new version of the CFX-GL (I think it's better to call it that), but the new version doesn't show in the fileshare area. Furthermore, the upload date for COGL stated on the forum differs from that stated in the file share page.

So for those of you who want to try out CFX-GL (formerly known as COGL) I urge you to take a look at my casio-page in the stead. By the way, did I ever mention that I have a cat-version available? No more manual typing .

Can you tell me what heppend? Did you use the Edit feature or created a new entry? Did the FS told you your upload was sucessful?

I used the edit feature.
I forgot to mention that I got a Authorization denied. Even though, the form was still available for me to fill in, so I sort of thought that it might have been a bug or something.
I can't specifically remember that FS told me that the upload was successful, nor can I recall that it ever told me it was an unsuccessful upload.

Ok, I've tried uploading again, and it definitely seems to be an access problem. I wonder why.

Can you tell me the exact "denie" message you get?

Also, please don't quote an entire post when it's the last of the thread, it's useless and fills the DB...

OK, this should be fixed, you were having this message because you registered less than 1 month ago. I removed that check.

Oh, I was too fast, aye?
My upload was now successful.


Sorry.. a bad habit of mine. I'll try to weigh my bytes with more care too.
Edit: ok, remedied most of it.

Ok, CFX-GL 3.0.1 is soon out. The txt-file is available on my site, but I'll soon work on updating the cat-file.
The reason for a new major version is that a few functions have been updated and a number of new functions have been added. There are now 21 library functions and 4 example programs. New functions are: GLCYLNDR, GLCONE, GLTORUS, GLTEAPOT, GLAXES, GLADDV, GLINITP. A demo program SHAPETST is also added, enabling you view models (GLCUBE, GLSPHERE, ...) from different viewpoints in "realtime" using the keypad.

As soon as I've updated the cat-file, a new rar-archive will be available in the file sharing.

Looking forward to see what you were up to
it is very nice to see somene so dedicated to calc 3D engines here at the forum.

Thank you LordNPS!
Well, in times like this, I really wish I could work with assembly instead. Basic sucks, as far as speed concerns.
Oh well... Anyway, I've published a new version of CFX-GL. Should be available anytime soon I reckon.

Bugfix in GLLINE. Furthermore, I've corrected a previous wrong assumtpion about the screen size (assumed 128x64 instead of 127x63) which affects GLINIT, GLPRJMAP and GLLINE. Enjoy!

Hey Scratty, you defintivly have to got some CG experience right? I mean, teapot??? that's a 3DMax Classic

Never quite understood why did they include that object... I figured it out it was to show the possiblilty of parametred objects with max script...

Oh, didn't know it was a 3DMax classic. Thought it was only used in OpenGL contexts. I've only worked with Art of Illusion.

Here's the history behind that famous object: http://www.sjbaker.org/teapot/

And yes, I've got a tad of experience (only from the last two years). Made a space simulator game in OpenGL in spring (project for a cg course I took): http://rasmus.anthin.se/wight-shaar/
The game, of course, uses the teapot (as a planetoid/space-base/whatever).

I've been playing with the thought of doing a space simulator for the CFX, but the problem is physics. I then need to utilize quaternions and stuff like that, so it's a bit involving. Thought that a tank game would be easier, but then the program disappeared by mistake when I was opening up my calc *sigh*. Perhaps a raptor game instead...

Nice! Always thought it was a Max thing...


I've converted Yout CFX-GL to G1r, I was wondering if I could post it on file sharing.
It should be ok with you however I thought I sould ask...
Of course I'll put your name there

And another thing, do you really need to call it CFX-Gl? I mean , fx 9860 is no CFX and I personally don't like the confusion, if you could rename it to a more ambyguos (don't know how to spell it ) name... it would be nice.

Sure, go ahead.. or you can send me the file so I can re-rar it with the other files and re-post it.

Sure, I've no idea what can be done on a 9860 and what can't be done, hence I took something well known to me. Of course, it's not a good choice of name if we consider to expand the API to apply for other models as well. I should've thought 'bout that. Oh well.
If you have a better suggestion, please tell me.
Perhaps COGL was better.. but I was mainly concerned over that Casio and OpenGL are registered trademarks/names or whatever... it might annoy people. I try to avoid the copyright-swamp as much as possible. Perhaps CCGL (Casio Calc Graphics Library)? Or why not simply FX-GL to cover all potential models?
CFX-GL could also mean (Casio FX GL, rather than Color FX GL (CFX = Color FX, right?)).

Actully I like FX-GL, Looks good and plain. Just like a good GL should look
Perhaps I could upload it to you through msn or something...

edited: I am going to upload it under Scratty in the 9860 section
And I errased anything related to color, since 9860 is bw... Everything seams to work...

Aha. Didn't know it was bw. It would be interresting to see a benchmark of the routines for the 9860. Not entirely necessary of course.

Edit: We should probably change the titles for all back-ends/libraries to something like this:

Or something like that. In order to make it all consistent. It is, after all thought to be an API and should as such look indifferent at the user front-end. The back-end, "hardware" implementations of the API should however differ depending on model. So we need a consistent naming of the API. Therefore FX as per your suggestion would be a good naming heuristic.

What dya think?

Edit edit: The only thing that bothers me now is the way I've set the version-number. IMO 3.0.1 is a tad too drastic don't you think?
It should probably be more suitable with 1.2.1 or something like that (I always get the version numbering wrong). However now it's probably too late to change it back. Oh well.

As long as there is a beta behind it, it's ok

FX-Gl it is then

On ething I would like to ask you, is for those of us who aren't that aquianted with projection mathematics, 3d engines etc, yo could write something comprehensive of how your engine works, it would be nice
Or at least a good site explaining 3D projection "for dummines"
I know the basics like lens matrice, world transform, from my previous 3D Max experience, but for those who don't have the false feeling that they actually dig up something in the subject it would be nice.

Hmm... have you looked at the Usage section?
Or are you looking for something a bit more elaborate?
Furthermore, the documentation contains information about each specific function, how to use them and what settings and variables that are affected.

Edit: I suppose I could add some stuff about how homogenous transformations work and also how the projection transformation works (projection transformation in particular). There is already a reference to at least gluLookAt in the documentation, since the documentation for gluLookAt is very descriptive. I might also have added references to other counterparts as well (can't remember).

Edit, Edit: Oh, talking about gluLookAt, perhaps I should give a brief tutorial on how to make camera movements with it, for instance in a FPS game. What say you?

In te documentation you are clear, about each function, so one can use it without fully understanding it, but about the code itself I am not so sure... Under the hood.

FPS engine would be great

Ok.. in the Usage section I've explained how to use the API and briefly how the matrices depend on each other and how to distribute the data best. Some functions are not worth to explain or very easy to explain, like GLLSTRIP, GLTRANSL and GLSCALE for instance, whilst e.g. GLROTATE, GLPRJMAP and GLPERSP could need some explaining. I'm a bit reluctant to explain GLCYLNDR, GLCONE and the like, since there's a lot empirism behind those.
I'm afraid of bloating the function reference documentation, so in that case I might add an appendix or section for this stuff instead.
I'll give it a thought.

Also, it would perhaps be a good idea to distill the doc for CFX and put in the 9860 distribution.

An FPS engine, hmm.. well I'll try to avoid thinking in terms of engine just as much as OpenGL does not contain or is any engine per se. I want to avoid implementing a glutMainLoop-stylish solution as that takes away lot of the freedom from the programmer. I'd rather give the programmer a recipe on how to implement an FPS engine him/herself by using the GLLOOKAT function. This is pretty straight forward and I can make a tutor for this in the documentation. Furthermore, the enclosed examples should also provide the programmer some ideas on how to use GLLOOKAT for his/her own applications. For an FPS it is simply a matter of setting the initial position of the head of the PC (playable character), define an initial orientation angle, then form a viewing direction from the angle l=(-sin(@), cos(@)) and then calculate the position at which the gamer is looking at. E.g.:

As you see, that part of the FPS engine is quite simple. Now the cumbersome part is to store the environment data and to render it efficiently. An even more greater task is to implement the collision detection, but that is almost out of the scope of CG programming.

Concerning the version numbering, I would really like to go back to major version 1 and have a minor of 5 (since there are currently 5 revisions). I actually haven't remade the whole API so the major shouldn't be higher than 1. Sorry for my muddle-headedness.

Would it be possible to make a port for the AFX calcs?

Next revision will among other things be: more efficient use of registers (GLROTATE will use X and Y instead of C and S. GLLOOKAT will use X,Y,Z as up vector rather than G,H,I). I consider X,Y,Z and r,@ to be volatile registers and I focus on reusing these variables as much as possible. After this revision you'll be able to use G,H,I and S freely in your app.
Stay tuned!

P.S. If you have any RFE:s or new functions you wish to see added, please let me know.
I've been playing with the thought of implementing an arcball function, but I don't feel entirely convinced about its usefulness. A gluUnProject would be a nice addition... however it won't work well on wireframes, hence the difficulty of making a working CD.

I've uploaded a new rar with the text file for the 9860. No alterarions however... sorry.

There's one feature I would like to see in FXGL : Some surface rendering. In the vertex matrice you could add another set of lines, for vertex connection. this way oclusion could be possible and surface rendering.
If you added 3 lines to the 2 lines to the vertex matrice, we could start building polygons, and some way to render them...

or even better, We could have a relation matrice: If vertex 5 and 6 are connected by an edge, Mat C [5,6] = 1

1. No problemo. A new revision will come out soon, which deprecates the input arguments for GLLOOKAT. I still consider that revision as a minor update.
   
2. Hmm... you mean rasterization? Yes that would work, however rendering polys this way will be extremely slow mind you.
   
   An FPS game with wires would be nothing compared the slowness of an FPS game with shaded polys. However if you're prepeared for an spf-rate (seconds-per-frame) in the order of minutes, you can do pretty neat stuff... for instance, per vertex lighting with Gouraud or even Phong interpolation. However, with 3 colors you will probably not notice much difference between diffuse and specular lighting (see the raytracing program for the 9850/9950 what you can do to be able to distinguish the difference between the two using some added noise). So even if you can have both diffuse and specular highlights, just diffuse lighting would suffice IMO.
   
   Keep in mind that on a regular computer (PC, workstation...) you have a GPU for this task (for both transform stage and rasterizer stage). So making games using a shading routine is not particularly feasible if you ask me .
   
3. Yes. But I would rather recommend using a list for this purpose. A relation matrix must be traverse through, testing all combinations, which is rather slow. Making an edge-list would keep the number of transformations to a minimum. Only problem is to efficiently transfer it to a pair of lists (x,y) for fast drawing using DrawStat. One tweak that came to my mind as of now is to use NaNs to represent edges in the strip that shall not be rendered. Instead of NaN we use -1 by setting a number in the edge list that is greater than the length of the vertex list, (see example). Here's an example of a cube:
   
   CODE
   Mat X =
   [-1 +1 +1 -1 -1 +1 +1 -1]
   [-1 -1 +1 +1 -1 -1 +1 +1]
   [-1 -1 -1 -1 +1 +1 +1 +1]
   [ 1  1  1  1  1  1  1  1]
   
   Prog "GLPRJMAP"
   
   File6:List4 = {1 2 3 4 1 9      'bottom
                  5 6 7 8 5 9      'top
                  1 5 9            'sides
                  2 6 9
                  3 7 9
                  4 8}
   
   Dim List 4->N
   Dim Mat X
   List Ans[2]->M
   Seq(0,X,1,N,1)->List 5
   List 5->List 6
   
   For 1->I To N
   List 4[I]->X
   If X>M                                   'if skip line
   Then -1->List 5[I]
   -1->List 6[I]
   Else Mat Y[1,X]->List 5[I]
   Mat Y[2,X]->List 6[I]
   Next
   
   DrawStat
   
   I think this algorithm should be most efficient for large sets of vertices.
   The problem is now how to interpolate the edges efficiently. If I succed in doing so, then GLLINE will become obsolete.
   This cube takes up 23 rows in the edge list. However, using the algorithm in GLCUBE we can achieve this with 16 rows. Setting:
   {1,2,3,7,6,5,8,4,1,5,8,7,6,2,3,4}->List 4
   will be slightly faster and take up less space.
   
   This way, you can draw a scene with up to 255/(16+1) = 15 cubes or blocks in it. You can multiply that amount by inter-copying lists.

Edit: I just realized that it is not possible to interpolate lines using the above line strip algorithm since that would require additional points in the list when two connected lines are partially outside of the screen.

Edit Edit: An interresting byproduct from this line strip algorithm is that you could check the order of the vertices for each face and check the orientation for each face and thus be able to perform some sort of back face culling. However this requires the vertices to be arranged in a strict order as either triangles or quads. Assuming we have an object consisting of 3 quads and we have 8 vertices, then we might have the following edge-list:
{1,3,4,2,9, 3,5,6,4,9, 5,7,8,6,9}->List 4
Now we simply take the three first points in the list (for each group of five points = each quad):

Ok. I've done some real progress on the line strip algorithm. The GLLSTRIP has been totally renewed and I have to do some major changes on both initialization routines and basic object routines.

I now have a fast FPS engine which has a "reasonable" framerate and an easy to use scene editor. One disadvantage though: since lines cannot be interpolated with GLLSTRIP, buildings/walls will not be rendered properly when they are intersecting the border of the screen.

I think I will enclose a pair of tutorials for these sort of things. One for making a scene editor and another for making an FPS engine.

If you thought FXGL was hard to use earlier... the upcoming revision won't be easier to use, but will at least give you more freedom .


*Sigh*, soo much to do .

I'm going to atempt to create a working edge renderer for your Gl scratty, if I manage to get something working I'll post it...
Somthing that makes programming easy: For wireframe geometry you only need to to get your vertex postions on the X matrix and the edges on the R matrice or something, I think that it would more simple to use the relational matrice, rather than the lists... Things would be more simple and clear...

Perhaps it would be a tad more simpler (well, to tell the truth, I can't see the gain in using a relational matrix over an edge-list), however... matrix data is precious and there's a limit on how much matrix data in total you can use (the overall memory is not the limiting factor here). A better choice would IMHO be to use a list for this task. With a list you can have up to 254 edges/lines to be rendered at once, which should be sufficient for most needs IMO. Also, I fail to see how using a relational matrix would be faster. Could you elaborate more about your idea? Write some pseudocode or something.

I've already reimplemented the GLLSTRIP routine and also GLINITP, GLINITV, and all of the primitive objects so that they are both smaller in size and faster than before (except for GLSPEHRE and GLTORUS which are a tad slower, but it is hardly noticable).
I'll do some more optimizations on the primitives before I post the new version.

I will try to find some time today and upload the new version of the FXGL API.

The most important thing with this API is speed, then comes minimizing the use of data and lastly the userfriendliness.
This is the workflow: first I try to find a way to optimize the code further, if there's an additional feature that can fit into this picture then I include it. Then I look for ways to minimize the use of registers, (also lists and matrices) and finally I try to tie it all together to make a coherent front-end for the programmer.

The way it works now is just a tad more involving, but isn't so very hard to work with:

A distinct difference in the list memory layout can be noticed in this version of FXGL: All data directly used by FXGL is located in File6. In File6 the List 3 is dedicated as an edge-list, List 4 is x-data used by the line drawing algo in GLLSTRIP, List 5 is the y-data and finally List 6 is initial vertex data {0,0,0,1} used by GLADDV and GLINITV. If you only keep this in mind when programming your app, it will all be a walk in the park. The example file STRPTEST now shows how to intercopy the edge-list data from one file to another, like this:

This is the only extra difficulty in the new API version.

Simple Scartty, most 3D apps use relational matrices, and 3DS Max does...(In fact if you program in maxscript like I do, each vertex is associated with 31 matrices just for geomety...) it would be even possible to create a program that would convert a 3D objects in .x format directly into .g1r documents, or do you expect to do those by hand?... of course we could conver them into edge lists but nearly all systems use relational matrice ...
I am not so fond of modelling things on my head, and then typing the coordinates into my calc, much less geometric systems connected by edges...
And you are right I haven't elaborated my idea, right now I don't have the time but tomorrow, I'm going to write down a full article about it, with screenshots and everyting.
Yes I know Iam a bit rockheaded...stuborness runs in the family

And this is my 69th post...
Happy 69th post to me.

Hmm... that might be true.
However... there will be lots of redundant data. Just think of a cube (the one I presented above). Then the relational matrix would be:



instead of an edge-list which contains only 16 points at a minimum (I think).
That is 64 numbers against 16. A factor by 4! Of course, the matrix way becomes more efficient/profitable the more connections each node (vertex) has.

This is a sparse matrix indeed, and even if you use the symmetry to represent half of the matrix. You would end up with twice as much data (not including the two elements representing the number of rows and cols for the matrix). So representing this as a list makes it cumbersome to use and would, as I see it, actually slow down rendering.

Anyhow... if you really want to represent geometry this way you could make an application that converts the matrix to an edge-list. But you still have the problem that the matrix grows quadratically with the number of vertices the model has. A 68x68 matrix for instance, will take up about 45kB of memory.


Congrats for your 69:th post

Edit: Now the new version is available for download as txt-format on my web site. Just som more documentation to do, then alter the cat-file and finally it'll be ready for the file share.