![]() |
|
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:
===================================================================== Matthew Leverton added build instructions for DMC and updated the MSVC Matthew Leverton added a shell script wrapper around gcc to build universal Peter Hull reenabled the Quit menu option on Mac OS X when Rikard Peterson fixed the Mac OS X joystick driver so that Matthew Leverton fixed a problem with the GDI driver blitting a rectangle Some minor changes. ===================================================================== Matthew Leverton added project files for MSVC 6/7/8 (see the build Matthew Leverton added initial support for the Digital Mars C compiler 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 Elias Pschernig added missing documentation for pack_ungetc(). Trent Gamblin fixed the C version of stretch_blit so it now draws orz and Matthew Leverton made the ALLEGRO_USE_C=1 option to work under Erno Schwetter fixed a long-standing bug in polygon() where the Anthony 'Timorg' Cassidy made d_menu_proc fill up its assigned area with Phil Krylov fixed a bug that prevented load_bios_font() from loading 8x16 Etienne Vouga fixed a bug with the reset_controllers MIDI command. Milan Mimica fixed a double SWITCH_IN event callback bug when Erno Schwetter fixed a bug where __al_linux_console_fd was used in 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 Jon Rafkind and Karthik Kumar fixed a problem where allegro-config would Peter Wang fixed some problems with the ALSA MIDI driver in the case of torhu fixed a bug in akaitest where an array was indexed with -1. Trent Gamblin implemented set_mouse_speed under X11. Peter Wang made Evert Glebbeek added desktop_color_depth and get_desktop_resolution to the Matthew Leverton fixed building of universal binaries on MacOS X. This Milan Miminca made the fbcon driver initialization fail if an unsupported Michal Molhanec and Milan Mimica simplified the MSVC build process Andrei Ellman made the MSVC makefile compatible with cygwin port of Daniel Schlyder added a functions is_trans_font, font_has_alpha. Daniel Schlyder made load_txt_font() additionally search for files Daniel Schlyder documented that register_assert_handler() and Daniel Schlyder prevented the Windows port from registering its default Andrei Ellman modified the 6-to-8 bit value scaling tables to be more Other minor bug fixes and documentation updates.
|
Matthew Leverton
Supreme Loser
January 1999
![]() |
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
![]() |
Awesome, great work! I'll be upgrading to Allegro 4.2.2 tonight. ---- |
GullRaDriel
Member #3,861
September 2003
![]() |
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" |
Paul Pridham
Member #250
April 2000
![]() |
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: OpenGL: ---- |
Matthew Leverton
Supreme Loser
January 1999
![]() |
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
![]() |
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 -- |
Matthew Leverton
Supreme Loser
January 1999
![]() |
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
![]() |
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). -- |
Paul Pridham
Member #250
April 2000
![]() |
OK, sounds great. Glad I could help verify the correct behaviour of polygon(). ---- |
|