Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 4.2.2

This thread is locked; no one can reply to it. rss feed Print
Allegro 4.2.2
Peter Wang
Member #23
April 2000

Allegro 4.2.2 is available on SF.net.

Thanks to everyone who sent bug reports and patches, and to Matthew Leverton for testing and patches in these last couple of weeks.

change log said:

Quote:

=====================================================================
============ Changes from 4.2.2 RC1 to 4.2.2 (July 2007) ============
=====================================================================

Matthew Leverton added build instructions for DMC and updated the MSVC
project files and instructions.

Matthew Leverton added a shell script wrapper around gcc to build universal
binaries (i386 + PPC) on Mac OS X and made the Allegro makefile use it.

Peter Hull reenabled the Quit menu option on Mac OS X when
set_close_button_callback is used.

Rikard Peterson fixed the Mac OS X joystick driver so that
HID_ELEMENT_STANDALONE_AXIS axes correctly got the flag JOYFLAG_UNSIGNED
and not JOYFLAG_DIGITAL.

Matthew Leverton fixed a problem with the GDI driver blitting a rectangle
smaller than the bitmap's height that touches the bottom left corner of a
bitmap.

Some minor changes.

=====================================================================
============ Changes from 4.2.1 to 4.2.2 RC1 (July 2007) ============
=====================================================================

Matthew Leverton added project files for MSVC 6/7/8 (see the build
directory and Allegro Wiki for instructions).

Matthew Leverton added initial support for the Digital Mars C compiler
(for the Windows port). It only works with the C-only port and
obj\dmc\plugins.h needs to be built by hand.

Peter Wang cleaned up most of the autoconf namespace pollution.

Matthew Smith made a fix for C locking code in GDI.

Trent Gamblin made the fullscreen DirectX driver save and restore the
palette when switching away and back in 8-bit video modes.

Elias Pschernig added missing documentation for pack_ungetc().

Trent Gamblin fixed the C version of stretch_blit so it now draws
correctly. He also made it about 20% faster along the way.

orz and Matthew Leverton made the ALLEGRO_USE_C=1 option to work under
MinGW and MSVC.

Erno Schwetter fixed a long-standing bug in polygon() where the
bottom-most pixels would not be drawn.

Anthony 'Timorg' Cassidy made d_menu_proc fill up its assigned area with
the gui_bg_color.

Phil Krylov fixed a bug that prevented load_bios_font() from loading 8x16
fonts.

Etienne Vouga fixed a bug with the reset_controllers MIDI command.

Milan Mimica fixed a double SWITCH_IN event callback bug when
de-minimizing an Allegro program in Windows.

Erno Schwetter fixed a bug where __al_linux_console_fd was used in
display_switch_lock() without the console being initialized first.

Erno Schwetter fixed an unbalanced __al_linux_console_graphics() call.

Ryan Patterson fixed a crash in free_config_entries.

Elias Pschernig added support for horizontal wheel mice (so far, only the
X11 driver reports any horizontal wheel movement though). Also increased
the number of supported mouse buttons from 3 to 5 for the X11 driver.

Jon Rafkind and Karthik Kumar fixed a problem where allegro-config would
respect neither --libdir nor --includedir.

Peter Wang fixed some problems with the ALSA MIDI driver in the case of
failure.

torhu fixed a bug in akaitest where an array was indexed with -1.

Trent Gamblin implemented set_mouse_speed under X11. Peter Wang made
setting stick only while the cursor is in the Allegro window.

Evert Glebbeek added desktop_color_depth and get_desktop_resolution to the
Linux fbcon driver.

Matthew Leverton fixed building of universal binaries on MacOS X. This
currently requires OS X 10.4 on both PPC and Intel.

Milan Miminca made the fbcon driver initialization fail if an unsupported
color depth was set.

Michal Molhanec and Milan Mimica simplified the MSVC build process
and updated the documentation.

Andrei Ellman made the MSVC makefile compatible with cygwin port of
make-3.81 (and newer?). makefile.vc now uses cygpath tool to convert DOS
8.3 paths to unix-style paths.

Daniel Schlyder added a functions is_trans_font, font_has_alpha.

Daniel Schlyder made load_txt_font() additionally search for files
referenced in the font script in the same directory as the script itself.
It still searches in the current working directory first (for relative
paths).

