Visit our Popular Forums

rgleason · 21-12-2014, 14:11

In shortcuts menu http://opencpn.org/ocpn/keyboard-shortcuts
Change Colour Scheme C (or F5) C C shortcut is new
Monochromatic Mode Ctrl-G Works on some Windows systems (depending on graphic driver)
and below that

Ctrl + C Change color scheme - new similar to Ctrl+G, "C" and (F5)
Ctrl + G* cycles through green, red and normal screen.

List sorted by keys

F5 toggle Daylight, Dusk & Night mode, if built into the Chart ( "C", Ctrl+C, Ctrl+G)
C change color scheme -new similar to Ctrl+C, Ctrl+G and F5
Ctrl + C Change color scheme - new similar to Ctrl+G, "C" and (F5)
Ctrl + G* cycles through green, red and normal screen.

In Windows these all seem to work except Ctrl G which the note says is because of graphics driver (but it seems to work with the other keys).
It seems to me that there is too much redundency here for the function, both for the programming and the multiple keys..
Which keys should we be using now to dim or change color ? "C" Ctrl+C and F5?

rgleason · 21-12-2014, 14:17

I think the previous Shortcut Keys list explains some of the intentions, lets keep those intention but make it clearer if possible.

Night Navigation

F6 General Dimming, of the entire Screen, in steps.
SHIFT + F6 reverses the dimming.
F5 Toggle Daylight, Dusk and Night mode, if it is built into the Chart.
Ctrl + G * cycles through (monochromatic) green, red and normal screen.∗

By the way the "F6" key brings up ten steps 1 ---> Max, but does not dim anything on my machine. Yet when I turn off Opengl it works. So we should note that F6 10 step dimming requires no opengl.

CarCode · 21-12-2014, 14:32

Quote:

Originally Posted by bdbcat

Ptizef, or any other user who can build from github and uses AZERTY keyboard...

I have committed a change to AZERTY keyboard code that should allow []\ keys for chart rotation.

Please build, test and report, if possible.

Thanks
Dave

Same as before, no action with Mac OS X Yosemite with/without OpenGL or with/without Quilt or Raster/Vector.
Gerhard

Hakan · 21-12-2014, 14:36

Quote:

Originally Posted by cagney

Håkan

O found 32 charts with GD=RT90 in my set of Swedish charts from 1998.
Attachment 94084

Thomas

Ooops--I've some in my folders as well! You'll learn every day, thanks.
You're right, for some reason they have actually used the inland grid system for Swedish overview charts, basically not used for detailed navigation. All coast- and approach- charts are in WGS84.

Well, that's how it is then.
I think you must know how to calculate RT90-WGS84 but here is one java script: http://www.gis.scb.se/how/sweref99/bjrt90latlong.js
The link was found here:Koordinatsystem - Geoskikt fr?n SCB in Swedish but there is a note: The code can be used by everyone "Open source"
Thanks
Håkan

rgleason · 21-12-2014, 14:40

Options screen anomoly - open the Options screen, change focus away from Opencpn, say the forum, go back to Opencpn by clicking on Opencpn at the tray. The options menu pops up but has portions of the forum website in it and some of the chart menus that are normal. The CPU starts working overtime....

By going back to the webpage and clicking Opencpn, sometimes the Options menu appears as it should, but this requires two cycles webpage, opencpn, webpage, opencpn, then the Options menu shows properly.

bdbcat · 21-12-2014, 17:41

Gerhard...

Forgive me for being slow...

Are you saying that []\ keys do not work on Yosemite to give chart rotation?

Thanks
Dave

bdbcat · 21-12-2014, 21:02

Sean...

1. I did find an opportunity for improvement of soundings rendering in OpenGL with FBO. Should be significant for some hardware. We were unintentionally rendering depth symbols way outside the clip buffer, a real waste of time...

2. In dc mode, all charts, overzoomed and rotated, I am not surprised we see performance issues. There are two post processing steps, all executed by the CPU in system memory. Not much more can be done here with the current structure. I expect most users of low powered systems that can't run OpenGL will not do much rotating or overzooming, or will switch those options off.
Still, in this mode, the system is still functional. Just maybe a bit too slow to be enjoyable.

3. And of course in OpenGL Raster mode, all is fine with raster compression and caching.

4. There are bigger fish to fry moving forward. We need to move to normalized coordinate systems and shaders for object rendering of vector charts. I see big wins there for some future release.

