HDTenEightyP/NetNews huggingface dataset:
From: gordon@meiko.com (Gordon Henderson)
Subject: Re: Pacman Ghost logic
Keywords: Pacman
Organization: Meiko Scientific Corp.
Date: Wed, 26 Aug 1992 09:29:13 GMT

In article <1992Aug25.160755.7776@hobbes.kzoo.edu> k044477@hobbes.kzoo.edu (Jamie R. McCarthy) writes:
>dmb@rice-chex.ai.mit.edu (David Baggett) writes:
>>neil@cs.hw.ac.uk (Neil Forsyth) writes:
>>>One thing about the real Pacman was that the ghosts only made decisions when
>>>they reached a junction. I don't think they ever doubled back along the same
>>>path
>>
>>I suspect the arcade Pac-Man used a much simpler algorithm, but it's
>>true that the ghosts can't ever double back.
>
>Not that I'm a big Pac-Man fan, but I just have to correct this.  At
>(pseudo-) random intervals, all four ghosts suddenly reverse direction.

I seem to remember from playing the original arcade game that the green ghost
would reverse and run away from you if it was chasing you, then you reversed
direction and headed straight for it!

A cowardly ghost?

----
  Gordon Henderson
From: neil@cs.hw.ac.uk (Neil Forsyth)
Newsgroups: rec.games.programmer
Subject: Re: Wolf 3d by Id - this is how they did it
Date: 1 Sep 92 10:30:47 GMT
Organization: Dept of Computer Science, Heriot-Watt University, Scotland

In article <10066@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes:
>benrg@ocf.berkeley.edu (Brn Rudiak-Gould) writes:
>>I have right now some working C code that does 3D graphics that are quite
>>similar to Wolf3d's walls (not the objects).  Compiled with DJGPP it's very
>>fast--I don't remember the exact number of frames per second but it's a lot
>>more than are needed.  I suspect that Id used used the same algorithm that
>>I'm using, but I'm not sure since I haven't looked at their code.
>> [excellent description of algorithm deleted]
>
>An old Atari 8-bit game (running at under 2MHz) used this algorithm (I guess).
>The game was called "WAYOUT".  All it was was a get-out-of-the-maze game, and
>only drew up about 80x60 pixels, but it was full speed (60Hz).

I remember that game too! I thought it was great fun (maybe I'm just simple
:-). You had an automatic mapmaker and a compass though sometimes a thing
called the kleptangle would steal them. One wall piece was designated the
exit and could only be approached from one side as strong wind prevented
access from the other side. There were loads of mazes and the best times
were stored on disk. I cheesed off my friend who had the game by persevering
against the wind to get a highly improbable time on one particular maze.

Technically I think the game used screen interrupts to reflect the top
half of the screen in the bottom and changed the palette on the fly to get
graduated blue sky above the maze and a green floor. I also had some theory
that they used the multicoloured text mode for the picture by using the
character definitions as a bitmap since the active window was so small.

All in all a great game which I have not seen the like of since on Atari
machines.

+----------------------------------------------------------------------------+
! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
!                                                                            !
! Neil Forsyth                      JANET:  neil@uk.ac.hw.cs                 !
! Dept. of Computer Science         ARPA:   neil@cs.hw.ac.uk                 !
! Heriot-Watt University            UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
! Edinburgh, Scotland, UK           "That was never 5 minutes!"              !
+----------------------------------------------------------------------------+
Newsgroups: rec.games.programmer
From: u910826@bruny.cc.utas.edu.au (Louis        siuoL)
Subject: Polygons
Summary: Needed a fast polygon filler
Keywords: Polygon fill
Organization: University of Tasmania, Australia.
Date: Wed, 26 Aug 1992 03:31:46 GMT

I think the heading says it all:
That is I want/need/would like a fast polygon filler.

