What's different between Debug and Release?
BlitzMax Forums/BlitzMax Programming/What's different between Debug and Release?
| ||
| I have a module and a test program which I've been working on for ages in debug mode which doesn't work at all well in release. It's using my TV3D module plus my own module so I can't possibly post code, but I'd like some suggestions on how to debug this. ( Since debug mode is how I generally debug ;) ) It's a GUI module built on TV3D, and the text ( bitmap fonts ) are rendered in release, but the other rendering ( also bitmaps ) are not. All media is IncBin'ed, but if that was wrong, I'm thinking I would get an error, and besides TV3D renders white meshes when textures are not found. I really can't think of anything else which is or could be different between debug and release. I do NOT use ?debug or ?release ( if that's even the right directives ) at all ever, so it's assuredly not that. |
| ||
| One of the main differences is that some modules are not linked in in release (for example the one that checks array boundaries) ... did you test with framework in debug to ensure such "invis bindings" are not causing the problem? |
| ||
| Yeah, I tried adding in Framework brl.bank and Framework brl.stream ( alternately ) and both work just fine, so it doesn't look like that. It's not crashing, and it actually does draw everything right in debug, so it won't be array bounds. Very puzzling. |
| ||
| If it does not give any error, then there must be a reason for it normally, because the most common thing that would happen is a MAV or media not found crash. I assume you are using strict everywhere? Theoretically the only difference between release and debug are the debug stuff thats used to check loops and array bounds Btw: the fact that it does not break with array in debug does not mean that they aren't the problem. Dont forget that loops are several times slower in debug than in release, so the app must run much longer to reach the same point ie the same type of errors as the release version. To test such stuff, declare methods / function you know they work correctly, as nodebug (ex: method test() nodebug). That way, loops in them run on release speed even in debug and you might find your problem after all. |
| ||
| SuperStrict, yes. Speed between debug and release is identical ( 850 FPS ) and besides, it displays wrong immediately in release and can run forever in debug. Nothing ever changes anyway, it's only a VERY simple test of displaying a couple of gadgets. The only thing that springs to my mind is that perhaps the debug version of the module is compiling properly but the release version is corrupted somehow. If I can't fix it, I may try a reinstall of BMax and/or MinGW, as a bit of a hail mary. |
| ||
| Could this be a problem with MaXML? I'm trying to see what connects the things that are being drawn and the things that aren't and all I can find is the XML stuff I'm using to put all my GUI components on a texture. |
| ||
| I've played with this a little more, and although it's very hard to test, I can confirm that it's definitely either MaXML or a module I wrote which uses MaXML. I'm assuming that it's my module for now, but there's so little to it that it's surprising. Any further suggestions are welcome, and I'll post if and when I can find any more information. |
| ||
| As we don't know how you connected all that stuff, its hard till impossible to "help" you beside general ideas. |
| ||
| I was thinking specifically of anyone who's noticed anything not working quite right with MaxML in release mode. If I can eliminate that possibility, it means I'm down to only having to check my own code, which is much easier. |
| ||
| Are you just getting errors or no textures drawn best option would be to create a method for each type thats saves it details to a log on instance creation. this could contain Image names and basic creation data at least then you can narrow it down to a function hopefully and maybe whats to blame your mod or Maxml |
| ||
| Also Gabriel The WhiteMesh Statement is not correct depending on how lighting is set and and which light is selected meshes can appear blank ie fully trans i did this by accident the other day and bugged the hell out of me |
| ||
| Thanks, but I've already confirmed that the error is with MaXml. I'm not up to fixing it myself, I'm really not very good at reading other people's code. So I'll continue to work in debug mode until it gets fixed, or I'll just write my own XML parser from scratch if it doesn't get fixed. |
   |