forums.silverfrost.com

BILLDOWS · Joined: 22 Jul 2005 Posts: 86 Location: Swansea, UK

I have come across one change in the latest v7 DLL re colour modes (over a DLL provided by Paul in March 2013) which may impact those with legacy code.

Previously the default colour mode was VGA (stated in manual) but now it appears to be RGB. Thus if a user (like me) had assumed the default and not used use_rgb_colours@ = 0 to specify this they now get 'rubbish'. I assume that this may have been an intentional change?

Many Thanks

Bill

LitusSaxonicum · Posted: Wed Oct 09, 2013 10:42 am Post subject:

Hi Bill,

Paul did it partly in response to a request from me that as surely no-one still used 16 colour VGA mode, perhaps the default ought to be 24 bit colour. Seems like I was wrong. It is mentioned in the CWP.ENH file and in the revision history on the website.

I'm almost never in favour of changes that break existing code, but sometimes, things must advance.

As it used to be, failure to USE_RGB etc gave you incredibly frustrating failure to show things in the right colours or at all, so the boot has simply moved to the other foot!

Eddie

BILLDOWS · Joined: 22 Jul 2005 Posts: 86 Location: Swansea, UK

Thanks for the quick response Eddie - I should have spotted it in the revision history. It is obviously 'slack' programming in a way (historically - this program dates from 199*?) and is easy to fix.

Thanks again

Bill

DanRRight · Posted: Wed Oct 09, 2013 12:26 pm Post subject:

If by USE_RGB you means RGB_COLOURS then yes, that was needed change. I do not know how many times in the past i was losing hairs and hours swearing to the hell trying to find out why abruptly the %GR stopped to work until realizing that i forgot again and again this subtle switch rgb_colours...

Another such bottom kick from the past is the use INTEGER*2 in some library subs like FILES@. We discussed this before. Hope Integer*2 will also be pesticided and exterminated.

LitusSaxonicum · Posted: Wed Oct 09, 2013 2:10 pm Post subject:

Yes, I mangled the routine name to indicate concept. If I'd quoted the exact routine, I would have used the final @ ! (Or I was to idle to get the correct name). I also swear, curse and rant at some of the issues...

Eddie

BILLDOWS · Joined: 22 Jul 2005 Posts: 86 Location: Swansea, UK

Thanks both - Whilst I appreciate the desire to eliminate everything from the past that is a pain I very much hope that Paul and others NEVER (in my working lifetime) remove old integer*2 support - some of us have to maintain and develop old programs and do not want to re-write them!

Yes I know such routines are a pain but most (but not all) have modern equivalents so those with modern programs can work unhindered - though I do see that it is reasonable to go to an RGB standard given the relative painless way (3 hours for me on 15 programs) of dealing with this.

All the best

Bill

LitusSaxonicum · Posted: Wed Oct 09, 2013 3:59 pm Post subject:

Why the move to an RGB default from a VGA default had to stop 16-colour modes working is a function of implementation, and I suspect that Paul simply changed the default without working through the ramifications (I would have done the same, so no criticism from me there).

Making INTEGER by default *4 instead of *2 certainly makes the old habit of having different contents in the same COMMON block in different routines into a real problem. It may also complicate some bitwise storage of flags. But sensible (sorry Bill!) code should survive this change, better than say REAL going from *4 to *8, where roundoff behaviour changes. That is unless you have specific code to catch integer overflow.

As an aside, why is LOGICAL so big? When I was short of RAM in early PC days, I wanted LOGICAL*0.125, or maybe a relative scale between .TRUE. and .FALSE. - with LOGICAL*4 one approaches the ability to shade nuances into this.

Eddie

PaulLaidler · Posted: Wed Oct 09, 2013 6:37 pm Post subject:

As far as I know there are no ramifications as far as the library is concerned.
Users who have old code with VGA colours will need to change before using the new DLL.

LitusSaxonicum · Posted: Thu Oct 10, 2013 9:01 am Post subject:

Paul,

There do appear to be ramifications, e.g.

PaulLaidler · Posted: Thu Oct 10, 2013 9:13 am Post subject:

My apologies.

The potential ramifications for users was clear at the outset and caused us to think long before making the change.

As far as I know there are no ramifications as far as the internal library code is concerned.

LitusSaxonicum · Posted: Thu Oct 10, 2013 12:10 pm Post subject:

Well, Bill said it only took a few hours. I call it a problem if I'm nowhere near a solution in several days! (Slow learner!)

I think the change was the right one.

Eddie