--
+-----------------------------------------------------------------------------+ |           Louis Solomon - a student at The University of Tasmania           | |                    e-mail: u910826@bruny.cc.utas.edu.au                     |
+-----------------------------------------------------------------------------+ |              "to err is human, but to really fuck things up takes           | |                   a computer" - unknown                                     |
+-----------------------------------------------------------------------------+
Newsgroups: rec.games.programmer
From: greg@Quotron.COM (Greg "Maddog" Knauss)
Subject: Re: Pacman Ghost logic
Organization: Quotron System, Inc.
Date: Wed, 26 Aug 1992 19:05:37 GMT

dmb@rice-chex.ai.mit.edu (David Baggett) writes:

Rice Chex?  Did you get to name your machine, Dave, or did you inherit it?

>Yes, but what would be more interesting would be a computer opponent
>that looked at the board and thought to itself, "I dunno, both those
>paths look about three inches long.  But I bet he's trying to snag that
>pill over there, so I'll turn left."  Perhaps that's part of the recent
>fondness for GA's and NN's in this group.

Interesting, yes, but practical -- probably not.  It's neat to talk about
GAs and NNs and say, "When..." and "What if..." but I don't think you're
going to see them in games (or anywhere else) any time soon.  Even the
"sensory input" of Pac-Man would overload the machine.
	What I would like to see (and probabaly should do, with "Night
of the Brain-Sucking Undead Businessman From Beyond the Grame" if I ever
get off my butt and start working on it again...  Heh) is fuzzy logic.
I think it's much more realistic to attempt a program that keeps track
of the types of moves used by the player in a certain situation, recording
percentages.  The bad guys then use those percentages to counter-attack.
"Hey, he's moving under me.  Using Attack 1, I've died 80% of the time;
using Attack 2, I've died 40% of the time.  Attack 2 it is.  Yaaah!"
	You get realistic battles -- you're not going to get away with
the same thing nine times in a row -- and can still safely stay within
the bounds of a home computer's ability.  Plus, since the game constantly
changes stragety, maybe it says interesting longer...
--
 ------------------------------------------------------------------------------
 Greg "Maddog" Knauss               "Aieee!"              greg@duke.quotron.com
 ------------------------------------------------------------------------------
Newsgroups: rec.games.programmer
From: hamrick@milton.u.washington.edu (Mike Hamrick)
Subject: Adventure Game Compiler
Organization: University of Washington, Seattle
Date: Sun, 30 Aug 1992 08:59:56 GMT

Hey there!

I am looking for an adventure game compiler.  A while back I read parts
of a discussion concerning a fellow named Josh, and how he couldn't have
possibly made an adventure game compiler that was as good as mumblemumble.

I now find myself in need of this compiler.  If some kind soul out there
could point me in the right direction I would be much obliged.  Please use
electronic mail if possible, as I don't wish to waste bandwith with this.

---
hamrick@milton.u.washington.edu -- "I feel most at home among the defiled."
From: dmb@rice-chex.ai.mit.edu (David Baggett)
Newsgroups: rec.games.programmer
Subject: Re: Pacman Ghost logic
Date: 27 Aug 92 17:46:38 GMT
Organization: MIT Artificial Intelligence Laboratory

greg@Quotron.COM (Greg "Maddog" Knauss) writes:
>dmb@rice-chex.ai.mit.edu (David Baggett) writes:
>
>Rice Chex?  Did you get to name your machine, Dave, or did you inherit it?

Actually, rice-chex is just a general-purpose server.  If you want a
challenge, try finding a breakfast cereal (with approprite hyphenation)
that *doesn't* work when you say "ping <cereal>.ai.mit.edu"  :-)

>Interesting, yes, but practical -- probably not.  It's neat to talk about
>GAs and NNs and say, "When..." and "What if..." but I don't think you're
>going to see them in games (or anywhere else) any time soon.  Even the
>"sensory input" of Pac-Man would overload the machine.

