[AD] BeOS virtual resolution fix

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Ok, I've posted a patch to Sourceforge that adds a better virtual resolutions 
handling for the BeOS fullscreen driver. I've examined the original method 
used by Jason, trying to understand where it was causing my programs to crash 
sometimes... Well, here's the reason: though on the BeBook it is 
saidSetFrameBuffer() accepts any int32 values for width and height of the 
framebuffer (as long as they're bigger than the physical resolution), 
actually the function crashes if these values are outside the boundaries of a 
signed short variable. As I have 32MB of video RAM, the virtual height was 
almost always bigger than this limit, and I was getting problems.
This patch ensures the virtual height doesn't get bigger than 32767, so it 
makes the driver to work.
exaccel now also works perfectly (though there's a bit of flicker, but I 
think that's due to the Be driver for my TNT2)
Now, I was wondering what's the right behaviour for a gfx driver when you 
pass 0 to both virtual width and height. On the docs it is explained that 
this means you don't care about virtual screen size, but then the Allegro 
test.c program has a strange way of handling the thing... Here I report the 
mode setup of such a program, as found in the change_mode() routine:

<snippet>

   if (set_gfx_mode(gfx_card, gfx_w, gfx_h, (gfx_w >= 512) ? 1024 : 512, 
(gfx_w >= 512) ? 1024 : 512) != 0) {
      if (set_gfx_mode(gfx_card, gfx_w, gfx_h, (gfx_w >= 512) ? 1024 : 512, 
0) != 0) {
         if (set_gfx_mode(gfx_card, gfx_w, gfx_h, 0, 0) != 0) {
 
            if ((gfx_card == GFX_AUTODETECT) && (gfx_bpp > 8) && (gfx_w == 
640) && (gfx_h == 480)) {                                                     

</snippet>

Well, if screen resolution is 640x480, the first attempt of this snippet is 
to set a virtual size of 1024x1024 (btw, shouldn't the third "gfx_w" on the 
first line be a "gfx_h"?)... Shouldn't the test program try to use all the 
available video mem? Then why not to use 0,0 or a more in-deep scan of 
available virtual sizes?

So as the test.c program works now, it is right that the BeOS fullscreen 
driver detects a 1024x1024 virtual resolution.

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx
ICQ UIN #66972680



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/