scasm 2 vtp naive question

[Guest]

Dear all,I am still going through my first steps into the world of MASM programing.I can see the potential of using BGLC compiler but there is no doubts that as it is, the code for this compiler is much more complex than that needed for the scasm compiler.I tried the latest program scm2vtp by falko which is both a great program but it is also a great concept - converting scasm directly to asm.I tried a few simple examples with this program. I generated a scasm file for a road with only five points. In scasm, the code needed is only 6 lines. The asm version generated by falko's program is almost 100 lines. Nevertheless this program managed to convert one piece of code into another.Now my question is the following. Wouldn't it be possible to work out macros that would enable us to write code that resembles more the scasm type of programming? In this particular example, the info that goes in is a couple of coordinates, the type of object we want and a world location. Couldn't the macros work out the rest of the code?One other approach is a pre-processor like this scm2vtp ideia!I know that this would result in less flexibility but some of the most common tasks could be coded as easily as in scasm.Any views?Cheersjmf

[rhumbaflappy 113]

Hi jmf.Actually BGLC is pretty crude. It'a an assembly language compiler, and it does take a billion lines or so to complete a simple mathematical task. That's why almost every programmer went to the C language.The SDK examples are in C++, so you can bet Microsoft designers didn't use BGLC!In truth, you can use any language capable of creating a binary file output... C, C+, C++, Delphi, Visual Basic.... You can also make the code with a hex editor!By using an output as BGLC code, we maintain a sort of compatability for our code, but we're not tied to assembly language. I'm considering BGLC as more of a "learning Language". Eventually, we'll migrate towards custom applications... like a SCASM, but probably with a higher level interface... a GUI in which you draw a line or give coordinates,and a description of a line or poly type, a texture to use a layer... and the BGL code compiled directly.If you were to look at my 'cellgrid2' package ( here at AVSIM's Library ), you'd see the use of nested Macros in BGLC code. So we can "extend" BGLC as we desire. In fact, if we extend it far enough, we'll have C++. :)So we can evolve several ways:1) We can stick to BGLC and "extend" the language with Macros. Just think of a Macro as a subroutine.2) We can use a complex GUI to derive simple BGLC code for compilation. I think GMAX has an option for this. You're not really tied to the GUI, as you can alter the BGLC output code, before compiling.3) We can use a simpler interface ( SCASM-like or C++-like code ) to derive the binary code directly... avoiding BGLC entirely. Unless such an interface was made open source, we'd inherit the same problems as we have with SCASM... always waiting for the language updates and bug fixes... always tied to one person or group.4) We can use a complex GUI, that in turn compiles code directly, without any "source code" output at all. I'm sure this was more like Microsoft's way. I thinking their GUI's output was to C++, and in turn, that was compiled... but perhaps it was compiled directly.Dick

[Guest]

Hi Dick,Great post!In my opinion we are probably closer to 1) and 3). You already did that in some way for the BGLHeader macro. With this we are using only one line of code instead of a long list of meaningless code.What I was sugesting is one step further to that. One macro or set of embeded macros that would produce the necessary code to draw a road (or a coastline, flatten poly etc).. Looking at the example I already mentioned it seems that a great part of the code is a setup of headers, point or poligon count and texture to use.However, there must be a good reason why you haven't done that yet. I noticed that a set of 5 points in my scasm road has almost 30 points in the asm version. I have no idea why but I have an impression that asm language is not powerfull enough for this sort of maths processing. Is this part of the reason?You also mention a very interesting thing. You can produce a bgl with C++. That explains why the sdk shows C structures but MS failed to show specific examples. Just looking at the SDK alone I cannot do anything usefull apart from banging my head against the wall.I have no idea how to setup a C compiler (VStudio for example) to produce a bgl. I managed to set it up at some point to produce panel gauges but it never crossed my mind that you could use C or C++ to produce sceneries. I like the idea though. C is a very powerful and flexible language! Could you give me some hints in how to approach this?Finaly, could I ask you to briefly comment the code I am enclosing in this message! I am trying to understand it! I am also including the scasm code.Cheers & sorry for the lenghty message!jmf

[rhumbaflappy 113]

Hi jmf.I'm no C++ programmer, but any language that allows you to create a binary file can be used for BGL creation. It's just putting the right bits and bytes in order. That's all BGLC does. If you were to study your compiled BGLC code with a hex editor, you'd begin to to able to read the hex code directly. The only puzzle is the 'little endian' reversed order for WORDs. That's an Intel standard, and that's why we usually have 16LSB ( least significant byte ) for mesh source input.The worst problem for BGLC is a lack of a good, usable set of floating point math routines ( and conversion of INT to FLOAT, and back ). It's probably out there in public domain, as it would be the same as MASM. We just need a BGLCMath Macro published to help with number conversions. Maybe somebody can come up with one and publish it. As far as commenting the code, I can do no better job than Microsoft's SDK. The FS2002 terrain SDK does have a few mistakes, but 99% of it is there. You may have to read it a few times. I printed the SDK out, enclosed it in plastic protectors, put them in a notebook. The book is on my desk every day. And I look at it often. I'll bet I've read it a dozen times. I made the TDFMacros.inc to correspond to the syntax of the SDK's C++ code, so you can understand it exactly.Dick

[wsieffert 0]

If you bang your head on the wall, you'll get C** NOT C++!:-lolAh! My first computer, the SIM-1, single board computer with 6502 CPU and a grand total of 1K (expandable to 4K) RAM. You programmed in hexadecimal with a LED readout.