a) just to note, if you click on a piece of example code in the documentation, it will load that example program as a program in the IDE. You can then cut-and-paste it at your leisure, or compile it. etc. Your other points are probably valid. A search would be nice, and definitely more detailed documentation for all commands. For example, ReadData, RestoreData, DefData have no description at all - although I used various forms of Basic in the past, it's been a while and I couldn't remember which of these did what.
b) Regarding incbin, I *think* there are technical reasons why you cannot use variables for the incbin'd files, although that would be nice. The reason is, as soon as you change from a constant (ie give the string of the file as part of the incbin command) to a variable, that would be implying you could change the content of the variable and something else would be incbin'd instead. That doesn't make sense because files are incbin'd at compile-time, not runtime. As the program compiles, the specified file is loaded up and inserted into the executable. This is then a fixed chunk of data in a fixed location in the exe and can't be changed. If you were to use a variable to define what the included file is, at runtime, and changed the content of that variable, a) how would you go about `re-incbin'ing` a different file (same as loading), and no overwrite or waste memory given that the original file size determines its space usage in the exe? If BRL wants to implement adjustable incbin'd files, they would have to come up with a much more flexible system, but then that functionality would be a duplicate of simply loading the files in at run-time anyway. So no point. You can't use variables with incbin, and to refer to it you need to give it a string probably because it uses that as a label to refer to the address of where the data starts. If you used a number (kinda feasible) it wouldn't be so clear. Maybe that's BRL's personal preference. Since Incbin is a compile-time functionality, you don't get any flexibility about what is included. You specify the file, that's it. If they were to try and support redefinable incbin contents, they would have to make an exception to how variables are handled in only that case, which I'm sure would complicate the compiler.
c) That is a bit odd, about the floats, but it probably is to do with the floating point format used. From what I recall, since they use exponents and so on, the numbers that can be represented can only have a certain amount of accuracy. Thus you might see a little extra or less showing up? If you need to, use a `Double` to give you more accuracy. (I don't think this is a bug, is it?)
d) In most modern games these days everything you can see on the screen is completely redrawn every frame. Background preservation algorithms aren't used as much anymore - they prefer to throw CPU/GPU power at it and just refresh everything. So double-buffering is pretty commonplace. Unfortunately that means that what you might've achieved in a single-buffered environment becomes more of the exception than the rule. To get both buffers to look the same and keep the same content, you either have to draw the object to both buffers (which would require you using a bit of OpenGL to redirect drawing to the front buffer). Alternatively you can draw the object to the backbuffer, flip the screen, then either draw that same object to the backbuffer again or copy from the front buffer to the backbuffer. You basically have to draw it twice somehow, either accross 2 frames or by copying part or all of the display. Your easiest bet is probably to draw the object twice - once at the end of rendering the current frame, and again at the start of next frame. That way you don't have to mess with OpenGL.
If there is no OpenGL driver then they won't be able to use your BlitzMax software as it stands. BlitzMax's 2D commands are based on OpenGL and require it to be supported. I have an ibook which has only software OpenGL support, whereas a more modern iMac has hardware OpenGL support. The ibook dates back to at least 1999 so you should be okay in most cases. If there is no support, either state that the user must have OpenGL support, or look for some other graphics rendering library such as Mesa as suggested, or make your own 2D graphics routines.
b) Regarding incbin, I *think* there are technical reasons why you cannot use variables for the incbin'd files, although that would be nice. The reason is, as soon as you change from a constant (ie give the string of the file as part of the incbin command) to a variable, that would be implying you could change the content of the variable and something else would be incbin'd instead. That doesn't make sense because files are incbin'd at compile-time, not runtime. As the program compiles, the specified file is loaded up and inserted into the executable. This is then a fixed chunk of data in a fixed location in the exe and can't be changed. If you were to use a variable to define what the included file is, at runtime, and changed the content of that variable, a) how would you go about `re-incbin'ing` a different file (same as loading), and no overwrite or waste memory given that the original file size determines its space usage in the exe? If BRL wants to implement adjustable incbin'd files, they would have to come up with a much more flexible system, but then that functionality would be a duplicate of simply loading the files in at run-time anyway. So no point. You can't use variables with incbin, and to refer to it you need to give it a string probably because it uses that as a label to refer to the address of where the data starts. If you used a number (kinda feasible) it wouldn't be so clear. Maybe that's BRL's personal preference. Since Incbin is a compile-time functionality, you don't get any flexibility about what is included. You specify the file, that's it. If they were to try and support redefinable incbin contents, they would have to make an exception to how variables are handled in only that case, which I'm sure would complicate the compiler.
c) That is a bit odd, about the floats, but it probably is to do with the floating point format used. From what I recall, since they use exponents and so on, the numbers that can be represented can only have a certain amount of accuracy. Thus you might see a little extra or less showing up? If you need to, use a `Double` to give you more accuracy. (I don't think this is a bug, is it?)
d) In most modern games these days everything you can see on the screen is completely redrawn every frame. Background preservation algorithms aren't used as much anymore - they prefer to throw CPU/GPU power at it and just refresh everything. So double-buffering is pretty commonplace. Unfortunately that means that what you might've achieved in a single-buffered environment becomes more of the exception than the rule. To get both buffers to look the same and keep the same content, you either have to draw the object to both buffers (which would require you using a bit of OpenGL to redirect drawing to the front buffer). Alternatively you can draw the object to the backbuffer, flip the screen, then either draw that same object to the backbuffer again or copy from the front buffer to the backbuffer. You basically have to draw it twice somehow, either accross 2 frames or by copying part or all of the display. Your easiest bet is probably to draw the object twice - once at the end of rendering the current frame, and again at the start of next frame. That way you don't have to mess with OpenGL.
If there is no OpenGL driver then they won't be able to use your BlitzMax software as it stands. BlitzMax's 2D commands are based on OpenGL and require it to be supported. I have an ibook which has only software OpenGL support, whereas a more modern iMac has hardware OpenGL support. The ibook dates back to at least 1999 so you should be okay in most cases. If there is no support, either state that the user must have OpenGL support, or look for some other graphics rendering library such as Mesa as suggested, or make your own 2D graphics routines.