GMAX and bglc: Lights off during the day

[Guest]

Hi!I tried to tweak the bglc code as follows as was suggested earlier in the forum:---------------------------------------------------------------------- DRAW_TRI 23, 25, 28 ; poly=31 part=1 DRAW_TRI 23, 28, 30 ; poly=32 part=1 DRAW_TRI_END; Alphadus_Alpha label BGLCODEIFIN1 daytime, 28c, 2, 4 BGL_LIGHT LIGHT_NAV, -0.033, 40.009, 0.181, 20, 0.60, 0.40, 0FFFF0000h, 0.000000, 0.000000, 1.000000 ; source poly num = 33 BGL_LIGHT LIGHT_NAV, -0.333, 20.000, 0.033, 20, 0.60, 0.40, 0FFFF0000h, 0.000000, 0.000000, 1.000000 ; source poly num = 34 BGL_LIGHT LIGHT_NAV, 0.267, 20.000, 0.033, 20, 0.60, 0.40, 0FFFF0000h, 0.000000, 0.000000, 1.000000 ; source poly num = 35 BGL_LIGHT LIGHT_NAV, -0.033, 20.000, 0.333, 20, 0.60, 0.40, 0FFFF0000h, 0.000000, 0.000000, 1.000000 ; source poly num = 36 BGL_LIGHT LIGHT_NAV, -0.033, 20.000, -0.267, 20, 0.60, 0.40, 0FFFF0000h, 0.000000, 0.000000, 1.000000 ; source poly num = 37daytime label word BGL_END BGL_RETURN---------------------------------------------------------------------Now when i try to compile the *.asm file bglc reports the following error:Error A2048: no ndigit in number IFIN1(5) Macro called from... without the IFIN1 line and the label it compiles just fine. Does anybody know where the problem lies?Best wishes,Ingo

[Guest]

Well, found the solution myself. BGLC doesn't seem to like a hex code (28C) instead using 652 works fine.Bye Ingo

[rhumbaflappy 113]

Hi Ingo.BGLC will handle hex just fine, but the default is decimal base.028Ch would be the number in hex. The '0' isn't needed for this number, but if a number starts with a letter, like FF, then it must be described as 0FFh. So, I always start a hex number with 0, to keep it consistant.Dick

[arno 1]

I think it is more the h at the end, but the safest way is to use 'tod' (time of day), that refers to the same variable.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi All.Here's the scoop on number bases in BGLC or MASM: Radix Specifiers _____Name__________Base___Specifier___Digits______Binary_________2______Y_or_B_____0_1_____Octal__________8______Q_or_O_____0_1_2_3_4_5_6_7_____Decimal_______10______T_or_D_____0_1_2_3_4_5_6_7_8_9_____Hexadecimal___16______H__________0_1_2_3_4_5_6_7_8_9_A_B_C_D_E_F_____Floating-_____10______R__________0_1_2_3_4_5_6_7_8_9_._E_+_-______point To indicate the radix of a constant, place the specifier at the end of the number. Specifiers and hexadecimal digits can be uppercase or lowercase. Hexadecimal numbers must always start with a decimal digit (0-9). If the first digit is one of the letters A to F, prefix the number with a leading 0 to distinguish it from a symbolic name. If the current default radix, specified by the .RADIX directive, is 10 or less, B and D are treated as radix overrides. B and D are treated as hexadecimal digits if the default radix is above 11 or above 13, respectively. Floating-point constants may be used as initializers only with the REAL4, REAL8, REAL10, DWORD, QWORD, and TBYTE directives. Floating- point constants can be represented with an optional exponent or a decimal point.-----------------------------BGLC defaults to a Radix ( base ) of decimal, so "t" or "d" are not required. "h" is required for hexidecimal, and it must have a numeral to start... using "0" if the numeral starts with a letter.So 255 in hex is '0ffh'. 9 in hex is '9h' or '09h'. Dick

[Guest]

Hi Dick,Thanks for the usefull information, just a question, what about negative values, ie -255 in Hex value?Thanks,Rafael Sanchez[a href=http://www.fsnova.com][http://www.fsnova.com/images/NsAnimation1.gif ][/a][/p]

[rhumbaflappy 113]

Hi Rafael.I wouldn't be the best one to ask that question! I know it can be encoded as long as the type expected is an SWORD or SDWORD ( signed word or signed doubleword ).Some BGLC default macros may need negative numbers in parameters, like SPRITE_VICALL ( page 102 of the FS2000 scenery SDK ). But those numbers can be entered as decimal numbers, as is true for any other number in BGLC. We don't really need to know how negative signed integers are represented in BGLC. So why use hex?I use a hex editor that can decode hex values as negative decimal equivalents, and in the rare case that I need to know, I'd use that.When I made 'TDFHeaders.inc' here's how I encoded the first part of the Macro:BGLHeader Macro NorthB, SouthB, EastB, WestB, LWM_Header, VTP_Header; if LWMStart = TerrainHeaderStart then LWM polygon header disabled; if VTPStart = TerrainHeaderStart then VTP polygon/line header disabled; NorthB, SouthB, EastB, WestB, are the Bounds in whole integer degrees; Make the bounds generous by giving an extra degree to the areaNorthBounds EQU ( ( NorthB * 1111305 ) / 10 )SouthBounds EQU ( ( SouthB * 1111305 ) / 10 )EastBounds EQU EastB * 11930465WestBounds EQU WestB * 11930465BGLHeaderStart label word dw 1 ; world set number dd NorthBounds dd SouthBounds dd EastBounds dd WestBounds dd 0 ; VOR data dw 0 ; lowest VOR freq dw 0 ; highest VOR freq dd 0 ; seeds level 8 data......."NorthB, SouthB, EastB, WestB, LWM_Header, VTP_Header"...... none of these were defined as types, and BGLC handles it quite well. As the macro does the math on the Bounds, again the datatype is ignored, but the sign ( + or - ) is preserved, and plugged into the appropriate places in the header.With TDFHeaders.inc, I cheated, and made the Bounds as integers, as this is demanded by BGLC's simple math abilities. So as long as the "NorthB, SouthB, EastB, WestB" are whole numbers appropriate to the degrees on the globe, and they are slightly greater than the area of the contents of the BGL, we're OK. ( I got the idea from some comments about bounds by Bob Bernstein... ).----------So I don't know a lot about negative hex notation in BGLC. Maybe I'll never need to know.BGLC math is a little difficult to deal with after using Delphi or VB. I don't know C+, but I'll assume there are floating point, and higher math routines available. It may be possible to construct some math and FP to integer funtionality with includes, as BGLC is basically a version of MASM.Christian Stock has been looking at MASM as a design tool, and may have some tricks he uses along these lines. But, BGLC Opcodes require integer numbers, except for the new floating point commands. to try to figure floating point, and it's negativity, in hex would really be maddening! :)Dick