Add the ability to be able to:
Implementation: Add the following functionality to the API (game_import and appropriate network protocol extensions) :
gi.BlitImage (unsigned char* image, int xloc, int yloc, int xwidth, int yheight, float lifespan);xloc and yloc describe the location on screen, in some NDC. Scaling parameters might also be needed (see below).
Alternately, have gi.BlitImage return a "handle" to the image, which can then be used for repeated rendering. In this case, int gli.SendImage( char* image, int xwdith, int yheight ) would precede any call to gi.BlitCachedImage( int handle, ...). This requires client side handling of caching, and server side assignment of per-client handles (server can't wait for client to return a handle to return from SendImage). It also requires flags to indicate that the image should not be purged when lifespan is exceeded, or other means for controlling client side caching from the server.
Further detail: given various resolutions and aspect ratios (16:9), Normalized Device Coordinates (NDC) and auto-scaling/auto-aspect flags might be necessary.
gi.BlitText uses the same concept, except that fonts can be cached by the client in advance, with fixed handles, and that a text string instead of image data or handle is transferred. It it not useful to cache the actual strings.
Advantages: You know... HUD extensions. Movies, demos, etc would also benefit.
Adds overdraw (blitting will be done when frame is finished, overwriting areas that have been filled at some expense).
Adds a lot of bandwidth. If there is no client side caching of transferred images, and no reference by handle, this will not be feasible for per-frame animations or frequent use.
Both John Carmack and John Cash announced an addition to the client-server interaction that allows for displaying any image. They did not mention caching, and the NDC's they were seemingly heading for are units of 640x480. Different aspect ratios (16:9) might be adressed.
Submitted 980401, revised 980504, by Josh Martel.