127 replies to this topic

[LordNPS]

Yes, indeed I've reconsidered Relational matrice is a bad idea for low resources systems, however its most due to basic being an interpretated language if we were gifted by casio with more advanced means of programming such as ASM to use relational matrices...
it's best to use edge list then, I agee.

So, new release hey?

Some sugestions:
-Some Camera and rendering presets: Perhaps an APP wich includes already all the steps creating the matrices, just a few inputs: Camera Coordinates, Geometry coordinates and edgel list Something for those who don't want to learn FXGL just use it

-A cube engine for geometry: Much of 3D things we are going to get in a calc will be groups of cubes, not iliterationed at all. So what I sugest is a quick efficient way to render cubes, and a basic system for creating them Somthing like:

Mat X =
[1,1,1,1,1,1,1]
[0,0,0,2,4,4,4]  
[0,2,4,2,0,2,4]
[1,1,1,1,1,1,1]
D=2

would render something like:


This can be easily done with your GLCUBE program.

Sample :
for i=1 to n_cubes
program "Create_Temp_Cube"  #with Mat X[1, (1,2,3)] as center coordinates and with D as edge lenght
Render																	   
next

This way, geometry is rendered without actually having to use all those matrice entrys for the vertexes...
The cube is created 7 times in the same registers...
Instancing geometry is yet the best solution for somehow complex models (like an "H" )


-Is it possible actually to shade some faces I don't mean render them or raytracing, but with the >= commands from graph it is possible, we just would have to write a program than would convert the limiting edges of the polygon into their analitical form , and then we could use the graph functions to shade the area:

Imagine I have the front face of a cube:

And we want to shade the surface where the cursor is...

Ok we need to know the analitical expression for each of the for edges... so for each edge, we put both projection coordinates in a list, get linear regression and the otput is on Y=ax+b
We change to graph mode and y(1...4)>=ax+b and it shades all that surface...


There are 3 problems with this improvised method:
- Very slow method indeed
-How do we know in the equation if it is the upper or lower edge for using the signals > or < (or right and left)
-If the edge is totaly vertical , x=c like...

The third problem can be solved, it the x coordinates are equal, then we just have to add a very small value to one so it results in a y=ax+b expression... else I really don't know
edit: Now that I saw it posted this is way to stupid... just ignore it

[Scratty]

Hey. This is indeed interresting stuff. An application for producing stacks with boxes wouldn't be hard as you suggest, at least not in theory.. unfortunately, in practice it is a bit more involved. For instance you can't easily merge lists together. If we just disregard edge-lists the following algorithm can be used:

Prog "GLCUBE"
Mat X->Mat Y	 'temp
Dim Mat D		 'displacement matrix
List Ans[2]->N
Mat D[1,1]->X:Mat D[2,1]->Y:Mat D[3,1]->Z:Prog "GLTRANSL"
Mat T*Mat Y->Mat X
For 2->I To N
Mat D[1,I]->X:Mat D[2,I]->Y:Mat D[3,I]->Z:Prog "GLTRANSL"
Augment(Mat X,Mat T*Mat Y)->Mat X
Next

We will unfortunately, get redundancy in the vertex matrix whenever two boxes share sides/patches.

Your idea about using the relational graph for shading sounds very intriguing. It will be very interresting to see what you'll come up with.

About camera presets... there's already a camera preset if you write:

1->@:Prog "GLLOOKAT"

Also, using a camera will hardly get any easier than the syntax for GLLOOKAT. You simply define camera (or eye) position, position at which you look at and an up vector which tells you if the camera is upside-down or straight up or tilted, etc.

The problem with making another API layer is that you will lose another degree of freedom. The more userfriendliness you stuff in it the less versatile it becomes. If you want to make another API on top of FX-GL, then be my guest.

Edit: I've created a brief tutorial on how to make an FPS "engine":
http://rasmus.anthin...utorial_fps.txt
I'll include it in the rar archive.

Edit Edit: *phew*. Now, I'm out with version 1.7. Yeah, I know the version numbering has been quite confusing, but I'll try to be more consitent from now on. The API package comes now with a cat containing only the FX-GL functions and a separate cat-file with the examples. I've also included a tutorial over how to implement an FPS (First Person Shooter) "engine".

As you might have noticed, CUBETST1 is gone. This is because I didn't find it useful. GLLSTRIP has been renamed to GLFSTRIP (GL fast strip) and a new function GLSTRIP has arisen which instead uses an edge-list. GLSTRIP uses DrawStat but due to the edge-list a slight slowdown in performance is expected. Check the documentation for bottlenecks.

Please let me know if you find any bugs!

Edit Edit Edit: NB! Keep in mind that List 3 to List 6 in File6 are specialized lists used by FX-GL internally.

Edit Edit Edit Edit: Now I really really need a major break from this! My apartment is a real mess and I have a lot to tidy.

[LordNPS]

Yes, perhaps you do need a major break, and instead of using "edit" use P.S. P.S.S. etc... it will save you some time

about your apartment, well you're a programmer dude, you're not expected to have you apartment clean unless your parents are visiting, smoke a cigar a forget all about it, we need you here

[Scratty]

Oh, did I say apartment? Eh, I meant my room of course.. , sorry.
Hehe.. wish it was that simple anyway.

P.S., Edit... whatever, I tend to use them interchangeably .


Edit: Now I see what you mean about shading with GraphY> and GraphY<. Even though you can make a filled patch, the lines are not confined to the patch. That's a pity. I really liked the idea.

[Scratty]

Oh.. how interresting. I wasn't aware of that. Hmm.. this opens up for some new possibilities.
Thanx Master!

[Andy.Davies]

or, you can use the custom BBCode for editing :

[Edit]
This is an edit
[/Edit]

makes:


EDIT:

This is an edit

[Scratty]

Ah. I wasn't aware of that. I'm so used to PunBB .

Master: it's a pity you can't do these things on a 9950 .

[caspro]

Master: it's a pity you can't do these things on a 9950 .

