rtlib/gfxlib2: Fix RORW() macro for non-x86

It didn't truncate the value to 16bit, causing it to fail when working
with 32bit variables, which is how the gfxlib2 box/line drawing code uses
it. Sooner or later it would start shifting the upper 16bits into the lower
16bit, and eventually end up with all 1's, meaning the <if (style & bit)>
type of checks used by fb_GfxDrawLine() etc. would always be true. Thus it
eventually started drawing all pixels instead of the wanted pattern.

http://www.freebasic.net/forum/viewtopic.php?p=214164#p214164

Author: dkl

changelog.txt

@@ -19,6 +19,7 @@ Version 1.05.0
 - 1.04.0 regression: Get# for WStrings was incorrectly changed to convert the loaded bytes to wstring characters, like Input# would do. Now it's changed back to just loading the raw bytes into the wstring, which is also how Get# works for other datatypes.
 - 1.04.0 regression: Due to the Get# wstring breakage, the compiler failed to read source files encoded in UTF16LE with BOM on Windows, and UTF32LE with BOM on Linux.
 - Eof() could incorrectly return TRUE too early on Windows, when reading a big text file with LF line endings, OPENed FOR INPUT (text mode)
+- Line's styled/pattern drawing support was broken on non-x86 systems
 
 
 Version 1.04.0

src/rtlib/fb.h

@@ -274,7 +274,7 @@
 		return 0;
 	}
 
-	#define RORW(num, bits) num = ( (num) >> (bits) ) | (num << (16 - bits) )
+	#define RORW(num, bits) num = (((((num) & 0xFFFF) >> (bits) ) | ((num) << (16 - bits))) & 0xFFFF)
 	#define RORW1(num)      RORW(num, 1)
 #endif