It may have something to do with the fact that you're trying to allocate over 4 gigabytes of memory for a single image. Most of the time, this is caused by using a bitmap whose header is not being read correctly (in my experience, due to the difference between Windows and Mac bitmap header standards), since the self-declared image size in the header is used to allocate memory.

The best way to work around this in SDL, in my opinion, is to not use bitmaps. I know it sounds extreme, but there are better (smaller, faster) file formats that are actually easier to load, handle, and map to textures than copying bits from a bitmap. See SDL_image, or other image libraries documented on these forums, for more details.

TythosEternal Wrote:It may have something to do with the fact that you're trying to allocate over 4 gigabytes of memory for a single image. Most of the time, this is caused by using a bitmap whose header is not being read correctly (in my experience, due to the difference between Windows and Mac bitmap header standards), since the self-declared image size in the header is used to allocate memory.

The best way to work around this in SDL, in my opinion, is to not use bitmaps. I know it sounds extreme, but there are better (smaller, faster) file formats that are actually easier to load, handle, and map to textures than copying bits from a bitmap. See SDL_image, or other image libraries documented on these forums, for more details.

I have tried to use DL_image but I keep getting an error that it can't find the SDL_image.h file when I compile. I have the framework in the /library/frameworks directory.

My hard drive just died on me, but I will try again when I have everything up and running again.

You need to specify the location of a copy of SDL_image.h (possibly copying the file to your project directory), but mainly make sure you link the framework library to your project. I've had very few problems with SDL_image, but one alternative library that a lot of people on this forum use is libpng. In any case, you need to be cautious when utilizing bitmap headers on a Mac because of the different standards; either you need to account for it, or use another format / loading library.

You're part way there. I'm assuming you're still getting the "can't find sdl_image.h" message at compile time. You might want to review the C/C++ compiling process. (It's ok, I've been programming for 20+ years and I never fully understood it until about a year ago.) Wikipedia's article on compilers isn't a bad place to start, but it might be a little vague and abstract. There's also this article from Duke's computer science department:

Basically, your project is not compiling the entire SDL_image library with the main code. Instead, it is referencing the framework with the assumption that it will be available at link time or runtime. (That's why you need to include uncommon frameworks, like SDL_Image, in your install package when you get around to releasing your final code - that's the only way to guarantee that Bob will have the same libraries available when he tries to run your program on his computer.)

In order to use the framework, though, you have to include the header that tells the compiler which functions are going to be available to the program at compile time. The header, SDL_image.h, is different from the actual framework / library because it just declares the functions, and doesn't actually define them. To include the header file, copy a version to your project folder and use the usual pre-compiler instruction:

Ok, I'm still not getting it and I don't know why. I know that I need to include the framework for the project to work for people that don't have it. I was under the assumption that when I add a file to the project, then compile it, xcode puts it in the app bundle.

I looked at the contents on the app bundle and the only framework I see there is the SDL.framework. Is my problem that xcode is not including the SDL_image.framework in the app bundle?

Sorry that I don't get it. Seems like it should be an easy task. I also wanted to use the SDL_ttf.framework too. I'm assuming that I will have the same issue.

Yes, the process will be the same for other frameworks. You need to do 2 things for the framework to be used correctly in your program:
- Include the framework in your project
- #include "" the framework header in your source code

Note on the left that the framework SDL_image.framework is being linked against the project. Note on the right that the header is being included from the source code, #include "SDL_image.h"

The last thing you'll have to worry about is including the framework in your installation package once you've finished your program. Apple makes this very easy via PackageMaker, though, so you really don't have to do any extra work.

My app looks the same as yours as far as the SDL_Image framework. I have added it into "Linked Frameworks" group in Xcode. Then right after I "#include SDL.h" I put "#include SDL_image.h". I always get "error: SDL_image.h: no such file or directory".

While I could not get this to work I did try to use Opengl (with no success) and the frameworks needed for that were fine. It seems to be only frameworks that I have added that give me this issue.

I also have a problem refreshing my screen. I found a bmp file that did not give me an error. When I put in my code SDL_flip(window) the app hangs and the console gives me this when I try to continue the app.

Quote:Program received signal: â€œEXC_BAD_ACCESSâ€.

I don't know why I keep running into these problems. I've used SDL before and was able to get things working well.

Regarding #include "SDL_image.h": that's because you have to copy the header SDL_image.h to your project directly.

Regarding the access error: As far as I can tell, that's a kernel-level conflict that has less to do with your library and more to do with (I'm guessing) bad memory management. This is just a shot in the dark, though - it's hard to say more without knowing more. Either way, you might want to create a new post for the new problem so you get some more expert opinions on that one.