OpenCPN Beta Version 3.3.2410 Released

[Hakan]

Originally Posted by bdbcat

Håkan..

About Intel OpenGL on linux:

Here is my logfile stuff. This OpenGL setup works fine on Ubuntu 12.04

21:08:37 EST: OpenGL-> Renderer String: Mesa DRI Intel(R) Q35 x86/MMX/SSE2
21:08:37 EST: OpenGL-> Detected Intel renderer, disabling stencil buffer
21:08:37 EST: OpenGL-> Texture rectangle format: de1
21:08:37 EST: OpenGL-> Using Vertexbuffer Objects
21:08:37 EST: OpenGL-> Using Framebuffer Objects
21:08:37 EST: OpenGL-> Using FBO Stencil buffer
21:08:37 EST: OpenGL-> Using Depth buffer clipping
21:08:37 EST: OpenGL-> Using s3tc dxt1 compression
21:08:37 EST: OpenGL-> Compressed tile size: 128kb (6:1)
21:08:37 EST: OpenGL-> Minimum cartographic line width:  1.0
21:08:37 EST: OpenGL-> Minimum symbol line width:  1.5

Compare, please.

Thanks
Dave

Dave....And here is mine when the buffer was activated, also Ubuntu 12.04:

11:09:55 CET: OpenGL-> Renderer String: Mesa DRI Intel(R) 965GM x86/MMX/SSE2
11:09:55 CET: OpenGL-> Detected Intel renderer, disabling stencil buffer
11:09:55 CET: OpenGL-> Texture rectangle format: de1
11:09:55 CET: OpenGL-> Using Vertexbuffer Objects
11:09:55 CET: OpenGL-> Using Framebuffer Objects
11:09:55 CET: OpenGL-> Using FBO Stencil buffer
11:09:55 CET: OpenGL-> Using Depth buffer clipping
11:09:55 CET: OpenGL-> Using 3dfx fxt1 compression
11:09:55 CET: OpenGL-> Compressed tile size: 128kb (6:1)
11:09:55 CET: OpenGL-> Minimum cartographic line width:  1.0
11:09:55 CET: OpenGL-> Minimum symbol line width:  1.5

Two rows differ. Does that matters? Or what more to check?
I use the same chart files as in Windows where the buffering works fine, dual boot.
>So one difference from your machine could be I'm reading the charts from a static mounted NTFS disk. Is it worth copying over to the Linux partition for a test??
>The .deb package is created on another PC, pure Ubuntu 12.04 single boot, but probably with another graphic card, is that an issue?
> More???
Thanks
Håkan

[Hakan]

Originally Posted by bdbcat

............Works fine for me in all cases. Maybe it is a French keyboard difference? Any other users with French kb may test?.......
Dave

Nope, but a Swedish. I've to key: Altgr+8 = [ or Altgr+9 = ] and as said it works fine. (Altgr is the Alt key to the right of space)
Håkan

[Ptizef]

Originally Posted by bdbcat

Jean Pierre (ptizef)

Regarding your OpenGL trouble with "Suppress display emphasis..."

Will you post your log entries for the OpenGL configuration?

Thanks
Dave

Dave
here opengl part of my log

6:58:50 PM: Warning: unable to use NPOT texture for chart symbols
6:58:50 PM: OpenGL-> Renderer String: Mobile Intel(R) 4 Series Express Chipset Family
6:58:50 PM: OpenGL-> Detected Intel renderer, disabling stencil buffer
6:58:50 PM: OpenGL-> Texture rectangle format: de1
6:58:50 PM: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
6:58:50 PM: OpenGL-> Vertexbuffer Objects unavailable
6:58:50 PM: OpenGL-> Detected Windows Intel Mobile renderer, disabling Frame Buffer Objects
6:58:50 PM: OpenGL-> Framebuffer Objects unavailable
6:58:50 PM: OpenGL-> Using Depth buffer clipping
6:58:50 PM: OpenGL-> Using s3tc dxt1 compression
6:58:50 PM: OpenGL-> Compressed tile size: 128kb (6:1)
6:58:50 PM: OpenGL-> Minimum cartographic line width: 1.0
6:58:50 PM: OpenGL-> Minimum symbol line width: 1.0
6:58:50 PM: ChartDB Cache policy: Application target is 1024 MBytes
6:58:50 PM: Loading chart db version: V018



I precise : it happens only in the two cases 1 and 2
case3 is the only one working
Jean Pierre

Jean Pierre

[LJH]

Originally Posted by bdbcat

Gilletarom:

re:
On the map rotation with the shortcuts "[" or "]"?

I never managed to make it work. Is it really implemented? Or the radio button for "north up" or "COG up" he prevents the operation of the keyboard shortcuts?

Works fine for me in all cases. Maybe it is a French keyboard difference? Any other users with French kb may test?

Thanks
Dave

Dave,

With a normal US keyboard and French Canadian Layout selected I need to use the right alt key and [ or ]. Then it functions properly.

Lyndon

[bdbcat]

Håkan....

Regarding Intel OpenGL:

If this is a dual boot machine, then lets see the same log information for the Windows boot. The difference is in the compression algorithm used.

Thanks
Dave

[bdbcat]

Gilletarom...

Again, which PlugIn is currently causing trouble with over-riding and replacing OCPN core translations?

I need to know for testing new idea...

Thanks
Dave

[Hakan]

Originally Posted by bdbcat

Håkan....

Regarding Intel OpenGL:

If this is a dual boot machine, then lets see the same log information for the Windows boot. The difference is in the compression algorithm used.

Thanks
Dave

Dave..
Here from the dual boot machine using WinXP:
(I also included the NPOT row if you would explain it, please)

