mwtilden@watmath.waterloo.edu (M.W.Tilden, Hardware) (02/02/89)
I recently got Sozobon all loaded and was annoyed to discover that
the documentation makes NO MENTION of how to execute graphics!
Ideally, all I need is a clear_scrn command along with point, line,
frame, polygon, text and arc (and the permutations therein).
If anybody's got a sample program which can do any of this, could
they please send me compilable source.
Thanx in advance.
--
Mark Tilden: _-_-_-__--__--_ /(glitch!) M.F.C.F Hardware Design Lab.
-_-___ | \ /\/ U of Waterloo. Ont. Can, N2L-3G1
|__-_-_-| \/ (519) - 885 - 1211 ext.2454,
"MY OPINIONS, YOU HEAR!? MINE! MINE! MINE! MINE! MINE! AH HAHAHAHAHAHAHAHAHA!!"c60c-3ds@web-1f.berkeley.edu (John Kawakami) (02/02/89)
In a similar vein: are there GEM/AES libraries that work with Sozobon C, and where can I get them. If there are none (but I bet there are) where should I look for info on writing my own. Assume I'm a novice at ST library construction (I am). John Kawakami c60c-3ds@widow.berkeley.edu
koreth@ssyx.ucsc.edu (Steven Grimm) (02/02/89)
I've just posted a package called "gemfast" to comp.binaries.atari.st; it
contains public-domain GEM bindings for Alcyon C. I believe Sozobon C
uses the same object file format as Alcyon, so these should work there too.
---
These are my opinions, which you can probably ignore if you want to.
Steven Grimm Moderator, comp.{sources,binaries}.atari.st
koreth@ssyx.ucsc.edu uunet!ucbvax!ucscc!ssyx!korethtim@brspyr1.BRS.Com (Tim Northrup) (02/03/89)
From an article by mwtilden@watmath.waterloo.edu (M.W.Tilden, Hardware): > I recently got Sozobon all loaded and was annoyed to discover that > the documentation makes NO MENTION of how to execute graphics! > > Ideally, all I need is a clear_scrn command along with point, line, > frame, polygon, text and arc (and the permutations therein). > > If anybody's got a sample program which can do any of this, could > they please send me compilable source. Sozobon is just the compiler. To do graphics you need library of suitable routines. On the ST, graphics are usually done using the VDI which is a set of graphics primitives held in the ROM's. To get at the VDI you need a set of bindings in a library. You have a couple of choices to get these bindings: * Get ahold of the GEMQ libraries. This is a set of AES and VDI bindings for Sozobon C (actually, I think they were written for Alcyon, but they work). I got my copy off of GEnie, but check around, it's probably in other places as well. * Write your own -- using documentation on the VDI calls (I used Compute's Tech Ref -- Vol.1) it's pretty easy to write your own C bindings for them. I started to do my own and had pretty good success, but then GEMQ came around and I quit on mine. > Thanx in advance. You're welcome. -- Tim Northrup +------------------------------------------+ +---------------------------------+ GEnie: T.Northrup | UUCP: uunet!steinmetz!brspyr1!tim | Air Warrior: "Duke" | ARPA: tim@brspyr1.BRS.Com +------------------------------------------+
Fiacha of Glencar@hjuxa.UUCP (Fiacha of Glencar) (02/03/89)
From article <5377@brspyr1.BRS.Com>, by tim@brspyr1.BRS.Com (Tim Northrup): > From an article by mwtilden@watmath.waterloo.edu (M.W.Tilden, Hardware): >> I recently got Sozobon all loaded and was annoyed to discover that >> the documentation makes NO MENTION of how to execute graphics! >> > * Get ahold of the GEMQ libraries. This is a set of AES and > VDI bindings for Sozobon C (actually, I think they were written > for Alcyon, but they work). I got my copy off of GEnie, but > check around, it's probably in other places as well. > Even easier, use the GEMFAST libraries posted in the binaries topic. I tested them, to a limited extent, last night and they worked fine for me. My objection to the GEMQ libraries is that AESQ needs a magic table in the startup module that defines the number of arguments to each of the AES calls. Without a copy, I don't see how you are going to get the calls to work, and I didn't see the table in the DASTART.S routine posted here a few days ago. One good thing to take from the GEMQ routines is the rectangle stuff, i.e. most of the routines in UTILQ.S The next step is to throw together a linea package.-- Nigel R Haslock | If you have to be warped to weave, __-------___ Manalapan NJ 07726 | what do you have to be to forge? |___ __ ___/ nrh%hjuxa.uucp@decuac.dec.com| | | or ...!rutgers!hjuxa!nrh | Hotter! Make the sparks fly. /____\
steve@pnet51.cts.com (Steve Yelvington) (02/05/89)
Fiacha of Glencar@hjuxa.UUCP (Fiacha of Glencar) writes: >Even easier, use the GEMFAST libraries posted in the binaries topic. > >I tested them, to a limited extent, last night and they worked fine for me. I've run into a couple of minor bugs in GEMFAST, but I think it'll be a nice library once Ian gets them fixed. His versions of vq_extnd(), which apparently is mistagged, also crashes the programs in which I've tested it. I have not found GEMFAST to produce smaller code; in fact, it's been consistently larger. However, I have not #defined out the VDI control arrays that GEMFAST does not need. (It uses stack space). > >My objection to the GEMQ libraries is that AESQ needs a magic table in the >startup module that defines the number of arguments to each of the AES calls. >Without a copy, I don't see how you are going to get the calls to work, and >I didn't see the table in the DASTART.S routine posted here a few days ago. > If you're referring to the _cntrl_cnts: array, it can be found in the crystal.o module inside dLibs, thus it is not included in the startup code. However, the crystal() function itself is not in the current dLibs object library. I believe it is in the sources, though. I can send a copy if you need it. >One good thing to take from the GEMQ routines is the rectangle stuff, i.e. >most of the routines in UTILQ.S >The next step is to throw together a linea package.-- Yes! A linea.a library would be great. UUCP: {uunet!rosevax,amdahl!bungia,chinet,killer}!orbit!pnet51!steve ARPA: crash!orbit!pnet51!steve@nosc.mil INET: steve@pnet51.cts.com ----------- -or- stag!thelake!steve@pwcs.StPaul.GOV "A member of STdNET -- the ST Developers' Network"