Have you tried the list manipulation techniques at:
http://members.lycos...html/lists.html

Not as simple as on the 9860, but maybe worth a shot.

Might be a bit slow for a 3D program though.

[Scratty]

EDIT:

As usual I didn't pay enough attention. Your list mainpulation techniques are superb! Thank you Caspro!!!

Hmm... still, it's a pity I can't do these things on my 9950. Oh well... I can get around it by using a temporary list. Perhaps File6:List 2 would be suitable for this. File6 is getting crowded .
I was namely thinking about making a routine GLADDE (GL add edge (or in swedish: gladde=rejoiced )).
So that you could add edges in the same way as adding vertices with GLADDV:

Prog "GLADDV":-1->Mat X[1,@]:-1->Mat[2,@]
Prog "GLADDV":+1->Mat X[1,@]:-1->Mat [2,@]
Prog "GLADDV":+1->Mat X[1,@]:+1->Mat [2,@]
Prog "GLADDV":-1->Mat X[1,@]:+1->Mat [2,@]
Prog "GLADDV":2->Mat X[3,@]
Prog "GLADDE":1->List 3[@]
Prog "GLADDE":2->List 3[@]
Prog "GLADDE":3->List 3[@]
Prog "GLADDE":4->List 3[@]
Prog "GLADDE":1->List 3[@]
Prog "GLADDE"
Prog "GLADDE":1->List 3[@]
Prog "GLADDE":5->List 3[@]
Prog "GLADDE":3->List 3[@]
Prog "GLADDE":
Prog "GLADDE":2->List 3[@]
Prog "GLADDE":5->List 3[@]
Prog "GLADDE":4->List 3[@]

For a pyramid for instance.

Not entirely necessary.. but might be useful for prototyping work. It makes it easier to modify the geometry as you're working with it. You can, of course achieve the same thing by the usual more compact form:

5->@:Prog "GLINITV"
-1->Mat X[1,1]:-1->Mat[2,1]
+1->Mat X[1,2]:-1->Mat [2,2]
+1->Mat X[1,3]:+1->Mat [2,3]
-1->Mat X[1,4]:+1->Mat [2,4]
2->Mat X[3,5]
File6
{1,2,3,4,1,0,1,5,3,0,2,5,4}->List 3

What'ya think? Is perhaps GLADDE totally unessecary? Perhaps I should deprecate GLADDV as well?



Btw, should I make a tutorial on how to make a scene editor (for rendering boxes of different shapes with bottom face at z=0)? What dya think?
It works well together with the FPS engine I made a tutorial for, only the SPF-rate is increadibly high, in particular when using GLLINE.

Would be nice with selective rendering... i.e. a renderer that detects if an object has vertices both inside and outside the screen and in that case uses GLLINE, otherwise uses GLSTRIP. But I'm not sure there would be much gain from such a funciton. After all, you have to analyse the vertices for each object before deciding which rendering method should be used. As it is now, at the one hand GLLINE is extrememely slow but it takes care of edges that are partially outside the viewing volume, on the other hand GLSTRIP culls away all lines that are partially outside the viewing volume, but it is much much faster. So a hybrid between these two would be excellent. But this feels like the task for an API at a higher level (perhaps something like FX-DK (dev-kit)). Just ideas...

[Scratty]

I've made a GLADDE implementation for my 9950 which uses a temporary list and is thus very slow.
The neat thing with these tools is that since FX-GL is an API, the usage is consistent for all models that have an implementation of FX-GL.
You could do stuff like:

For 1->I To N
Prog "GLADDV"
...->Mat X[1,@]
...
Next
For 1->I To M
Prog "GLADDE"
...->List 3[@]
...
Next
etc...

and the program could be used on any FX machine that has an FX-GL back-end for it.
Therefore, you can make a 3D game which in theory is cross-platform. For instance, a doom game which works for 9850/9950 and 9860 and other models in the future.

So if there's enough with people out there who are interested in this project, they can contribute by porting FX-GL to their models, just like LordNPS has done. Why not a port for MLC too? (ok that might be tricky since I suppose MLC is fundamentally different from Casio Basic).

[LordNPS]

Is there any chance of me seeing an implementation that allows me 2 fps with edges?
Else... I don't think there's point in GLADDE...

It has been a long time since I last posted...

[Scratty]

Hi LordNPS and all you other guys!
I've been on a vacation if you wonder why I've wandered away from the forum.

A 2 fps framerate aye? Hmm.. don't think you can achieve that even with a single line if you're doing transformations with it during each iteration. Recall that 2 fps = 0.5 secs per frame. Using the Casio basic language and considering the clock frequency, you won't achieve faster frame rates than 1 fps. It would be more suitable to talk about the inverse frame rate, i.e. seconds per frame (spf), or frame period. For moderately complex objects, you would typically achieve frame cycles in the order of 4-8 spf (expect smaller frame cycles if you don't do any transformations or calls to GLLOOKAT).

Now about GLADDE. The use of this function is to build models/objects with it. It doesn't have any particular effect on rendering speeds. You call a number of GLADDE at the startup of your application.

Some news about GLADDE: Under my vacation, I couldn't resist bringing along something to program on and since I don't have a laptop, I brought my calculator. This means I've implemented a back-end to GLADDE for my 9950 using a temporary list. I will take a closer look att the methods presented by caspro in order to find some ways to use the memory more efficiently. The syntax goes like this:

1->@:Prog "GLINITE"	'@=number of edge elements to start with
2->List 3[1]
1->X:Prog "GLADDE"
3->X:Prog "GLADDE"
2->X:Prog "GLADDE"
...

General FX-GL news: I've also made some fundamental changes to a lot of stuff (so I'm a bit unsure as to whether I'm gonna change the minor or major version number for this release).

