The Allegro Wiki is migrating to github at https://github.com/liballeg/allegro_wiki/wiki

Talk:Allegro Hack Day/2007 April 7

From Allegro Wiki
Jump to: navigation, search

Vista Themes /w Allegro

Under windowed mode, "Aero Glass" is only disabled when running in a non-native color depth. I don't know if this is a problem that Allegro can even "fix." A simple solution is to use: set_color_depth (desktop_color_depth()); for 15/16/24/32 color depths. That obviously does not address 8-bit modes. Matthew Leverton 14:52, April 9, 2007 (MDT)

OSX implementation

I've written an OpenGL driver for Allegro on OSX. It's basically functional but contains some omissions and bugs. I have a number of questions about it.

At the moment it is unaccelerated so I'm using allegro graphics to draw to a buffer which matches the screen, then updating the GL context. If we want to mix 'native' GL drawing and direct pixel manipulation we need to read back from GL as well as writing to it.

Here's my scheme:

  • acquire_bitmap: ensure that the GL context is current, obtain a lock
  • bitmap_read_line: Acquire the bitmap if not already done. Read back from the GL buffer with glReadPixels if not already done. Mark line as read
  • bitmap_write_line: As bitmap_read_line, also mark line dirty
  • bitmap_unwrite_line: release bitmap if it was acquired by the above
  • release_bitmap: Write all dirty lines using glDrawPixels, release lock

This is not too bad performance-wise but not ideal. Hopefully as more allegro drawing functions get rewritten as GL drawing functions, direct pixel manipulation will be rare, so the above scheme will not be used often.

Indexed mode (8 bit)

I couldn't see how to get an indexed mode in OSX's OpenGL, so it's done via emulation using glColorMap. Unfortunately this means the 'read back' won't work as glReadPixels won't read back colour indices if GL is not in indexed mode. Because all the drawing is done by Allegro, and because of the indexed mode issue, I disabled read-back for now. Is there a better way to do indexed mode? Should we drop indexed mode support?

Multithreading

On OSX the active GL context is maintained per thread, so each new thread needs to select a context before drawing. How should this be done?

Implementation

The structure of AL_DISPLAY has not been defined yet AFAIK. I have implemented Objective-C class ALDisplay which can be subclassed with ALDisplayWin, ALDisplayFullscreen and ALDisplayOffscreen. Only ALDisplayWin is done at the moment. It works OK but the biggest omission so far is sub-bitmaps. I'm not sure how to implement this. ALDisplayWin almost encapsulates everything so that multiple displays are possible. I say almost because there are some globals still - e.g. the dimensions of the screen are in the GFX_DRIVER struct, not the screen bitmap. Hopefully in the future these classes can be 'mapped' to AL_DISPLAY. Events (mouse & keyboard) are captured by the OpenGL view and passed onto the keyboard and mouse handlers. How are the events to be transmitted if there is more than 1 display (i.e. more than 1 window onscreen.) As far as I can see, the GL output is retained, so covering and uncovering the window doesn't require the window to be repainted. The implementation is set up to receive repaint events from the OS.

At the moment it's a no-op but it could post an event to the Allegro event queue. Is this desirable and what's the protocol?

Closing

At the moment Allegro has a callback function which is called if the user tries to close the app. This has to be extended for multiple windows, and also 'All windows' if the user selects the quit menu from the menu bar or dock icon (or taskbar for windows) What's the best way to do this?

On offscreen rendering, the suggestion was to attach a bitmap to an existing display. Another option would be to create a display from an existing bitmap, i.e.

AL_DISPLAY* disp = al_create_display_from_bitmap(my_bitmap);
// Draw... 
al_destroy_display(disp);
// Now use my_bitmap for drawing elsewhere

Depends a bit on how GL works with offscreen buffers, there are several ways to do it, aren't there?

I'll upload the new files as a diff against SVN as soon as I can.

Peter Hull 07:34, May 11, 2007 (MDT)