Annoying Runtime Error: Please Help !
Blitz3D Forums/Blitz3D Beginners Area/Annoying Runtime Error: Please Help !
| ||
Hi everyone ! I have worked hard these days, avoiding errors and mistakes in my program : all works perfectly or should work perfectly ; Indeed, I get a totally random "Runtime Error" saying "Texture does not exist" then I click on "OK" and it's all I can do. the problem that annoy me is that sometime you get this error and sometime there's no error at all. I've looked into the "Blitz debbuger" and there's a line highlighted: EntityTexture V_Eau_Plan_E, V_Eau_Tex but I'm pretty sure there's nothing wrong with this line ! note that I use the command "ReadFile" and "ReadLine" to get file names, like this : V_Lecture2_S = ReadLine$ ( V_Terrain_Fichier_Config_E ) ; -----------------------------------------73 V_Eau_Tex = LoadTexture ( "data\Data\" + V_Lecture2_S ) So,what do you think ? why this error and sometime not ? please help, I don't want the final user to run into random runtime errors! |
| ||
| Well the error is simple enough. The texture doesn't exist. I suggest putting a Stop in between those two lines you've given above and seeing what line is actually being read by ReadLine. it could be that something's gone wrong with reading your config file, and it's not returning the result you intended. You could also DebugLog the value, if you don't like stopping the program. When you say "random" - do you mean on a per-run basis or that this part of the code gets run more than once in the program? Because if the file is being read again, does it have enough data for two definitions? Or perhaps you're trying to read the same definition but not resetting the file pointer by closing and reopening the file? Last edited 2011 |
| ||
| Hi @Yasha ! I'll do / try what you suggest, and when I say "random" I mean "on a per-run basis": the problematic part of the program gets run only once. |
| ||
| Yeah, it's got to be a problem with ReadLine is not reading the correct line, and therefore not returning the texture stored, just another variable stored. One nice thing about computers is that they will only do exactly what we tell them to, and it's very rare to have the exact same situation and have the computer respond randomly each time. My guess is that when you use WriteLine and ReadLine, it's not consistent from start to finish. Are there any points in your game where you use WriteLine more than once at different times? In other words, does one function have writing commands, and then later on, another function has writing commands? If so, is it possible that if one of these functions is not called or is called too many times, will that throw off the intended line of where you wish to ReadLine the texture stored? Try to replicate the problem on a per-run basis. If you start the game, open a door, do a back flip, and then save when the MAV occurs, then run it again, and do those exact same steps. If you can mimic the previous situation and it pulls the MAV again, then you can come closer to finding out why the texture isn't where it should be. To further test this, once you think you've figured out the pattern as to when the MAV is going to happen, then try a different set of steps until the MAV comes on again, and repeat this process until you've narrowed down all possibilities and you know exactly where the problem lies in your code. |
| ||
| Hi @Rob The Great ! thanks for the help everyone ! I've removed the lines that seems to cause the runtime error, but the problem persists: now it is another texture that is missing and so on... so, patiently I've removed every texture related commands / lines to avoid any runtime error: - now that I've removed the lines there is no missing texture anymore BUT: sometime when I run the program, unexpected things occurs: I get a black screen instead of what my program should display ! I guess it's the same problem, the same runtime error that has "evolved" to a black screen ! - But there is something interesting: when I create an executable from my program no problems occurs and there is no black screen ! I guess [and bet that] the solution to the runtime error is to create an executable... what do you think ? PS: In fact, the problem persists even when running an executable ! It has occured recently in the executable, a black screen. I was wrong. The real problem for me right now is this unexpected behaviour, (a black screen) that occurs sometime. Maybe you know why this is happening? [EDIT]: I found out that the problem has something to do with "NaN" "Not a Number": yes, when I print the coordinates of the camera I get an NaN ! Last edited 2011 |
| ||
| I have noticed that when in Debug mode, Blitz seems to be more sensitive to bad code which could lead to an error in the final product, but if you turn Debug Mode off, the game being run and the executable will run the exact same way. Maybe I'm wrong, but if your executable is having problems, so should the test version Blitz generates. As far as the black screen goes, it could be a wide variety of things: No flip command, the buffers are not set as they should be, you've set AmbientLight to black and created a light with a very limited range, the Cls command will make everything black if it's placed in the right spot, even something as simple as forgetting to make a camera will result in black. So, is it always black from when you first start the program? Does it flicker to black occasionally? In other words, under what conditions will the program go black? If it's black from the get-go, check to make sure you have a camera and some entities to look at. If it's still black, make sure you're performing all 3D rendering and drawing to the backbuffer and that you're flipping it every loop. If you're using windowed 3D mode, make sure your game is active by clicking on the game window. Check your code and make sure that the entities are close enough to the camera and that the camera has a wide enough range to "see" those entities. You mentioned that you removed a lot of textures in the debugging process. Maybe just be sure they aren't being replaced with black textures as you would have no way of being able to see the black on black. If the game starts normal and then flickers to black or holds on black for a while, then you're back to step one which is to figure out why it goes black. Deliberately try to make the screen go black, and when it does, note exactly what was happening. I'm not much of a power programmer, but a lot of people will use commands like DebugLog to keep track of where the program flow is when this happens. I doubt it's an issue, but make sure you have the latest DirectX for your computer and that there aren't any hardware or software incompatibilities. I wish I could help more, but I need more information to know exactly where the problem is. If you're code is relatively small, maybe you can post it and we'll see if we notice any problems. |
| ||
| You can tell if a texture loaded successfully by testing the value of the variable: t = LoadTexture( "whatever.jpg" ) t will now be zero if the load failed. The fact that it may succeed or fail depending on whether you created an executable is happening because of different default directories. The IDE has its own idea of where to place the (temporary) program it builds when you "Run program". Once an executable is created the default will usually be wherever the .exe file is located, although it is possible to override this. For example you can edit the Windows Shortcut used to launch the program. Note you can find out where your program is located with SystemProperty( "AppDir" ). Finally, about the NaN problem. This is almost always the result of dividing by zero somewhere. |
| ||
| Hi @Floyd ! I found where the problem is : yes my program was dividing by zero ! But it's not an error from me : I did everything right ! In fact the problem comes from "ReadLine" because sometime the data is not read correctly and it leads to divisions by zero. I'm pretty sure that "ReadLine" has a bug or a malfunction because the problem is random: -is there a solution to read data correctly ? -Should I post in the "bug report section" about "readLine" ? |
| ||
| I doubt it's a bug because ReadLine is a relatively simple command for Blitz to execute in the sense that it has one purpose: to read 1 line of information from a file and then move the pointer to the next line for the next ReadLine command. Normally, when this command fails, it's because ReadLine is not being used correctly with WriteLine, or ReadLine is not pointing to the specific line you're actually looking for. Look at this example of the lines a data file might contain. Data files don't actually look like this, but it's easier to visualize the problem this way: Texture1.bmp Texture2.bmp 7 Texture3.bmp Notice how lines 1 and 2 are related to texture file names, line 3 is a stored variable to something else, and line 4 is another texture file name. If you're writing a game and you want to read all three texture names, this code would cause a problem:
filein = ReadFile("data.dat") ;Open the file to be read.
FirstTexture$ = ReadLine$(filein) ;FirstTexture$ is now "Texture1.bmp"
SecondTexture$ = ReadLine$(filein) ;SecondTexture$ is now "Texture2.bmp"
ThirdTexture$ = ReadLine$(filein) ;Whoops, the ThirdTexture$ is now "7", not "Texture3.bmp" like you intended.
tex1 = LoadTexture(FirstTexture$) ;This works and loads just fine.
tex2 = LoadTexture(SecondTexture$) ;This works and loads just fine.
tex3 = LoadTexture(ThirdTexture$) ;This is where the problem occurs.
;When Blitz goes to open the texture "7", it won't be able to find anything
;named "7", and thus tex3 becomes 0 to let you know that it failed.
;This sounds like where the divide by zero problem is coming from that you
;mentioned.
If you can, be absolutely 100% positive that the lines are in the correct order, and that you're reading them in the correct order. Check out some of the other commands for File operations. SeekFile might be useful in your situation. Also, it might be worthwhile to make sure all textures you're trying to load match what's stored in the data file. "Texture1.bmp" and "Texure1.bmp" is very easily overlooked by humans, but to Blitz, that's the difference between a successfully loaded texture and a big, fat goose egg being returned. If you can make a very simple and small replication of why you think ReadLine has a bug in it, post it here, and if it's the same for our machines, then we know it's a bug. Keep in mind that this is one of the oldest commands in Blitz, goes back even before 3D was available for Blitz, so if someone else hasn't noticed the bug by now, it's probably not a bug. Last edited 2011 |
   |