Tips to avoid unexpected in blitz3D
Blitz3D Forums/Blitz3D Programming/Tips to avoid unexpected in blitz3D
| ||
| Well that's all, for people who have experience in the subject, give me some advice because I am going crazy with unexpected shutdowns without knowing how to deal with effectively. A greeting. |
| ||
| Without example code, all I can really suggest is adopting a strict testing process (and trying to stay relaxed!)... If you're having difficulty finding errors in your program as it stands, the best thing to do is try to create a simpler version of the program that replicates the error. Then the error will either become obvious, or you'll identify it during the elimination process. e.g. (create a copy of your project for this): (Step 0: Run your code as it is, in order to identify a point where you can reliably replicate the error. It sounds like you've already got this bit.) Step 1: Replace all complex media with placeholders. Replace all your meshes with untextured cubes, all your images with blank squares, and comment out any lines loading brushes or animations. Run your code: if it works, the error was in the media; if it doesn't work, go to step 2. Step 2: Comment out the purely visual effects. Turn off shadow casters, remove all FastExtension effects and so on. Run your code again: if it now works without any errors, you know to look in the VFX code. If not, go to step 3. Step 3: Start removing any references to secondary userlibs one by one (e.g. say you were using three separate userlibs, you'd take three separate steps, each time removing all references to one userlib and trying the program again). Step 4: Do the same for any "primary" userlibs that directly affect the way your program works (such as physics engines), and replace them with the bare minimum code required to run the program logic (e.g.if you had a physics-based driving simulation, replace it with simple forward-backward-left-right movement with no collisions). Step 5: If you're still getting the error at this point, it's probably a problem with your program logic. Start removing as many individual lines as possible to simplify program structure without changing it (e.g. if you have any text strings left after step 1, remove them now). This will shorten your program and make it easier to analyse the flow. Step 6: Trace through everything by hand, preferably using pen and paper. Step 7: If you still can't see what's going wrong, post the simplified, shortened code here, and maybe one of the other forum users can help identify the problem! Last edited 2010 |
| ||
| Hi Yasha greatly appreciate your response, I made you eat at exactly what you have said. First I mention that my code is written in modules, for example one is specifically to save variables (Variables.bb) other resources to load the first level and so on. In response to the above I have found and fixed some things, like loading the main menu had a file (Recursos_Menu.bb), where global variables used to charge the net, for example loadmesh Jeep = ("Jeep.b3d") to pass progress indicator representative scene of the menu was removed from memory, with exception of the textures, and to reuse the variable to reload the same jeep, that presents no problems, so the global variable in the first level is no longer Jeep, if not Jeep1. That corrected the unexpected problems. Now the other problem found is that by hooking a camera always make a change of shade in the video options menu and trying to enter the level again unexpectedly quits the application, if the camera hooked the Jeep, everything works fine or if instead leave the system without shadows with the camera hooked everything goes well, another problem is that I have a function that detects collision on the vertices me for the Jeep, and when called a second time closes the application and everything happens loading the first level. In conclusion something happens to the shadow system that can not be, but always unexpected output errors point to the quality change of shade and do not know what to do about it. My question is whether other machines in the same or only happen in mine. I would like to publish the code of each file so they can see but my taste is pretty, but if necessary I can post it. A greeting. Utilizar el Traductor de Google para:Búsquedas Last edited 2010 |
| ||
| another problem is that I have a function that detects collision on the vertices me for the Jeep, and when called a second time closes the application and everything happens loading the first level. Collisions on the vertices? You mean Polygonal Collision Detection? It is really hard to imagine what is wrong when we only know that there is a function, but we don't know what the function is doing. As a suggestion for the google translation: you may translate it back (espaniol>english>espaniol , to see what google translated, because sometimes it's really funny, eg: "I made you eat at exactly what you have said" :) ). Last edited 2010 |
| ||
| I just use Debuglog() in places where i think the error is, this way i can see what is realy going on with mi variables. Simple but i always manage to find the error. What do you mean with unexpected shutdowns exactly? Don't you get error messages in debug mode? Last edited 2010 |
| ||
| Ferret Hi, the program closes without valid information in debug mode. |
| ||
| Error on second function call is a bit hard to track down, so here are my suggestions for simple Debugging. What I do, also because it's language independent: I use the END command. Simply end the app where you think the error happens. This way you'll find the command that is causing the problem. When it ends, the error will be one of the following commands, simply move the END one line down, and so on, until the error happens before it ends. When an error happens only the second time when a function is called, then it's a bit harder to find the error, you should use a global counter with the function call and END only, when the function was called the second time. This way you can isolate the problem as described before. |
| ||
| Yue: I see, i hate these erors, if the debugger does not know then how the hell should we know LOL You will get less errors and solve them quicker as you learn more about Blitz. Most errors i get is accesing something in memory that is not there or typos in variables. Learned a new trick, using END for debugging. |
| ||
| For debugging, i use the "Print" + "Flushkeys" + "Waitkey" commands to check the variables, then when the program is working correctly, i write a semicolon before each of these commands to disable them. For example if a function is modifying a variable, i write this : Variable# = Variable#+X# Print "Variable# : "+Variable# Flushkeys Waitkey So for each step of the program, i can check if the program is working as i want to. It works very well. I don't use debuglog, i have to try that. Last edited 2010 |
   |