• The primitives are more user friendly (stores edge-list to File6:List 3 right away).
• GLTEAPOT have a smaller file size but geometry remain unchanged.
• GLSPHERE and GLTORUS have complete wireframes (have slightly larger file sizes though, but framerates are only a tad slower, so you won't notice much difference in performance). All edges in GLSPHERE are unique! This means that the organization of edges for the sphere is at its absolute optimum. GLTORUS has unfortunately a few edge overlaps which seems to be inevitable.
• Added GLPYRAMID and GLTETRA.
• In overall, syntax is more consistent and user friendly.
• GLADDV uses X,Y,Z, as input arguments which makes it more compact and easier to use. The syntax is similar to that of the edge-functions:
  

  1->@:Prog "GLINITV"	'@=number of vertices to start with
  1->Mat X[1,1]:-1->Mat X[2,1]:2.5->Mat X[3,1]
  1->X:3->Y:2.5->Z:Prog "GLADDV"
  2->X:3->Y:5->Z:Prog "GLADDV"
  ...

• I've made a GLINITE for initializing the edge-list (not very useful, but it makes it all much more consistent).
• Added GLINITT for initializing triangle strips and triangle fans, and GLADDTS for adding triangle strip vertices and GLADDTF for adding triangle fan vertices (just like you can in OpenGL).
• GLSTRIP is slightly faster than previously.
• Added GLCPYOBJ and GLCATOBJ for concatenating objects, i.e. joining objects in the same Mat X (vertex list) and List 3 (edge list) (keep in mind that the edge-list is limited to 254 edges).
• Added GLGENGLP for generating 3D font glyphs, and GLGENTXT for creating 3D texts using GLGENGLP (this means many layers of abstraction: your application -> GLGENTXT -> GLGENGLP -> GLADDTS -> GLADDV & GLADDE -> Mat X, List 3).
• Updated examples and added new ones.

About those fonts. Both GLGENGLP and GLGENTXT uses File5 (List 5 and List 6) because there's not enough room in File6 to work with and at the same time have a constistent and streamlined API.
To generate 3D text with these functions is quite simple:

File5
{26,42,41,75,25}->List 5
Prog "GLGENTXT"

Then point your camera towards the centre of the text (each font is 0.7 wide (0.5x0.8 with 0.2 space)) from the positive z-axis and set the up-vector to (0,1,0). Then render using GLPRJMAP, GLINITL and GLSTRIP... or put it into SHAPEDMO to view the text from different angles. Voila!
The character codes used are the same as the key codes (with exceptions for digits and special characters).

P.S.
I think that it would probably be a good idea to put GLLOOKAT, GLGENGLP, GLGENTXT and the primitives into a separate cat-file called FX-GLU or something as these are just utilities. It can be discussed which other functions that fit into FX-GLU but it would seem most appropriate to keep OpenGL counterparts to the FX-GL library, GLU and GLUT counterparts to the FX-GLU library and examples in its own library. Lemme know what you think.
D.S.

[Scratty]

I know I'm monologuing now, but I thought it would be interresting for you to know how to achieve the different drawing modes in OpenGL with FX-GL. I'm refering to the parameter to glBegin(). Here's the list of the parameteres and their counterparts in FX-GL:
http://rasmus.anthin...awing_modes.txt

[LordNPS]

vacations, right, got to get me some of that Was suposed to go camping into Peneda Gerez National Reserve here in Portugal, but the whole country is on fire... peneda-gerez included

I think it is possible to achive 2 fps standard.
With the 9860 the 3d rotating cube does something like 3 to 4 FPS

What kind of a geek are you? no one takes his calculator on vacations (Well i did last time bu just in case I was bored...)

So, seams to me that we have a bunch of new features to the FX-GL, that's great, really looking forward the GLSTRIPT, If it can add some speed to things...

That list of drawing modes might come handy make sure to include it within the documentation

[Scratty]

Oh. Sorry to hear that . This summer has been really terrible. At least we got some rain now up here.

Oh! Ok. Guess your calc's got a faster professor than mine. The cube thingy is slower on mine: 2.93 spf (or 0.34 fps). The old version of CUBETST2 (which used 16 vertices) did 3.27 spf, so it is quite an improvement in performance. The hybrid rendered CUBETST1 (which is deprecated now) did 2.87 spf, but this rendering method was too ad hoc to be feasible in general applications. So to summarize, the cube does about 0.3 fps on mine, but does 3 fps or more on yours (and probably even faster after I've released the new version). That's more than 10 times faster! WOW!