Dave

bdbcat · 21-12-2014, 21:04

Ptizef...

JP, I made one more try at overzoom blurring for very generic OpenGL systems. This code is really simple, and should run on almost any OpenGL system.

In github now.

Dave

CarCode · 22-12-2014, 01:15

Quote:

Originally Posted by bdbcat

Gerhard...

Forgive me for being slow...

Are you saying that []\ keys do not work on Yosemite to give chart rotation?

Thanks
Dave

It seems I don't have any rotated charts and never can or could rotade any other chart with these keys. Only rotation is Course up/North up.
Gerhard

HappySeagull · 22-12-2014, 06:59

Quote:

Originally Posted by cagney

Happy

It looks like you are discussing a slightly different question.

My point only concerns charts that cannot be related to a recognized Geodetic Datum.
A typical case are NGA charts containing notes similar to this:

If O assigns a GD=WGS 84 to such charts, big errors are possible.

Example NGA 28201:

CM93 V2 is based on chart 28201 but has applied huge corrections to make it compatible with WGS84.

This is exactly the reason why we can't just assign WGS84 to a chart were GD=UNKNOWN or not stated at all.

Thomas

Absolutely agree but I'm merely saying that if O is displaying UNKNOWN, isn't she just posting that from the text header? while In fact she is "displaying" the chart using the metadata (or whatever it is called).
So UNKNOWN (or WGS84,orNAD27) is not an indication to me that O is "doing" anything to the chart.
Of course one hopes there are not many like me typing randomly into chart headers in conflict with the actual chart...

ADDED Likewise when the header says WGS84 that is not a Guarantee of accuracy either. I think I've seen this , likely from NGA days

HappySeagull · 22-12-2014, 07:55

Quote:

Originally Posted by Gilletarom

Hello Dave,

O 332410 on ASUS EEPC 1015H, W 7 stater

On a new installation, no GPS connected, no unit entered when trying to create a new connection anyway, O offers us the com port 4 and 6. It is not serious but rather abnormal.

This is something that took place with 3.2.2 and all previous beta versions. The problem seems to have already been pointed out to me by another user, but I do not know if it had been analyzed. In any case, I do not remember seeing an answer to this on any thread.

Best regards. Gilletarom

just a usr opinion, Gilletarom, but That's not abnormal...Simply speaking, those ports "exist" in the Windows Device Manager and Opencpn looks there. When the gps is plugged in, it will "exist" in the same place.
Those persistent ones you see are "loaded" when Windows is started, but the gps may only be "loaded" when it is plugged in.

Have a look on your computer. Find the "Device Manager" on XP or it's equivalent on other versions. You will see them under "Ports"

nkiesel · 22-12-2014, 12:45

Hi,

I just noticed that some marks are not drawn when panning ENC charts. The effect is bigger when panning slowly using cursor keys. It can be "fixed" by changing zoom levels back and forth (or probably anything that triggers a redraw).

The following 2 sceenshots showing the San Mateo Bridge in San Mateo, CA illustrate the problem. The first one shows the display after panning so that the center span of the bridge is no longer shown and then - using cursor keys - slowly getting the center span of the bridge back into the view. The second one shows the same after a `-`,`+` (ie zooming out and in again).

I can't try right now if that also happens when on the boat but if so that could be potentially bad because you could miss lots of marks etc. on the charts as you sail along.

Ptizef · 22-12-2014, 13:08

Quote:

Originally Posted by bdbcat

JP, I made one more try at overzoom blurring for very generic OpenGL systems. This code is really simple, and should run on almost any OpenGL system.
Dave

Dave

You got it !
It works on my damned Intel !
Just a small regret : At full zoom, panning become slow and jerky.
But it's acceptable
Now I have blurring on all my configurations ( I don't find this slowness
on the same machine with Ubuntu neither on my little low powered W8.1 )

many Thanks

Jean Pierre

cagney · 22-12-2014, 14:12

Quote:

Originally Posted by Ptizef

Dave

You got it !
It works on my damned Intel !
Just a small regret : At full zoom, panning become slow and jerky.
But it's acceptable
Now I have blurring on all my configurations ( I don't find this slowness
on the same machine with Ubuntu neither on my little low powered W8.1 )

many Thanks

Jean Pierre

Dave
With an up to date Git I now get this when zooming in and panning.