Hey Grey.
With your new DMG everything worked fine once the application is dragged out of the disk image and onto the `real harddrive` or desktop. Running from the HD or desktop works fine. However, *usually* most games will run directly from the disk image itself without requiring it to be put into the applications folder or whatever. Your game does `run` but it comes up with a message saying it can't write an ini file. The path it's trying to write to is presumably within the DMG disk and not on the real harddrive. Just something to consider. Also you probably should not have a data folder alongside the .app unless you're going to put both of them into an enclosing folder, otherwise the user has to create a folder to keep both in the same place.
As to your framework itself, you have improved and tweaked it nicely. The game is more impressive with lots more objects onscreen and your explosions and sound effects are much better. Everything worked correctly and once I figured out to hold down the Z key instead of pressing it many times suddenly proved to make it very easy to progress; -D
Everything seemed to work fine with regards to prefs and options, except for when switching to or from windowed mode. This *TOTALLY* screwed with your graphics. I can't even begin to describe what happens to your visuals when switching between those modes. ... Well, to give some idea, many image textures are lost, resulting in various pieces of the GUI etc becoming white instead of textured. There is some kind of crazy thing which goes on with the buffers, etc. Changing between screens within the game while remaining in windowed mode seems to for the most part restore most of the images but not all of them. It's pretty wierd.
I am not sure whether you can trust that when you switch between full and windowed modes the graphics will all be retained. It was my understanding at some point in BlitzMax's past that it was not able to retain any images in videoram when you close the screen or window, because it loses the OpenGL context and thus all textures. This *seems* to be what is happening, because switching between modes seems to give you `leftover` graphics and missing image data, as if you were accidentally referencing parts of video ram which are now partly overwritten or whatever. Unless someone can say for sure that Max is supposed to be able to retain all image data after an EndGraphics(), I think I would personally re-upload all texture data (images) upon opening a new display.
See below 9 screens which occurred after swapping between full and windowed and back. You get different corruption each time. As you can in some of the shots the mouse pointer graphic is actually taking the place of the backdrop image in the menu! This is not a bug in your code, I think it is more likely the effect of texture references getting lost and confused and using old references which are disassociated from their proper texture data.
With your new DMG everything worked fine once the application is dragged out of the disk image and onto the `real harddrive` or desktop. Running from the HD or desktop works fine. However, *usually* most games will run directly from the disk image itself without requiring it to be put into the applications folder or whatever. Your game does `run` but it comes up with a message saying it can't write an ini file. The path it's trying to write to is presumably within the DMG disk and not on the real harddrive. Just something to consider. Also you probably should not have a data folder alongside the .app unless you're going to put both of them into an enclosing folder, otherwise the user has to create a folder to keep both in the same place.
As to your framework itself, you have improved and tweaked it nicely. The game is more impressive with lots more objects onscreen and your explosions and sound effects are much better. Everything worked correctly and once I figured out to hold down the Z key instead of pressing it many times suddenly proved to make it very easy to progress; -D
Everything seemed to work fine with regards to prefs and options, except for when switching to or from windowed mode. This *TOTALLY* screwed with your graphics. I can't even begin to describe what happens to your visuals when switching between those modes. ... Well, to give some idea, many image textures are lost, resulting in various pieces of the GUI etc becoming white instead of textured. There is some kind of crazy thing which goes on with the buffers, etc. Changing between screens within the game while remaining in windowed mode seems to for the most part restore most of the images but not all of them. It's pretty wierd.
I am not sure whether you can trust that when you switch between full and windowed modes the graphics will all be retained. It was my understanding at some point in BlitzMax's past that it was not able to retain any images in videoram when you close the screen or window, because it loses the OpenGL context and thus all textures. This *seems* to be what is happening, because switching between modes seems to give you `leftover` graphics and missing image data, as if you were accidentally referencing parts of video ram which are now partly overwritten or whatever. Unless someone can say for sure that Max is supposed to be able to retain all image data after an EndGraphics(), I think I would personally re-upload all texture data (images) upon opening a new display.
See below 9 screens which occurred after swapping between full and windowed and back. You get different corruption each time. As you can in some of the shots the mouse pointer graphic is actually taking the place of the backdrop image in the menu! This is not a bug in your code, I think it is more likely the effect of texture references getting lost and confused and using old references which are disassociated from their proper texture data.