RGB@

I'm having problems with the colours generated by RGB@ using x64.

My lines that were red under win32 are now blue, and v/v, and my cyan background grid under win32 is now yellow.

What do I need to change to get the old win32 colours back under x64?

Can you provide a short sample program and give the FTN95 version number.

Are your R, G and B values REAL4 or REAL8 ?

Hopefully, integer arguments.....

Blimey, Bill, I always put this sort of mistake down to autocorrect, but this one can only be geriatric brain fade!

INTEGER4 or INTEGER8, of course.

I put it down to my mind being elsewhere, Chapter 41 of my latest book, to be precise.

Eddie

'INTEGER4 or INTEGER8, of course.'

Would it have any effect, as only the first byte of R, G and B values are used.

Or am I having a geriatric brain fade also ?

I've always wanted @RGB to be a special geriatric intrinsic that provides an INTEGER*4 result.

Hi Paul

I've cut my code down to make it as simple as I can.

It's a while since I used the forums -- I've forgotten how to send attachments.

The version is:

[FTN95/x64 Ver. 8.30.0 Copyright (c) Silverfrost Ltd 1993-2018]

Norm

PS Interestingly, using something like

     nclr = 10
     
     nSymblColor = RGB@ ( nclr, nclr, nclr )

gives a black line for both v32 and x64, whereas

  nGridColor = RGB@ (0,255,255)

gives a cyan grid under v32 and yellow under x64.

I'm using Draw_Line@ in both versions, with

  include < dbos.ins >

included in the x64 code.

Do I need to replace the '255' by 'n255', where n255 = 255?

[/code]

The program

nclr = 10
nSymblColor = RGB@ ( nclr, nclr, nclr )
print*, nSymblColor
end

prints 657930 which is A0A0A in hex.

You don't need DBOS.INS.

I am using FTN95 v8.70 but it shouldn't make any difference.

My apologies, Paul, my email was not clear.

The code

nclr = 10

nSymblColor = RGB@ ( nclr, nclr, nclr )

gives a black axis under both v32 and x64, which is what it should do.

A bit later on, I use

nGridColor = RGB@ (0,255,255)

to draw lines for a background grid. This gives a cyan grid for the plot under v32 and yellow under x64.

What is the best way to send you the code and data file?

You can put

nGridColor = RGB@ (0,255,255)

into my code above to see what you get for 32 bits and 64 bits.

If you need to send code then you could use DropBox (say) and post a link.

Did you say which version of FTN95 you are using?

Yes, I did.

FTN95/x64 Ver. 8.30.0 Copyright (c) Silverfrost Ltd 1993-2018

Hightail wants an email address to send you a notification.

I found an old program from the forum, and tested red and blue in PLATO for 32-bit and 64-bit with no problem of rgb order. This works for Ver 8.30 and Ver 8.64, without any swapping of reg/blue. Norm, test if you have a problem with this code.

 PROGRAM main

 use clrwin 

   integer, external  :: winio@  !, rgb@  ! defined in clrwin or FTN95 ??
!
   integer, parameter :: width = 800, height = 350, gutter = 20
   integer :: black = 0, red, cyan, blue, col
   integer*8 :: mag = 255                        ! test of 8 byte integer as argument to rgb@
   integer :: iw, i, k
   integer :: last_x, last_y, mid_y, len_x, new_x, new_y
   real    :: x,y
!   integer(7) :: ctrl                     ! fails for /64
   integer*4 :: ctrl
!
   blue   = RGB@(0,0,mag)
   red    = RGB@(mag,0,0)
   cyan   = RGB@(0,mag,mag)

   iw = winio@ ('%ca[sin(x)exp(-x/10)]&')
! set up the surface to draw onto. Remove [smooth4] to see what anti-aliasing has given you
!z   iw = winio@ ('%gr&', width, height)
   iw = winio@ ('%gr[smooth4]&', width, height)
   iw = winio@ ('%lw', ctrl)

 ! draw axes
   mid_y = height / 2
   len_x = width-(2*gutter)
   call draw_line_between@ (gutter, gutter, gutter, width-gutter, black )
   call draw_line_between@ (gutter, mid_y, width-gutter, mid_y, black )
!
   do k = 1,2
    do i = 0,len_x
     ! make the width of the x-axis span 0..8pi. REAL(len_x) is the width of that axis
     x = (i/REAL(len_x))*8*3.1415926d0
     if ( k==1) then
       col = red
       y = sin(x)*exp(-x / 10)
     else
       col = cyan ! blue
       y = cos(x)*exp(-x / 10)
     end if

     new_x = gutter+i
     new_y = mid_y + y*(mid_y-gutter)
     if (i > 0) then
       call draw_line_between@ (last_x, last_y, new_x, new_y, col )
     end if
     last_x = new_x
     last_y = new_y
    end do
   end do

END PROGRAM main

Norm.Campbell

I have sent you a Forum message containing a temporary email address.

Norm.Campbell

I have looked at your code. The result of RGB@(0,255,255) is correct and the same for 32 and 64 bits.

Also, for me, the resulting images are the same with a cyan coloured grid.

Are you using the same machine for the two tests (32 bits and 64 bits)?

I am using v8.70 but this should not make any difference.

Norm.Campbell

I need to take another look at this. I am now able to reproduce the failure.

The failure does not appear to be in RGB@ nor DRAW_LINE@. Maybe it is in one of the 'DIB block' routines when used in a 64 bit application.

I had assumed that you were reporting a regression but this does not now appear to be the case.

In the meantime there is nothing lost by only using the 32 bit version.

Hi Paul

I was about to send you a response, noting that I'd done some more checking, and found that my computer was reporting a memory error when it rebooted, and that perhaps the difference in memory accessed between the 32-bit and 64-bit versions was the problem. Then I noticed that the posts had gone over to a second page, and saw your latest comments.

It's good to know that the problem is real. As you note, I can work around it using the 32 bit version, and I've got to quite like the yellow background for some of my plots.

Merry Christmas

Norm

The fault is in the 64 bit version of RECOVER_DIB_BLOCK@. This has now been fixed for the next release of clearwin64.dll.

Hi Paul

Just to let others (and you) know that replacing

PUT_DIB_BLOCK@ ( flno, ... )

with

nFUNC = Export_Image@ ( flno )

fixes the problem.

I also replaced DRAW_LINE@ with DRAW_LINE_BETWEEN@, and removed

INCLUDE < DBOS.IN >.

Thank you for fixing this for me.

Happy New Year

Norm

To take your comment seriously, I quite like the 64-bit version.

I spend a fair bit of time writing code to process remotely sensed images. I can usually just fit my images in in 32-bit mode, but when there is a bug in my code (and that still seems to happen all too frequently) then it is a pain having to cut down my array sizes so that I can find the bug.

So far, the 64-bit version has alleviated that problem.