HDTenEightyP/NetNews huggingface dataset:
From: erica@wariat.org (Lady of the BitMode)
Subject: EGA CARDS
Organization: Akademia Pana Kleksa, Public Access Uni* Site
Distribution: usa
Date: Wed, 11 Nov 1992 06:39:56 GMT


Hello. I have a question. I want to make a little game and put it on the
shareware market. I was thinking about using the EGA card because it's 
supported by vga too. But there are two standards of EGA; 64K and 128K
which one should I support. Since it's just a simple game to get me up to
speed I was thinking about 64K but I really want 128K but it's a little
more worthwhile with 2 pages at 640 x 350 graphics mode. I'm hoping that
a lot of people have EGA 128K, or VGA, memory boards so that they can run my 
program on there machine if I decided to support EGA 128K, which I think I
will..


What do you Graphics Gurus or others think about that?


PS: as many of you realize i'm using an  ibm 386 clone.

Thanxs,
Erica Ramsey
From: cbusch@ub.d.umn.edu (Chris)
Newsgroups: rec.games.programmer
Subject: EGA scrolling
Date: 9 Nov 92 10:27:24 GMT
Article-I.D.: ub.1dmokcINNofo
Organization: University of Minnesota, Duluth
NNTP-Posting-Host: ub.d.umn.edu

Hello
   I am trying to devolop a fast and effecient system to make
an EGA scrolling game (scroll all 4 ways).  I have some ideas
regarding this.  How do I pan the ega virtual screen (320x200x16 res)
by single pixels instead of eight?  Any ideas on animation?


--
Chris Busch   CBUSCH@ub.d.umn.edu
"I guess Intel invented radioactiveware!"
"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 person!"
Newsgroups: rec.games.programmer
From: mucds@uxa.ecn.bgu.edu (Corey D. Stinson)
Subject: More on loading into vga video mem!
Organization: Educational Computing Network
Date: Fri, 6 Nov 1992 15:53:39 GMT

 

   Hi,   
     I have some more questions about loading directly into vga
