mrh@camcon.co.uk (Mark Hughes) (09/12/89)
I am fiddling around with graphic objects in C++ on a PC (EGA mode) and am frustrated by the time taken to save/restore areas of the screen bit-map. On my 20Mhz machine, typical screen menu sizes can be saved acceptably fast, but larger areas (say 20,000 pixels) take a noticable period to save. On a slower machine things would get really painful. I have had a peek at the assembly code doing the pixel copying and it seems to take around ten instructions per pixel. The code is supplied with an otherwise speedy graphics library, and is not using BIOS calls. (The library is the "flash graphics" library supplied with Zortech C++ v1.07). ***** Can this process be speeded up? ******** I'm interested to know what features of PC graphics hardware make this process so tortuous, and if there are any ways of speeding things up. If there are faster ways of doing this, do they have disadvantages - like reduced portability/compatibility? All comments appreciated. -- ------------------ mrh@camcon.co.uk or mrh@camcon.uucp | Mark Hughes | Tel: +44 (0) 223 420024 Cambridge Consultants Ltd. |(Compware . CCL)| Tlx: 931 211 0193 (KZ G) The Science Park, Milton Road, ------------------ BT Gold: 72:MAG70076 Cambridge, UK. (Own opinions etc.)
djm@castle.ed.ac.uk (D Murphy) (09/12/89)
In article <3776@titan.camcon.co.uk> mrh@camcon.co.uk (Mark Hughes) writes: > >I'm interested to know what features of PC graphics hardware make this >process so tortuous, and if there are any ways of speeding things up. >If there are faster ways of doing this, do they have disadvantages - like >reduced portability/compatibility? > >All comments appreciated. > > >-- >------------------ mrh@camcon.co.uk or mrh@camcon.uucp >| Mark Hughes | Tel: +44 (0) 223 420024 Cambridge Consultants Ltd. >|(Compware . CCL)| Tlx: 931 211 0193 (KZ G) The Science Park, Milton Road, >------------------ BT Gold: 72:MAG70076 Cambridge, UK. (Own opinions etc.) FLAME ON I'm not sure about EGA, but this would sound about right for CGA. The reason is the idiotic way in which the video memory is arranged. There is 64K of video RAM mapped in 4 planes onto 16K of real address space, and the plane read is determined by sending instructions to the CRTC. Thus, to record the status of one pixel, each plane would have to be read, with appropriate instructions being sent to the CRTC before the read operation. Not only that, but the screen is NOT mapped as one line then the next, but as all the odd numbered lines, then the even ones. Not only THIS, but each byte codes as: Red plane: 76543210 Green 76543210 Blue 76543210 Intensity 76543210 So that you read 4 bytes for 8 pixels - which is fine - but it takes a lot of messing about to do so, since you must instruct the CRTC to let you read each plane in between each read. FLAME OFF (sorta) A question, why didn't *they* arrange the video map as, say, one byte coding for 2 pixels in a high-nybble, low-nybble manner, and have them arranged running continuously from top left to bottom right ? Murff....