MAV caused by "Line" ,,,?
Archives Forums/Blitz3D Bug Reports/MAV caused by "Line" ,,,?
| ||
| (oops, ignore the rogue commas in the topic title!) I've dusted off an old B3D project, and been working on it on my laptop. Then, I came upstairs to this computer, and suddenly it's all MAVs. Oddly enough, this line is causing the problem, according to the debugger: Line ((Float(sofar#/max#)*Float(xres%-4))-xx)+1,0,((Float(sofar#/max#)*Float(xres%-4))-xx)+1,7 Okay, maybe I just made a dumb error in all that, so I changed the line to: Line 0,1,2,3 And it still MAVs on it. So, I made a test program that set the 3d graphics mode, and just used the simple Line command above. That worked fine. Ordinarily, I'd assume I did something wrong, but since the program ran okay on my laptop, it looks like Blitz is having a problem with my computer. Clearly, there's something in my program which is triggering it, because the command on it's own works. Even more confusingly, a Rect command a couple of lines above works perfectly fine. If I remove the Line command altogether, the program carries on what it's doing, (which is transitioning from the menu of my game into the game itself... the "Line" is part of the progress bar), it stumbles with another MAV on a Renderworld this time. And yet, the menu uses 3d elements with Renderworld just fine. The computer with the problem is running Vista 32bit. The graphics card is an nVidia 8600 GT. I had fastext installed, but this game doesn't use it, so none of the fastext stuff should be involved. I removed the decls file just to be sure. I know Renderworld can stumble on very large vert counts, but if my rubbish laptop can manage to draw things okay, this machine should be able to as well. And the vert count should be low, same as it was when I wrote this thing in 2004. I have multiple monitors, but have done for years, never been a problem with Blitz before. I disabled monitor 2, and the problem still occurred. I'm sorta stumped on this one. Has anyone come across anything like this? If I can reproduce this in a simple program, I'll post one. |
| ||
| SOLVED IT. Not sure if this is stricly a bug, I'll leave that to BRL to decide: There was a copyrect in there, I was copying the front buffer to the back buffer, and my dumb younger self was copying an area 1 pixel larger in width and height than the screen (ie 0,0,xres%,yres% which is 0,0,800,600 in this case). While that apparently has been okay all these years, it seems to now have some kind of knock-on effect, and by the time the Line command came up, it triggered the MAV. |
| ||
| The various buffers ( front, back, image etc. ) may have the amount allocated memory that you expect. But they may have more, and this extra amount depend on the graphics card and/or driver. I recently checked and found that my current card always pads the width to a multiple of 16. I've seen other numbers in the past on different hardware. Anyway, I guess in one case your error is harmless due to padding. But in the other you are trying to access unallocated memory. |
| ||
| That sounds right. Still, seems like the error could have been a bit more specific, rather than subsequent calls crashing it. Then again, I guess it's like trying to access a missing texture or entity: you don't know it's missing until Blitz crashes telling you it isn't there. The difference is, the error gives you a clue in those cases. |
   |