video memory.
 
     Someone posted that one correct method might be:

         ifstream in("PICTURE.RAW");
         unsigned char (far *)VideoMem[320][200];
         (unsigned char far*)VideoMem = 0xA00000000L;
         for (int x = 0; x < 320; x++) {
            for (int y = 0; y < 200; y++) {
            in >> (*VideoMem)[x][y];
                  or
            in.get((*VideoMem)[x][y]);

     This doesn't seem to work at all.  Could someone provide
     some advice?  Thanx
                               Corey
From: u2105546@csdvax.csd.unsw.edu.au
Newsgroups: rec.games.programmer
Subject: Joystick routines ... Help!
Date: 6 Nov 92 09:43:07 +1000
Organization: University of New South Wales

Dear r.g.p'ers,
  A friend and I are writing an arcade game (SVGA 640x480x256, Undercover cops
style) and while we have extensive AI and Graphics experience, we know nothing
about programming joysticks! So, if anyone out their could point us to a good
book on joystick programming or some well documented source code (any language)
for writing assembler or C joystick routines it would be most appreciated...

Regards, 

PS. Please e-mail reponses, I am in the middle of exams and don't have much
time to read the news and filter an entire group for responses.... Thanks...

------------------------------------------------------------------------------
Richard Laxton, Computer Engineer at UNSW, Australia.
u2105546@csdvax.csd.unsw.oz.au
------------------------------------------------------------------------------
From: imcc@cs.strath.ac.uk (Iain McCord)
Newsgroups: rec.games.programmer
Subject: Re: Card Shuffling
Date: 11 Nov 92 13:03:50 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

In article <1992Nov9.223125.20083@unislc.uucp> ttobler@unislc.uucp (Trent Tobler) writes:
>	for i = 1 to NUM_CARDS
>		r = random number between 1 and NUM_CARDS
                                          ^ should be i
>		swap card[i] and card[r]
>	end for
 
>As long as the random generator is reasonably random, this will shuffle the
>deck.
 
The unmodified algorithm has N**N different shuffles.  There are only N!
possible permutations.  As N! doesn't divide N**N evenly, some of the N!
permutations will be repeated more than others.  The modified algorithm 
gives N! shuffles, and all of the possible permutations are repeated once.
  How useful that modification is depends on the cycle length of the
pseudo random number generator.

-- 

		~~~~~/\~~~~~
Iain McCord	~~~~/()\~~~~	Wed Nov 11 13:03:42 WET 1992
		~~~~~~~~~~~~
From: det@phlan.sw.stratus.com (David Toland)
Newsgroups: rec.games.programmer
Subject: Re: Card Shuffling
Date: 11 Nov 92 16:33:50 GMT
Organization: Stratus Computer, Software Engineering
NNTP-Posting-Host: phlan.sw.stratus.com

In article <1992Nov11.170046.11528@siesoft.co.uk> huw@siesoft.co.uk (Huw Roberts) writes:
>Try this one (guarantees that each possible ordering is equally likely given
>a perfectly random random number generator).
>
>    for (i = NUM_CARDS; i > 0; i--)
>	r = random number between 1 and i inclusive
>	swap card[i] and card[r] (may be the same card)

Uh, C uses 0-based arrays.  Should be:

    for (i = NUM_CARDS - 1; i >= 0; i--)
        {
	r = random number between 0 and i-1 inclusive
	swap card[i] and card[r] (may be the same card)
        }

This is essentially the same as a response I gave via email, but using
a single deck instead of two.  My method (in pseudocode) was:

unshuffled_deck_count = 52
do while unshuffled_deck_count != 0
    take card unshuffled_deck[random(0..unshuffled_deck_count-1)]
    append card to shuffled_deck
    --unshuffled_deck_count
    end;

A problem I pointed out with this approach is that it may be TOO
random.  If you're trying to model a card game accurately, you
may want to simulate the patterns of non-randomness that result
from human methods of shuffling.  For example, riffling the cards
tends to leave sequences of cards in the same order, or a pair of
such sequences intermixed but not randomized beyond that.

Simulating the shuffling patterns of human players requires more
sophisticated algorithms and is measurably slower.  It CAN make
a difference in the actual play.  Some card players can get a good
idea from a shuffled deck what game it was last used for.
-- 
det@phlan.sw.stratus.com   |  "Laddie, you'll be needin' something to wash
                           |  that doon with."
Newsgroups: rec.games.programmer
From: johnf@apollo.hp.com (John Francis)
Subject: Re: Help building a game?
Date: Fri, 13 Nov 1992 23:43:05 GMT
Distribution: usa
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <1e164mINNj32@life.ai.mit.edu> dmb@case.ai.mit.edu (David Baggett) writes:
>Find a copy of the following book:
>
>Berlekamp, Elwyn R., John H. Conway, and Richard K. Guy.  _Winning
>Ways_ Volume 2, London: Academic Press, 1982.
>
>Both volumes of _Winning Ways_ are brilliant and fun -- must-reads for
>anyone interested in game theory.
>
>Volume 2 also contains a proof-by-construction that Conway's Game of
>Life is Turing-equivalent.  Neat!

Actually,it doesn't. There is a flaw in the proof as presented which
I keep on meaning to point out to Conway.  Why don't you try and find it?

By the way: if you have the 2nd edition of the books, look at the
footnote for the table of winning postions in `Sylver Coinage'.

>Dave Baggett

-- 
John Francis                                 johnf@apollo.hp.com
with 9 cats to feed, I don't have time to think up a clever .sig
Newsgroups: rec.games.programmer
From: boutell@isis.cshl.org (Tom Boutell)
Subject: Re: Advice needed for fastest sort algorthm
Organization: Cold Spring Harbor Labs
Date: Tue, 10 Nov 1992 21:46:43 GMT

In article <1992Nov10.185527.3584@amd.com> roberts@angelo.amd.com (Dave Roberts) writes:
>In article <1992Nov8.012628.23338@menudo.uh.edu> libh@Jane.UH.EDU writes:
>>In article <BxD5pt.DyI@news.cso.uiuc.edu>, jas37876@uxa.cso.uiuc.edu (John A. Slagel) writes:
>>>   Definately the quick sort.  Its even built into ANSI C specs, so it
>>>   should be easy to implement.  Look up quicksort in your C manual. If
>>>   I remember right, bubble sort works in O(n*n) and quicksort works in
>>>   O(n*log n).

Caveat Emptor:

I gather that, although quicksort() must be available, it is not required
that it be implemented as the algorithm known as quick sort. Indeed, some
C libraries apparently implement it with bubble sort.

-T


-- 
Tom Boutell, boutell@cshl.org

Clausthaler is the best non - alcoholic beer in the known universe.
From: kds@phy.duke.edu (Stokes Kevin)
Newsgroups: rec.games.programmer
Subject: Advice needed for fastest sort algorthm
Date: 6 Nov 92 19:24:50 GMT


  I am well along in a new 3D game engine, and I need some advice
about sorting algorthms.  My past game, Corncob 3D, used a bubble sort
to sort all the objects from farthest to closest to the observer.
  This method seemed ok, because in a flight simulator, the objects are
generally very sparse, and from frame to frame, there should be few changes
in the order of objects.
  This new project has objects much closer to the observer, and I fear
there may be significant changes in the list order between every sort.
Which sorting algorthm is the most time efficient?
                                              -Kevin

-- 
------------------------------------------------------------------------------
|  Kevin Stokes                        |     Please direct all pointless     |
|  Pie in the Sky Software             |   flames to my mailbox, it's much   |
|                                      |          more irritating.           |
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Newsgroups: rec.games.programmer
Subject: Re: using video-ram in mde 13h (ibm pc)
Date: 11 Nov 92 15:30:53 GMT
Organization: University of Illinois at Urbana

s026@brems.ii.uib.no (Paal K Holmberg) writes:

> thanks for the response. if i have this right, i cant use other parts of the video
>ram than the 64k used by the screen in mode 13h.
 
    Correct. (By the way, keep your line size under 80 characters, please)

> I have a fair idea about how mode x works, but i didntt want to use it as i thought
>the polygon routines wold be slowed down by having to manage which bitplanes to write
>to. is this right ?

    Nope, this is entirely wrong... You can write 4 pixels in one MOVSB, if
    they're all the same color.  Michel Abrash published code in Doctor Dobb's
    Journal for a fast 3D graphics using modex. 

    If you have FTP access, check out on wuarchive.wustl.edu in
    the pub/mirrors/msdos/ddjmag/xsharp15.zip file.  This is the
    complete 3D graphics package, with source. It contains fast 
    polygon fill routines.

-- 
------------------------------------------------------------------------
  John A. Slagel, email: jas37876@uxa.cso.uiuc.edu
Newsgroups: rec.games.programmer
Subject: Re: Advice needed for fastest sort algorthm
From: <CXC19$@psuvm.psu.edu>
Date: Thu, 12 Nov 1992 13:27:40 EST
Organization: Penn State University

In article <11018@uqcspe.cs.uq.oz.au>, warwick@cs.uq.oz.au
  (Warwick Allison) says:
>
>BOGUS!  M is NOT a constant.  Sure, for values between 000 and 999
>it is the constant 3, and for values between 000000 and 999999 it
>is the constant 6 [assuming decimal radix sort, for simplicity].
>and for values in the range 000000000 to 999999999 it will be 9.
>
>ie. for a range of R values, M = log R.  Now, I suggest that for
>general purposes, R will be larger than N.  For example, R will
>be 2^32 (ie. integers), while N will be, say 10000000.

There seems to me to be some confusion here.  If M is allowed to grow,
then the proper measure of the length of the input to a sorting algorithm
is not N, but N*M = N*log(R).  So if Radix sort takes N*M time, then the
time would still be a linear function of the length of the input.  It only
makes sense to measure the length of the input to a sorting algorithm by
N alone if M is taken to be bounded.  Extreme Example:  If we don't keep M
bounded, then two numbers can't be sorted in constant time beacuse the
amount of time needed to compare them is a function of M.  I hope this
helps.

Carl Cotner
cxc19@psuvm.psu.edu
From: cbusch@ub.d.umn.edu (Chris)
Newsgroups: rec.games.programmer
Subject: Fast compression
Date: 9 Nov 92 11:07:40 GMT
Article-I.D.: ub.1dmqvsINN497
Distribution: world
Organization: University of Minnesota, Duluth
NNTP-Posting-Host: ub.d.umn.edu

Hello
	What is the fastest compression technique?  How fast
is LZW?
--
Chris Busch   CBUSCH@ub.d.umn.edu
"I guess Intel invented radioactiveware!"
"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 person!"
Newsgroups: rec.games.programmer
From: mgemmel@cs.vu.nl (Martin Gemmel)
Subject: Re: Software Pinball Machine
Organization: Math & CS, VU Amsterdam
Date: Mon, 9 Nov 1992 08:22:16 GMT

Kevin Martin (sigma@picasso.ipl.rpi.edu) writes:

}                                                                it was sort
} of just that the ball could accidentally go through things.

Here is another problem that could easily be overlooked. If the ball's
speed is sufficiently high, it is not enough to check for collision
with just 1 object borderline. Bluntly computing its new position and
heading after 1 collision might cause it to pass a couple of
other borders too, that are ignored in the computation.
If you ask me, during each frame collisions should be checked like
this:
	while ball will collide with some object:
		compute new heading and position ball AT the object's
		border;
		repeat, to see if it can hit something else;

	position ball for next frame;

So the above while-statement should definitely not be an if-statement.
Am I right?

Martin
Newsgroups: rec.games.programmer
From: colin.buckley@rose.com (colin buckley)
Subject: Aspect ratio in modeX
Organization: Rose Media Inc, Toronto, Ontario.
Date: Fri, 13 Nov 1992 09:59:43 GMT
X-Gated-By: Usenet <==> RoseMail Gateway (v1.70)


Date Entered: 11-13-92 04:51
B(>When I use the modeX 320 x240 resolution I am not getting a square aspect
  >ratio.  It seems to be squashing the screen.  I'm using borlandc and
  >the twk bgi library.  I was under the impression that this mode was designed
  >to have a 1:1 aspect ratio.  Any ideas and help would be greatly
  >appreciated.

I have no idea what your saying, but I here's a message regarding aspect
ratios I just read in another conference.  But before that, are you
sure you're in 320x240?  Try drawing a line from 0,0 to 0,239 and another
from 0,239 to 319,239 and see if it comes out right.  Anyways, on with the
other message.
===========================================================================
Date: 11-09-92 (13:00)             Number: 2688
From: JON-ESPEN HETTY              Refer#: NONE
  To: ANDERS HORNTVEDT              Recvd: YES
Subj: Re: 320x240                    Conf: (1150) RN-GameDes
---------------------------------------------------------------------------
 AH> I know that this is a reply to an old message, but could you please
 AH> explain what an aspect ratio is?

The aspect ratio is a meassure of how square a pixel is. Because the
monitors width/hight ratio is 4:3, the resolution of the screen must
compensate this to get a square pixel.

In the 320x200 resolution the aspect ratio of a pixel will be :

  4/3      = 1.333333333
  320/200  = 1.6

  1.33/1.6 = 0.831  -> Not a square pixel

If you are using the 320x240 resolution, however, the aspect ratio is :

  4/3       = 1.33
  320/240   = 1.33

  1.33/1.33 = 1  -> The pixel is a true square

As an example of the result of an aspect ratio different from 1, you could
try drawing a circle in 320x200 resolution. Because of the difference in
hight and width of a pixel, the circle will become an oval instead.
You would have to compensate for this by drawing an oval when you want
a circle.
In the 320x240 mode, no compensation is needed.

Hope this helps.

  Jon.
---
   RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285
Newsgroups: rec.games.programmer
From: berked@aix.rpi.edu (Daniel Leon Berke)
Subject: Re: Number of unique tiles in a game?
Organization: Rensselaer Polytechnic Institute, Troy, NY
Distribution: rec.games.programmer 
Date: Fri, 13 Nov 1992 17:56:35 GMT

I believe Ultima III had a 128x128 tile map, Ultima IV was 256x256.  I am
not sure of the games beyond that.

I am currently working on an Ultima "clone" in which my main map is 500x500
tiles, and there are about 60 towns & dungeon levels combined, each with
a 75x75 tile map.  I'm just glad that my partner drew mostly everything,
not me!

Dan

-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> Daniel Berke           Rensselaer Polytechnic Institute, Troy  NY        <>
<> berked@rpi.edu         Department of Electrical, Computer & Systems Eng. <>
<> "Keyboard bad or missing.  Press <F1> to continue"                       <>
Newsgroups: rec.games.programmer
From: cat@wixer.cactus.org (Dr. Cat)
Subject: Re: Number of unique tiles in a game?
Organization: Real/Time Communications
Date: Fri, 13 Nov 92 10:23:14 GMT


   If I remember right, Ultima III had 128 tiles, Ultima IV had 256, Ultima V
had 512, and Ultima VI had 2048.  I might have some of those numbers wrong,
though, it's been a while since I worked on the series...  I'd say 256 should
be fine for your first game.  You'll be lucky if you can find the time to
think up & draw that many unique shapes.
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: rec.games.programmer
Subject: Re: Advice needed for fastest sort algorthm
Date: 11 Nov 92 00:45:02 GMT
Reply-To: warwick@cs.uq.oz.au


>A radix sort has a time complexity of O(N), which means that it
>operates in linear time on N units of data.

Gee, I'm sure the theoreticians would LOVE to see the algorithm,
since it has been PROVED long ago that sorting takes O(N log N)
time OPTIMALLY.

>This integer may then be
>represented as the path in a binary tree, with the higher order
>bits represented as paths near the root and the lower order bits as
>paths near the leaves.

Guess what?  The number of bits will be of the order LOG N !!!!!!


Let's rename this group to rec.games.!programmer, and succumb to the
community's belief that "games programmers" aren't real programmers
at all.  All the Windows programmers and DOS device driver programmers
can then cross there arms smugly and shake their heads at us non-
programmers, who can only write GAMES, saying "gee, they've discovered
SORTING"...

Come on people, games programming is definately an art-form, but we
really must learn to hold our mallet and chisel correctly.  (Of course,
asm programmers only need to learn to hold the chisel, since they use
their head to supply the force).

--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /  
Newsgroups: rec.games.programmer
From: fxmlk@acad3.alaska.edu (KIENENBERGER MIKE L)
Subject: Re: Software Pinball Machine
News-Software: VAX/VMS VNEWS 1.41.UAC
Organization: University of Alaska - Fairbanks
Date: Fri, 6 Nov 1992 16:13:00 GMT

In article <1992Nov5.135235.7388@meiko.com>,
gordon@meiko.com (Gordon Henderson) writes...
>Does anyone remember the pinball games that ran on the Apple ][ ???
>(1MHz 6502 for you who don't rmember the good old days!) There
>were at least two of them, and there was even a pinball creation game
>system! (Author Bill Budge, but I may be wrong - it's been a *long* time!)
> 
>It had a basic board area, and an area where you could drag the little
>icons representing bumpers, pushers, flags, flippers and whatnot into
>the board using a joystick! You could also draw scenery onto the board.
>I seem to recall that it was quite fast too!

Yep. This was the "Pinball Construction Set" by (as you said) Bill Budge.

The other really awe-inspiring Apple II pinball game was "Night Mission
Pinball."  This game had a set playing field, but it offered zillions of
configuration options.  Truely amazing.

Taking a look at both of these games is definitely a step in the right
direction for the design of a Software Pinball Machine. 
=============================================================================
-Mike Kienenberger                       FXMLK@ALASKA           (BITNet)
 Academic Computing                      FXMLK@acad3.alaska.edu (Internet)
 University of Alaska-Fairbanks
 "I'm a computer programmer....<link><link><kludge><kludge> say-no-more!"
From: jmunkki@vipunen.hut.fi (Juri Munkki)
Newsgroups: rec.games.programmer
Subject: Re: Software Pinball Machine
Date: 5 Nov 92 20:23:13 GMT
Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology

In article <1992Nov6.034457.11981@waikato.ac.nz> gford@waikato.ac.nz writes:
>The ball is moving on a sloping table, (slope in y direction). The x component
>of the velocity remains constant. And the y component  vy(t) = vy(t-1) + a
>where a is a fraction of gravitational acceleration. 

I don't think that you can really realistically model a pinball without
taking ball spin into account. Writing a less than perfect pinball program
isn't hard, but making the collisions affect the ball spin can make things
complicated.

-- 
  Juri Munkki					       Windsurf: fast sailing
 jmunkki@hut.fi					      Macintosh: fast software
Newsgroups: rec.games.programmer
From: gardabr@unix1 (Gard Eggesbo Abrahamsen)
Subject: Re: Advice needed for fastest sort algorthm
Organization: University of Trondheim, Norway
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 10 Nov 92 12:21:06 GMT

Kristof Roomp (krisr@cue.bc.ca) wrote:
: In article <1992Nov8.012628.23338@menudo.uh.edu> libh@Jane.UH.EDU writes:
: >  The bubble sort takes N! (# factorial) steps, rather than N*N steps.  A BIG
: >difference.  But as pointed out, the quicksort is the easiest to implement
: >since it is in C libraries.  Why reinvent the wheel.  If that isn't quick
: >enough then I would check out Knuth's 'Art of Programming' Vol. 3 since it is
: >pretty much only about sorting.
: >
: nope.its worst case is n*n where n is the number of items in the list...
: you have to watch the quicksort with lists of objects which are already
: sorted, because its performance on a sorted list is a lot worse than
: the bubble sort. on a presorted list , the quicksort will also use
: in the order of n stack space. This could be prevented by taking a different
: pivot element when quicksorting (like the middle one). the library quicksort
: uses the first element.
: 
Some time back, I and a friend of mine were competing on who could write the
fastest sort routine. The fastest result was combining the bubble and the
quick sort routines, like using the bubble to determine the threshold as well
as checking wether the data already was sorted or not. This way, the routine
would have only one pass if the list already was sorted.

I COULD see if I can find the routine, if I look in my archived routines
library. I have one written for Power BASIC (on the Atari ST series computers)
and another one written in pure 68000 assembler.

/Gard
Newsgroups: rec.games.programmer