SCREEN 13 800x600

[Karelius]

is it possible to use SCREEN 13 with 800x600? :bounce:

what is the codes? :???:

please!!!

[Dio]

no

[KiZ]

go get an SVGA lib for Qbasic.

Search for future library


didnt you get the message the first time?: http://forum.qbasicnews.com/viewtopic.php?t=10491

[voodooattack]

... or just use freebasic... hifty:

[RyanKelly]

is it possible to use SCREEN 13 with 800x600? :bounce:

what is the codes? :???:

please!!!

The difficulty with higher resolutions in the 256 color mode involved the way VGA memory was mapped into the system memory. (Mind you all of this is now, on most machines, a limitation imposed by the emulation of the standard and not the actual hardware). The VGA accessed a 64 kilobyte segment of memory. In the 256 color mode, each pixel is mapped to one byte. At a resolution of 320 by 200 pixels, you're working with 64,000 bytes, which is just a bit less than 64k. Graphics adapters that support higher resolutions have more memory, but that memory is divided into "banks" which can be selectively mapped into that 64k of system memory.

With the OUT command and the INP() function we can force the VGA into a higher resolution on an SVGA card through the use of well documented IO ports (again, on a Windows system these are merely emulated), however the hardware level details of performing a bank switch were never completely standardized and seldomly publicly documented, VESA introduced a standard video BIOS interface (sometimes implemented as a loadable driver rather than VIDEO ROM BIOS). Using the INTERRUPT routine from QB.LIB and QB.QLB we can interface with the VESA driver (but it requires some very unconventional hacks to accomplish in QB).

Implementing this in QB is rather gritty compared with C and assembly language, so the common alternative is to use a library built in such a language for use with QuickBasic 4.5 (not an option with Qbasic).

There remains, however, one further complication if you are working with a Windows machine. Support for the VESA interface seems to vary both from one model of computer and another and from one installation of Windows and another (even within the same software version). The solution to this problem (which takes us entirely away from QB) is to implement a virtual device driver for NTVDM (the dos emulator used by NT based versions of windows) to provide a custom emulation of the video hardware, but as yet, I've never seen this done.

For more specific information, search the web for the VGA specification, VESA, and VDD (virtual device drivers). The first two are widely available. Information concerning VDDs is very sparse.

[nkk_kan]

welll
u can use the WINDOW command
but the graphics may go sluggish,....

[na_th_an]

WINDOW doesn't change the resolution, just the reference system.

[nkk_kan]

Well it doesn't change the resolution but
you can get 800 X 600 pixels space...

[Rattrapmax6]

:roll: Having 800x600 means you can do:

Code:

PSET (800, 600)

..and see it on the screen... ... Just cause you can resize and stretch it doesn't give you that 800x600 quality, or ability to use smaller pixels, which lead to smoother images.... So it's not 800x600, it's just a stretched 320x200 #13 screen.... :winkwink:

If you want anything above 640x480 (that's QB's highest no? I forgot), then use FB.... And get actual 800x600 or higher quality.... Plus, 32bit colour, for a finer grandient, larger colour selection, etc.... :^_^:

[Anonymous]

Yep, and the graphics library in 8-bit mode is FAST. You would have to know lots of asm tricks, and use MMX and SSE, to beat it in software rendering. It's top notch.

Ever hear of Allegro? One of the developers is the guy who made WetSpot, and that's the same guy who wrote the FreeBASIC gfx library