Board index FlightGear Support Compiling

newbe compile problem

Building FlightGear from source, and in the need for help?

newbe compile problem

Postby kuifje09 » Wed Jun 26, 2013 10:15 am

Hello, I have a little question about compiling simgear. I added a new class-member lineXTo in simgear/canvas/elements/CanvasPath.[hc]xx
Compiled it en relinked flightgear ( fgfs ) but when I start the canvas module using this function flightgear complains:

Nasal runtime error: No such member: lineXTo

What do I have to do/change to get it working. The funktion is like lineTo but instead ( float,float ) its (float[], int) .
kuifje09
 
Posts: 579
Joined: Tue May 17, 2011 8:51 pm

Re: newbe compile problem

Postby TheTom » Wed Jun 26, 2013 11:52 am

kuifje09 wrote in Wed Jun 26, 2013 10:15 am:Nasal runtime error: No such member: lineXTo

If you add a function on the C++ side you can not access it from Nasal as long as you dont register the function to the canvas nasal module. The lineTo for Nasal is currently defined in http://gitorious.org/fg/fgdata/blobs/ma ... as#line597 . C++ functions/methods can also be exposed to Nasal using nasal::Ghost from simgear (see Scripting/NasalCanvas.cxx in flightgear).

Btw. I have not forget about fgplot. Just be patient ;-)
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: newbe compile problem

Postby kuifje09 » Wed Jun 26, 2013 1:33 pm

Thanks TheTom. This did the trick.
About fgplot, I do understand it is only usable into flightgear if it is good enough and if it needs more developing I do understand.
There are sure things to do better, and there is also some debug-code to be taken out I think...

About the compile issue. It was indeed the api.nas I did not know. But then I run , you did expect it already... , into other problems.
Should it be possible to feed an array of doubles/floats from nasal to a symgear function.
I see only char as arrays, and propertynodes, never arrays of int or float... or *float or *int

I try this:
Path& Path::lineXTo(float y_abs[],float numx) but long before it enters this simgear, nasal complains:
Nasal runtime error: props.setDoubleValue() with non-number
in Nasal i call :
plot[i][y].lineXTo(pnts[i][y],99);

This makes me think pnts[i][y] is not reconized as an array of "double"
kuifje09
 
Posts: 579
Joined: Tue May 17, 2011 8:51 pm

Re: newbe compile problem

Postby TheTom » Wed Jun 26, 2013 2:35 pm

How is lineXTo defined exactly? You want to create a number of data points passed as array to a single function? What I think what would be nice for fgplot is a graph where just one datapoint at the end is added once eg. per frame, and datapoints removed from the front at the same time. By this a nice scrolling graph would be created.
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: newbe compile problem

Postby kuifje09 » Wed Jun 26, 2013 3:49 pm

Just what I was thinking too, but is it possible to remove just one point? I only know about reset().
Now I would like to a test reset a whole line, and draw a new one, at simgear level, not from nasal. However I think that is not fast enough. So just for test... Because I have not much knowledge of how all parts are working together, I run into these silly problems.
When I want to do this test I would have to create also a new nas.api routine. And then it is probably not doing good enough.

If there is a way to remove one pixel a time instead of reset() then it would be possible to have the graph running backwards. but even then, the whole line needs a redraw. Could the whole graph be scolled as one pixmap, then only 1 pixel per line is to be added, and all other pixels good be forgotten.

For the moment I would like to know how to change/add a function to api.nas , to forward an array of double to the simgear function.
If one would like to join development about this, would be fine.

The current setup of api.nas is to call I.E addSegment with a pair of coordinates , right ? I had expect nasal to call i.e. lineTo with some arguments.
So here I lose the track.
Last edited by kuifje09 on Wed Jun 26, 2013 4:13 pm, edited 1 time in total.
kuifje09
 
Posts: 579
Joined: Tue May 17, 2011 8:51 pm

Re: newbe compile problem

