consp11@bingsuns.cc.binghamton.edu (Brett Kessler) (05/03/90)
In article <892@tau.sm.luth.se>, d88-mbe@sm.luth.se (Michael Bergman) writes: |>space@ncc1701.sub.org (Lars Soltau) writes: |>>why does the stupid thing only run on a 80*25 window/screen? Hm? I have a |>>704*282 pixels big Workbench screen and I bloody well expect any professional |>>software to not stuff me into any NTSC frame. |>However, just like Lars, I'm getting very tired of all these NTSC frames that |>US programs use all the time. I know it's easy to check if the machine is PAL |>or NTSC. I don't want to have an unused stripe at the bottom of my screen... |>So come on guys: when you write a program, make the screen 255 high if it's |>a PAL machine and leave the 200-line screens for the inferior NTCS mode. Sure, NTSC is inferior. But, by that same token, I've seen a number of games made outside of the US that go right off of the bottom edge of my screen. This makes it a bit harder to see things like score, number of lives left, etc. So it works both ways. NTSC programmers and PAL programmers alike: CHECK YOUR SCREEN HEIGHT AND WIDTH, and (obviously) USE THE CORRECT ONE. +------///-+------------------| BRETT KESSLER |------------------+-\\\------+ | /// | consp11@bingvaxu.cc.binghamton.edu | \\\ | | \\\/// | consp11@bingvaxa.BITNET | \\\/// | | \XX/ | (PeopleLink) B.KESSLER | \XX/ | +----------+-----------------------------------------------------+----------+
pfalstad@phoenix.Princeton.EDU (Paul John Falstad) (05/03/90)
In article <3396@bingvaxu.cc.binghamton.edu> consp11@bingsuns.cc.binghamton.edu (Brett Kessler) writes: >Sure, NTSC is inferior. But, by that same token, I've seen a number of >games made outside of the US that go right off of the bottom edge of my >screen. This makes it a bit harder to see things like score, number of >lives left, etc. My favorite is the European Tetris clone "Tetris Metallica." I got a demo version of it, and liked it so much that I decided to send in the money for the real version. Unfortunately, the only place the address was printed was on the title screen. And, yes, you guessed it, you couldn't read it because it was off the bottom edge. What a brilliant marketing technique! -- Paul Falstad INTERNET: pfalstad@phoenix.princeton.edu PLink: HYPNOS GEnie: P.FALSTAD CIS:70016,1355 Disclaimer: Everything I said is false, including this sentence "I'd like to leave the army, sir." "Why is that?" "It's DANGEROUS!"
rick@tmiuv0.uucp (05/03/90)
In article <3396@bingvaxu.cc.binghamton.edu>, consp11@bingsuns.cc.binghamton.edu (Brett Kessler) writes: > In article <892@tau.sm.luth.se>, d88-mbe@sm.luth.se (Michael Bergman) writes: > |>So come on guys: when you write a program, make the screen 255 high if it's > |>a PAL machine and leave the 200-line screens for the inferior NTCS mode. > > Sure, NTSC is inferior. But, by that same token, I've seen a number of > games made outside of the US that go right off of the bottom edge of my > screen. This makes it a bit harder to see things like score, number of > lives left, etc. NTSC is not inferior. Nor is PAL superior. They're just "different". But, I agree. Software should sense what display is running and accomodate it. Many commercial programs do. And some of the shareware/freeware/PD stuff do. Some don't. That's life. Besides, I think this thread got started by a flame on JRComm's lack of PAL support. I think Jack answered reasonably by stating that JRComm is a terminal emulator, and 90% of the terminals out there use 80 or 132 character wide screens, 24 or 25 lines high. In those cases, I'm not certain that the additional screen height in PAL mode would be of much use. But then again, I'm in the States. Must be my North American bias showing again. 8-) > +------///-+------------------| BRETT KESSLER |------------------+-\\\------+ > | /// | consp11@bingvaxu.cc.binghamton.edu | \\\ | > | \\\/// | consp11@bingvaxa.BITNET | \\\/// | > | \XX/ | (PeopleLink) B.KESSLER | \XX/ | > +----------+-----------------------------------------------------+----------+ -- .-------------------------------------------------------------------------. / [- O] Rick Stevens (All opinions are mine. Everyone ignores them anyway.) \ | ? +--------------------------------------------------------------------| | V | uunet!zardoz!tmiuv0!rick (<-- Work (ugh!)) | |--------+ uunet!zardoz!xyclone!sysop (<-- Home Unix (better!)) | | uunet!perigrine!ccicpg!conexch!amoeba2!rps2 (<-- Home Amiga (Best!!) | \ 75006.1355@compuserve.com (CIS: 75006,1355) (<-- CI$) / `-------------------------------------------------------------------------' "A day without sunshine is like..............night!"
wschmidt%decefix@decefix.iao.fhg.de (Wolfram Schmidt) (05/03/90)
In article <3396@bingvaxu.cc.binghamton.edu> consp11@bingsuns.cc.binghamton.edu (Brett Kessler) writes: [...] >So it works both ways. NTSC programmers and PAL programmers alike: >CHECK YOUR SCREEN HEIGHT AND WIDTH, and (obviously) USE THE CORRECT ONE. > >+------///-+------------------| BRETT KESSLER |------------------+-\\\------+ >| /// | consp11@bingvaxu.cc.binghamton.edu | \\\ | >| \\\/// | consp11@bingvaxa.BITNET | \\\/// | >| \XX/ | (PeopleLink) B.KESSLER | \XX/ | >+----------+-----------------------------------------------------+----------+ Same for programmers who do their own keymapping. You should really use the default keymap and not a hardwired one. Also bad is disallowing the ALT key (like Aztec SDB, e.g.); example: the '@' is ALT-2 on a german keyboard. Ever tried to use the formatted print command (of sdb) w/o '@' hahahahaha :-{ . Wolfram Schmidt
BAXTER_A@wehi.dn.mu.oz (05/03/90)
In article <3396@bingvaxu.cc.binghamton.edu>, consp11@bingsuns.cc.binghamton.edu (Brett Kessler) writes: > > So it works both ways. NTSC programmers and PAL programmers alike: > CHECK YOUR SCREEN HEIGHT AND WIDTH, and (obviously) USE THE CORRECT ONE. > > +------///-+------------------| BRETT KESSLER |------------------+-\\\------+ > | /// | consp11@bingvaxu.cc.binghamton.edu | \\\ | > | \\\/// | consp11@bingvaxa.BITNET | \\\/// | > | \XX/ | (PeopleLink) B.KESSLER | \XX/ | > +----------+-----------------------------------------------------+----------+ I completely agree. C= have posted the way of reading the screen size from preferences and I have shown how to read the WB screen size. If anyone wants it again I can email. THERE IS NO EXCUSE FOR BEING SLACK!!! Regards Alan
gt5784a@prism.gatech.EDU (REYNOLDS,WALTER GERALD JR) (05/04/90)
In article <7431@wehi.dn.mu.oz> BAXTER_A@wehi.dn.mu.oz writes: >In article <3396@bingvaxu.cc.binghamton.edu>, consp11@bingsuns.cc.binghamton.edu (Brett Kessler) writes: >I completely agree. C= have posted the way of reading the screen size from >preferences and I have shown how to read the WB screen size. > >If anyone wants it again I can email. > >THERE IS NO EXCUSE FOR BEING SLACK!!! >Regards Alan Well, I tried to email you asking for it, but the net stuffed the message back at me. Anyways, I would very much appreciae a copy of this code.. preferrably both ways of getting the screen size (via prefs and reading the workbench screen size). Thanx in advance... JJ -- Disclaimer: None needed... my lawyer makes more money than yours. uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!gt5784a ARPA: gt5784a@prism.gatech.edu
papa@pollux.usc.edu (Marco Papa) (05/05/90)
In article <1177@tmiuv0.uucp> rick@tmiuv0.uucp writes: >Besides, I think this thread got started by a flame on JRComm's lack of PAL >support. I think Jack answered reasonably by stating that JRComm is a terminal >emulator, and 90% of the terminals out there use 80 or 132 character wide >screens, 24 or 25 lines high. In those cases, I'm not certain that the >additional screen height in PAL mode would be of much use. But then again, >I'm in the States. Must be my North American bias showing again. 8-) It makes a LOT of sense even if you have just NTSC. How about when you go interlace? You can have 48 lines instead of 24! How about when you use morerows? You can get 30 or 60 lines on NTSC. And if you have an A3000 (or flicker fixer) they'll all be rock solid. And what if you have an A2024 or Viking 1? It is quite easy to check the screen size AND the current window size. A-Talk III recomputes the max cols/rows even in workbench on the fly, and reset the terminal to those sizes. It is really very simple. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
rfrost@spam.ua.oz.au (Richard Frost) (05/05/90)
I would like to add my views on this subject. I have written an
Amiga USENET NewsViewer (should be on c.b.a & c.s.a soon) along with a
friend that, on start up, looks at the workbech screen dimensions and opens
its window of the same size. The code to do this was VERY simple and I cannot
see why programmers with NTSC amigas STILL (over 5 years after the Amiga's
release) INSIST ON HARD-WIRING THEIR WINDOW DIMENSIONS TO 200 VERTICAL LINES!
I find so many programs that do this and its REALLY ANNOYING to have a nice
PAL overscanned screen with all this space and a puny 200 pixel high
window that refuses to be re-sized beyond 200 lines!
====================================================
IN THE NAME OF
PAL AMIGA USERS
&
OVERSCANNED WORKBENCH USERS EVERYWHERE
PLEASE STOP THIS PRACTICE, PLEASE PLEASE!!!!!!!!!!!
please?
====================================================
--
______________________________________________________________________________
_ ___ | Email Address: rfrost@spam.ua.oz.au
I) I_ |
I\ ichard I rost | FidoNet (ADAM LINK BBS): 3:680/805 Richard Frost
---------------------+--------------------------------------------------------
Bewildered Earth Scientist: "How do you re-wire alien equipment like that??"
Dr. Who: "Its easy when you've had 900 years experience in alien technology."
______________________________________________________________________________BAXTER_A@wehi.dn.mu.oz (05/05/90)
In article <1177@tmiuv0.uucp>, rick@tmiuv0.uucp writes: > > NTSC is not inferior. Nor is PAL superior. They're just "different". But, > I agree. Software should sense what display is running and accomodate it. > Many commercial programs do. And some of the shareware/freeware/PD stuff do. > Some don't. That's life. > > Besides, I think this thread got started by a flame on JRComm's lack of PAL > support. I think Jack answered reasonably by stating that JRComm is a terminal > emulator, and 90% of the terminals out there use 80 or 132 character wide > screens, 24 or 25 lines high. In those cases, I'm not certain that the > additional screen height in PAL mode would be of much use. But then again, > I'm in the States. Must be my North American bias showing again. You're not joking!! A standard NTSC screen in just over half the area of my overscan PAL screen. For almost any sort of program I can think of, if resolution (by which I mean the number of dots on screen) is not important, The actual physical space is. In the particular example you cite, VLT is an excellent example of a terminal emulator which handles screen sizing properly, an gives a significantly better review window and terminal window size as a result. It also allows for the placement of "function buttons" at the bottom of the screen which do not reduce the real estate available for terminal emulation. Surely if the additional 1/4 of the screen is not of use to PAL users, they wouldn't keep asking folk to support it. Regards Alan
d88-mbe@sm.luth.se (Michael Bergman) (05/07/90)
rick@tmiuv0.uucp writes: >NTSC is not inferior. Nor is PAL superior. They're just "different". But, >I agree. Software should sense what display is running and accomodate it. >Many commercial programs do. And some of the shareware/freeware/PD stuff do. >Some don't. That's life. Hmm, that depends on what you mean with "inferior". As I see it, PAL is better than NTSC in a number of ways, but I think that sort of discussion belongs somewhere else. Anyway, you americans are stuck with it because it was the first system and was widely spread before anything else came along... (recog- nize the pattern here..?) Some PD/Share/Free do, *most* don't. At least to my experience. >emulator, and 90% of the terminals out there use 80 or 132 character wide >screens, 24 or 25 lines high. In those cases, I'm not certain that the >additional screen height in PAL mode would be of much use. But then again, You're right, I don't care either if this type of program doesn't detect my PAL screen. As I've said before, it's the programs using graphics I care about. Good examples are MandFXP and MandelVroom - run these on a PAL machine and you'll se what I mean... If there is going to be a new verion of MandelVroom, I sure hope he gives PAL a thought. (BTW, which *is* the latest verion? Maybe I missed it!) Mike -- Michael Bergman Internet: d88-mbe@sm.luth.se // Dept. of Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se \X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe
bjornk@bula.se (Bjorn Knutsson) (05/07/90)
In article <899@tau.sm.luth.se> d88-mbe@sm.luth.se (Michael Bergman) writes: >rick@tmiuv0.uucp writes: >>emulator, and 90% of the terminals out there use 80 or 132 character wide >>screens, 24 or 25 lines high. In those cases, I'm not certain that the >>additional screen height in PAL mode would be of much use. But then again, > >You're right, I don't care either if this type of program doesn't detect my >PAL screen. As I've said before, it's the programs using graphics I care I beg to differ. It is VERY useful to have a terminal window that is larger than 80*25/132*25. I normally use 72 columns in interlace or 36 in noninterlace. This is a BIG win for me and many other I know. >about. Good examples are MandFXP and MandelVroom - run these on a PAL machine >and you'll se what I mean... If there is going to be a new verion of >MandelVroom, I sure hope he gives PAL a thought. (BTW, which *is* the latest >verion? Maybe I missed it!) I agree with that. 640*200 or 640*400 just doesn't look right when your system is using 704*284/704*568 normally. And he shouldn't adapt to PAL. He should adapt to whatever resolution is the default in the system (i.e, check the workbench screen). >-- > Michael Bergman Internet: d88-mbe@sm.luth.se > // Dept. of Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se >\X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu > UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
jprad@faatcrl.UUCP (Jack Radigan) (05/09/90)
bjornk@bula.se (Bjorn Knutsson) writes: >I agree with that. 640*200 or 640*400 just doesn't look right when >your system is using 704*284/704*568 normally. And he shouldn't adapt >to PAL. He should adapt to whatever resolution is the default in the >system (i.e, check the workbench screen). I am, I am... I've repented from my past transgressions of slighting the *other* side, please now, find it in your hearts to forgive us wayward Americans, or at least *me*. <grin> -jack-
bjornk@bula.se (Bjorn Knutsson) (05/09/90)
In article <1371@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >bjornk@bula.se (Bjorn Knutsson) writes: > >>I agree with that. 640*200 or 640*400 just doesn't look right when >>your system is using 704*284/704*568 normally. And he shouldn't adapt >>to PAL. He should adapt to whatever resolution is the default in the >>system (i.e, check the workbench screen). > >I am, I am... I've repented from my past transgressions of slighting the >*other* side, please now, find it in your hearts to forgive us wayward >Americans, or at least *me*. <grin> Well, I'll think about it... :-) Of course, the screensize isn't the only problem, especially not in a terminal package. You see, we Europeans often use hacked up ASCII (7-bit) for telecommunications. Now, this really screws things up since we're using 8-bit code in our systems. This leads to two problems, bot easily solved if you're aware of them. Namely: o We must be able to change the font. We have to alter the normal font in order to get our national characters into the 7-bit code. o We must be able to use a separate keymap for the terminal package. Otherwise we'll be sending 8-bit codes to a system expecting the 7-bit codes or using 7-bit codes on the Amiga (which expects the 8-bit codes) In Sweden, we remap "}{|][\" to be our national characters. If you can't do the two things above, we're going to have a lot of problems using your software. Now, the first problem is often easily solved. The second problem seems to be harder. Marco solved the problem in a pretty ugly way for ATalk III. It works, but... He makes a local copy of the keymap in use at startup time inside his program. This works, but you have to fiddle around with the keymaps when you start your program. A Norwegian program called NComm solved in an entirely different way. It scans the current keymap on startup just like ATalk, but it, being a European product, has internal support for many different countries, and can use the default national keymap. Also, you don't have to change any fonts to use that package. It knows about several European languages and how to convert internally between the 8-bit and 7-bit codes. This is a pretty good solution, unless you happen to come from a country who's national characters aren't supported by the program. Online has a builtin conversion table that the user can customize. This is really a very nice solution, too bad the rest of the program is unusable. What I really think I'd like to see is a program that lets you use the font of your choice along with the keymap of your choice. I mean, if Bill Hawes can include a keymap-command with WShell/ConMan that allows you to choose what keymap a specific shell should use, why can't you guys do something similar? It would solve a lot of problems for us Europeans. > -jack- --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
wschmidt%decefix@decefix.iao.fhg.de (Wolfram Schmidt) (05/09/90)
In article <1371@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: [...] >I am, I am... I've repented from my past transgressions of slighting the >*other* side, please now, find it in your hearts to forgive us wayward >Americans, or at least *me*. <grin> > > -jack- I forgive you :-) , but i don't forgive MANX (see z, db, sdb, sdbf) :-< Wolfram
papa@pollux.usc.edu (Marco Papa) (05/10/90)
In article <6939@bula.se> Bjorn Knutsson <bjornk@bula.se> writes: >What I really think I'd like to see is a program that lets you use the >font of your choice along with the keymap of your choice. I mean, if >Bill Hawes can include a keymap-command with WShell/ConMan that allows >you to choose what keymap a specific shell should use, why can't you >guys do something similar? It would solve a lot of problems for us >Europeans. Do you mean something like a ToolType AND CLI parameter like: 1.> Atalk3 KEYMAP myswede FONT swe (CLI) KEYMAP=myswede (ToolTYpe) FONT=swe The KEYMAP deal should be easy (Use default if no keymap is given as AT-/// does rigth now). The font would not work that well (since VT100 needs a whole family of fonts). It would work just for the initial font only. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bjornk@bula.se (Bjorn Knutsson) (05/10/90)
In article <24604@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >In article <6939@bula.se> Bjorn Knutsson <bjornk@bula.se> writes: >>What I really think I'd like to see is a program that lets you use the >>font of your choice along with the keymap of your choice. I mean, if >>Bill Hawes can include a keymap-command with WShell/ConMan that allows >>you to choose what keymap a specific shell should use, why can't you >>guys do something similar? It would solve a lot of problems for us >>Europeans. > >Do you mean something like a ToolType AND CLI parameter like: > >1.> Atalk3 KEYMAP myswede FONT swe (CLI) > >KEYMAP=myswede (ToolTYpe) >FONT=swe Well, that could solve the problem. But actually, I think I'd prefer to have it as a menu option, or in the case of ATalk, have it in the quickmenu. That way, you could specify font/keymap combinations for every entry in the phonebook. We currently have to deal with three different "standards" for our national characters. The 7-bit code, the IBM PC 8-bit code and the ISO (Amiga) 8-bit code. Having to reload the program just to switch between them seems like overkill to me. >The KEYMAP deal should be easy (Use default if no keymap is given as AT-/// does >rigth now). The font would not work that well (since VT100 needs a whole >family of fonts). It would work just for the initial font only. I can see your point about the fonts. But since VT100 uses its own fonts, you could count that as a special case. Your ANSI emulation, on the other hand, could support many different fonts. >-- Marco >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >"Xerox sues somebody for copying?" -- David Letterman >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
jprad@faatcrl.UUCP (Jack Radigan) (05/10/90)
bjornk@bula.se (Bjorn Knutsson) writes: >o We must be able to change the font. We have to alter the normal font > in order to get our national characters into the 7-bit code. >o We must be able to use a separate keymap for the terminal package. > Otherwise we'll be sending 8-bit codes to a system expecting the > 7-bit codes or using 7-bit codes on the Amiga (which expects the > 8-bit codes) Well, the font has *always* been user definable. As for the keymap, I only use RAWKEYS and open the console.device to convert them to cooked keys. I hope that this is sufficient for your use, is it? >Online has a builtin conversion table that the user can customize. >This is really a very nice solution, too bad the rest of the program >is unusable. Yes, I plan on adding a set of input and output conversion tables, but since I allow font changing and only use RAWKEYs to do key conversion, I don't really see the need for this. It'll be there for completeness though. >What I really think I'd like to see is a program that lets you use the >font of your choice along with the keymap of your choice. I mean, if >Bill Hawes can include a keymap-command with WShell/ConMan that allows >you to choose what keymap a specific shell should use, why can't you >guys do something similar? It would solve a lot of problems for us >Europeans. Does this mean you need the application to set the keymap specifically? I was udner the impression that the program will inherit the keymap of the CLI that it was launched from... >Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk -jack-
jprad@faatcrl.UUCP (Jack Radigan) (05/10/90)
bjornk@bula.se (Bjorn Knutsson) writes: >Well, that could solve the problem. But actually, I think I'd prefer to have >it as a menu option, or in the case of ATalk, have it in the quickmenu. >That way, you could specify font/keymap combinations for every entry in the >phonebook. We currently have to deal with three different "standards" for >our national characters. The 7-bit code, the IBM PC 8-bit code and the ISO >(Amiga) 8-bit code. Having to reload the program just to switch between >them seems like overkill to me. Oh, now I see what you need, consider it done. -jack-