the r_imageextensions cvar defines the image file extensions that the engine will search for, though you can have a pfm file with the .tga extension and it'll be loaded okay regardless of the 'wrong' extension. Or you can just be explicit about the file that you're trying to load.
setviewprop(VF_RT_DESTCOLOUR, "texturename", IMGFMT_R8G8B8A8, [imagewidth,imageheight]); //switch to drawing to a texture
setviewprop(VF_RT_DESTCOLOUR, __NULL__); //switch back to the screen.
then you can render with a shader like:
Code: Select all
and it'll read from your rendered texture (the extra $rt: part is annoying, but avoids race conditions with the requisite image flags).
that said, if you're drawing a console, the resolution differences get quite messy, so its generally best to just render your text directly to the screen, via polygon_begin with coords aligned to your screen's surface. throw in polygonoffset to your text's shader and it'll nudge it slightly away from the surface without needing extra offsets in your own code. If you're careful with fixed-width fonts then it should be possible to tune it to work without needing to add any of your own extra clipping logic.
my menusys code had some logic to replace the drawstring etc functions with some plane-aligned logic in order to provide in-world UIs, but I never polished it enough (and defining the appropriate menus was still hardcoded). it'd have been nice to give it some 'please enter passcode' panels instead of all those func_buttons that quake normally uses, but I was too lazy to really flesh it out properly.