Postby Hooray » Wed Jun 26, 2013 4:08 pm

Before you look further into optimizations, I suggest to do some real profiling first: http://wiki.flightgear.org/Built-in_Profiler
That should give you a good idea about where the bottlenecks are.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11272
Joined: Tue Mar 25, 2008 8:40 am

Re: newbe compile problem

Postby TheTom » Thu Jun 27, 2013 9:46 am

kuifje09 wrote in Wed Jun 26, 2013 3:49 pm:Just what I was thinking too, but is it possible to remove just one point? I only know about reset().

The API does not support it directly yet, but it is possible to remove the according property nodes (always one cmd node and two coord nodes for lineTo segments). I will extend the API to support this.

kuifje09 wrote in Wed Jun 26, 2013 3:49 pm:If there is a way to remove one pixel a time instead of reset() then it would be possible to have the graph running backwards. but even then, the whole line needs a redraw. Could the whole graph be scolled as one pixmap, then only 1 pixel per line is to be added, and all other pixels good be forgotten.

If removing and adding nodes is too slow I will improve it on the implementation side. Don't worry about this, it should be fast enough.

kuifje09 wrote in Wed Jun 26, 2013 3:49 pm:The current setup of api.nas is to call I.E addSegment with a pair of coordinates , right ? I had expect nasal to call i.e. lineTo with some arguments.

Currently there is no relation between the C++ lineTo and Nasal lineTo (and other related) methods. I want to merge them in the future and provide the same API within C++ as well as Nasal, but this is currently not the case. It is always possible though, to controll the Canvas by just modifying the according properties in the property tree.
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: newbe compile problem

Postby kuifje09 » Thu Jun 27, 2013 12:32 pm

Thanks for those reactions again.

I will do a check if setting the pixels via the property is faster then via lineTo. sure it will be smother to just delete a few nodes then a whole part.
Silly I wasn't aware of this, so much to learn... Still rolling "backwards" would be a lot point to "move".
kuifje09
 
Posts: 579
Joined: Tue May 17, 2011 8:51 pm

Re: newbe compile problem

Postby TheTom » Thu Jun 27, 2013 3:24 pm

kuifje09 wrote in Thu Jun 27, 2013 12:32 pm:Still rolling "backwards" would be a lot point to "move".

Just apply a translation to the graph. That's what graphics cards are made for ;-)

Code: Select all
path.setTranslation(x,y);
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: newbe compile problem

Postby kuifje09 » Thu Jun 27, 2013 6:24 pm

path.translation ... have to look for that. But I did a simple test, Wrote the whole line and closed the graph.
Then you can change the values of the points and that works well. The graph becomes like an elastic band. Very funny.
Also this method is not very fast. my framerate drops from around 15 to around 10. The current version is still the fastest.

What I just discovered, when in the menu debug is pushed, you can choose for "Cycle on-screen statistics" which sets "/sim/rendering/on-screen-statistics". Push it 2 times and you get a perfect rolling backwards graph. 8 lines. with another few bar graphs.
what am I trying to to with nasal ... when there is someting that can be usable ? and much much faster...

Also , it is better to close this thread I think, we are going far off-topic. better continue in fgplot?
kuifje09
 
Posts: 579
Joined: Tue May 17, 2011 8:51 pm

Re: newbe compile problem

Postby Hooray » Thu Jun 27, 2013 6:32 pm

We already briefly explained how the translation thing works in the original fgplot thread, I suggest to have another look and specifically search for "translation".
The on-screen-stats are OSG-specific, and don't use the canvas system. Like Tom said, the canvas should definitely not be the bottleneck for fgplot - you can use the built-in profiler and the on-screen stats to identify bottlenecks - but it's almost certainly implementation-specific (i.e. algorithmic issues in the Nasal code).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11272
Joined: Tue Mar 25, 2008 8:40 am


Return to Compiling

Who is online

Users browsing this forum: No registered users and 1 guest