Well. I normally don't bring my calc along, but I'm a programming addict. Oh well, I only worked with it in order to fall asleep. I have to read or work with something in order to get drowsy and fall asleep or else I would wrap around the day (not good when you're on vacation). But I'm suppose you're right. I'm quite a geek :/. I should probably get a life.

Oh.. don't confuse the rendering methods GLSTRIP and GLFSTRIP with the triangle strip/fan generating functions GLINITT, GLADDTS and GLADDTF.
I should probably have chosen another name for GLSTRIP, like GLRENDER, but GLRENDER is reserved for a more general purpose renderer that will probably be available in the future . Perhaps GLDRAW would be better.. hmm.
Anyways.. the triangle strip and triangle fan routines doesn't speed things up in particular, they only makes it easier to input geometry. If I would have implemented quad strips that would be faster than triangle strips, given that the triangles in the strip form quads (of course). The only things that would increase speed (besides properly generated geometry) is optimizations in GLPRJMAP and GLSTRIP, and of course all other routines that are called in the main loop.

About that doc... yes, I'll include that in the package.


EDIT:

Btw... if I make a thorough description of all the routines in the library. Would any of you MLC guys be interrested in porting FX-GL to MLC? Would be really nice to see some FPS games (Dome, Descent, etc...) for calculators in the future, and I think that a FX-GL back-end in MLC would make that feasible.

[LordNPS]

About the speed I chronometred it and it's like 40 frames 11 seconds, so it is not full 4 fps but is more than 3fps.

Guess your calc's got a faster professor than mine

When is the new release coming out anyway? By your posts it seams to have changed quite dramaticly.

I just wich there was a way for me to have MLC in my calc , BASIC sucks so god damn much ...
Hopefully someone might reverse assemble the 9860 some day .
There is so much that could be done if we could use just a little more of the calcs potetencial.
=~ 4 fps is not bad, however we're talking about a cube here... not even a maze game. Well I guess I should dedify my efforts more into 3D Graphing rather than 3D gaming of sorts.
I was thinking in making a go for it, at the Graph 85 contest, is there a problem in using your FX-GL?

[Scratty]

Hi Lord!
4fps is indeed good even though it's a cube. Say you have a cube forest consisting of 20 blocks, you would roughly get 4/20 = 0.2 fps. I.e. 5 seconds per frame. That's pretty slow, but my mario game was almost that slow and it was playable. It all depends on how much patience the gamer has . Still, a block-forest of 10 would probably work well. I have an FPS engine with scene editor (List 1~List 3 in File5 determines the top vertices of each block) and you can switch between the interpolated mode and the fast rendering mode. It would be fun to see how fast GLLINE runs on your machine. I'll post a tutorial on the scene editor thingy along with the library package and include the complete code of the FPS engine for you to play with.

Yes, indeed the API has changed quite a bit since the last update. I've done some further optimizations and added some more userfriendliness and consistency since yesterday.
Now you can write:

1->X:3->Y:2->Z:0->@:Prog "GLINITV"
4->Y:Prog "GLADDV"

which will create two vertices (1,3,2) and (1,4,2). @ = 0 is the same as @ = 1 in that it produces only one vertex, but the difference is that @ > 0 makes all vertices initialized to zeros whereas @ = 0 sets the single vertex to (X,Y,Z). The same goes for GLINITE. See the OpenGL/FX-GL comparison documentation in an older post.

Before I can post an update I need to complete the GLGENGLP function which means adding the remaining fonts. I'm using a variation on and subset of ASCII, where the letters correspond to the key codes and digits remain the same (0 -> 0, 1 -> 1, ...), Only I'm not sure which fonts I should implement. Each font doesn't take up much space, but altogether it adds up.
Furthermore, I'm considering whether I'm gonna make a GLADDQS. Hmm...
Lastly, I need to update the complete documentation and stuff the new code in the cat-files and that takes quite some time.

Concerning whether you're allowed to use an API in a competition is hard for me to say. You should ask the judge instead. For me it's just fine, as long as you don't claim the library to be your own .

[Scratty]

FYI, there's a new and more optimal memory layout:
File6
List 2 : GLGENTXT retrieves string characters from this list.
List 3 : Swap space used by GLCPYOBJ & GLCATOBJ.
List 4 : X-data (as before).
List 5 : Y-data (as before).
List 6 : Edge data.

So instead of File6:List 3, use File6:List 6 for edge data from now on.

Furthermore, as previously mentioned, I'm developing a character encoding table:

0 : 0
1 : 1
2 : 2
3 : 3
4 : 4
5 : 5
6 : 6
7 : 7
8 : 8
9 : 9
10 : !
11 : "
12 : #
16 : '
17 : (
18 : )
19 : *
20 : +
21 : ,
22 : -
23 : .
24 : /
27 : :
28 : <
29 : =
30 : >

67 : r
57 : theta
76 : A
66 : B
56 : C
46 : D
36 : E
26 : F
75 : G
65 : H
55 : I
45 : J
35 : K
25 : L
74 : M
64 : N
54 : O
73 : P
63 : Q
53 : R
43 : S
33 : T
72 : U
62 : V
52 : W
42 : X
32 : Y
71 : Z
61 : space
41 : (-)
31 : nl + cr

80 : ?
82 : [
84 : ]
85 : ^
88 : {
90 : }
91 : ~

The 3D fonts are 5x7 (fixed size). They are 0.4 units wide, 0.6 units high and 0.1 units deep (I know it sounds contradictory, but the reason this is so is that each strip length unit corresponds to a pixel, would it have been a bitmapped font). GLGENTXT adds an extra 0.2 unit space for each glyph (making the text string 0.6N-0.2 wide).
Let me know if there's an existing econding table for FX calcs that is better than this one.


EDIT:

Regarding GLGENGLP = GL generate glyph (which is now part of FX-GLUT = FX-GL Utility Toolkit). This function now uses complex numbers instead of a list to store glyph font coordinates. For instance, the letter A has the geometry D=11355915+16761944i where 9 means line skip. This number is then parsed by the formula 10Frac (Int ((Rep D)/10^F)/10) for X-data and ...Img D... for Y-data, where F is the current vertex number (0..N-1). When the function returns 0, this means the end of the geometry data. Problem is that you can only have up to 9 vertices in a glyph (8 lines). But using an additional complex number, this doubles the amount. Glyphs # and : both take up 11 vertices (I could keep it down to 9 for : using triangular shaped dots though). Anyhow, this representation is IMHO the most compact I can achieve and keeps the program size at a minimum. Adding new glyphs is easy and take up very little additional space. The total program size is about 1634 bytes large with all glyphs listed above. Now I will Reorganize functions a bit and revise the whole documentation, put it in cat-files, make some additional tutors and realease the whole thing as FX-GL 2.0. Stay posted!

EDIT:

Character encoding table updated as of 19/8.

[Scratty]

Ok. Some little update on how the project is going:

I've reorganized the functions into three separate libraries of which the two first are API:s and the third is example files. Here's a summary:
FX-GL FX Graphics Library (2640 bytes)

• Initialization: (80 bytes)
  • GLINIT
• Geometric Operations: (589 bytes)
  • GLINITV
  • GLADDV
  • GLINITE
  • GLADDE
  • GLINITT
  • GLADDTS
  • GLADDTF
• Transformations: (297 bytes)
  • GLSCALE
  • GLROTATE
  • GLTRANSL
• View, Projection and Mapping: (794 bytes)
  • GLORTHO
  • GLPERSP
  • GLLOOKAT
  • GLPRJMAP
• Rendering: (880 bytes)
  • GLINITP
  • GLINITL
  • GLLINE
  • GLDRAW
  • GLFDRAW

FX-GLUT FX Graphics Library Utility Toolkit (4246 bytes)

• Geometric Primitives: (2094 bytes)
  • GLCUBE
  • GLCYLNDR
  • GLCONE
  • GLSPHERE
  • GLTORUS
  • GLTEAPOT
  • GLAXES
  • GLPYRAM
  • GLTETRA
• Geometric Operations: (411 bytes)
  • GLCPYOBJ
  • GLCATOBJ
  • GLE2V
• Font Rendering: (1741 bytes)
  • GLGENGLP
  • GLGENTXT

FX-GL_EX FX Graphics Library Examples (4641 bytes)

• CUBETST2
• STRPTEST
• SHAPEDMO
• TRITEST1
• TRITEST2
• CATTEST
• 3DTEXT
• TESTMODE
• GEOM
• 3DGRAPH

--------
total = 11527 bytes


Now I will practically have to rewrite the whole documentation... *sigh*.

P.S. Naturally, I won't write all this in the description for this package in the file sharing.


EDIT:

Ok... I'm monologuing.. again . Just wanted to say that implementing GL_QUAD_STRIP was trickier than I though so I postpone that for now. I got a cool idea just a few minutes ago: Why not implement display lists. I was thinking of using File6:List 1 for this. I could also keep future state variables in this list too. The following protocol for List 1 appeared in my mind: File6:List 1: [ ] Call lists from File1 [ ] Call lists from File2 [ ] ... future state vars, if any. For instance if we want to display the following lists: File1:List 2, File1:List 3, File1:List 4, File2:List 5, File2:List6, File2:List 1, File2:List 2 in that particular order, then the display list would look like: File6:{234, 5612} Associated vertices would be Mat A~Mat F for File1 and Mat G~Mat L for File2. Only thing I'm worried about is that it might take some time to encode the display list entries and that it will consume some more register vars. Any thoughts on this (judging by the lack of communication in this thread, I guess there won't be)?

EDIT:

Updated the size figures in the lists above as of 20/8.

[Scratty]

Ok. I think FX-GL 2.0 is about done now, at least as far as documentation concerns.
Here it is:
http://rasmus.anthin...m/eng/fx-gl.txt
and here's an update on the drawing modes tutorial:
http://rasmus.anthin...awing_modes.txt
Now, I have the documentation for FX-GLUT 1.0 and the examples/tutors left to do.
Stay tuned!

[LordNPS]

EDIT:

Ok... I'm monologuing.. again sad.gif.

Just wanted to say that implementing GL_QUAD_STRIP was trickier than I though so I postpone that for now.
I got a cool idea just a few minutes ago: Why not implement display lists. I was thinking of using File6:List 1 for this. I could also keep future state variables in this list too. The following protocol for List 1 appeared in my mind:
CODE

File6:List 1:
[ ] Call lists from File1
[ ] Call lists from File2
[ ] ... future state vars, if any.

For instance if we want to display the following lists:
File1:List 2, File1:List 3, File1:List 4, File2:List 5, File2:List6, File2:List 1, File2:List 2
in that particular order, then the display list would look like:
File6:{234, 5612}
Associated vertices would be Mat A~Mat F for File1 and Mat G~Mat L for File2.

Only thing I'm worried about is that it might take some time to encode the display list entries and that it will consume some more register vars.
Any thoughts on this (judging by the lack of communication in this thread, I guess there won't be)?

What? I don't really get what does it do...
Sorry for the lack of discussion, thing is, there's very little to discuss...i read something you post and just think ohh... sounds good.

I just hope this release gets off pretty soon, there's no point in starting to program for the jeux casio until I get the package...

Want me to get the fx-gl text into g1r?
perhaps cat too?
If you want I can contribute with something for the examples... perhaps a fully fleged 3D grapher?
I am trying to create a technology that allow me to draw grids, with a single sweep, I mean like those games where you have to draw a figure without ever lifting your pencil or drawing in top of an already drawn line.
Optimizing the process of draw.
Optimizing the process of projecting the maps and that kind of stuff, I am working in an instance trick to speed things up. Actually I believe I am going to get a 3D grapher that spins things in live time:)

Of course there is no generic way of doing this (that I know of) nonetheless I am going to ask a friend of mine, which is actually a brain in this kind of things... he is going to the IOI2006 (International Olympiad in Informatics) in mexico, representing portugal... that should mean something.

[Scratty]

What? I don't really get what does it do...
Sorry for the lack of discussion, thing is, there's very little to discuss...i read something you post and just think ohh... sounds good.

Oh, I'm terribly sorry. This often happens when I get carried away.
Good thing you think it sounds good anyways.. even though it seems you are one of the very few that actually have any use of this API .

Display lists in OpenGL is primarily a way of compacting geometry to make transfer times to the graphics card smaller. But it is also a way of grouping static geometry into identification tags which can be easily referred to in the rendering loop. Since intrinsically, FX-GL only works with one vertex matrix and one edge list, using display lists would open up the possibility to utilize all other lists and matrices for a quick and easy way of storing geometry and calling geometry from other matrices/lists during rendering.

I just hope this release gets off pretty soon, there's no point in starting to program for the jeux casio until I get the package...

Oh, sorry, I wasn't aware that it was that urgent. I've been in the middle of negotiating for a salary and all I've been thinking about these last two days is money .

Want me to get the fx-gl text into g1r?

Yes, that would be a blast!

perhaps cat too?

Well, probably not. I will update the cat as soon as I'm finished with all of the documentation work.
I can't make any promises, but I attempt to have both FX-GL and FX-GLUT ready by the end of the weekend.

Trying to make all documentation as consistent as possible is quite hard, especially explaining in detail what each function can do on a level that hopefully most people can understand.
Should you find anything you feel is unclear with the doc, then please let me know right away and I'll try to clarify.

If you want I can contribute with something for the examples... perhaps a fully fleged 3D grapher?

Well, actually, I have a more advanced 3D grapher that is based on the one posted in this thread. Actually the only added feature is the possibility to make X-lines, Y-lines or a grid. Perhaps you had something more advanced in mind. Well I normally don't include other peoples programs in my own releases, but I'm willing to do an exception if the API:s are gained by it.

I am trying to create a technology that allow me to draw grids, with a single sweep, I mean like those games where you have to draw a figure without ever lifting your pencil or drawing in top of an already drawn line.

I see you have great ambitions. That is very good.
About grids, there's those horizontal and vertical commands you might find useful for that.
Hmm.. not quite sure what you mean by the lifting pencil stuff. But something that I've been thinking on during quite some time now is something that is related to graphical imput, namely an arcball function and a unprojection function. An arcball is a way of rotating things around in the world or rotating the camera, it shouldn't be that hard. Unprojection is nice since it allows picking objects with the cursor or programatically. Just some thoughts. I should be careful with making the API:s too large, after all, there are still people that only have 32 kB available.

Optimizing the process of draw.

Hmm.. sure, if you find a way to make it even faster without trading for functionality, I'm all ears and I'll incorporate it into the API.

Optimizing the process of projecting the maps and that kind of stuff, I am working in an instance trick to speed things up. Actually I believe I am going to get a 3D grapher that spins things in live time:)

Hehe... mapping, not maps . Optimizing these functions are not impossible (nothing is impossible, they can only be very unlikely at most ) but is probably quite hard since I think much of the time spent in GLPRJMAP is in matrix multiplications. However, you might be able to speed up a bit more if you remove the test for whether depth scaling is performed or not.
If you remove this test, GLLINE will run faster alright, but GLFLINE will most certainly run slower (assuming the test operation is cheaper than the multiplication operation).

I wish you good luck on making a real-time 3D-grapher (you'll need it ). I cross my fingers for you.

Of course there is no generic way of doing this (that I know of) nonetheless I am going to ask a friend of mine, which is actually a brain in this kind of things... he is going to the IOI2006 (International Olympiad in Informatics) in mexico, representing portugal... that should mean something.

Oh. Now that would be something to put in your resume, wouldn't it?

[LordNPS]

Well I've been thinking about money pretty much myself this last few days... I am saving for a trip to north dakota USA...
It has the most relaxed driving licensing laws ever... you can aply for a drivers license at the age of 14, and the requirements for it are way down that EU's... so, I was thinking about having myself a driver's license at the age of 16 which is a killer thing... then you can request an ILP from the EU, and then finaly one to portugal... it is a costfull process however is the only way for you to drive a car in Portugal without being 18 or older...

now, about things... I will make th g1r then...

That thing abou t drawing a figure without lifting your pencil, is a comparasion with the fact that draw stat uses connected points so, for optimizing the process of draw, you must have a way to draw the entire grid, in a single pair of lists ( X and Y)... optimising the process of draw...
Non Optimized process I am using:

#Vertical strips
For x=1 to Xresolution
####vertical Strips X and Y values
-------For y=1 to Yresolution
--------------List 5[y]=Mat Y[1,((x-1)*Xresolution)+y]
--------------List 6[y]=Mat Y[2,((x-1)*Xresolution)+y]
-------Next
DrawStat
Next
#Horizontal Strips
For x=1 to Xresolution
####Horizontal Strips X and Y values
-------For y=1 to Yresolution
--------------List 5[y]=Mat Y[1,((y-1)*Yresolution)+x]
--------------List 6[y]=Mat Y[2,((y-1)*Yresolution)+x]
-------Next
DrawStat
Next

In the procedure above, my calculator does something like 3.5spf for an 8*8 grid.
So I am trying to Improve it... however there are numbers of complications...

And about the 3D grapher I just want to do something simple yet powerfull, not something like 3D graphers from neuronix, wich are more developed in the menus that in the graphing itself (no offense)
Something like the 2D Grapher from casio...
Only with the expressions.. the limits, resolution, and viewing coordinates...
Yet I was expectng to do it through menus...

And there is another thing for optimizing the process of rotating around the graphed surface... its using the 2D graph, more precisly the 20 slots of the 2D grapher... if things work out as I expect it would allow 10*10 projections live time, as well as rotation
As I said it is all under investigation.

Looking forward for the release...

[Scratty]

Making grids can easily be done using for-loops with the horizontal/vertical commands since I reckon these are pretty fast (they don't need to rasterize using the Bresenham algorithm, for instance). If you want to render the grid in 3D, i.e. rotate the grid and stuff like that, then my advice will, naturally, not work.

Keep in mind that you can lift the pen using DrawStat, just set an x-element that is outside the window range (this will force the beginning of a new line strip), this is exactly what GLDRAW does. Only drawback is that you get two extra elements that makes the edge list larger than if you'd done it in a sequence. The edge list {1,2,0,2,3} for instance, is of course larger than {1,2,3} which renders the same thing.

Sure, a 3D-grapher with menus would be pretty advanced and sounds pretty cool actually .
I thought it unlikely to do it faster than it already is, but given your algorithm sketch I may revise my thought on that matter. It seems like a very interresting workaround you have there. I hope it'll work. I still doubt it somehow, but I encourage you to keep on investigating.

One completely different thing I've been thinking about recently is sprites, I've heard people have used some sprite-like technique for their casio-games, and a way of standardizing that would be really good.

Now about FX-GLUT, I'm working on it at this very instant and if you're cracking up of curiosity you can find a work copy here:
http://rasmus.anthin...eng/fx-glut.txt
The programs are done but I've only started with the documentation.

Now I wish I hadn't sold my 9700 calculator. It would've been soo cool to make a back-end to FX-GL for 1:st generation calcs.

[LordNPS]

Keep in mind that you can lift the pen using DrawStat, just set an x-element that is outside the window range (this will force the beginning of a new line strip), this is exactly what GLDRAW does. Only drawback is that you get two extra elements that makes the edge list larger than if you'd done it in a sequence. The edge list {1,2,0,2,3} for instance, is of course larger than {1,2,3} which renders the same thing.

I had no Idea that happened (blessed be my ignorance)
:
Actually I thought Drawstat was such a great method because I thought that didn't happen.... well that opens some doors...(double bless)

[Scratty]

Yeah... I was thinking a lot about how to break up lines in Stats mode drawing. One day I just got a nirvana and voila, it worked as a charm. To tell the truth, I'm a teeny weeny bit proud for the hack .

Check the documentation for GLINITE and GLADDE. It says all about it.

[LordNPS]

It's done scratty
The g1r is ready... when you wish I will update the Fx-GL2

[Scratty]

Good!
What I have in mind is to put both FX-GL and FX-GLUT in the same distribution.
Since I'm still working with the docu for FX-GLUT, some tiny changes might occur to the code, so if you wan't to do the FX-GLUT as well, I would urge you to w8 until that txt-file is done.
I think the best way is if you send me the g1r files as you go along and I'll upload a rar file together with the accompanying (condensed) documention miself.

[LordNPS]

Ok then... sujest a amethod and I'll send the g1r to you...

[LordNPS]

My 3D grapher is now on 3 spf... and descending
The actual draw process is totaly instantaneus upt to 8*8 (wich is the resolution I am aiming for). it just apears drawn.
Now the main problem is with calculations....
There is an excess of "for"'s, that slow things down, it's a shame I can't use Mat->list in this however I think Seq( might do the trick

[Scratty]

Hmm... but you know, GLFDRAW uses just that, I mean, Mat->List(.

[LordNPS]

No I can't use that: The horizontal strips are not sequencial, you have to use Yresolution jumps to get to the right vertex...

edit:
Another thing.... is there any way of maging errors?
You see, when expression given by the user returns impossible results (like z=x/y, and one of the points is x=1 and y=0 so Z=1/0 which is mathematicly impossible), so the program breaks... which is not very nice...
Any way to dodge this problem? like...

Something

[Scratty]

No I can't use that: The horizontal strips are not sequencial, you have to use Yresolution jumps to get to the right vertex...

Ah, I see.

edit:
Another thing.... is there any way of maging errors?
---8<--- snip ---8<---

You mean raise an exception? Yes, that is possible. Actually, the basic language is quite fit for this task. Exceptions is more or less a branch to a place in the code where a catch statement is located. For instance, in a high level language such as java, an exception branches (jumps) to where a catch statement can be found (at least that's what I'm told, and it makes sense too).

Say you wish to try a division statement for division with zero. This would in C++ (or Java) look something like this:

Vector v(1,2,3);  //create a vector object.
float d;	  //initialize divisor
cin >> d;  //input divisor value from terminal
try {
  v /= d;   //divide vector with divisor
}
float s = v*v;
return s;
...
...
catch (overflow_error) {
  v = Vector(0,0,0);
  cerr << "Cannot divide vector with zero!" << endl;
}
...
...
//The /= operator in the try-statement above
const Vector& Vector :: operator/= (float d) throw(overflow_error) {
  if (!d) throw overflow_error("Vector::operator/=");
  float a = 1.0f/d;
  x *= a;
  y *= a;
  z *= a;
  return *this;
}

Now I haven't used try-catch statements for a while, so the above might have faults. Bascially, what the code snippet does is to try the division statement and perform it if it allows for division with zero, else it will throw an exception, print the exception string, jump to where the closest catch statement occurs that matches the exception type overflow_error set the vector to zero and print an error message, then it'll go back to wherever the program was executing, i.e. right after the try-statement.

In Basic, you would do this the following way:

1->A:2->B:3->C
?->D
'TRY START
  8->T:'THROW FLAG WHICH TELLS CATCH WHERE TO GO BACK
  Prog "DIVIDE"
  T=>Goto C
  Lbl 8
'TRY END
Prog "DOTPROD"
Return
...
...
'CATCH START
  Lbl C
	0->A~C
	"CANNOT DIVIDE VECTOR WITH ZERO!"
  T=1=>Goto 1:'GO BACK TO THE CORRECT THROWER
  ...
  T=8=>Goto 8
'CATCH END
...
...
program DIVIDE:
If D<>0:'CHECK IF DIVISOR IS OK
Then 0->T:'CLEAR THE THROW FLAG
A/D->A
B/D->B
C/D->C
Else "VECTOR->DIVIDE":'OUR THROW MESSAGE
IfEnd

There are - of course - a number of ways to simplify all this. I just wanted to make the examples as equal as possible so that you can compare the high level (C++) code with the low level (Basic) counterpart.

A slightly simpler way to raise a (single) division exception would be:

?->D
'TRY START
Not D=>Goto C
A/D->A
B/D->B
C/D->C
Lbl 9
'TRY END
...
'CATCH START
Lbl C
(Resolve the exception here, display error etc...)
Goto 9
'CATCH END

Or... you could simply just make an If-statement to test for the case when the divisor is zero. If it is, then print something out, or pretend nothing happens, else divide as usual. However, this is not exception handling in its actual sense. Exception handling is when you can pick up errors somewhere else in a program and resolve all errors of one kind on one place (if you want), which makes things more structured and the code more readable, at least in high level languages .


Hope you get the idea.
One could say that exception handling is spaghetti code on a high level .



EDIT:

I made the first example more comprehensive and general.

[Scratty]

Ok, I think the documentation for FX-GLUT is about done now.
Moving on with the examples...


EDIT:

Ok, now I've written down the examples. Just have to type some words about them too.

EDIT:

Ok then... sujest a amethod and I'll send the g1r to you... You can email it/them to me. Use my email from the docus.

EDIT:

The examples are completed. Think I'll skip the scene editor tutor (I think the WALK program is pretty self explanatory). Moving on with cat-making (cats are nice ).

EDIT:

Oh. The view count is on 666. Hope this isn't some kind of omen

[LordNPS]

Oh. The view count is on 666. Hope this isn't some kind of omen unsure.gif

That's evil I am frightned now


now, I'll e-mail it to you along with Fx-Glut

And about the exception, I don't just mean divide by 0, any other kind of problem is aplyied, if the answer is not numerical, the program should not display the vertex... or something...

Facing terrible problems now...with my Live3D app

I've talked to that fella, the programming expert and he also happens to own a casio Fx1 , however is has neither time or patience for it, however he did help me realize a few concepts, and optimizing some of the code (I can post what I have so far if anyone cares) it is now benchmarking the fllowing :
For a 7*7 divisions net:
The overall calculation process ( (x,y)matrix ,z-values, Ortho etc.) is on 6.3 s then the program takes 1.3 to project from a given camera position, and then create the grid lists.) then the drawing part which is instantaneous.
For rotating, 1.4 seconds overall speed with the method I am using so far (which still use a rather large portion of "for"s) it's nearly live time ...

I fell however that I should swap back to my older drawing method (which uses even more "for"s) it is slower yet you get to see the program drawing the net which is kind of nice.
So the question is do you prefer to wait 3 s for a frame and watching it being drawn in live time, or instead you would rather stare at a blank screen for 1.4 seconds and then see the image projected?

Yet, there are further optimizations that I am working right now

You should buy a 9860 scratty.
CFX kind of sucks in performance

[Scratty]

Now I'm quoting the last message again... sorry admins.

That's evil I am frightned now

mohahaha

And about the exception, I don't just mean divide by 0, any other kind of problem is aplyied, if the answer is not numerical, the program should not display the vertex... or something...

Now, I'm not sure what you meant by "not displaying the vertex or something", but
yes... look at the code above and you'll see that you can raise virtually any kind of exception. Division with zero was just an example (which actually you brought up ).

If you don't want to display any error messages when an exception is raised, then that's fine. Just don't do anything in the catch block. The catch block should only do stuff that you want the program to perform when something bad happens. You could just write a message like "ER, I PRETEND THAT DIDNT HAPPEN.", or you could rethrow an exception, making another catch block catch the exception and do something else if you wish. You're more or less limited by your imagination.

If you want to keep things simple - as I gather you do - you might want to just make an If-statement like this:

If <condition for doing the following stuff is fulfilled>
Then <do the stuff>
Else <do nothing>
IfEnd

It all depends on how complex your program is, how structured you want it to be, how fast you want it to run and how small you want the file size to be. There's a handful of trade-offs to consider.

Facing terrible problems now...with my Live3D app

I've talked to that fella, the programming expert and he also happens to own a casio Fx1 , however is has neither time or patience for it, however he did help me realize a few concepts, and optimizing some of the code (I can post what I have so far if anyone cares) it is now benchmarking the fllowing :
For a 7*7 divisions net:
The overall calculation process ( (x,y)matrix ,z-values, Ortho etc.) is on 6.3 s then the program takes 1.3 to project from a given camera position, and then create the grid lists.) then the drawing part which is instantaneous.
For rotating, 1.4 seconds overall speed with the method I am using so far (which still use a rather large portion of "for"s) it's nearly live time ...

I fell however that I should swap back to my older drawing method (which uses even more "for"s) it is slower yet you get to see the program drawing the net which is kind of nice.
So the question is do you prefer to wait 3 s for a frame and watching it being drawn in live time, or instead you would rather stare at a blank screen for 1.4 seconds and then see the image projected?

Yet, there are further optimizations that I am working right now

Oh. Seems you've don'e some progress after all. I mean, rendering a function surface in realtime, wow!
Either be it 3 spf or 1.4 spf, that's still incredibly fast for this kind of application. I'm amazed!
That'd be 30 or 14 spf on my own calculator, very roughly speaking.
I would say, go for the latter technique if it allows a higher framerate.

You should buy a 9860 scratty.
CFX kind of sucks in performance

Hehe... yes perhaps I should. But I guess I'm growing a bit too old for this kind of programming. On the level I'm on, it is only Matlab, C and Fortran that does the job for me. A Casio calculator - be it 9860 or not - isn't particularly fit for running simulations of advanced physical models and stuff like that. However, it would be very interresting to see how FX-GL performs on a 9860.

On the other hand, high performace hardware wouldn't give me the same kicks out of it as less advanced hardware does. I mean, making a pong game for a PC ins't particularly rewarding, whereas succeeding in making a pong game for your bike computer would give you some real psychosis issues afterwards .
Actually this is the foremost reason I'm doing this kind of programming. I'm a real Casio crackpot, haha.

A secondary goal is of course to make graphics programming as available as possible to youngsters in order to nurture their interest in the field. If I can achieve in causing a growth in the interest of OpenGL, then I'll get a something little extra out of all this.

[Scratty]

Ok, FX-GL 2.0 & FX-GLUT 1.0 is out and available through the FS.
Here's the readme for a summary of the contents.
Now, I haven't yet received your g1r-files NPS... (note that I use the &-symbol to represent "10^" and that some minus signs need to be changed to unary ones).

Please lemme know if ya find any bugs in the cat/txt files.


Long live Casform!

[caspro]

(note that I use the &-symbol to represent "10^" and that some minus signs need to be changed to unary ones).

The & symbol ?
Casform recognises quite a few different ways of doing things, but now
I think you're trying to break it
I suppose it is shorter than typing \10^ every time though.

Maybe next version of Casform will have a user-defined option
for choosing your own symbols.

[LordNPS]

Well I've e-mailed the FX-GL2, now it's up to you to publish it

[Scratty]

Ah, great! I'll take a look.

I think you're trying to break it

Sorry... I just didn't have many standard characters left to choose from, and & was the first I found on the keyboard that looked feasible enough. On the other hand... all tokens (including weird ones) are always listed in the Symbols section of the txt-file. It is then simply a matter of replacing those characters with ctrl-H or alt-% or whatever in an editor and then put it in casform (if needed).

Perhaps user defined characters in casform would be good, but it might be even better if we could come up with some standard for single/double character representations, just like the _ token is used for the disp-command or <> is used for not equal. I know that there's already such a standard, but perhaps it should have an extension or so? (please enlighten me if I'm way out).