jhenders@jonh.wimsey.bc.ca (John Henders) (12/09/90)
I'm trying to find info or source on adjusting resource files for
resolutions. I'm using a free.tree as there's too much info to fit otherwise.
I don't want to have separate files for colour and mono. I was sure I had
a file and code that showed how to adjust the mono resource file by halving
the vertical dimensions of objects, but now I can't find it.
Can someone help me find this info?
--
John Henders jhenders@jonh.wimsey.bc.ca
Vancouver,B.C. or jhenders@wimsey.bc.ca
or ubc.cs!van-bc!jonh!jhendersrosenkra@convex.com (William Rosencranz) (12/13/90)
In article <A0axe3ds@jonh.wimsey.bc.ca> jhenders@jonh.wimsey.bc.ca writes: > I'm trying to find info or source on adjusting resource files for >resolutions. I'm using a free.tree as there's too much info to fit otherwise. >I don't want to have separate files for colour and mono. I was sure I had >a file and code that showed how to adjust the mono resource file by halving >the vertical dimensions of objects, but now I can't find it. > Can someone help me find this info? the quick answer may be to consider making more trees rather than trying to cram everything on one screen. the long answer is to look at rsrc_obfix AES call. this converts from character coords (what res construction set puts out) to pixel coords. i believe this takes resolution into account. i also believe this may be done by rsrc_load automatically. what u need to do is something like this for each tree (assuming resource was built in high res): int res; OBJECT *obj; int xnewlo[NUMOBJ],ynewlo[NUMOBJ],ynewmed[NUMOBJ]; rsrc_load ("MYAPP.RSC"); res = Getrez (); for (i=0; i<NUMOBJ; i++) { rsrc_gaddr (R_TREE, i, &obj); switch (res) { case LO: obj[i].ob_x = xnewlo[i]; obj[i].ob_y = ynewlo[i]; break; case MED: obj[i].ob_y = ynewmed[i]; break; } } this assumes the object can stay the same size, just move locations before you draw the obj. make the table ahead of time, noting that obj coords are relative to the PARENT not the SCREEN. objc_xywh gets the screen coords. you can get the parent from ob_next/head/tail things and walking top down. i don't believe you can do just: obj[i].ob_y /= 2; or obj[i].ob_y >>= 1; if you have a resource editor which can dump C source, do so. you can manually load it yourself then you don't need ANY .rsc file. if you really need to change the size of the objects (like icons) you need to replace things like ob_spec (which is a ptr to the ICONBLK struct, for example. generally strings, tedinfos, buttons, etc are ok. it is icons that pose the biggest problem. another trick to try is to build sets of icons on each resolution, then hard code them into your code, switching the ptr in ob_spec as above. decent GEM references (if u can still find them) are: Pollack and Weber, ATARI ST Application Programming, Bantam, 1987 Balma and Fitler, Programmer's Guide to GEM, Sybex ATARI ST Gem Programmer's Reference, Abacus the abacus books (at least the early editions) occasionally are buggy but not in this area, as i recall. you can also get the "official" docs from atari by becomming a bona fide developer. the atari docs are probably the most complete, but are references, and generally do not tell how to use things like the books do. i learned most from the Sybex book (it is the oldest) but later found pollack and weber to be about the best single volume reference on AES/VDI/GEMDOS/BIOS/XBIOS. numerous examples with source. i also think it is out of print. also: practice makes perfect :-) this is for memory, and i have not written AES/VDI code in quite some time. i do have a custom file selector (with drive buttons) i wrote years ago which does this sort of thing if you still have problems. it is self contained in that it sets up a complete object tree in C and contains no .rsc file. you should also try and find the PROGEM tutorial series by tim oren (ex-DRI guy who co-authored parts of GEM). it is quite good. i believe it can be found on terminator. you may want to consider posting a request like this to c.s.a.st.tech since more weenies probably read that than this newsgroup, depending on the level of insanity of this group at any particular point in time :-) actually, this is a refreshing subject for a change. better than a zillion articles on memory upgrades (which only are of interest to me when someone starts talking 8 MB :-)... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (12/16/90)
In article <110968@convex.convex.com> rosenkra@convex.com (William Rosencranz) writes: > >the long answer is to look at rsrc_obfix AES call. this converts from >character coords (what res construction set puts out) to pixel coords. >i believe this takes resolution into account. i also believe this may >be done by rsrc_load automatically. A long time ago, I looked into this for TeXShell, so I could spell it with an 'E' half a line down. I had used rsctoc to imbed the resource into my C program. Upon looking at the stuff in the resource file, it was obvious that all coordinates were stored as 256*pixels + characters. And the fixup-routine just knew how many pixels tall and wide a character are, and converted everything to pixels. So all you have to do is modify the fixup routine to treat the pixel offsets in a resolution-independent fashion, and you're all set. >this is for memory, and i have not written AES/VDI code in quite some time. Ditto.