Fullscreen crushing. |
Fullscreen crushing. |
Koshmaar
Guest
|
Could you post here the smallest possible source code example which reproduces your problem? It's hard to debug without it... :-) Koshmaar |
|||||||||||||
|
Fullscreen crushing. |
Ryan C. Gordon
Guest
|
Try the windib target...might be a DirectX issue (we've been having those, recently). Set the environment variable "SDL_VIDEODRIVER" to "windib" before running your app: http://www.newbreedsoftware.com/tuxpaint/docs/windib/ Please let us know if this does (or doesn't) fix your problem. --ryan. |
|||||||||||||
|
Fullscreen crushing. |
Milan Golubovic
Guest
|
Hello Koshmaar,
Wednesday, January 4, 2006, 4:49:53 PM, you wrote:
K> Could you post here the smallest possible source code example which K> reproduces your problem? It's hard to debug without it... :-) Sorry, I can't. It's huge already, and chopping it down will take me too much time. But don't get me wrong here. There really is a bug (mine). And from my experience I probably write/read some un allocated memory (out of some array or something). I crushes sometime (with some settings which I can't find now) in window mode too, but all the time in full screen mode. In window mode it crash distant from place where the bug is made, so it's hard to find bug. But in full screen it's even harder, because after every crush I must reboot machine. -- Best regards, Milan mailto:milan_g at eunet.yu |
|||||||||||||||
|
Fullscreen crushing. |
Milan Golubovic
Guest
|
Hello Ryan,
Wednesday, January 4, 2006, 8:04:17 PM, you wrote:
RCG> Try the windib target...might be a DirectX issue (we've been having RCG> those, recently). RCG> Set the environment variable "SDL_VIDEODRIVER" to "windib" before RCG> running your app: No, I'm 99% sure that it is my bug. In some settings (I'm loading level settings, which I can set different) it sometime crash in window mode too. I'm aware of that. Problem is that I can't find again those settings and force it to crush in window mode again. And in full screen every start = crush = reboot. :( -- Best regards, Milan mailto:milan_g at eunet.yu |
|||||||||||||||
|
Fullscreen crushing. |
john.beuving at beatfo...
Guest
|
It sound to me like you have a multithreaded application. So I have some more questions. Do you run graphics in the main thread ? Do you start the application from visual studio (debug) ? If you do start it from visual studio and also visual studio hangs it might be a problem in another thread. Sometimes visual studio will hang if you set a breakpoint in a workerthread. Is this really a SDL problem ? John |
|||||||||||||||||
|
Fullscreen crushing. |
Milan Golubovic
Guest
|
Hello john,
Heh, I think I found it and like I assumed it was my mistake - I was using array elements out of range. I started with little frames, but I was adding and adding and after some time I reached out of defined maximum (400). Sorry for annoying you all guys and thank for your help. -- Best regards, Milan mailto:milan_g at eunet.yu |
|||||||||||
|
Fullscreen crushing. |
Ricardo Cruz
Guest
|
Em Quarta, 4 de Janeiro de 2006 10:42, o Milan Golubovic escreveu:
The task manager sends a signal that can be blocked by the application. There is a way to really kills the application in Windows. I think it's from a tab of the task manager or something. I'm not a Windows user, so I don't know how the dialog to issue such a signal, but it's there somewhere when you press Control-Alt-Del. Cheers, Ricardo -- Warp 7 -- It's a law we can live with. |
|||||||||||||
|
Fullscreen crushing. |
cal at splitreflection...
Guest
|
Milan Golubovic <milan_g at eunet.yu> wrote:
I personally avoid microsoft compilers, so I'll have to advise in generic terms. Build your program with debug information, then run in a debugger. When the program crashes, the debugger should be able to tell you where. If it's a matter of the program going into an infinate loop and being unresponsive, the debuger should be able to interrupt the program and then tell you where it was. |
|||||||||||||
|
Fullscreen crushing. |
Alan Wolfe
Guest
|
What i like to do is make a function that i pass text to. The function
opens a file, writes the text, then closes the file (thus saving the file changes, very important because if it crashes before you close the file, you may be missing text from the log that should be there, which makes it useless). In my code, when im having crashing or preformance problems etc like this, i make it output stuff to the log file in various places in the code. Then, I run the program and when it's done (i killed it, it crashed, whatever) i look at the log file and see what the last thing it said was. If i need more info, i put more output between the last thing it reported and the next thing it should have reported and i keep going in finer and finer detail until i find the line of code causing all the problems. Works really good for me (: ----- Original Message ----- From: "Milan Golubovic" <milan_g at eunet.yu> To: "A list for developers using the SDL library. (includes SDL-announce)" <sdl at libsdl.org> Sent: Thursday, January 05, 2006 4:48 AM Subject: Re: [SDL] Fullscreen crushing.
|
|||||||||||||
|
Fullscreen crushing. |
Ricardo Cruz
Guest
|
Personally, I think a better solution is to just use "fprintf(stderr, ...)"
or "std::cerr" and then "progname 2> log", since it allows you to define the log filename from the command-line or even just let it be displayed on screen. It's also faster and easier to implement. Just my 2 cents, Ricardo Em Quinta, 5 de Janeiro de 2006 21:38, o Alan Wolfe escreveu:
The Fifth Rule: You have taken yourself too seriously. |
|||||||||||||
|
Fullscreen crushing. |
Milan Golubovic
Guest
|
Hello Alan,
Thursday, January 5, 2006, 10:38:59 PM, you wrote: AW> What i like to do is make a function that i pass text to. The function AW> opens a file, writes the text, then closes the file (thus saving the file AW> changes, very important because if it crashes before you close the file, you AW> may be missing text from the log that should be there, which makes it AW> useless). AW> In my code, when im having crashing or preformance problems etc like this, i AW> make it output stuff to the log file in various places in the code. AW> Then, I run the program and when it's done (i killed it, it crashed, AW> whatever) i look at the log file and see what the last thing it said was. AW> If i need more info, i put more output between the last thing it reported AW> and the next thing it should have reported and i keep going in finer and AW> finer detail until i find the line of code causing all the problems. AW> Works really good for me (: Heh, maybe you won't belive me but I got exactly same idea and did same thing and that's how I found where my code is crushing. :) But! I wrote here that I found the bug, but later, even "fixed" that bug appeared again. I got one array where I hold pointers of loaded images: SDL_Surface** bobs; //images And I'm allocating array mem like: bobs= new SDL_Surface* [number_of_bobs]; And for number_of_bobs I always put bigger number that I really got images to load. I.e. I got 217 images and I put 400. 1 KB of memory more or less - who cares. :) So, I found that in my loading function: int MG_BOBS::Load (char* name) { SDL_Surface* tmpsrf=NULL; bobs[first_free]=IMG_Load(name); if (bobs[first_free]) { SDL_SetAlpha(bobs[first_free], SDL_SRCALPHA | SDL_RLEACCEL , 255); tmpsrf=SDL_DisplayFormatAlpha (bobs[first_free]); if (tmpsrf) { SDL_FreeSurface(bobs[first_free]); bobs[first_free]=tmpsrf; } first_free++; return first_free-1; } return -1; } ... func call IMG_Load() crushes. First I didn't checked how many pictures I actually got so I increased number_of_bobs to 1000, program stopped crushing and I realized - it must be it. But later just in case i checked how many bobs I'm really loading(217 so far), so I saw it wasn't it. I also saw that random array size gives me random results - sometime it crushes and sometime not. All this in fullscreen mode only - windowed it never (or very rarely) crush. And crush was always in libpng1.dll I checked on Internet for that lib and saw that some versions crush with alpha channel (which I use), but mine (1.0.8.0) is not mentioned. For testing I removed part of image loading function which converts formats: int MG_BOBS::Load (char* name) { SDL_Surface* tmpsrf=NULL; bobs[first_free]=IMG_Load(name); if (bobs[first_free]) { first_free++; return first_free-1; } return -1; } And THIS works. I expected that my bobs/images (ex Amiga user) will have white background instead of transparent, but that didn't happen ?!? Only my frame rate dropped from 41 to 37 fps. But it works! So, it must be that part of code I removed is messing up unallocated memory and the more unused memory I alloc the better chance for that code part is to hit right there. At end, is this my bug? Or lib is bugged? If so, which version should I use? Is this format conversion really needed (I can live without that extra 4 fps)? -- Best regards, Milan mailto:milan_g at eunet.yu |
|||||||||||
|
Fullscreen crushing. |
Milan Golubovic
Guest
|
Hello Milan,
And me again. I just removed dumping messages to file and it again started crushing even without alpha processing part. I'm stuck at beginning again without any idea how to find a bug. I tried with 2 other libpng.dll libs which I found at www.dlldump.com : libpng12.dll and LibPNG.dll (I just renamed them to "libpng1.dll"), but with them my program wont even compile. MG> Heh, maybe you won't belive me but I got exactly same idea and did same thing MG> and that's how I found where my code is crushing. :) MG> But! MG> I wrote here that I found the bug, but later, even "fixed" that bug appeared again. MG> I got one array where I hold pointers of loaded images: MG> SDL_Surface** bobs; //images MG> And I'm allocating array mem like: MG> bobs= new SDL_Surface* [number_of_bobs]; MG> And for number_of_bobs I always put bigger number that I really got images to MG> load. I.e. I got 217 images and I put 400. 1 KB of memory more or less - who MG> cares. :) MG> So, I found that in my loading function: MG> int MG_BOBS::Load (char* name) MG> { MG> SDL_Surface* tmpsrf=NULL; MG> bobs[first_free]=IMG_Load(name); MG> if (bobs[first_free]) MG> { MG> SDL_SetAlpha(bobs[first_free], SDL_SRCALPHA | SDL_RLEACCEL , 255); MG> tmpsrf=SDL_DisplayFormatAlpha (bobs[first_free]); MG> if (tmpsrf) MG> { MG> SDL_FreeSurface(bobs[first_free]); MG> bobs[first_free]=tmpsrf; MG> } MG> first_free++; MG> return first_free-1; MG> } MG> return -1; MG> } MG> ... func call IMG_Load() crushes. First I didn't checked how many pictures I MG> actually got so I increased number_of_bobs to 1000, program stopped crushing MG> and I realized - it must be it. But later just in case i checked how many bobs MG> I'm really loading(217 so far), so I saw it wasn't it. I also saw that random array size MG> gives me random results - sometime it crushes and sometime not. All this in MG> fullscreen mode only - windowed it never (or very rarely) crush. MG> And crush was always in libpng1.dll MG> I checked on Internet for that lib and saw that some versions crush with alpha MG> channel (which I use), but mine (1.0.8.0) is not mentioned. For testing I MG> removed part of image loading function which converts formats: MG> int MG_BOBS::Load (char* name) MG> { MG> SDL_Surface* tmpsrf=NULL; MG> bobs[first_free]=IMG_Load(name); MG> if (bobs[first_free]) MG> { MG> first_free++; MG> return first_free-1; MG> } MG> return -1; MG> } MG> And THIS works. I expected that my bobs/images (ex Amiga user) will have white MG> background instead of transparent, but that didn't happen ?!? Only my frame rate MG> dropped from 41 to 37 fps. But it works! MG> So, it must be that part of code I removed is messing up unallocated memory and MG> the more unused memory I alloc the better chance for that code part is to hit MG> right there. MG> At end, is this my bug? Or lib is bugged? If so, which version should I use? MG> Is this format conversion really needed (I can live without that extra 4 fps)? -- Best regards, Milan mailto:milan_g at eunet.yu |
|||||||||||
|
Fullscreen crushing. |
Alex Volkov
Guest
|
Milan Golubovic wrote:
[...]
Sounds like something is overflowing buffers somewhere, not necessarily your code or SDL.
This last call is a) completely unnecessary for alpha-channel images; b) a bad idea for alpha-channel images. Do not enable RLE acceleration for alpha-channel images -- I do not even know what SDL would do in such a case, and it just *might* be the root of all your evil. Certainly, the conversion to display format should not cause crashes, unless SDL_image/libpng somehow creates a malformed SDL_Surface.
This may be indirectly due to your app getting a hardware surface when in fullscreen mode. Blits to hardware surfaces are sometimes processed differently. If you remove SDL_RLEACCEL in that last call and it stops crashing for good -- it's most likely a bug in SDL, some unforeseen (?) or unhandled edge case. Also just try removing the SDL_HWSURFACE flag (if you have one) in the SDL_SetVideoMode() call. [...]
SDL_DisplayFormatAlpha() does not *create* transparency, so it wouldn't effect (much) how an image is rendered. But what it does do is convert an image to a format suitable for fast blitting to your screen. So the drop in frame rate is quite normal and expected.
Who knows. SDL_DisplayFormatAlpha() might be bugging when it is faced with a alpha-channel surface that has an SDL_RLEACCEL flag on it -- that would be the first thing I checked. -Alex. |
|||||||||||||||||||||||||||
|
Fullscreen crushing. |
Milan Golubovic
Guest
|
Hello Ryan,
Wednesday, January 4, 2006, 8:04:17 PM, you wrote:
RCG> Try the windib target...might be a DirectX issue (we've been having RCG> those, recently). RCG> Set the environment variable "SDL_VIDEODRIVER" to "windib" before RCG> running your app: RCG> http://www.newbreedsoftware.com/tuxpaint/docs/windib/ RCG> Please let us know if this does (or doesn't) fix your problem. I tried this but nothing changed. -- Best regards, Milan mailto:milan_g at eunet.yu |
|||||||||||||||
|
Fullscreen crushing. |
Milan Golubovic
Guest
|
Hello Milan,
I couldn't make solo project so I removed all unnecessary and put archive at: http://topeurope.org/~milang/Banzai/ It's zipped and about 11 MB, so if any of you experienced coders can take a look, please do. Now it's crushing all the time and exactly on IMG_Load(). Please help! -- Best regards, Milan mailto:milan_g at eunet.yu |
|||||||||||
|