Mail Archives: djgpp/1998/12/21/11:44:59
jsc AT lds DOT co DOT uk writes:
> int bank_switch(int bank_no)
> {
> union REGS regs;
> regs.x.ax = 0x4F05;
> regs.x.bx = 0; ///check this line - is it relevant?
Yes, it is very relevant. From the VBE 2.0 spec:
Input: AX = 4F05h VBE Display Window Control
BH = 00h Set memory window
= 01h Get memory window
BL = Window number
= 00h Window A
= 01h Window B
DX = Window number in video memory in window
granularity units (Set Memory Window only)
So if you want to set window A, %bx must be zero. You may also
sometimes need to call this routine with %bx=1, to set window B,
which some cards use for reading video memory (that can be a handy
feature because it allows you to simultaneously read and write
different parts of the screen through the two windows, but it is
surprising how many programs fail to bother with this, so they
won't work on cards that use a dual window scheme).
> offset = (long)y*2560 + ((long)x * 4) + rgba;
> my_bank=(int)(offset/64000);
Where did you get 64000 from? A 64k bank is 0x10000 bytes in size,
ie. 65536. This is the cause of your banding problem.
> bank_switch(my_bank);
> offset=offset - (64000*(int)my_bank);
That will work (apart from using the wrong number), but it would be
much simpler to write it as:
offset = offset % 0x10000;
or:
offset &= 0xFFFF;
> _farpokeb(_dos_ds, 0xa0000 + (long)offset, colour);
>
> //rgba is either 1, 2, 3 or 4 and represents whether you are setting
> //the b, g, r or alpha.
You do realise that not every card stores the RGBA values in the same
order? Almost all use RGB format, but every now and then you will come
across one that uses a BGR ordering instead, and as it stands your
program will display the wrong colors on these machines. You need to
read the color field information from the VESA mode information
structure, and use this to work out where each color component is
located within the 32 bit pixel value.
> set_mode(0x112);
That mode number is probably safe to use, but you should always check
for an error in this function: not every driver will even be capable
of a 32 bit mode! If you want to make your code really robust, it is
far better to use the VESA mode list to find the number, rather than
just hardcoding it. From the VBE 2.0 spec:
Note: Starting with VBE version 2.0 VESA will no longer define new
VESA mode numbers and it will not longer be mandatory to support these
old mode numbers. However, it is highly recommended that BIOS
implementations continue to support these mode numbers for
compatibility with old software. VBE 2.0-aware applications should
follow the guidelines in Appendix 5 - Application Programming
Considerations - for setting a desired mode.
Shawn Hargreaves.
- Raw text -