jjoshua@topaz.rutgers.edu (Jon Joshua) (06/12/89)
In MS QC 2.0, _getimage() and _putimage() are great ways of blasting
data onto the screen. I was wondering how the data is kept in memory.
I want to be able to create a screen in memory and the use _putimage()
to display it. It would seem that _putimage() was only meant to be
used with data from _getimge().
Does anyone have any info?
JOn.
--
/\ ? ________________
jjoshua@topaz.rutgers.edu \ ____ __ fgu |.signature under|
Anything is possible... \ | | / | orywlut- | construction |
========== gfgsdfsdfsd |________________|
_____________________________OO_____O___hfdhksjdhfksjdfs_______||__________||__880716a@aucs.UUCP (Dave Astels) (06/12/89)
In article <Jun.11.13.28.35.1989.24006@topaz.rutgers.edu> jjoshua@topaz.rutgers.edu (Jon Joshua) writes: > >In MS QC 2.0, _getimage() and _putimage() are great ways of blasting >data onto the screen. I was wondering how the data is kept in memory. The format is as follows: 1 word (2 bytes) specifies the width in pixels of the image 1 word specifies the height in pixels the data follows, raster scan order. I found _getimage() & _putimage() to be handy for manipulating parts of the screen. For instance, there is no way to write text to the screen with a halftone ANDed with it (to create gray shaded text for unselectable menu option). Just write the text as usual, use _getimage() to grap it, AND the data with the appropriate mask, and _putimage() it back. Incidentally, the same data format is used with GetImage & PutImage in Turbo Pascal (v 5.0 at least). I've played with this quite a bit, so if you have any furthur questions, just ask. -Dave 880716a@Adadia 880716a@aucs.UUCP
adverb@bucsb.UUCP (Josh Krieger) (06/12/89)
In article <Jun.11.13.28.35.1989.24006@topaz.rutgers.edu> jjoshua@topaz.rutgers.edu (Jon Joshua) writes: > >In MS QC 2.0, _getimage() and _putimage() are great ways of blasting >data onto the screen. I was wondering how the data is kept in memory. >I want to be able to create a screen in memory and the use _putimage() >to display it. It would seem that _putimage() was only meant to be >used with data from _getimge(). The same functions exist in Turbo C (however, it is possible they may not be handled the same way). Anyway, Turbo C stores the length and width of the image in the first four bytes of memory containing the image. It's stored low byte, high byte, low byte, high byte. I'm not quite sure whether the width or the length is specified first. You can test if this is the case in Quick C by using getimage on an area of specified size and seeing if the first four stored bytes coincide with your request. -- Josh Krieger
mike@relgyro.stanford.edu (Mike Macgirvin) (06/13/89)
In article <Jun.11.13.28.35.1989.24006@topaz.rutgers.edu> jjoshua@topaz.rutgers.edu (Jon Joshua) writes: > >In MS QC 2.0, _getimage() and _putimage() are great ways of blasting >data onto the screen. I was wondering how the data is kept in memory. >I want to be able to create a screen in memory and the use _putimage() >to display it. It would seem that _putimage() was only meant to be >used with data from _getimge(). > >Does anyone have any info? > The data is stored as int [2 bytes] width * depth int [2 bytes] height unsigned char image[] depth * width * height bits of image I have succesfully used the _{get,put}image arrays for my own use, with the following limitation: the depth info. Since the depth changes with adapter types, you must limit your program to working at a particular depth, or make sure that when you use the buffer yourself, you place the info in it correctly. I'd love to get my hands on the source, since these routines are so darn FAST! ------------------------------------------------------- "There must be some kind of way out of here." Mike Macgirvin - mike@relgyro.stanford.edu (36.64.0.50) -------------------------------------------------------
T8M-KAUP@FINTUVM.BITNET (Asko Kauppi) (06/24/89)
According to Dave Astels: > Incidentally, the same data format is used with GetImage & PutImage in > Turbo Pascal (v 5.0 at least). That is not completely true. I changed from using MSC 5.0 to Turbo C 2.0 (all Turbo products use a common Borland Graphics Interface, BGI) recently and had to make some changes to the putimage() structures I had saved on disk: 1) The size data words in Turbo's putimage() are one less than the corresponding MS _putimage() ones. 2) The bitmap rows come out in a different order, changing color 0 to color 15, 1 to 14 and so on... 3) Otherwise, the routines seem to be identical, except for that the MSC routines don't work: they make text output go crazy. This is a known bug in the GRAPHICS.LIB and might have been fixed in a later version (5.1) but I doubt it. Anyway, I prefer the Turbo routines. Somehow they even feel a bit faster, but I haven't really tested it... I DO NOT have time to check, whether these comments are 100% right. They are just what I can recall of my fights with the putimage() incompatibility problems. Please correct me if I was wrong. _____________________________________________________________________ Asko Kauppi alias T8M-KAUP at FINTUVM.BITNET (BitNet MAMMUTTI.UTU.FI (InterNet Student of Physics Turku University addr: Kakskerrantie 176, 20960 Turku, FINLAND Finland tel : +358 (9)21 588 359 / 588 434
srt@aerospace.aero.org (Scott "TCB" Turner) (07/23/89)
DISCLAIMER: I use Turbo C myself. It seems to me that one possibility is to construct a screen image on one of the unused pages of graphics memory and then do a getimage() from there and a putimage() to the active page. Of course, you can also just switch the active page, if you want to change the entire display. Related Questions: Is there any way to tell how many pages of graphics memory are available? In Turbo it seems the only way is to switch to a page and check for an error. I presume the graphics memory is on the adapter card and is not being taken from core? Is there a good way to dump/retrieve images to file? -- Scott Turner
fredex@cg-atla.UUCP (Fred Smith) (08/14/89)
In article <53050@aerospace.AERO.ORG> srt@aero.UUCP (Scott "TCB" Turner) writes: >DISCLAIMER: I use Turbo C myself. > >It seems to me that one possibility is to construct a screen image on >one of the unused pages of graphics memory and then do a getimage() from >there and a putimage() to the active page. Of course, you can also >just switch the active page, if you want to change the entire display. > >Related Questions: > >Is there any way to tell how many pages of graphics memory are >available? In Turbo it seems the only way is to switch to a page and >check for an error. I presume the graphics memory is on the adapter >card and is not being taken from core? > >Is there a good way to dump/retrieve images to file? > > -- Scott Turner ------------------------------ Scott et al: I am told that there is no way to tell how many pages of display memory are available on a given display adapter. If one assumes that the current display adapter is the original hardware manufacturer's model (i.e., not a clone) then you can make ASSUMPTIONS about it--but I have hard it said that this is not dependable in the world of clones because not all clone board makers implement an exact copy of the original board. In Dr. Dobbs Journal back in the spring of 1989 Jeff Duntemann discusses this problem in one of his columns. Fred