That's very much an assumption, and one based on the current state of
the art.  There are possibly ways of simulating generalized thought
without using the conventional GA and NN methods.  I don't think the
information overload is inherent in the problem, but rather a
side-effect of the solution methods we currently have.

>	What I would like to see (and probabaly should do, with "Night
>of the Brain-Sucking Undead Businessman From Beyond the Grame" if I ever
>get off my butt and start working on it again...  Heh) is fuzzy logic.

That still sort of seems like "faking it" to me.  The character is
still chosing from a predetermined set of choices.  It only becomes
interesting, IMHO, when the algorithm (method) starts producing
patterns of behavior that were not programmed in at the outset.  GA's,
at least, provide a straightforward way to make this happen, though
it's unclear (to me at least) that they have anything at all to do
with independent thought.

Dave Baggett
--
dmb@ai.mit.edu           MIT Artificial Intelligence Laboratory                  
ADVENTIONS: interactive fiction (text adventures) for the 90's!
dmb@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS
Newsgroups: rec.games.programmer
From: tmkk@uiuc.edu (Khan)
Subject: Re: VGA memory address
Followup-To: alt.dev-null
Organization: University of Illinois at Urbana
Date: Wed, 26 Aug 1992 13:04:56 GMT


In article <1992Aug26.095612@axion.bt.co.uk> pcellik@axion.bt.co.uk (Peter SPHINX Cellik) writes:
>
>In article <BtJK9v.8Bw@news.cso.uiuc.edu>, tmkk@uiuc.edu (Khan) writes:
>|> 
>|> In article <92237.172148KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
>|> >
>|> >Assuming that I am usind a VGA monitor, this chould place the character
>|> >'u' in the upper left corner of the screen. (under assumption that 0xB800
>|> >is the right address) But it doesn't.
>|> 
>|> That's because B800 is not the right segment for the video buffer on a
>|> VGA.
>|> 
>
>What do you mean that B800 is not the right segment for VGA text?  It is.
>Only for EGA and VGA GRAPHICS modes that the video segment moves to A000.
>
>Don't start thrashing the bloke if you don't know yourself.

#1 I was not "thrashing the bloke." I tried to help him. You
   conveniently omitted my reference to a VGA programming reference book.

#2 I was not talking about VGA text modes. Read my sentence again: the
   word "text" does not appear anywhere in it. Now I admit that I missed
   the reference to text mode in the original post, but that was an
   honest mistake on my part.

Even with this slight blunder, mine was the MOST helpful reply posted so far.
Everyone else has been flaming him for posting an IBM VGA question in this
group. If you are going to flame anyone, it should be *them,* not me.

Redirect followups out of this group, please.

Newsgroups: rec.games.programmer
From: neilb@scs.leeds.ac.uk (Neil Bowers)
Subject: Re: Question: Rotating a small bitmapped image?
Organization: The University of Leeds, School of Computer Studies
Date: Wed, 26 Aug 1992 16:56:01 GMT

In article <17ga9eINN221@chester.ksu.ksu.edu> sdoran@chester.ksu.ksu.edu (Steven Marcotte) writes:
>
>mucds@uxa.ecn.bgu.edu (Corey D. Stinson) writes:
>
>
>>	Could someone help me with a problem.  I have a small sprite
>>(bitmapped) and when animating, instead of re-drawing the picture over
>>and over to repesent the rotation stages I would like to develop some
>>algorithm to rotate the image.  And suggestions on one that would not
>>degrade the image?
>
>	Wouldn't the idea be the same as rotating a point on a screen
>except instead of moving a point on the screen you are moving a point 
>in an array?  Say you wanted an image rotated in 6 different directions.
>You would start out with your source bitmap, then apply the rotation
>function (which I don't remember right off hand, but it should be in
>any trig book) to all points in the array at intervals of 60 degrees.

This solution can result in `holes' in the destination image.  To prevent
this, take every point in the destination image, and perform the reverse
transformation back to the original image to determine the value for
the dest. image.

-neilb
Newsgroups: rec.games.programmer
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Subject: Re: VGA memory address
Organization: University of Illinois at Urbana
Date: Wed, 26 Aug 1992 15:05:00 GMT

Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:

>In article <22AUG199203465370@acad3.alaska.edu>, sxmlk@acad3.alaska.edu
>And for all of those who send me email: Lets say I have such a code in
>my program.


>struct character{
>    char ch;
>    unsigned char att;
>} *p;
>        .
>        .
>        .
>        .
>p=(struct character *)MK_FP(0xB800,0x00);
>p->ch='u';

    
     Well, it looks to me like you aren't using a far pointer. Try this:

     struct character {
	 char ch;
	 unsigned char att;
     } far *p;

     p=(struct character far *)MK_FP(0xB800, 0x00 );
     p->ch='u';

     Hope this helps, and I think that the people who flamed this posting
     need to spend their time helping people, not insulting them. Jerks.


-- 
------------------------------------------------------------------------
 John A. Slagel     "My old man used to tell me, before he left this
 j-slagel1@uiuc.edu  shitty world, never chase buses or women- you
                     always get left behind." -The Marlboro Man
Newsgroups: rec.games.programmer
From: maddie@crash.cts.com (Tom Schenck)
Subject: Re: 3D Maze Algorithms
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 01 Sep 92 08:59:48 PDT

I have complete AppleSoft BASIC source code for a 3-D maze wanderer. If you
would like to look at this for ideas, I could e-mail it to you. It also
contains a random maze generator.

Tom Schenck
Knight Technologies
E-Mail:maddie@crash.cts.com

Newsgroups: rec.games.programmer
From: cad28526@uxa.cso.uiuc.edu (Chuck Douglas)
Subject: Cribbage Algorithm Wanted
Summary: Cribbage algorithm wanted
Organization: University of Illinois at Urbana
Date: Wed, 26 Aug 1992 00:36:08 GMT
Keywords: cribbage

The title pretty much says it all.  I am interested in writing
a cribbage game for another computer but I can't for the life
of me imagine how to programme any sort of intelligence into the
computer opponent.

If anyone has source code for the cribbage game that occasionally
appears on some Unix machines, I would be very appreciative if you
would send it too me.  Failing that, any sort of hints would be
helpful.

Thanks.

-- 
Chuckers -- a computer operator/programmer/benthic sorter/emaciated aryan.
cad28526@uxa.cso.uiuc.edu	          |"You know I'll give you everything
Novanet:  douglas/o/nova douglas/cerl/nova|I've got for a little peace of mind!"
douglas-cerl OR douglas-o@nova.novanet.org|--"I'm So Tired" by The Beatles
Newsgroups: rec.games.programmer
From: tmkk@uiuc.edu (Khan)
Subject: Re: Tile Map Animation
Organization: University of Illinois at Urbana
Date: Tue, 1 Sep 1992 12:54:32 GMT


In article <8190@dirac.physics.purdue.edu> saxena@maxwell.physics.purdue.edu (Virendra K. Saxena) writes:
>
>	I know people don't want IBM-graphics questions posted here, but 
>	there's no other group to post to right now, so for those of 
>	you who want to flame me, sorry :-)
>
>	Anyways...I'm working on a computer game that is like the 
>	Ultimas.  I'm using 640x350x16 Enahanced EGA mode.  I have two 
>	problems right now:
>
>	1) When I change modes to _ERES16COLOR(quick C 2.5), if I change the
>	pallette to suit me, it is different on an EGA and VGA card.  How
>	do I fix this problem???

I haven't noticed this, although I haven't compared EGA to VGA in a
side-by-side comparison. Worst case is you'll have to detect which type
of card your program is running on and select palette definitions
accordingly.
  
>	2) What is the fastest way to do tile map animation like in
>	the ultimas.  I have a two-d array in which each different tile
>	has a different number.  When you move, the program checks the tiles
>	around you and places the correct tiles at the correct location 
>	on the 2nd video page, and then switches pages.  This is smooth,
>	but it is VERY slow.  Considering that I have a 386-33...something is
>	definetely WRONG!!! Is there a faster way to do this??  Does anyone
>	have their own replacement to _putimage that is a lot faster?

In the Wilton book (Programmer's Guide to PC and PS/2 Video Systems)
there is some code for a BITBLT. I hacked it up to use fixed size bit
blocks and to allow for masked copies. If you arrange things in your
game such that all tiles are of fixed size and ALWAYS begin and end on
byte boundaries, the BITBLT will go a lot faster. These shortcuts will
undoubtedly outperform the more generic routines built into the Borland
and Microsoft graphics libraries.

If you don't have the book, the code from the book is floating around
the net somewhere are MSCVIDEO.ZIP/ARC/whatever. Perhaps an Archie
search will turn up some ftp sites.
  
>	3) Does anyone have code for loading PCX's that actually works?? I have 
>	typed in code from a Lee Adams book and tried some code that I dl'ed.
>	Didn't work.  Help?

Heh heh heh... Lee Adams' books have been flamed to death periodically
in various groups. I'm not surprised his code doesn't work. ;-)

Have you checked SIMTEL20/wuarchive? I'm sure you'll be able to find
some PCX code there...
From: baylor@ccwf.cc.utexas.edu (Baylor)
Newsgroups: rec.games.programmer
Subject: Autodesk files
Date: 27 Aug 92 02:51:59 GMT
Organization: The University of Texas at Austin, Austin TX


	Three questions
1.I'm using sprite.pas that reads/uses files written by autodesk.
  I need to know the format. Skip the first 800 bytes then read it into
  an array [1..maxsize]. That can be directly loaded into into a source
  by lds, so i guess it's in whatever mode is needed by mode $13
2.Stupid question. I have an editor in 16 color (ega) modes. It blockwrites
  out the data. I assume this data, if read into a source with lds, it will
  be in the wrong format? Is this why directly loading my icons into this
  mode $13 application isn't working?
3.Anyone get the SPR files to work? I always get invalid numeric type.

Really, i'm looking for a way to draw 256 color icons without having
to write yet another graphics editor, and i kinda like my current 
16 color one.
From: tomk@westgac3
Newsgroups: rec.games.programmer
Subject: Re: Adventure Game Compiler
Summary: speaking of ADVSYS
Keywords: ADVSYS lisp
Date: 3 Sep 92 10:35:36 GMT
Distribution: usa
Organization: West Georgia Color Computer 3

amitp@owlnet.rice.edu (Amit J Patel) says:
+I'd like to also recommend ADVSYS (which Josh mentioned), which is the
+"best darn adventure system I've ever seen" (and I have seen TADS).  ;)
+Of course, "best" is subjective, so I won't say TADS is worse than ADVSYS.
+They're probably equal in power, and it may just be a personal preference.
+
+There is an Amiga version at:
+
+        gatekeeper.dec.com
+        /.2/micro/amiga/fish/f0/ff087/AdvSys.zoo
+
+and an IBM-PC version at:
+
+        procyon.cis.ksu.edu
+        /pub/PC/Games/Misc/advsys.arc
+

and an OS9 version, I'd like to add! Haven't sent it to any archive site
yet since I haven't figured out how to do that yet.

+[or at least Archie tells me they're there...]
+
+"ADVSYS is a Lisp-like object-oriented language, which has a

That explains why I had a devil of a time understanding it.

+source-code #include file that defines everything having to do with
+adventures, so you can change everything."  :) ADVSYS also comes with
+C source so that you can mess with it --- you can tweak it so that if
+your adventure is REALLY REALLY huge, you can change it so that it
+works under a DOS-extender to run in many megabytes.  (Or at least it
+seems possible...)
+
+What probably keeps most people away from it is the lisp syntax, but
+that also keeps the interpreter down to 20k (or Josh's version down to
+12[??]k).  David Betz, the author of ADVSYS, also wrote the XScheme and
+XLisp compilers, and he used the same byte-compilation techniques in
+ADVSYS.
+
+I think that ADVSYS is crippled because it doesn't have first-class
+procedures, symbol manipulation, and lists.  It is Lisp brought down
+to the restrictions of Pascal.  :( I'd rather be using the Real Thing
+(Scheme).  :)

Hey, it's difficult enough trying to follow the "logic" without all
those extras. 8-) Perhaps, if you wouldn't mind, you could write a
quick tutorial on how to augment the sample files. That way we who
are not well versed in LISP can get a better grasp on some of the
complexities of ADVSYS. Writing the adventure source data is not bad,
but those methods, verbs, classes, etc. are not intuitively obvious!

-- 
Thomas Kocourek  KD4CIK                       :UUCP on an OS9 system,
UUCP: ...!{emory,gatech}!wa4mei!westgac3!tomk :Multitasking & windows in
INTERNET tomk@westgac3                        :512KBytes - All in a COCO3!
Newsgroups: rec.games.programmer
From: maddie@crash.cts.com (Tom Schenck)
Subject: Re: Console game Programmers
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 25 Aug 92 18:03:37 PDT

It would also be nice to hear from any OTHER console programmers out there. I don't expect to hear from
any Apple ][, Commodore 64, or other 8-bit programmers, but for those who
do Nintendo, Lynx, GameBoy and other low-end consoles.
From: rahmanqi@ERE.UMontreal.CA (Rahman Qazi Ibadur)
Newsgroups: rec.games.programmer
Subject: Real-Time animation
Date: 27 Aug 92 18:25:13 GMT
Organization: Universite de Montreal

Hello,

  I was reading Michael Abrash's column in Dr. Dobbs journal on Xsharp the other day and I saw that he made reference to Real-Time animation.

  My question is how can you say that you are developping a real time animation package. Do you access the timer or what? I looked at his code to XSHARP and noticed that he made no access to any timer.

  I know that there are a lot of games that are Rael-Time but what makes real time diffrent from normal animation?

Thanks!

rahmanqi@brise.ERE.UMontreal.ca
Newsgroups: rec.games.programmer
From: grey@bnr.ca (Bryan Miller)
Subject: Re: Question: Rotating a small bitmapped image?
Reply-To: grey@bnr.ca (Bryan Miller)
Organization: Bell-Northern Research Ltd.
Date: Wed, 26 Aug 1992 16:30:36 GMT

In article <1992Aug26.152939.4449@uxa.ecn.bgu.edu>, mucds@uxa.ecn.bgu.edu (Corey D. Stinson) writes:
|> 	Could someone help me with a problem.  I have a small sprite
|> (bitmapped) and when animating, instead of re-drawing the picture over
|> and over to repesent the rotation stages I would like to develop some
|> algorithm to rotate the image.

Rotating the bitmap is easy. Apply a 2x2 rotational transformation
of sin/cos the angle you want to rotate by.

|> And suggestions on one that would not degrade the image

That's the tough part. The rotation is gives you floating point
results (between) pixels. When you integerize, it'll get a little
blocky. If you're really keen on getting good results you'll have
to clean it up (esp. the edges). Convolve the image with a Laplacian
mask (3x3 would be (0,1,0),(1,-5,1),(0,1,0)) to smooth it.
These are simple to apply, and give reasonable results.

Bryan
Newsgroups: rec.games.programmer
From: slogan@ms.uky.edu (Stan Logan)
Subject: Archive site...
Date: Mon, 24 Aug 1992 15:13:11 GMT
Organization: University Of Kentucky, Dept. of Math Sciences

Any chance someone could point me to an archive site for this group?
Being fairly new to game programming, it would be nice to "catch up" 
on the discussions so far.

Thanks!

Stan Logan
Newsgroups: rec.games.programmer