A quick search doesn't bring up anything - I tried running one of my old games
http://www.increpare.com/2008/12/rara-racer/
which was done in allegro 4.3, and get a crash in:
0 liballeg-4.3.dylib 0x00219aa9 _linear_clear_to_color32 + 105
anyway, I wonder if there's any easy workaround for this or, if not, if there's any more recent version that's confirmed to work in lion?
]]>Did they drop QuickDraw in Lion? It's been deprecated for a while. If so, Allegro 4.* programs will not work.
]]>according to somewhere on the internet ( https://bugzilla.mozilla.org/show_bug.cgi?id=661636 )
"Most QuickDraw header files have disappeared from OS X 10.7, and from the OS X 10.7 SDK. "
Guess that answers that. Hmm. Will be a pain, but can probably port most the games to something newer.
]]>A quick search doesn't bring up anything
What did you expect? Lion has only been released today. 
Anyway, apart from that, I guess that's it as far as Allegro 4 is concerned. Allegro 5 should be fine though, but it'd be great if someone could try it out and report any issues they run into.
]]>Elias downloaded it and I paused my download most of the way through so I could do some stuff in Windows. I'll be trying it with my game in the next few days for sure since I'm doing a release.
]]>I paused my download most of the way through so I could do some stuff in Windows.
Must... resist... urge... to sig!
]]>It should still work even if the headers are missing.
]]>Unless the headers missing is a sign of other things missing.
]]>Possibly the same problem that SDL 1.2 has (doesn't work in fullscreen software mode). From ( http://forums.libsdl.org/viewtopic.php?p=29146#29146 ) :
"
CGDisplayBaseAddress() has been deprecated in 10.6 and while it still exists on 10.7, it now returns NULL instead of the display's base address. SDL_SetVideoMode() ends up calling a number of deprecated CG functions via the Quartz implementation including CGDisplayBaseAddress(). It is SDL_SetVideoMode()'s call to SDL_ClearSurface() that actually causes the crash when it tries to clear the frame buffer memory at address zero.
A new set of APIs has been added as of 10.6 and while they let you capture a display, they do not allow direct frame buffer access. Quartz or OpenGL are the only methods that can update a captured display.
"
can't find any fixes for it based on a google about, and the associated bug in sdl's bug tracker ( http://bugzilla.libsdl.org/show_bug.cgi?id=1215 ) hasn't been fixed.
]]>A new set of APIs has been added as of 10.6 and while they let you capture a display, they do not allow direct frame buffer access. Quartz or OpenGL are the only methods that can update a captured display.
I was under the impression that very few if any video cards now have cpu addressable video memory. OpenGL allows you to upload a block of system memory to video, but that's different, the driver tells the card to fetch it.
[EDIT]
On second thought, that was rather stupid of me to say cards don't have any cpu addressable memory, as the computer BIOS has to use VGA mode 3 or similar.
]]>this breaks zsnes on 10.7 as well. Quickdraw still works partially, just can't be in full screen.
]]>I'm not familiar with the intricacies of OSX updates (or rendering on the Mac for that matter!), but for what it's worth, this is an issue of great importance to me too.
Sorry, but what should I expect here? Is this the sort of thing Apple will fix in a future update? Or does that depend on community response? And if not, will a workaround in Allegro 4.x be feasible? I get the impression they're phasing out software rendering altogether, but again, not exactly an expert on the subject here. 
It's just frustrating, since Allegro applications have run flawlessly and consistently on all my Windows machines the last decade. Consequently, I've put a lot of work into an Allegro-bound framework with which I was THIS close to attempting to deploy to Mac for the first time. (A matter of days, I swear!)
TL;DR: $%@#&, I hope this gets fixed! 
Is this the sort of thing Apple will fix in a future update?
No.
The API has been deprecated for a very long time, and they're now finally removing support for it. They will not reverse that.
And if not, will a workaround in Allegro 4.x be feasible?
Not very likely, unless someone is willing to invest the time and energy in updating Allegro 4.
This has been a long time coming, and for me was one of the initial reasons to switch to using Allegro 5.
]]>It's just frustrating, since Allegro applications have run flawlessly and consistently on all my Windows machines the last decade
There are problems with Windows Vista / 7 too, although those can mostly be worked around. And the ones that cannot, probably could be fixed without too much trouble... at least for now.
]]>@Evert: Ah, just as I feared. And "updating Allegro 4" in this case would mean a full-scale conversion to hardware rendering, I assume. Ugh. 
@Matthew: There are? I'm on Win 7 64bit now (previously Vista on a laptop), but I guess I'm simply not accessing these components? Either way, it's nothing on the level of not being able to draw to the screen! I hope that ominous "at least for now" doesn't mean you've heard something about this happening... have you? 
P.S. I finally got 'round to checking out A5 a week or so ago. Great stuff! Kudos to everyone involved. Quick to set up, worked fine, and I for one dig the style of function_names.
Also, the threaded, event-based timing is SUCH an improvement. However, browsing through the (Windows) source, I didn't see it checking QPC against ticks for jumps or setting the thread affinity, but A) I'm not sure I was looking at the development branch to begin with and B) this is getting stupidly off-topic, sorry.
Anyway, thanks for the quick replies! I never post, but this forum has been my go-to place for programming knowledge, no matter what I've been working on/with, for a long time. All the best! 
(Heh, I think the notion of A4 games not working on future systems has got me a bit... sentimental.)
]]>Either way, it's nothing on the level of not being able to draw to the screen!
But it does. e.g., There are problems with DX windows not updating and 8-bit palettes not working in full screen.
I hope that ominous "at least for now" doesn't mean you've heard something about this happening... does it?
Nothing specific, no.
]]>I see... Mostly I use it for retro, pixely-style games, which aren't typically being rendered in "true" full screen on modern computers, anyway (what with their low resolutions and not-widescreen display ratios). But that is good to know, thanks!
I guess ultimately what I need to do, if I plan on continuing to make this sorta stuff into the future, is recreate the retro look (with all its quirks) using hardware-accelerated methods. Not terribly difficult, I suppose, but I'm just so lazy.
(Also, a big part of not doing this to begin with was the idea that using 4.x would be "more compatible" or something, which is apparently-and-increasingly untrue! Jeepers.)
]]>