Daniel Schlyder documented that register_assert_handler() and
register_trace_handler() can be called before initialising Allegro.

Daniel Schlyder prevented the Windows port from registering its default
trace handler on initialisation if the user had previously registered a
custom trace handler.

Andrei Ellman modified the 6-to-8 bit value scaling tables to be more
evenly distributed, and changed the implementation of
create_blender_table() to create a more evenly distributed distribution of
the lower 2 bits. It should be faster as well.

Other minor bug fixes and documentation updates.

Matthew Leverton
Supreme Loser
January 1999
avatar

Binaries will be uploaded to the files page within the next 24 hours.

Update: All binaries have been uploaded, except for AllegroGL as I'm waiting for 0.4.2 final.

I have added binaries for DMC, but am no longer providing binaries for BCC.

Paul Pridham
Member #250
April 2000
avatar

Awesome, great work! I'll be upgrading to Allegro 4.2.2 tonight.

GullRaDriel
Member #3,861
September 2003
avatar

All version compiled, all my projects, example && projects are working ok.

WXPSP2, Amd Turion Mingw32

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Paul Pridham
Member #250
April 2000
avatar

OK, with the new Allegro and new AllegroGL, SaucelifterGL runs nice and smooth. The framerate seems faster and more stable than before.

However, the software version seems a bit slower, and there's a glitch that is appearing during some of the polygon drawing.

Check the attachments to see the difference between the software and OpenGL versions. The polygon in question is highlighted in red.

Software:
http://www.allegro.cc/files/attachment/592705

OpenGL:
http://www.allegro.cc/files/attachment/592706

Matthew Leverton
Supreme Loser
January 1999
avatar

Any differences with polygon drawing were probably introduced with this patch.

Edit: Plus if you switched from the assembly version to the C only version, maybe that would affect things.

Paul Pridham
Member #250
April 2000
avatar

How does one switch from the assembly version to the C only version? If I did so, I did it unknowingly. I simply downloaded the Windows/DOS 4.2.2 package from the files area and built it.

Elias
Member #358
May 2000

Can you somehow find out the positions of the polygon vertices, and make a simple test case?

Maybe we can reach the guy who wrote that polygon patch and he can fix it :)

Or if it turns out it is now more broken than before, revert the patch. But previously it was leaving out the complete bottom line, now it seems only the middle part of it, so still an improvement :P

--
"Either help out or stop whining" - Evert

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

How does one switch from the assembly version to the C only version? If I did so, I did it unknowingly. I simply downloaded the Windows/DOS 4.2.2 package from the files area and built it.

The MSVC project files are 100% C. If you use the makefiles, you'd have to explicitly set ALLEGRO_USE_C=1.

Paul Pridham
Member #250
April 2000
avatar

Elias: I can take a look at it later tonight. Interestingly, some polygons that are flat on the bottom do not exhibit the behaviour. IE. look at the bunker in my screenshot.

Matthew: OK then, I used the makefiles and didn't specify ALLEGRO_USE_C.

- Update -

I've investigated this further. The little chunk missing from the polygon is not the fault of Allegro (not directly). It's the top edge of a rectangle that I place in order to hide the gun before it has risen out of its base.

The problem here seems to be that since we've got the extra row of pixels at the bottom of the polygon now, there will always be overlap when polygons meet edge-on-edge. Under AllegroGL, the polygons are thinner and don't ever exhibit overlap on these edge conditions; for instance, two polygon edges can meet at "y = 10" and not overlap.

I've accounted for the missing gun base chunk by changing the draw ordering of the gun, but I assume that now it's not possible to have soft polygons be compatible with OpenGL ones.

Elias
Member #358
May 2000

They are not supposed to do the same as OpenGL. putpixel/line/rect/polygon are compatible instead. Also polygon did not work for non-overlapping meshes previously, as only the bottom but not the right edge pixels were left out - so the current behavior is more consistent in any case.

You can use polygon3d to get more OpenGL like behavior (i.e. bottom as well as right edge pixels are not drawn).

--
"Either help out or stop whining" - Evert

Paul Pridham
Member #250
April 2000
avatar

OK, sounds great. Glad I could help verify the correct behaviour of polygon(). ;)

Go to: