HDTenEightyP/NetNews huggingface dataset:
From: boutell@isis.cshl.org (Tom Boutell)
Newsgroups: rec.games.programmer
Subject: Xlib Clipping Revisited
Date: 14 Dec 92 17:40:18 GMT
Article-I.D.: phage.Bz9Fr7.5uy
Organization: Cold Spring Harbor Labs

Well, I now suspect the problem is that the clipping support can only be
used for bitmaps (specifically the "clipped bitmaps" set of primitives).
I also infer from this it probably can't be used for compiled bitmaps.

Decent clipping is important to getting the look of this game right,
but line-drawing, even with the speed of this library and the simplicity
of the images, was proving too expensive a technique anyway, so I'll
probably bite the bullet and move to bitmaps. Hope clipping works for
compiled 'maps, but even if it doesn't I suppose I can use the
uncompiled 'maps when I know I'm in an edge situation this is probably
the best approach.

XLIB is still an amazing thing to have around. One pet peeve, though:
the color and basepage arguments aren't always in a consistent order.
That gets really annoying when trying to move mentally from one
function to another.

-T

-- 
Tom Boutell, boutell@cshl.org

Clausthaler is the best non - alcoholic beer in the known universe.
Newsgroups: rec.games.programmer,alt.tv.red-dwarf
From: daniel@yoyo.cc.monash.edu.au (Daniel Bowen)
Subject: Re: WOLF3D - ShareWare version
Organization: Monash University, Melb., Australia.
Date: Sat, 19 Dec 1992 13:52:13 GMT

etljmme@etlxd30.ericsson.se (Jim) writes:

>Message-ID: <1992Dec16.100256.6269@ericsson.se>
>Sender: news@ericsson.se
>Nntp-Posting-Host: etlxd10h.ericsson.se
>Reply-To: etljmme@etlxd30.ericsson.se
>Organization: Ericsson
>Date: Wed, 16 Dec 1992 10:02:56 GMT
>Lines: 18

>Hi everyone.

>I've received alot of requests for the ftp site for wolf3d.  I don't know!!

>Because alot of people want it, I'll uuencode it with all relevant details and
>post it to alt.binaries.multimedia by the end of the week.  Sorry for the delay
>but I've got to go home and get it, etc.

Yeah?? Yipee!! Now I think I'll go post on rec.games.programmer for the
Red Dwarf FAQ, on comp.sys.ibm-pc.games for the Simpsons FAQ, and
perhaps I'll go look on misc.consumers for the Green Golfball joke,
in aus.tv for the Bastard Operator From Hell, and rec.railroad for Toxic
Custard.


Daniel Bowen, smeghead extraordinaire.
-- 
Daniel Bowen, Monash University |  "We all live in a mellow submarine..."
            Melbourne Australia |
   daniel@yoyo.cc.monash.edu.au |                         The Jamaican Beatles
      TCWF: tcwf@gnu.ai.mit.edu |                                    [TCWF126]
From: cbusch@ub.d.umn.edu (Chris)
Newsgroups: rec.games.programmer
Subject: Computer problems
Date: 12 Dec 92 08:35:21 GMT
Article-I.D.: ub.1gdie9INN4b4
Distribution: world
Organization: University of Minnesota, Duluth
NNTP-Posting-Host: ub.d.umn.edu

Hello
    Has anyone heard any negative things about Packard Bell, Acro,
FastData, Comtrade or any others?  How 'bout any thing great about a
computer brand?  (Cost definately matters the most! so no Compaqs)  I am
thinking about purchasing a 386DX or greater.

--
Chris Busch   CBUSCH@ub.d.umn.edu
"C++ is the language of choice."
"The use of COBOL cripples the mind; its teaching should, therefore,
    be reguarded as a criminal offense." - E. W. Dijkista 
"High-level languages should remove burden from the programmer, not
 put burden on the programmer!"
"Don't ask 'why would you do that?' instead ask 'why wouldn't you do that?'"
From: mkelly@mystix.cs.uoregon.edu (Michael A. Kelly)
Newsgroups: rec.games.programmer
Subject: Re: Jerky animation (Was: The Correct Way to Control Game Speed)
Date: 19 Dec 92 22:54:50 GMT
Article-I.D.: cs.1992Dec19.225450.21560
Organization: University of Oregon Computer and Information Sciences Dept.

In article <1992Dec19.221442.3741@news2.cis.umn.edu> toddl@county.lmt.mn.org (Todd Lehman) writes:
>In article <1992Dec19.190258.15117@midway.uchicago.edu> greg@dent.uchicago.edu (Greg Kuperberg) writes:
>>Now for some specifics.  The eye and the visual cortex integrates
>>separate images into continuous motion if the images appear at a rate
>>faster than 5 or 10 times per second or so.  15 or more frames per
>>second looks good, and it is a waste of CPU time to have more than 30
>>redraws per second.
>
>No matter how perfectly your page flipping / double buffering works, no
>matter how fast your sprites are painted into video memory, if you move an
>object n pixels every 2 video cycles, there will be a ghost image trailing
>behind by n/2 pixels.  (Don't believe it?  Try it!) 
>
>Has anyone else observed this ghosting effect?  Does anyone know what is
>the cause?  I believe it to be an optical illusion, since the ghosting is
>not there when your eyes remain fixed.

I have noticed it, just yesterday when it started taking more than one tick
to do my pre-draw calculations, and it ended up drawing every other tick
(where a tick is one monitor refresh).  I thought something was wrong with
my drawing routines at first, but then realized that was impossible.  I
believe it's an optical illusion, since I have proved (in my head) that the
old sprite and the new one can not be on the screen at the same time.  I
don't know what you mean by 'your eyes remain fixed' but the ghosting is
always there for me.  I recently took a computer science graduate level
course in vision, not that that means anything, but my somewhat-educated
intuition tells me that it's definitely an optical illusion.

But more importantly, is there any way to reduce or (gasp!) eliminate the
effect?  It sure would be nice to only have to do 30 frames per second....

>It's the same kind of effect you
>see when 24 f.p.s. movies are converted to 30 f.p.s. video cassette format
>by doubling up every 5th frame.  (Ever wonder why movies on TV look kind-of
>jerky, but live video such as talk shows and soaps look smooth?)

I've never noticed this effect.  Are you sure it isn't just you? :)

Later,

Mike.
-- 
_____________________________________________________________________________
Michael A. Kelly                                               Senior Partner
mkelly@cs.uoregon.edu                                      High Risk Ventures
_____________________________________________________________________________
Newsgroups: rec.games.programmer
From: dpifko@navier.UVic.CA (Daniel  Pifko)
Subject: Is there a FAQL archived for this group?
Organization: University of Victoria, Victoria, BC, Canada
Date: Sun, 13 Dec 92 21:56:20 GMT

And if so, could some kind soul tell me where?  

In particular, I'm looking for how to handle modem (or just serial) communications for passing statuses, etc.  I just did a multi-player maze game, but it 
was on an Ethernet, and the information was buffered as packets already by the
ENet card driver.   All I need to send across the line is some initialization
information and updates to the user's XY position.  

Thanks,

Daniel.

-- 
Daniel Pifko
dpifko@sirius.uvic.ca
Newsgroups: rec.games.programmer
From: kludge@hardy.u.washington.edu (Kludge)
Subject: Re: Xlib Clipping Revisited
Organization: University of Washington, Seattle
Date: Mon, 14 Dec 1992 22:18:38 GMT

In article <Bz9Fr7.5uy@phage.cshl.org> boutell@isis.cshl.org (Tom Boutell) writes:
>Well, I now suspect the problem is that the clipping support can only be
>used for bitmaps (specifically the "clipped bitmaps" set of primitives).
>I also infer from this it probably can't be used for compiled bitmaps.
>
>Decent clipping is important to getting the look of this game right,
>but line-drawing, even with the speed of this library and the simplicity
>of the images, was proving too expensive a technique anyway, so I'll
>probably bite the bullet and move to bitmaps. Hope clipping works for
>compiled 'maps, but even if it doesn't I suppose I can use the
>uncompiled 'maps when I know I'm in an edge situation this is probably
>the best approach.

  I *really* doubt it works for compiled bitmaps - how do you clip code? :)
Maybe there should be a new type of compiled bitmap that does clipping
automatically, but I bet that wouldn't have much of a speed advantage over
regular bitmaps - and they'd be about 8 times as large. 
  Don't give up on lines, though.  They're pretty easy to write a clipping
routine, though it's been a while since I tried.  There are quite a few
books with algorithms for clipping lines in them.  It also looks as if
the XLib line drawing algorithm could be sped a bit, but I'm not sure.

>
>XLIB is still an amazing thing to have around. One pet peeve, though:
>the color and basepage arguments aren't always in a consistent order.
>That gets really annoying when trying to move mentally from one
>function to another.

  Yeah.  That annoys me, too.  But it's a pretty small drawback to the power
of this amazing little package.

							-Kludge
