HDTenEightyP/NetNews huggingface dataset:
From: pcellik@axion.bt.co.uk (Peter SPHINX Cellik)
Newsgroups: rec.games.programmer
Subject: Re: video game standard!?
Date: 8 Sep 92 08:48:40 GMT
Reply-To: pcellik@axion.bt.co.uk (Peter SPHINX Cellik)
Organization: British Telecom Research Labs


In article <gate.H4PPqB1w165w@toz.buffalo.ny.us>, cyberman@toz.buffalo.ny.us (Cyberman) writes:
|> 
|> My thought of
|> 
|> Video
|>     RGB and NSTC output
|>     24bit pallete (16million colors to work with)
|>     256 colors
|> 
|> Graphics hardware
|>     320x200x256 resolution (is thier a need for higher?)
|>     panable display area (virtual screen)
...


I agree on the video, one byte per pixel is the only way to go,
but I think the resolution should be 320x240x256 to give square
pixels.  This will make circle drawing and object rotation much
easier (faster).

   SPHINX

P.S.  I also support C as the development language.   :-)


==================================================
=== ?include "DISCLAIM.H--"                    ===
===                                            ===   
=== Kill others only if you wish to be killed. ===
==================================================
From: ron@zooid.guild.org (Secret Mud)
Newsgroups: rec.games.programmer
Subject: Re: Origin Systems buyout
Date: 13 Sep 92 17:13:51 GMT

From: cat@wixer.cactus.org (Dr. Cat)
>
>   Origin Systems put out a press release today announcing that they have
>made an agreement to become part of Electronic Arts in exchange for a stock
>swap.  Whether this will have much effect on the company will remain to be
>seen...
>               Dr. Cat

Whaaat?  That's certainly very suprising.  I can't see why Origin would do it.
Newsgroups: rec.games.programmer
From: rwallace@unix1.tcd.ie (russell wallace)
Subject: Re: Complexity - Ideas
Keywords: Complexity of Strategic games
Organization: Trinity College, Dublin
Date: Sun, 6 Sep 1992 20:39:39 GMT

Concerning the initial poster's idea of describing the complexity of a
game according to how difficult it is for one human player to describe
to another,

At present this is not an accurate measure of the computational cost of
the game (more or less, how long it would take a computer to decide on a
move).

Consider the way computers and humans play chess:

A computer does it by evaluating all the possible moves for the next few
turns.

A human cannot possibly beat a computer at this, since the computer can
obviously calculate far faster than the human. Instead, a good human
chess player will form a high-level view of the game, using "chunks" of
information about the strategic position. (To demonstrate this, it has
been shown that a good human chess player, given a brief look at chess
board and asked to reconstruct the position, will reconstruct a
strategically equivalent but not identical position.)

Therefore, the human player has to evaluate far fewer positions than the
computer; this is why the world chess champion is still a human.

So, while a game might be reasonably simple from the point of view of a
good human player, because the human player can grasp the position in
terms of high-level strategic concepts, the game is probably much more
complex from the point of view of the computer which does not understand
such concepts.

For example, war games are usually simpler from the point of view of a
human player because they are strategically simpler. However, because
there are more possible moves, it is much more difficult for a computer
to play one well by looking at the possible moves.

Of course, hopefully at some stage a computer will be able to think in
terms of high-level strategic concepts about a game; but for the moment,
the complexity of a game from a human's viewpoint is not a good guide to
its complexity from a computer's viewpoint.

--
"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@unix1.tcd.ie
Newsgroups: rec.games.programmer
From: galt%peruvian.utah.edu@cs.utah.edu (Greg Alt)
Subject: Re: Graphics help/advice
Date: 12 Sep 92 22:52:52 MDT
Followup-To: rec.games.programmer 
Keywords: algorithms 3-d
Organization: University of Utah CS Dept
Distribution: na

In article <20298@plains.NoDak.edu> tscott@plains.NoDak.edu (Timothy E Scott) writes:
>1) Created two 180 element arrays sine and cosine, which are
>   equal to the sine/cosine of an angle times 10000.  Any
>   references to an angles sine/cosine therefore are not
>   computed.

It should be faster to make the multiplier a power of 2.  Either
16384 or 8192 would be good.  That way, you can use a right shift
instead of a divide. 

A little bit of assembly would help out a lot, since many compilers
(BC++ for example) do a function call for every operation on a long.
It is annoying to do assembly code using 16 bit registers for 
operations on longs, but it is pretty simple, and you don't need to
learn much assembly.  

