| Re: [AD] stretch_blit GFX_HW_VRAM_BLIT ? |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Friday 27 January 2006 23:02, Elias Pschernig wrote:
> On Sat, 2006-01-28 at 08:53 +1100, aj wrote:
> > do the new accelerated hardware stretch_blit() going to have a
> > gfx_capabilities flag ?
They must have, yes.
> Well, scrolling down to Evert's post, I can see this:
>
> +#define GFX_HW_STRETCH_BLIT 0x00800000
> +#define GFX_HW_STRETCH_BLIT_MASKED 0x01000000
>
> But it's a good question.. the existing flags indicate if MEM, SYS or
> VRAM blits are accelerated:
>
> GFX_HW_VRAM_BLIT
> GFX_HW_VRAM_BLIT_MASKED
> GFX_HW_MEM_BLIT
> GFX_HW_MEM_BLIT_MASKED
> GFX_HW_SYS_TO_VRAM_BLIT
> GFX_HW_SYS_TO_VRAM_BLIT_MASKED
>
> So should the new flags indicate it as well?
Yes, they actually should. My original idea was that the MEM flags are
sortof pointless because I don't see when and how they can be and that for
the hardware acceleration both SYS and VRAM were accelerated, so I
combined the flags (which is why there is no SYS or VRAM indicator in the
name). I later realised that this is only true on Windows but not
guarenteed to be true on other platforms (that don't have real system
bitmaps), so those at least need to be added before the patch is applied.
Might as well add the MEM flags too in that case though I'm still not sure
that they serve an actual purpose.
> From what I understand, the
> new stretch_blit would work for VRAM and SYS_TO_VRAM, so 4 new flags
> instead of 2 new flags would be needed..
Yes. This actually raises another problem: the gfx_capabilities flags are
almost all taken. What do we do with new capabilities that we might add?
Create a more_gfx_capabilities variable? Use a function-call to decide
which one to populate (much more work and error-prone because internally
we'd still need gfx_capabilities and more_gfx_capabilities-like variables
and current functions directly set gfx_capabilities).
Or do we just call it done and don't add new hardware accelerated features?
The latter would be the easiest way, but then, we really shouldn't be
adding this to 4.2 either!
I personally think more_gfx_capabilities is the least of all evils.
Hmm... alternatively... what happens if we increase the width of
gfx_capabilities to 64 bit? Would older programmes (taht think it's 32
bit) using the newer dynamic library just see the lower 32 bits?
Evert