Newsgroups: rec.games.programmer
From: colin.buckley@rose.com (colin buckley)
Subject: DA & .fli
Organization: Rose Media Inc, Toronto, Ontario.
Date: Mon, 14 Dec 1992 18:57:39 GMT
X-Gated-By: Usenet <==> RoseMail Gateway (v1.70)


Date Entered: 12-14-92 13:48
BA>        In 256-color mode it doesn't seem like you have any room for
  >page flipping. Are the pictures loaded in a virtual page? Did they use
  >mode-x/y? Or are they just damn fast with their graphics routines?
  >        I assume these animations are stored as seperate pictures.

I don't know about DA, but AA only saves what has changed each frame.  So
If I draw a 320x200 face, I have 64000 bytes for the first frame, and if
the next 10 frames only have mouth movement, then only the mouth movement
is saved (maybe 1000 bytes for each).  AA will REP SCAS the previous
frame to the current frame looking for changes, then it REPNE SCAS
to see how long the change lasts.  Now all it does is save that change.
And continues it's search for changes in the rest of the screen, and then
goes on to the next and repeats.  Run length encoding is performed on the
portion that has changed to surpress repeated bytes and draw them fast.
.----------------------------------------------------.
| Colin Buckley                                      |
| Toronto, Ontario, Canada                           |
| InterNet: colin.buckley@rose.com                   |
|                                                    |
| So Eager to Play, So Relunctant to Admit it...     |
`----------------------------------------------------'
---
   RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285
From: mduffy@aludra.usc.edu (Michael Duffy)
Newsgroups: rec.games.programmer
Subject: Re: Xlib Clipping Revisited
Date: 15 Dec 1992 18:55:01 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu

In article <cf=bNLK00Vp=MOqlUB@andrew.cmu.edu> Court Demas <court+@CMU.EDU> writes:
> [quoted article deleted ....]
>
>I actually fooled around with this a bit, and I think it might be
>possible.  At least horizontal clipping seems fairly easy - you have a
>set on instructions n-bytes long broken into sections of each scanline. 
>Just compute the top line and jump into the correct section, and then
>check at the end of each line to see if you should cut out (could get a
>little hairy though if you wanna do it really fast (self-modifying code,
>blech)).  Clipping vertically would take a bit more work but it's
>basically the same concept.  Has anybody else played with this?
>
I've had some thoughts on this too.  Clipping could be done either horizontally
or vertically since compiled bitmaps (at least ones that use stosb instead of 
the more optimized stosw & stosd) need not draw across scanlines thanks to
their structure.  At the end of each line (vertical or horizontal) could be
instructions like "dec cx" followed by "jcxz @@End" where a "ret" was at @@End.
An array is kept as above with the entry points for each line.  When it is 
time to draw the sprite, the entry point for the first line is determined, and
cx is initialized for the number of lines to draw.  Bingo, clipping for
left and right or top and bottom (depending on how the compiled bitmap is 
structured.)  

Now what I haven't figured out is how to clip a compiled bitmap say top and
left or top and right........  Hmmmmm...... this one's probably not possible,
or would slow the code down so much that you'd lose the advantages of 
compiling it.

>
>Maybe implementing the "enhanced" bresenham's (or whatever it's called)
>would make it faster - precomputing the length of the spans and such. 
>Tricky to implement though (I think Abrash wrote something about this).
>

Run slice algorithm in Dr. Dobbs Journal, November and December 1992 issues.
Interesting stuff. 

>-court

Michael Duffy
The man with no .sig

Newsgroups: rec.games.programmer,comp.graphics
From: 4224_5142@uwovax.uwo.ca
Subject: WGT Tile Systems
Organization: University of Western Ont, London
Date: Sun, 13 Dec 1992 01:22:43 GMT


For those of you who had troubles using the WGT Map Maker (design utility
for creating tile maps in 256 colors), we've release version 1.1 and it
has proven 100% compatible with all machines. We discovered that some EMS
testing routines caused some systems to lock, and therefore removed the
offending routines. We have also added a user controllable delay for the
PLOT mode which, on some faster CPUs, polled the mouse too fast and froze
the system. Now you can slow our product down to meet your specific needs.

	The bitmap editor (Sprite Creator) has also been re-released with
delays, and is available for anyone who leaves me e-mail. In a week or so
I will be posting the frame rates for our scrolling game fields. The results
will reflect everything from a 286-10Mhz to a 486dx2 50Mhz. We will report
rates for window sizes of 4*4 up to 17*10 for each processor.
(Currently, we get about 9 fps for a 17*10 tile window, or 43520 pixels, on
our 386-16Mhz. Rates improve up to 49 fps on this system, depending on
the window size) 

*****************************************************************************
*       \\          //  _______   _______    egerter@obelix.gaul.csd.uwo.ca *
*        \\        //  //            |                                      *
*         \\  /\  //  ||   ___       |       Author of WGT graphics         *
*          \\//\\//   ||     \\      |       toolkit for 320*200*256 VGA    *
*           \/  \/ .   \\____// .    |  .    Version 3.0 Now Available      *
*                                            (Turbo C++ 1.0 or greater)     *
* Sprites  Color Cycling  Bitmap SFX  4-directional Scrolling  FLI routines *
*****************************************************************************
Newsgroups: rec.games.programmer
From: ortl@quads.uchicago.edu (james andrew ortlieb)
Subject: Re: NeXT game programmers
Reply-To: ortl@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Fri, 18 Dec 1992 17:25:44 GMT

	I'd like to, but I don't know when they'll get around to putting the
development tools on the NeXTs at the site I usually use (they don't even 
have a C compiler yet, sigh...) Anyway I'll talk to you if you need to chat.

-- jim


-- 
--------------------------------------------------------------------------
--- Jim Ortlieb          -- "Today you will win big,
ortl@midway.uchicago.edu --      pick a fight with a four year old ..."
--------------------------------------------------------------------------
Newsgroups: rec.games.programmer
From: rubin@godzilla.cis.ohio-state.edu (Daniel Rubin)
Subject: I to get in a major game developers door?
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Mon, 14 Dec 1992 23:58:43 GMT

Sorry if this is a frequently asked question but...

Does anyone know how to apply for a job at the major companies that develop
video games.  Like Sega, Atari, Nintendo, Bally Midway etc.   You never see
these companies represented at job fairs?  I would love to work as a software 
developer for a company like this.  Anyone got any good pointer on how to
get in...

Thanks                                                           - Dan

-- 

             Daniel Joseph Rubin     rubin@cis.ohio-state.edu 
     
                       GO BENGALS!      GO BUCKS!
From: baylor@ccwf.cc.utexas.edu (Baylor)
Newsgroups: rec.games.programmer
Subject: Re: Share Ware $5
Date: 14 Dec 92 04:42:29 GMT
Organization: The University of Texas at Austin, Austin TX

>	Well, I think you have to remember two things about these guys:
>1) They can't charge more than the author will allow (legally, anyway :)
>2) Even if the vast majority of people don't realize that they are buying
>	a shareware program, the services are usually free and will give you
>	some sales you normally wouldn't get.

	Ok, so these guys that distribute games for profit ARE getting
a shareware author's permission first?
	Are they allowed to distribute without permission?
					- baylor


Newsgroups: rec.games.programmer
From: chrisp@wimsey.bc.ca (Chris Phillips)
Subject: Re: Mouse hits on a hex grid? Here's how:
Organization: Wimsey Information Services
Date: Sun, 13 Dec 1992 12:22:25 GMT
X-Newsreader: Tin 1.1 PL5


	Here's a simple method if you have a little extra memory.

 	Use a background buffer to draw a mirror image of the displayed
hex grid only use one color per hex. Then when the mouse is clicked 
pick up the color on the background buffer thats at the same x,y as your
mouse and thats your hex location. You could also use variations on this
to just fine tune aproximations. eg narrow it down to 5 hexes and then use 
the back buffer to get the exact hex..
Xref: sparky rec.games.programmer:5072 alt.tv.red-dwarf:1978
From: sl859@cc.usu.edu
Newsgroups: rec.games.programmer,alt.tv.red-dwarf
Subject: Re: WOLF3D - ShareWare version
Date: 16 Dec 92 11:39:43 MDT
Organization: Utah State University

In article <1992Dec16.100256.6269@ericsson.se>, etljmme@etlxd30.ericsson.se (Jim) writes:
> Hi everyone.
> I've received alot of requests for the ftp site for wolf3d.  I don't know!!

      nic.funet.fi  its somewhere in there.  I think in msdos then games
the Apogee...
			Look around it's not that hard.
							wReam...
						Ultimate Ninja of LNH!
P.S.  Happy Holidays Gamers!
Newsgroups: rec.games.programmer
Subject: Re: games project
From: cs15fa38@csufres.CSUFresno.EDU ()
Date: 18 Dec 92 02:09:13 PST
Organization: California State University, Fresno

In article <1992Dec17.085451.10791@nuscc.nus.sg> eng10317@nusunix1.nus.sg (TAN PONG FEI) writes:
>hello anyone out there,
>    Hi!!!!! I am looking for some help from anyone of you, in fact quite
>a desperate help that i need. At this moment, we are told to write a
>programme on games on either the mastermind or othello. I have to submit
>my proposal as soon as possible. I really hope some of the kind hearted

I guess this must be a class assignment.  All I can say is do your own
work, there is no substitute for hard work!

Roland Chia

Newsgroups: rec.games.programmer
From: jmunkki@vipunen.hut.fi (Juri Munkki)
Subject: Re: Algorithm for Bitmap rotation & scaling
Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology
Date: Sun, 20 Dec 1992 10:28:27 GMT

Normally for 3D transformations, it is convenient to use a 3x3 matrix
with some constant items at the left:

	| a b 0 |
	| c d 0 |
	| e f 1 |

Assuming that your vectors are of the form [x y 1], you can then perform
translations as well as rotations and the operations can easily be combined.
PostScript does all it's scaling and transforming operations using 2x3 matrices
that are filled to the above form.

Doing just rotations and scales doesn't make much sense, since you can
save a lot of multiplies by just adding up the rotation angles and
multiplying the scaling operators instead of using matrices.

I'm not aware of any personal computer games that would use matrix
transforms on bitmaps. I seriously doubt that Wing Commander is using
anything like this. From what I have heard (I have only seen the game
once or twice), all the shapes are stored as pixel maps.

Once you move into polygon or vector based graphics, matrix operations
become more plausible. As you noted, the nice thing is that you can
scale and rotate (and translate) as much as you want. If you have seen
the arcade game "Assault", then you know what kind of effects are possible
(although Assault has some hardware assistance and probably uses a DDA
to scale and rotate the pixel maps).

-- 
  Juri Munkki					       Windsurf: fast sailing
 jmunkki@hut.fi					      Macintosh: fast software
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: rec.games.programmer
Subject: FAQ < how often should it be posted? >
Date: 16 Dec 92 22:42:59 GMT
Organization: The Tower of Zot - (716)8338-616

Ok I know this months FAQ has not been posted YET.
I'm changing it (like sorry).  Adding many corrections and
removing some LONG explanations.  The FAQ was not general 
enough AND it covered some things that were in other groups
(MOD format shoud be in in the amiga sound group)

So the question is how often should the FAQ be posted?

Cyberman

************************************************************
* Cyberman@TOZ.BUFFALO.NY.US                               *
*   "Life is what you put into it" - Cyberman              *
* Optimistic - running through a barn of manure looking    *
* for the horse!  /\ [] ( )                                *
Newsgroups: rec.games.programmer
From: isc30108@nusunix1.nus.sg (AMBAT SASI S/O PALISSERY P)
Subject: Re: Continous Keyboard interrupt
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 17 Dec 1992 23:20:45 GMT

Philippe Desaulniers (flipper@pascal) wrote:
: 
:  I am wondering how is it possible to get a continous keyboard interrupt, i.e. to prevent the standard PC procedure wich consists in getting a caracter once, then wait a bit, then get a series of caracters (when you keep a key pressed for a while). Of course my intention is to use the keypad's arrows as a "joystick".
: 
: Is that standard procedure due to DOS? or the BIOS? or what?
: 
: I am using your everyday PC, and I program with Bordland's Turbo C 2.01 & Microsoft's MASM.
: 
: If anyone can help me, I'd be very thankful....
: 
use BIOS int 9 to activate an interrupt driven module.
then read port 60h for scan code.

sasi.
Newsgroups: rec.games.programmer
From: colin.buckley@rose.com (colin buckley)
Subject: Fastgraph/ XLIB4
Organization: Rose Media Inc, Toronto, Ontario.
Date: Sun, 13 Dec 1992 07:51:49 GMT
X-Gated-By: Usenet <==> RoseMail Gateway (v1.70)


Date Entered: 12-13-92 02:44
CT>This is part 1 of 3 zipped files (pkzip) that contain IBM graphics Libraries
  >for really fast byte aligned animation.  The libraries can be used
  >with C quickbasic and pascal (also assembly)

Wasn't particularly pleased to see this forced upon me, but since it
has, why won't someone post XLIB04 for us without FTP and can't
recieve uuencoding's in EMail.  I got XLIB03 from a post here, I don't
care if it's bigger.  Atleast there have been other people who have
asked for XLIB, I didn't see any requests for Fastgraph.  Besides,
The Gruber's will send you a disk with Fastgraph for free.  Egg doesn't.
.----------------------------------------------------.
| Colin Buckley                                      |
| Toronto, Ontario, Canada                           |
| InterNet: colin.buckley@rose.com                   |
|                                                    |
| So Eager to Play, So Relunctant to Admit it...     |
`----------------------------------------------------'
---
   RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA