entropy@ai.mit.edu (entropy) (12/19/90)
In article <3391@medusainformatik.uni-erlangen.de> csbrod@medusainformatik.uni-erlangen.de (Claus Brod ) writes: >Right, you shouldn't use Line A anymore. AAAAAAAAACCCCCCCCCKKKKKKKK! What? How are we supposed to do graphics now? (PLEASE don't say "Use GEM" -- I really don't want to wait till next spring to get some graphics on the screen.) Is there any TT-compatible, acceptable method for producing FAST graphics on the ST? (Preferably one that will stay acceptable.) Or are we all doomed to either incompatibility or slow, creeping death? Perhaps I should read this group a little more closely. This is the first I've heard on this topic... Maybe I'll dig out my Atari 800...nobody complains if you POKE to the screen on those... :-) entropy
rosenkra@convex.com (William Rosencranz) (12/19/90)
In article <ENTROPY.90Dec18130428@pogo.ai.mit.edu> entropy@ai.mit.edu (entropy) writes: >In article <3391@medusainformatik.uni-erlangen.de> csbrod@medusainformatik.uni-erlangen.de (Claus Brod ) writes: > >>Right, you shouldn't use Line A anymore. > >AAAAAAAAACCCCCCCCCKKKKKKKK! What? How are we supposed to do graphics >now? (PLEASE don't say "Use GEM" -- I really don't want to wait till >next spring to get some graphics on the screen.) Is there any >TT-compatible, acceptable method for producing FAST graphics on the >ST? (Preferably one that will stay acceptable.) Or are we all doomed >to either incompatibility or slow, creeping death? u know, this was my initial reaction, when i first heard the TT would not support line A (which i use because it is extremely easy to program graphics, once u make a few trivial assembler functions to do put/getpixel and drawline). in fact, i just posted a mono gif viewer yesterday which uses linea 0, 1, and 3. it also will NOT run on a color monitor, tho that was the point, afterall. i own a couple of STs (including a mega4) with both monitors, tho i greatly prefer the really excellent mono monitor. i can just see the screams of anguish THAT will cause :-) :-) :-) :-) still, it is FREE (including src) so if u don't like it, TOO BAD (expletive deleted). don't use it, or post a version (including src) that does the same and runs on ST/STe/TT/?T. since i am not selling this, i really don't care that it won't work on the TT (or ST with overscan). if/when i get a TT or BIG monitor, i will program for it. maybe the people howling at me about portability will send me one gratis :-). my stuff runs on >1 million STs. i can live with that. my next COMMERCIAL code will run on all systems, IF it makes sense from a marketing perspective (it generally does, BTW). the advice i gave on dialog boxes is sound. i will conceed that it is not entirely portable, tho i'll stand by it nevertheless. i suspect it is the basic idea that the person was looking for, which is what i presented. it is up to him/her to fill in the blanks after that. i am glad this oversite was pointed out, though i resent being called a lousy programmer because of it. i GAVE this community a working nroff (i COULD have SOLD it to you). and yes, it is not a complete/perfect nroff, but i use it daily and format reports for my customers with it (files run UNMODIFIED under real unix) as well as 100's of man pages for my system. and it is FREE with NO RESTRICTIONS so u can do whatever u like with it (no, i won't say it :-). i just added hyphenation as well, and am planning a rewrite soon, complete with (non-GDOS) fonts for italics and BOLD in conjunction with man(1). this nroff is being distributed with Minix as well (and ported with extreme ease, BTW, eventho i do not even have a running minix system) and do not receive (nor wish to) a penny from its sale. i was going to write (and distribute, src included) a tcsh(1) using MiNT as well. i am NOT going to worry about it not running on some systems. you get the src, you fix it yourself. the only reason i am forced to write this (for myself) is that u can't get the src to gulam and fix it (tho i can't complain about something free which i use regularly - in fact, just the opposite). my guess is that >95% of the people reading this group have no intentions of selling their work. those that do plan on selling, will find out what portability really means when they get complaints. besides, i see them as potential competitors :-). and NOBODY should complain about free software they can't use. i also encourage everyone to post source code so that if someone does have an odd configuration, they can fix it to work (if they want to take the time and have the propensity to do so). i generally ALWAYS post source. others cannot make this claim for one reason or another. i share my efforts...completely... no need for followups on this. the issue is beaten to death... (ok, i have calmed down...it is good to vent the spleen every once in a while and i was pissed off) -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
csbrod@medusainformatik.uni-erlangen.de (Claus Brod ) (12/20/90)
entropy@ai.mit.edu (entropy) writes: >In article <3391@medusainformatik.uni-erlangen.de> csbrod@medusainformatik.uni-erlangen.de (Claus Brod ) writes: >>Right, you shouldn't use Line A anymore. >AAAAAAAAACCCCCCCCCKKKKKKKK! What? How are we supposed to do graphics >now? (PLEASE don't say "Use GEM" -- I really don't want to wait till >next spring to get some graphics on the screen.) Is there any >TT-compatible, acceptable method for producing FAST graphics on the >ST? (Preferably one that will stay acceptable.) Or are we all doomed >to either incompatibility or slow, creeping death? Perhaps I should >read this group a little more closely. This is the first I've heard >on this topic... Ahem... use GEM 8-) Yes, there are ways to have _fast_ GEM-compatible graphics. The idea is to build up your graphics in a non-visible background buffer. There, you can use any kind of hand-coded, optimized graphics routine - as long as you use the GEM standard format in the background buffer (no interleaved bitplanes). When you have generated what you need, vr_trnfm() it to the device- specific format used by your current screen driver and use vrt_cpyfm() or vro_cpyfm() to blit your graphics to the screen. This should be fast enough for most applications except animation. By the way: If you fool around with VDI a bit, you'll notice soon that it isn't as bad as most people think. The only part of it I don't like that much are the font functions, especially finding out reliably if some font is proportional or which default sizes you have. Hopefully, FSMGDOS will improve things now. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
hvaalde@cs.vu.nl (Aalderen van Harold) (12/21/90)
csbrod@medusainformatik.uni-erlangen.de (Claus Brod ) writes: >By the way: If you fool around with VDI a bit, you'll notice >soon that it isn't as bad as most people think. I can confirm this I once made a set of routines to give formatted text on the screen using LineA code. Later I rewrote the stuff to use only VDI routines. It turned out to be faster to use the VDI instead of the LineA? Never bothered to figure out why this difference, but I learned to handle VDI calls and still get reasonable speeds. The trick is not to use them to much be only when you really need them. This is ofcourse a useless statement but if you program carefully VDI is fast enough for general purposes. Harold van Aalderen (hvaalde@cs.vu.nl)
andyc@hplsla.HP.COM (Andy Cassino) (12/22/90)
re: LINEA considered harmful
I've been unable to find all the relevant postings on this topic, maybe they
didn't all make it here. The gist of it seems to be that the TT doesn't
support the linea functions so any programs that use them directly will
automatically not work on the TT. I hope that's an accurate summary.
If not, I'm sure you all will let me know about it! :-)
Well, last night I finally got around to reading my Neodesk 3 upgrade manual
(as opposed to gleefully playing with the program). There's a nice big
paragraph in there about how Neodesk 3.0 bypasses the horrendously slow VDI
functions and makes use of the quick linea functions instead. But wait
a sec, Neodesk 3 runs on a TT! Something here does not add up. (Not to
mention that I doubt Gribnif would head down the linea path if it was
going to be obsolete.)
Well, one other point of commentary. I *still* find incompatibilities with
the software blitter I use, and I have the latest version. So sometimes I
must turn it off. I'm glad Neodesk stays nice and snappy when the software
blitter isn't there.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Andy Cassino %
% Hewlett-Packard - Lake Stevens Instrument Division %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%R_Tim_Coslet@cup.portal.com (12/23/90)
In Article: <13510006@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) Writes... >re: LINEA considered harmful > >I've been unable to find all the relevant postings on this topic, maybe they >didn't all make it here. The gist of it seems to be that the TT doesn't >support the linea functions so any programs that use them directly will >automatically not work on the TT. I hope that's an accurate summary. > >Neodesk 3.0 bypasses the horrendously slow VDI >functions and makes use of the quick linea functions instead. But wait >a sec, Neodesk 3 runs on a TT! Something here does not add up. I wonder if maybe people have gotten LINEA and LINEF confused? LINEF (undocumented) functions are not supported on the TT, because these opcodes are used in the 68020/30 for coprocessors. But Motorola has not assigned anything to the LINEA operations, so I see no reason Atari would have dropped their support in the TT. I don't know one way or the other on the TT and LINEA, but I wonder if others might have confused the LINEF changes on the TT and concluded that LINEA was dropped too. Could someone at Atari clarify this? R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet
apratt@atari.UUCP (Allan Pratt) (12/28/90)
To clear up any confusion, when we talk about line-A we're talking about graphics. Line-F was a hack in the ST ROMs to save space, and that's not what we're talking about here. The blanket statement "Line A doesn't work on the TT" is actually a little misleading. The actual statement from Atari is more like this: "Line A is maintained for compatibility with existing programs only, and should not be used in new programs, and will not be maintained for new features of the ST/TT line of computers." This "new stuff not supported though line-A" is already in evidence in the TT: you can't use line-A in 256-color mode, because you only have access to four color bits. New programs should not use line-A. If you use VDI correctly, it is no slower than line-A. This is obvious when you realize that line-A is just a back door to the same routines that the VDI uses! There is a little overhead from VDI, but it's small compared to the time to do anything remotely complicated, like drawing a line. Two things can make VDI seem slow: using clipping when it's not necessary, and using some versions of GDOS. In the latter case, it's GDOS's fault, not VDI's, and newer GDOSes are faster. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt