"line" causes a memory access violation?
Blitz3D Forums/Blitz3D Beginners Area/"line" causes a memory access violation?
| ||
| I'm testing this code: Graphics 800,600,16 Repeat SetBuffer BackBuffer() Color 200,200,200 For t=0 To 100 Line 2,3,77,88 Next Flip True Until KeyDown(1) If a do a control-alt-delete and taskmanager, I get a memory access violation. This can't be a bug. (it's soooo basic) or is it? Anyone else get this? Or knows where to find the cause? I have Windows xp and use Blitz3DSetup164 |
| ||
| Blitz3D 1.64 is beyond ancient. Download 1.106 (Account>>Product Updates) and try with that. |
| ||
| I did use an array of other versions including 1.164, and every time the same reaction. I wouldn't mind so much, since it only occurs if I use Taskmanager, but I want to do so in the GUI I'm developing, so I can look for memory-leakage. @GFK: Did you try it out? and if so, no error? |
| ||
| No, I don't have Blitz3D installed - haven't used it in years. The only things I note from your code: 1. SetBuffer(BackBuffer()) should not be inside your main loop. 2. IIRC, Blitz3D apps are prone to crashing if you alt-tab out of them (or CTRL-ALT-DEL). Probably down to DX7. |
| ||
| As far as I remember there was a new function in one of the recent updates, allowing to catch surface-loss (what GfK mentioned under 2.), but AFAIK this is only required when Fullscreen is involved. Update to a recent version, then read the versions.txt that should be found in the install folder. EDIT, it was added in Version 1.99, read more here: http://www.blitzbasic.com/Community/posts.php?topic=81943#923029 |
| ||
| I don't see any problems in the code; it works fine here. Changing buffer in the loop is weird but shouldn't be a problem (you can change buffer whenever you want). Blitz3D apps are prone to crashing if you alt-tab out of them (or CTRL-ALT-DEL). Probably down to DX7. I've never, ever had any problems with Alt+Tab or Ctrl+Alt+Del with Blitz3D (or any other DX7) apps at all. Works perfectly and is very useful. there was a new function in one of the recent updates, allowing to catch surface-loss Pretty sure this isn't relevant; the graphics should only be lost in the case of something like (as suggested in the update log) a desktop resolution change, which destroys the DirectX context or something like that and is a bit of an edge case. Unless you were doing something more advanced that just looking at Task Manager, this shouldn't have happened. Really the only thing I can see that could be a problem are the graphics settings. 800x600x16 may not be supported properly on your system, and changing back to a normal resolution+depth for the desktop might prove difficult for it? (and making this suggestion may reveal my cluelessness about such matters!) Low resolutions (and any colour depth other than 32) are definitely bad for compatibility. |
| ||
| Thanks... Your suggestion helped me in finding some sort of solution. As I understand it?! it has to do with changing resolution and even more with windowed programs. If I run the code in fullscreen mode, I can access taskmanager without an interruption of an error. But I rather not use fullscreen, because I want access to other programs at the same time. Still. It's an improvement. But if someone knows something more...solid? |
| ||
Graphics 800,600,16,3 SetBuffer BackBuffer() Repeat Color 200,200,200 For t=0 To 100 Line 2,3,77,88 Next Flip True Until KeyDown(1) Uses scaled window mode but it can produce unwelcome graphical artifacts. |
| ||
| In "Mode 3" you still get a memory access violation. And it's rather slow and ugly and stinks if you hold it upsidedown ;P I'm now flipflopping between windowed and fullscreen until I have the base more stable. If I have more confidence in my graphic-routines I dare spending more time in windowed testing. Pfyoo, is it newyear already? ;P |
| ||
| A friend of mine said: Why don't you start Taskmanager beforehand?" Well doh... |
   |