Qbasicnews.com

Someone should make a lib which uses external files, somewhat like windows or DirectX.

If you have a GFX_Card_1 you just download a extra file for that put it in the game or programs dir and run.

If you have the GFX_Card_2 you just download some other file and it works.

The lib opens the file and checks where the cards adress is and such things. Every card uses a speciel way to acomplish the same thing, so if i call the lib wishing to draw a line, wouldnt it be possible for the lib to get the info required to draw a line, on a specific gfx card, from an external file?

This means skipping the autodetection part, but most users know which card they use.

I've checked some things up, and although I do not know nearly enough ASM that would be needed I know it can be done.

"Just" make a lib that opens a file to get the specific calls/interrupts/adresses to plot a pixel on the specified card.

Pseudo code:
user calls "draw-a-pixel"
library gets the call and open the file "HiRes.gfx" (or whatever)
inputs the calls needed to plot 1 pixel on the specified card, somewhat in the manner of a script engine
plots the pixel using the info gathered

-OR-

Pseudo code:
library inits loading all info in the file
user calls "draw-a-pixel"
library plots a pixel using the info loaded

Most libraries today are too focused to do everything in one file, UGL, so they even become too large.

Why not just put some data in external files?

I mean, the ASM code for, lets say, handling the mouse could very well be put in a file and loaded at library init or at mouse calls (first is faster for obvious reasons)

And this thing about the manufacturers don't wanting to give their code, how have "we" managed to write libs supporting multiple gfx cards in the past? By guessing, even if so, who says "we" can't guess some more? Also most manufacturers DO give addresses and such to their cards, how do you think Linux was given multi GFX support?, or Windows for that matter.

BWSB uses loadable drivers, but I don't know if that's the same as what you're talking about. I'm sure this could be done, but I am not sure if QB supports any kind of code overlays. Anyone got any leads?

I see instant problems:

1.- There are like 10,000 different SVGAs out there.
2.- Most people are not "techie" enough to know their exact brand/model.

This is what happened in the early 90's when people began having SVGAs (at least in my country). Most application programs (the only ones which used SVGAs back then, computers were very slow for SVGA games) had to include a zillion of different drivers (most card didn't support the VESA standard), and most of the times your SVGA was some kind of weird clone of a clone and you had to try one by one each driver crashing your computer until you found one that worked.

I really feel that SVGA in 16 bits DOS is a dead end. Modern OSs complain, modern boards complain. You end with a slow, unstable, uncompatible product. I'd rather stick to good ole mode 13h. If you want wider res, jump to a 32 bits compiler.