Sign in to follow this  
rhumbaflappy

GMAX and bglc: Lights off during the day

Recommended Posts

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

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this