graphics library - using watcom 10.6

I developted a little GUI for particular applications using the watcom 10.6
graphics library. The max resolution that I can use is 800x600x16 . If I try
to use 1024x768x16 it become very slow to write a pixel using
“_setpixel(x,y)” if “y” exced a value. It seems that the library become
slow to write in a video memory that exced a location.
Infact “_setpixel()” becomes slow also if I use 800x600x256.
Does someone know why? Is a “graph3r.lib”-patch exist ?
Thank’s in advance

Luca

“PRC-ASW” <prcswdpt@tin.it> wrote in message
news:9gnd28$npc$1@inn.qnx.com

I developted a little GUI for particular applications using the watcom
10.6
graphics library. The max resolution that I can use is 800x600x16 . If I
try
to use 1024x768x16 it become very slow to write a pixel using
“_setpixel(x,y)” if “y” exced a value. It seems that the library become
slow to write in a video memory that exced a location.
Infact “_setpixel()” becomes slow also if I use 800x600x256.
Does someone know why? Is a “graph3r.lib”-patch exist ?

Probably has to do with VGA paging.

The graph3r.lib is, if my memory is right, obsolete.

I don’t know of any way to solve that aside using Photon.
Maybe a different model of gfx card could help

Thank’s in advance

Luca

PRC-ASW <prcswdpt@tin.it> wrote:

I developted a little GUI for particular applications using the watcom 10.6
graphics library. The max resolution that I can use is 800x600x16 . If I try
to use 1024x768x16 it become very slow to write a pixel using
“_setpixel(x,y)” if “y” exced a value. It seems that the library become
slow to write in a video memory that exced a location.
Infact “_setpixel()” becomes slow also if I use 800x600x256.
Does someone know why? Is a “graph3r.lib”-patch exist ?
Thank’s in advance

That library was deprecated with 10.6 and is not supported – it was
only documented with 9.52. You are unlikely to get anything in the
way of a useful answer on it, unfortunately – it is just too old.
(It hasn’t been supported in more than 5 years.)

We generally recommend people use Photon if they want better graphics
support – but it sounds like it may be overkill for your application.

You’re probably best sticking with the 800x600.

-David

QNX Training Services
dagibbs@qnx.com

“PRC-ASW” <prcswdpt@tin.it> wrote in message
news:9gnd28$npc$1@inn.qnx.com

I developted a little GUI for particular applications using the watcom
10.6
graphics library. The max resolution that I can use is 800x600x16 . If I
try
to use 1024x768x16 it become very slow to write a pixel using
“_setpixel(x,y)” if “y” exced a value. It seems that the library become
slow to write in a video memory that exced a location.
Infact “_setpixel()” becomes slow also if I use 800x600x256.
Does someone know why?

Yes. Over 800x600x16 resolution, video memory is page banked in blocks of
64K. 800x600x16 is the highest resolution that fits just within 64K and so
there is no page bank calls. Switching banks is never cheap. What I
discovered about the Watcom Graphic library about 12 months ago was that it
did not bother to cache the current page bank. After each graphics call, it
resets it back to page 0. It should do that, it should assume that the next
graphics operation may be in the same locality on the screen.

This means that if you switch to 800x600x256 mode and do

int x, y;
for (x= 0; x < 800; x++)
_setpixel(x, 0);

this will be faster to draw than

int x, y;
for (x= 0; x < 800; x++)
_setpixel(x, 599);

Is a “graph3r.lib”-patch exist ?

Not for Watcom 10.6, QNX, AFAIK
I know what needs doing but not what tools you have available to you (I am
less familiar with Watcom 10.6 for QNX). Do you have WDISASM, WASM?
If so then

WLIB GRAPH.LIB * GRSVGAr.OBJ * GRSVGAs.OBJ
WDISASM /a GRSVGAr.OBJ /l=GRSVGAr.ASM
WDISASM /a GRSVGAs.OBJ /l=GRSVGAs.ASM

You should something like:

GRSVGAr.ASM
SVGAReset16:

call EGAReset
SVGAReset:
xor eax,eax

and

GRSVGAs.ASM
_SVGAReset16:

call _EGAReset
_SVGAReset:
push 0x00000000
call _SetPage
add esp,0x00000004
ret

The functions

_SVGAReset16()
_SVGAReset()

must not be allowed to “fall through” to do _SetPage(0). So this code should
be

GRSVGAr.ASM
SVGAReset16:

call EGAReset
SVGAReset:
ret

GRSVGAs.ASM
_SVGAReset16:

call _EGAReset
_SVGAReset:
ret

WASM /3r GRSVGAr.ASM
WASM /3s GRSVGAs.ASM
and replace in the library.

I have no doubt there are plenty of talented programmers here who can do
this in their sleep :slight_smile:

Hope this helps.

Stephen Howe [TeamSybase]