>3) The points to moveto and drawto (as I named the procedures)
>   are stored in memory and referenced through the use of a
>   pointer.  I have no idea if this improves performance or not,
>   but it seemed 'like the right thing to do.' :)

You might want to consider using polylines.  A polyline is just something
like this:

typedef struct
  {
  int  x,y,z;
  } point;

typedef struct
  {
  int  length;
  point *points;
  } polyline;

Then you just pass a pointer to the polyline to your draw_polyline()
which connects all of the points with a line.
(actually this probably won't improve speed, but it makes it a bit easier
to program)

If you have access to a profiler, use it.  You will probably find that
clearing the screen between frames (if you do that) takes a huge chunk
of the time.  The other big things would be the part of the code that
actually draws pixels to the screen and the bit that does the transformations.

----
"Dwayne Dibly?!" - The Cat (I've seen 5th season.  Have you?)
----
From: fxmlk@acad3.alaska.edu (KIENENBERGER MIKE L)
Newsgroups: rec.games.programmer
Subject: Atari 2600 console programming [was Re: video game standard!?]
Date: 14 Sep 92 09:36:00 GMT
Organization: University of Alaska - Fairbanks
News-Software: VAX/VMS VNEWS 1.41.UAC

In article <43890@skye.dcs.ed.ac.uk>, kc@dcs.ed.ac.uk (Kenneth Cameron) writes...
> 
>When this thread started, someone mentioned that there were notes about
>programming the Atari 2600 console on the net somewhere. I never saved
>the post, but would now like to get hold of the stuff. Can someone tell
>me where I can find it, I got nowhere with archie and wais. Thanks.
>
>Kenneth@Edinburgh

Yes. However, they are spotty at best.
An Atari 2600 programming mailing list has just formed.
Send mail to Ted Drude (drudetb@infonode.ingr.com) to be added to the list.
We are working on an FTP site for storing the big 2600 info file as
well as digests for the mailing list, so I will manually forward the file
for now.

To realistically be able to program on the 2600, you will need to be
fluent in 6507 assembly (6502 assembly without interrupts, mostly) and
have some way to communicate with a 2600 console (either by
building your own EPROM-driven cartridge -- requiring an EPROM burner and
eraser -- or by building a peripheral card to talk to the 2600 console from
your favorite platform.  I am designing an Apple II to Atari card now which
will cost around $70 in materials to construct, and I also have a prototype
design for an EPROM-driven cartridge working.)  Understanding of 2600
programming architecture wouldn't hurt either.
=============================================================================
-Mike Kienenberger                       FXMLK@ALASKA           (BITNet)
 Academic Computing                      FXMLK@acad3.alaska.edu (Internet)
 University of Alaska-Fairbanks
From: lanny.cobain@bville.gts.org (Lanny Cobain) 
Newsgroups: rec.games.programmer
Subject: RE: JOSH'S SCALE UNIT
Date: 10 Sep 92 14:17:00 GMT
Distribution: world
Organization: Baudeville BBS - Toronto, Canada 416-283-0114 2000+ conferences
Reply-To: lanny.cobain@bville.gts.org (Lanny Cobain) 

-> If you need me to post the code for these three things, just post a
-> note in this newsgroup.

Absolutely!  Post them as soon as possible.  Thanks alot, Josh!
From: cat@wixer.cactus.org (Dr. Cat)
Newsgroups: rec.games.programmer
Subject: Origin Systems buyout
Date: 11 Sep 92 06:08:05 GMT
Organization: Real/Time Communications


   Origin Systems put out a press release today announcing that they have
made an agreement to become part of Electronic Arts in exchange for a stock
swap.  Whether this will have much effect on the company will remain to be
seen...
               Dr. Cat
From: ccsteve@cybaswan.UUCP (s marshall)
Newsgroups: rec.games.programmer
Subject: VGA / IBM / DOS - ModeY putblock, getblock
Date: 9 Sep 92 11:03:33 GMT
Reply-To: ccsteve@pyr.swan.ac.uk (s marshall)

This group has definately become dull since the VGA graphics discussions
have gone, but since a rec.games.vga.programmer is unavailable. I'll post
here (kill files into action on the subject line). 

I've currently been developing a ModeY graphics library, which is really
just a skeleton for developing games on. At present I have getblock/putblock
functions which only work if the x co-ord is on a multiple of 4, and
likewise if the width is a mltiple of 4.

Does anybody have, or can point me in the direction of source code for these
functions in ModeY which will avoid these restrictions. I`m not overly
bothered about the width restriction its really the X co-ord problem that
irritates me.

If anyone can help I would greatly appreciate it...

-- 
.------------------------------------------------------------------------------.
|Steve Marshall         |                                                      |
|CCSTEVE@UK.AC.SWAN.PYR | This quote has been removed for repairs...           |
|CCSTEVE@CYBASWAN.UUCP  | Normal service will be resumed as soon as possible   |
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: rec.games.programmer
Subject: Re: video game standard!?
Date: 9 Sep 92 01:47:06 GMT
X-Maildoor: WaflineMail 1.00r


     -=> Patric Aalto spoke of "Re: video game standard!?" <=-
    To All at 09-08-92  07:45
 >Graphics hardware
 >    320x200x256 resolution (is thier a need for higher?)

 PA> Please! 320x200 is not nearly enough. In my game I support 320x200
 PA> (which is nearly useless due to lack of resolution), 320x400 (passable
 PA> when using antialiasing, but not great) and 800x600 (great). I would
 PA> like the last one to be a new standard. I think 256 simultaneous colors
 PA> from a palette of 16.7 million is usually enough.

    The reason for 320x200:

        1: It puts no strain on the hardware
        2: it does not use lots of memory access cycles
        3: it is compatible with cheap Tv's (common we are
            talking consumer here)
        4: graphics will be very fast
        5: leaves enough video memory for other things (sprites)

    640x400 would be the next best progression thier are problems
    though
        1: uses a considerable amount memory (requires > 256k
            video memory to perform any decent animation)
        2: SLOW the bigger the graphics array the slower the game
        3: lower access the amount of time the CPU or GPU will
            have access to display memory will be GREATLY
            hampered
        4: cost - the bigger the array the more expensive the
            hardware (unless using an existing chipset but that
            still goes without saying)
        5: it will not work well with a TV.  a NSTC monitor can
            handle only 64 color changes per scanline at 320x200
            this isn't bad at 640x400 you will have problems.

    Most TV's or NSTC monitors will not be able to show a
    descernable difference.  To me it's just an extravegance.
    However that doesn't mean that thier should be such a mode
    it's just not all to neccessary.

        Stephen Cyberman@Toz.Buffalo.NY.US
        Scripted at Wed  09-09-1992  09:11:04

... Then, quite suddenly, and all at once, nothing happened
--- Blue Wave/QWK v2.10
From: young@eniac.seas.upenn.edu (young "Deerslayer" shin)
Newsgroups: rec.games.programmer
Subject: Question about computer graphics for PC
Date: 8 Sep 92 01:27:50 GMT
Organization: University of Pennsylvania


Hi, I am posting this for a friend:

  Does anyone know of a good "Sprite Generator" for a PC, or are people using
various art/graphics programs to create bitmaps and manipulate those?
  I don't read the news groups, so can you please e-mail me the information?
Your help is greatly appreciated.

- Young
  young@eniac.seas.upenn.edu
Newsgroups: rec.games.programmer
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Subject: IBM VGA ModeX PutBlt
Organization: University of Illinois at Urbana
Date: Mon, 14 Sep 1992 19:23:44 GMT

   I recently mentioned some fairly fast ModeX,Y whatever routines
   and send that I would send them to you or post them if I got more
   than 10 replies.

   I have gotten MUCH MUCH more than 10 replies, so here's what I'll
   do:

   1. I don't have the time to e-mail people individual copies.
   2. The routines will take up some bandwidth on the news file...
      Maybe I'll put them at an FTP site, if anyone thinks I should.
       However, I don't know how, so e-mail me if you know for sure.
   3. I am going to clean up the routines, comment them so people can use
      them, and provide a nice demo, and post them hopefully by the end
      of the week. 

    To answer people's questions:
     -These routines with a few modifications will work with 320x200,
       360x400, 320x400-- All the tweaked video modes. 
     -I have code is MASM, and use Microsoft Quick C.
     -These routines are fast because I "unroll" the bitmap into groups
      of four so that I only change the plane 4 times, so thats only about
      4 outs per bitmap instead of 1 out per pixel. 
     -I also use 386 specific commands.
     -The routines do provide for some pretty basic, pretty fast collision
      detection.
     -I use Michel Abrash's ModeX code to set the video mode, switch pages
      etc.

    My pondering: The routines the Michel Abrash use's to copy from
    display memory to display memory might be faster than mine. I haven't
    used them.  I don't like them because you're limited by the number
    of figures and its kind of messy having to keep stuff in display
    memory. But, they might be faster, so if you're using 'em now,
    and happy, maybe you can use mine and compare.

    I do know one thing: Large bitmaps that can't fit into unused video
    memory should be faster with only 4 outs per bitmsp.          

-- 
------------------------------------------------------------------------
 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
From: sl8nl@cc.usu.edu
Newsgroups: rec.games.programmer
Subject: Re: JOSH'S SCALE UNIT
Date: 10 Sep 92 15:13:47 MDT
Organization: Utah State University

In article <62430019@acf3.NYU.EDU>, reznick@acf3.NYU.EDU (Daniel Reznick) writes:
> Some time ago, you (Josh) offered to post "psuedo" code to this group
> for your mapper / scaler code.  Was the algorith similar to the one
> offered up here last week for Wolf 3D? I do understand assembly code,
> I just find it much more meaningful if I have some idea about how it
> works before I try to understand someone else's code.

As a quick summary, the Scale routine calls a modified Bresenham routine
(off the top of my head) that will skip a line for every Errorterm, or keep
adding lines for everything in between Errorterms (down/up).  It then takes
this info, and scales the image.  For instance, if the scaletable is

2,0,4,0,1   (which will probably never happen, scaling up and losing pixels,
too?)

It would draw pixel 1 twice (or row 1 depending on rows or columns), skip pixel
2, 4 on pixel 3, etc.

The perspective routine used the ScaleTable routine to generate the column
scales:

|\
| \
| /
|/
4321 (or whatever)

and used a modified line drawing routine to draw a line in memory for the
slope.

Josh
From: baylor@ccwf.cc.utexas.edu (Baylor)
Newsgroups: rec.games.programmer
Subject: ega games
Date: 13 Sep 92 01:04:45 GMT
Organization: The University of Texas at Austin, Austin TX


	Besides the installed base, is there any reason why games like
Keen are written in ega (asuuming vga is easier to program in)?

-- 
*******************************************************************************
baylor@ccwf.cc.utexas.edu            free leonard peltier
From: red@hpfcso.FC.HP.COM (Floyd Moore)
Date: Fri, 11 Sep 1992 15:54:04 GMT
Subject: Help with Solar/Lunar Cycles in a game
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: rec.games.programmer

Hello,

I am trying to design some routines for a game system (ok actually it is
a MOO - Mud varient) that handles some things having to do with solar
and lunar cycles.  

My problem is that I need a relatively simple (trig functions are fine)
function that will compute the location of the sun in the sky (approx is
ok, like just the vertical angle above the horizon given the time of day
and the locations latitute).   The same question also applied to lunar
cycles is needed also (what phase is the moon and where in the sky is it
at this time).  Note that I am not trying to develop precise algorithms
for the position, but I also want something a little beter then a simple
gamma*sin(theta + phi) function.  

Does anyone have a good reference on this type of modeling, or better
yet have a sample routine in some high level language (ie C, pascal,
etc) that could be used in this situation.


Any help would be appreciated.

-----
Floyd Moore                           red@fc.hp.com
Entry Systems Operation               
Hewlett Packard Co.                   Fort Collins, Colorado	
Newsgroups: rec.games.programmer
From: stone-andy@CS.YALE.EDU (Andy Stone)
Subject: Re: ega scrolling
Organization: Yale University, Department of Computer Science
Date: Tue, 15 Sep 1992 00:28:18 GMT


There's a product out called GAME-MAKER, which allows people to make Keen like
games for the 320x200x256 VGA mode without programming.  I've seen ads in
various game-oriented magazines (PC Games, Video Games and Computer Entertainment
(I think)).  The add says how to order.

							| Andy |
-- 
                                                  |  Andy Stone |
From: tscott@plains.NoDak.edu (Timothy E Scott)
Newsgroups: rec.games.programmer
Subject: Graphics help/advice
Keywords: algorithms 3-d
Date: 13 Sep 92 02:54:22 GMT
Distribution: na
Organization: North Dakota Higher Education Computing Network

This is my first post here...so here goes everything:

A few months ago I picked up Lee Adam's _Graphics in C: Animation and
Simulation_ and gained an large interest in graphics programming for
the PC (the book, on the whole, sucked...I'm new to graphics programming
and he didn't take too much time justifying/explaining his algorithms.)
From there, I found a book at the library by L. Ammeraal entitled
_Programming Principles in Computer Graphics_ (which also used
C for its examples.)  By far, this book was more explanatory in the
area of graphics I'm interested in -- that being three dimensional.
My interest stems from a friend and I collaborating on making a
3-d space fighter game.

I basically lifted a program straight out of Ammeraal's book (which
draws a 3-d cube rotated/translated using spherical coordinates)
and added animation.  The program first sets to a nonvisible
page, and either moves to a point, or draws from the current
point to a given point.  After drawing all lines, it flips the nonvisible page
visible, switches operations to a nonvisible page, erases it, and begins
the process again, rotating both the angle factors one degree at a
time.  This, BTW, is only a wire frame model -- no hidden lines,
shading etc...

The problem is the algorithms, in both books, are WAAAAAAAY too
slow.  Here are some ways that I've tried to get around this:

1) Created two 180 element arrays sine and cosine, which are
   equal to the sine/cosine of an angle times 10000.  Any
   references to an angles sine/cosine therefore are not
   computed.

2) As a result of scaling up the sine/cosines, I was able to
   eliminate any need for floating point operations (which
   GREATLY improved speed -- but still fails to draw complex,
   many-lined objects very fast.)

3) The points to moveto and drawto (as I named the procedures)
   are stored in memory and referenced through the use of a
   pointer.  I have no idea if this improves performance or not,
   but it seemed 'like the right thing to do.' :)

The drawback to 2) is that now I'm doing more LONG operations
to compensate, and I'm sure those slow down computations a bit, but at least
not as much as floating point operations would.

Now, I'm looking for any suggestions/pointers to books/algorithms/
whatever that'll clue me in on how to make things go faster and
look nicer (ie shading and line hiding) -- anything besides learning
to program in 80x86 assembly (which I'm afraid I might have to end
up doing anyway.)  Any help anyone will be able to give me
will, of course, be GREATLY appreciated.

Thank you..

--tim

-- 
------------------------------------------------------------------------------
uunet!plains!tscott OR tscott@plains OR tscott@plains.nodak.edu "Call collect!"
------------------------------------------------------------------------------
From: kc@dcs.ed.ac.uk (Kenneth Cameron)
Newsgroups: rec.games.programmer
Subject: Re: video game standard!?
Date: 13 Sep 92 18:19:17 GMT
Reply-To: kc@dcs.ed.ac.uk (Kenneth Cameron)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U


When this thread started, someone mentioned that there were notes about
programming the Atari 2600 console on the net somewhere. I never saved
the post, but would now like to get hold of the stuff. Can someone tell
me where I can find it, I got nowhere with archie and wais. Thanks.

On the subject of the standard. Is n`t OS9 just a little bit over-kill, hmm ?
All that is really needed is a boot rom, which will start up the cartridge,
rom or otherwise. And has a large number of vectored (to allow code change)
subroutines for doing useful things like bitblit. Some decompress code might
also be useful to save rom space.

--
Kenneth@Edinburgh
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: rec.games.programmer
Subject: Re: video game standard!?
Date: 7 Sep 92 03:55:50 GMT
X-Maildoor: WaflineMail 1.00r


     -=> Kenneth Cameron spoke of "Re: video game standard!?" <=-
    To All at 09-05-92  15:41
 KC> Why patent ? Publish it, then it becomes prior art. Besides any
 KC> company that managed to get a patent would have to do a major rework to
 KC> add some sort of lock chip because without that anybody could develop
 KC> carts,but with the added advantage of an easily obtained console.
 KC> As for software, (at least where I come from), the copyright goes to
 KC> whoever wrote it. If you want to give it away, but not into the PD,
 KC> write it on the licence.
    Freeware instead, hhmm like GNU free software foundation.
 
 >Base machine ideas.  68k based with a built in kernal

 KC> More important will be the graphics and sound, and will it use carts,

    Actually the processor is important you want something EASY
    to develope for.  Otherwise you'll have a lovely machine that
    poeple HATE programing.  I'd rather have weak audio and video
    capability and have a good solid system to program.

 KC> or will it have a disc drive ? Take a look at some of the TI graphics

    To answer your question, both.

 KC> processors. They have a processor, dram control and video timing all in
 KC> one chip. Just add video DACS, sound chip, glue including jostick

    Hmmm I contact TI and ask for a spec book (or buy it).

        Stephen Cyberman@Toz.Buffalo.NY.US
        Scripted at Sun  09-06-1992  22:07:51

... Blue-shifted: The way to travel ...
--- Blue Wave/QWK v2.10