OpenCPN Beta test 4.1.1108 Release

[NahanniV]

Originally Posted by boat_alexandra

... Also, all the android and single board arm platforms probably can use scissors....

I found that disabling scissors resolved problems with rendering CM93 on my ARM based CubieTruck with Mali GPU.

Scissors is now disabled for Mali.

Cheers,
JM.

[bdbcat]

Sean..

OK, I'll wait for a pull request fixing the Initpoints() problem, and others you have identified.

I can't see any immediate reason to modify the cm93 compositor order if we are going to use complex region clipping anyway. But I'll look again at the logic.

Thanks
Dave

[rooiedirk]

Around last new year there has been a discussion about magnetic bearings and courses when the "Show magnetic bearings and headings" was ticked. (I don't see any good reason for using this, but if it is there it should be working)
As far as I can recall it was also implemented with the use of the local variation at the point of departure. (In bearings and routes)
I noticed that in the latests git it does'nt work like this anymore. Is this a followup of the integration of WMM?? And is it on the 'bucketlist'??
Dirk

[bdbcat]

Dirk...

Lots of water under the bridge.
Can you please refresh us on the issue as you see it?

Thanks
Dave

[rooiedirk]

Dave,
See screenshots.
Show magnetic bearings and headings is ticked.
First is a measure off Newfoundland, while ownboat is in the Netherlands. The measure is showing a magnetic bearing using the own position variation, while the variation around Newfoundland is abt -018.
Second screenshot is showing a route for more or less the same position. Also showing magnetic bearings for the own ship position and not the local bearing/course.
I think the ownship variation should be used only vor distance and bearing in the status bar.
As I see it, if WMM is available the local variation should be used, and without WMM the true bearing (without the (M) )
If WMM is available, in the option dlg "assumed magnetic variation" could be greyed out.
Dirk


Dirk

[BluegillBoy]

i found an issue with the beta - on some chart sets it only allows a view that's fairly far zoomed in. specifics...

beta 1108
windows 7 pro
using USACE enc charts for the tenntom waterway in alabama
when zooming out to try and show more than 2-3 miles, the screen goes to solid tan (land color) and the chart indicator bar at the bottom shows a solid green unloaded chart. obviously, i can't get a broad view given the 3 mile or so max zoom out.

this is made worse when also loading the NOAA region 17 (gulf of mexico) charts. then max zoom out is only about 1 mile, and when i zoom one click further out, the screen message curiously says "overzoom".

the first part of this issue was somewhat evident in V4.0 which only allowed about 100 miles of outward zoom, but that was never a problem in navigation.

any other info i can furnish to help?

PS - i'm lovin V4.0

[wdkester]

Originally Posted by BluegillBoy

i found an issue with the beta - on some chart sets it only allows a view that's fairly far zoomed in. specifics...

beta 1108
windows 7 pro
using USACE enc charts for the tenntom waterway in alabama
when zooming out to try and show more than 2-3 miles, the screen goes to solid tan (land color) and the chart indicator bar at the bottom shows a solid green unloaded chart. obviously, i can't get a broad view given the 3 mile or so max zoom out.

this is made worse when also loading the NOAA region 17 (gulf of mexico) charts. then max zoom out is only about 1 mile, and when i zoom one click further out, the screen message curiously says "overzoom".

the first part of this issue was somewhat evident in V4.0 which only allowed about 100 miles of outward zoom, but that was never a problem in navigation.

any other info i can furnish to help?

PS - i'm lovin V4.0

In the waterway there seem to be only two different chart scales, 1:5000 and 1:2160000, a huge difference. I think this large difference causes the effects you are seeing. The big chart is all tan except for the coastline. The small charts disappear when they have been reduced to about 1/5 of their normal scale. This is probably reasonable for harbor charts, but maybe not so reasonable for long skinny waterways where the background charts have no useful information.

I think it would be reasonable to keep some of the text on the screen so you could have 5 miles visible.

Also, the "Distance Markers" AKA mile markers are in KM even though I have units set to Nautical miles

[fgd3]

I didn't observe any new behavior. The Tenn-Tom charts have always behaved this way. I lose all detail when zoomed out enough to have a distance of 1.5 miles shown from the top to the bottom of my screen.

Fabbian

[BluegillBoy]

the behavior itself isn't new, but is more severe in 1108. sorry i wasn't more specific about the problem.

in 4.0.0 i too lose detail after a few zooms out, but can continue to see the river, it's shape, coming turns, and most importantly AIS targets headed my way. 4.0.0 will allow me to zoom out and see about 100 miles screen edge to screen edge. (more than is necessary.)

in 1108, once the detail is lost/reduced, the river disappears completely so i can't see coming bends, or where an AIS target is located other than on a plain tan screen. can't tell if the AIS target is 1/2 mile from me coming in a straight line, or around a river bend and really 2 river miles from me because I can't see the shape of the river. and in 1108, the max distance i can get from screen edge to screen edge is less than 2 miles. plus it says "overzoom" which it certainly is not.

[transmitterdan]

Latest git of O will not build without OpenGL support. I tried this cmake configuration on Ubuntu (Wily):

cmake -DUSE_GL=NO ..
make

But LLRegion.cpp will not compile.

The reason I want to remove OpenGL is because on my virtual machine use of OpenGL crashes O all the time and sometimes causes a kernel panic.

[seandepagnier]

Originally Posted by transmitterdan

Latest git of O will not build without OpenGL support. I tried this cmake configuration on Ubuntu (Wily):

cmake -DUSE_GL=NO ..
make

But LLRegion.cpp will not compile.

The reason I want to remove OpenGL is because on my virtual machine use of OpenGL crashes O all the time and sometimes causes a kernel panic.

Is this a bug in the virtual machine? Can't you just run without opengl enabled? In the meantime, but of course we can fix the build to work without opengl support.

[transmitterdan]

Sean,

I suspect this is not the only module that will not build without OpenGL support. And when building with MSW VS 2013 a different problem arises during the same build.

It may be a bug in the virtual machine or it may be a bug in the Ubuntu system itself. I haven't the ability to figure out what is wrong. But we claim it can be built without OpenGL support but no one seems to do a regression test on this ability. I am just trying to find holes in the latest git as I feel we should be getting close to a production release and it would be good to have a cleanup on this sort of stuff. If anyone disagrees I can stop doing it.

[seandepagnier]

Dan,

It is great you can do this testing. Basically no one bothers to test every possible type of build for every commit, but from time to time (every month or two) it gets tested and usually fixed quickly. For this reason, it is usually not much work to stick some ifdef guards where they are needed.

LLRegion depends on GLU not GL. We are already using the tesselator elsewhere in opencpn, so I didn't imagine it could be a problem. I will take a look.

I thought this was blocking you from running opencpn which is why I made suggestions... let me know if you can't use opencpn without opengl unless it is built without opengl.

[transmitterdan]

Sean, I managed to get a build to run.

[Hakan]

Win10 mystery ??
Today I made a long time run test using my usual VDR feeding Win10 and XP simultaneously. Both using the same source but built by VS13 and VS10 respectively.
XP was no problem but when I should end the Win10-O it wont close but just stop "answering" after a while and I had to force it close. The log file is full of CM93 messages I never seen before, like:

5:00:14 PM: Warning: Caught MainLoopException, continuing...
5:00:14 PM: Loading CM93 cell C:\Users\admin\Documents\Charts\CM93_2012\\03900000/A/03900000.A
5:00:14 PM:    cm93chart  Error ingesting C:\Users\admin\Documents\Charts\CM93_2012\\03900000/A/03900000.A

Since XP was normal I think Win10 is involved in some way. Please give me a description what can cause the CM93 log entries and I can try to find out how Win10 is interacting. (Hibernation although not set/Sleeping/screen save/just tired???)

Log file attached, pls delete ".pdf". First log session is the one. Last is next normal open/close.

Håkan