I'm working my way through the Allegro tutorials and every time I try to call al_draw_bitmap() the program crashes. I'm not sure why. After some further testing I've found that drawing primitives also crashes the program.
I've created a bitmap and set it as the target bitmap, I'm not sure what else needs to be done before I can draw to it.
]]>post your code...
]]>I betcha a weeks supply of Pepsi(TM)(Nectar of the Godz)that you forgot to do al_init_image_addon(void).
]]>I'm really starting to wonder if Allegro 5+/"6" should have a different API mentality. Ever since I learned about "the common case should be default/easy" for data-oriented design, it really makes sense. In my opinion, everything in Allegro should be defaulted unless you opt out.
allegro_init() should give you every common case "for free". (Or at least have one new function that does that.) Graphics (at default desktop depth), primitives, jpeg/png/whatever input, sound, a single event queue with the mouse/keyboard/joysticks attached, and even a FPS timer occurring once a second with a variable you can send to print (or even have one that hijacks onto al_flip_display and overlays it automatically in the corner).
And, when you want something different than the default, you override those defaults. Default depth is desktop depth, until you manually ask for it. etc.
This would likely be easier in C++ with default arguments, but perhaps with some kind of C method/functioning chaining it could be done.
The people who know what they're doing, are used to writing lines of code for "on the metal" features. The people who don't, should already be in an environment that lets them play around instead of a crash. Maybe the color depth "is wrong", and they can google it/ask about it. But there will still be pixels on the screen which will help them diagnose the problem.
Also, one great thing about D (not suggesting we port it for everyone) is the built-in asserts that allow you to pack a message in. In debug mode, asserts catch a file missing, or a addon not initialized, and halts the program. But you also get a custom message with the assert. "You failed to initialize the addon!" Instead of just a line number in a piece of code. Maybe C supports that (with macros?), but IIRC it doesn't.
]]>Eagle 5 does all this for you. It's super simple, and super easy. Here's the code it takes to display Hello World :
Of course, this is overkill for hello world, but the thing is, it sets up and installs and registers every single input and addon there is for you without having to do it over and over again.
There is a default system timer, queue, input handler, and window manager that does pretty much everything for you.
]]>I think an official add-on with such an "easy" API would be a nice addition to Allegro5. Even with just C, there is quite a bit we could do.
]]>Edgar that Eagle 5 thing looks interesting. Where can I read up on it?
Here's my code, which I'm modifying from a basic A5 sample I found somewhere. I did in fact do al_init_image_addon() on line 22. Or rather, the sample did.
]]>
You don't check if Square is null.
It you're on Linux, filenames are case sensitive too so make sure the name AND the extension match both in letters and case.
And if you're on windows, sometimes the "Base" directory, isn't the one with your files. It could be my_project/bin/ or some other directory. It's called the "Working directory" in Windows.
]]>The problem persists even if I comment out all the references to the Square variable.
]]>Are you sure running with the same version of the library you linked with? I had problems where they didn't match before and it exploded. Try compiling monolithic so there's no DLL/SO.
]]>al_init_primitives_addon is required for al_draw_rectangle
]]>Success! I have it drawing a thing.
]]>al_init_primitives_addon is required for al_draw_rectangle
I thought we covered that already.
]]>Also, free software debugger 101:
1. Find gdb on your system. Or if it didn't come with your toolchain you can find a download for it.
2. gdb .\game.exe
3. run
4. After a crash occurs, bt to view the call stack, ending at the point in your code where it crashed.
You should get a function name in C, and a line number too if you have debugging symbols built in. C++ might be a mess unless you have debugging symbols due to name mangling though.
]]>We did cover that Chris. But I tried adding it without the if statement and it worked.
]]>You can find Eagle here : http://members.allegro.cc/EdgarReynaldo/Eagle.html
Some of the GUI functionality is still undone, but you can do many things with Eagle. Graphics, input, and event handling are all much simplified.
Right now it takes CodeBlocks to build, with MinGW on Windows, gcc on Linux, and I haven't had the opportunity to try and build Eagle on OSX. I wanted to release binaries but I'm still working out a few bugs in the multi threaded aspect of Eagle, trying to make the essentials thread safe.
It works fine for single window (thread) apps though.
]]>