Just please. Compile dynamic library for me ;(

It would be funny if Allegro 5 ended up being released on April 1.

I did have a "huh?" moment while looking through the list of contributors as well.
But it puts a series of commits this morning into perspective.

What happens if you change the example to use OpenGL instead of D3D?

4.9.19 binaries are now available on allegro5.org.

I've just built the plain 4.9.19 release (not the latest SVN) and I see an old issue with drawing rectangles:

{"name":"600939","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/0\/b02331d8f6d1e273019d134423c22196.png","w":648,"h":514,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/0\/b02331d8f6d1e273019d134423c22196"}

Maybe it's fixed in the latest SVN?, maybe it only affects old integrated Intel cards since rectangles in the other screenshots posted in this thread appear correctly?.

Oh, and it only seems to happen with the Direct3D driver.

It's missing a pixel in the lower left corner. However I guess with thickness=1 it will look right.

[post removed] Wrong thread. :}

I'm getting an infinite loop here:

The part between the first and second _al_fill_display_settings repeats several thousand times.

...
#14516 0x00e6362c in _al_fill_display_settings (ref=0x16) at /Users/kibiyama/svn/allegro5/src/display_settings.c:161
#14517 0x00e7f3ae in tls_get () at /Users/kibiyama/svn/allegro5/src/tls.c:87
#14518 0x00e7f60b in _al_get_new_display_settings () at /Users/kibiyama/svn/allegro5/src/tls.c:258
#14519 0x00e62a98 in al_set_new_display_option (option=22, value=0, importance=1) at /Users/kibiyama/svn/allegro5/src/display_settings.c:33
#14520 0x00e6362c in _al_fill_display_settings (ref=0x16) at /Users/kibiyama/svn/allegro5/src/display_settings.c:161
#14521 0x00e63788 in _al_fill_display_settings (ref=0xb030d008) at /Users/kibiyama/svn/allegro5/src/display_settings.c:155
#14522 0x00e61cbc in al_create_display (w=800, h=600) at /Users/kibiyama/svn/allegro5/src/display_new.c:56
#14523 0x00c69d73 in ?? ()
#14524 0x00c69cce in ?? ()
#14525 0x00c624a3 in ?? ()
#14526 0x00c6234c in ?? ()
#14527 0x00cd508e in ?? ()
#14528 0x00e8fb04 in call_user_main [inlined] () at /Users/kibiyama/svn/allegro5/src/macosx/osx_app_delegate.m:213
#14529 0x00e8fb04 in +[AllegroAppDelegate app_main:] (self=0xebc3b4, _cmd=0xea6636, arg=0x0) at /Users/kibiyama/svn/allegro5/src/macosx/osx_app_delegate.m:225
#14530 0x909488d8 in -[NSThread main] ()
#14531 0x90948888 in __NSThread__main__ ()
#14532 0x97508fbd in _pthread_start ()
#14533 0x97508e42 in thread_start ()

Happens in SVN as well, with the only difference in the stack trace being display_new.c:57 rather than display_new.c:56.

His 1999 speedhack game was included as a demo.

I'm having some issues with this version:

• Speed does not work properly. I can hear the music but the timing seems a little off. Nothing displays on the screen and I can't exit without force-quitting.

• The manual says 'ALLEGRO_STATE_TRANSFORMATION' is the flag for storing the transformation state but 'ALLEGRO_STATE_TRANSFORM' is how it's defined in the code.

• Setting a target bitmap and then trying to draw outside that target bitmap causes an assertion failure, at least for drawing below the lower edge (a case I ran into with one of my projects).

The display problem is very strange. There's nothing special going on there. Can you try other resolutions (i.e. on the command line, run "speed <w> <h>")?

EDIT: wait, no, it's a windowed mode so that shouldn't matter

With the music, do you mean the pitch is correct, but the notes are a little delayed? There is a background thread (sound_update_proc) that waits for timer events, which then fires new notes. Some latency processing the events could be the culprit, although there may be other reasons. Perhaps you could print out the differences in the event timestamp and al_current_time() and see if they are too large.