22:36:09: Warning: unable to use NPOT texture for chart symbols
22:36:10: OpenGL-> Renderer String: Intel 965/963 Graphics Media Accelerator
22:36:10: OpenGL-> Detected Intel renderer, disabling stencil buffer
22:36:10: OpenGL-> Texture rectangle format: de1
22:36:10: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
22:36:10: OpenGL-> Vertexbuffer Objects unavailable
22:36:10: OpenGL-> Using Framebuffer Objects
22:36:10: OpenGL-> FBO Stencil buffer unavailable
22:36:10: OpenGL-> Using Depth buffer clipping
22:36:10: OpenGL-> Using s3tc dxt1 compression
22:36:10: OpenGL-> Compressed tile size: 128kb (6:1)
22:36:10: OpenGL-> Minimum cartographic line width:  1.0
22:36:10: OpenGL-> Minimum symbol line width:  1.0
22:36:10: ChartDB Cache policy:  Application target is 499 MBytes

The whole catch is not yet built but about 30 M around the position of the boat.
Thanks
Håkan

[Hakan]

Originally Posted by bdbcat

Gilletarom...

Again, which PlugIn is currently causing trouble with over-riding and replacing OCPN core translations?
Thanks
Dave

Dave, If I may interfere I've some possible examples;


#: src/AISTargetListDialog.cpp:412 src/AIS_Target_Data.cpp:605
Here is the word “Range” used as distance. This one is in Crowdin translated to the Swedish equivalent to “Distance”(Avstånd) but actually is the equivalent to “Area” used in run time, probably from the example below.

From BR24Radar_pi

#: src/br24radarcontrol.cpp:585
Here the word Range is used as an area. This one is in Crowdin translated to the Swedish equivalent to “Area” or “reachable area” (Räckvidd) and it’s also what’s used in run time, e.g. correct.

Håkan

[nohal]

Hakan...
I don't know Swedish very well but even on a radar range means distance, not area as far as I can tell...
But yes, it is tricky and actually impossible to do right in all cases - as an example in some languages adjectives conjugate, "New" can have 4 (de jure 6) different translations in Czech depending on the context... Of course, we can make every label half a page long, but I really doubt it will be very usable.
Not saying there are no cases where we can do better, but we need to know exactly where in the GUI they are, not just "This word is broken in MY language" as without the context we will likely break some other immediately...

Pavel

[Hakan]

Pavel..
I know it's tricky but it was a possible example Dave seemed to ask for?
And.. of course the radar cover a distance, so to say, but since it's a circulating movement the range/distance will sweep over an area, and for that we have a word at home. This is not a big thing, I can make the translations to be rather good using another but the same word in both places.
Håkan

[bdbcat]

Håkan...

OK, this a useful example.

Let me make sure I understand the situation:

1."Range" is translated correctly to Swedish in the OCPN core.

2.But if you load the br24radar_pi, the translation for "Range" is overridden by the PlugIn.

3. So then it is OK for the PlugIn, but just wrong for the base OCPN.

Is this correct?

Dave

[bdbcat]

Håkan ...

Lets be sure we understand what is theoretically possible.

I don't know if I can do this, but I will investigate.

What I propose is that (in the instant case) when O loads the BR24Radar_PI, he somehow prevents the PlugIn from replacing the word "Range" in the master catalog. So, the PlugIn translation will be exactly the same as the core OCPN translation for the same English word. There will only be one translation for the word "Range", and that one will be the original core interpretation. Any different translation in the PlugIn will be discarded.

And we can only hope that the static translation makes sense in the PlugIn context.

Not even sure I can do this. I may have to read the PlugIn .mo file, parse and remove items that exist in the core, create a temporary .mo file, and let the PlugIn register that one. Cache it for next time, maybe. Lotta trouble, I think...

We might be able to do a better job on this if PlugIns can be rebuilt, with new strategy for loading .mo file. But we need to handle the legacy PlugIns correctly.

We should do something, though, because it is just not right for a PlugIn to be able to disturb an existing validated translation in the core. Not all PlugIns will play nice here.
Dave

[Littlechay]

Originally Posted by NahanniV

I think the term should be "Track" up. Besides testing, this is what I use the rotation keys for, perhaps it could be automatic if the data is available or manual by keyboard if not.

Cheers,
JM.

No I don't think so. Track implies historical data so track up would mean that you are retracing your track.... course is where you are going, track is where you have been.

Chris

[Littlechay]

Originally Posted by bdbcat

Littlechay....

When I upload with Furuno checked, I see this in the log:

21:10:10 EST: Opening NMEA Datastream Serial:/dev/ttyS0
21:10:10 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $PFEC,GPwpl,3125.326,N,08117.091,W,001000,,,A,,,,
21:10:10 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $PFEC,GPwpl,3126.153,N,08113.994,W,002000,,,A,,,,
21:10:10 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $GPRTE,1,1,c,01, 001000, 002000*35
21:10:10 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $PFEC,GPxfr,CTL,E
21:10:10 EST: Closing NMEA Datastream Serial:/dev/ttyS0

I don't see any errant spaces.
Compare your results?

Thanks
Dave

I'm definitely seeing a space in the latitude, longitude is OK, see attached screenshot from the NMEA monitor window.

There is an added complication in using the GP-33 in that it sends its normal NMEA output at 4800 Baud and uses 38400 Baud for exchanging waypoints. This would be a feature request but would it be possible to have the port used in the route manager configured to a different speed than the same port in connections panel?

Chris

[nohal]

Chris...
Can you check in the logfile as Dave suggests? To me it does not seem like there is a space between 51 and 40 at all.
How does the dual speed work? It really outputs at different speed over one wire and expects different one over the other at the same time? That is really weird...

Pavel