HDTenEightyP/NetNews huggingface dataset:
From: rael@diku.dk (Peter Hj{resen)
Newsgroups: rec.games.programmer
Subject: RISK: Anouncement, calling for discussion, etc...
Keywords: Risk
Date: 7 Oct 92 13:33:12 GMT
Organization: Department of Computer Science, U of Copenhagen

Hello world...


[This is my first posting, so bear with me...]

I have been following this group for quite a while, and I (almost) 
haven't seen one single discussion about RISK. I think this is a shame...

Recently I finished developing a Risk-game for Windows 3.* as part of
my study. Today, I distributed it as a "Share Ware"-program in Denmark
(home, sweet home). My plan is to it give a couple of weeks here, and
if it is a succes (well, maybe even if it aint), I will translate it to
english and distribute it worldwide. Only, I have a minor problem: I
don't know how to do this!

Should I send it out as a (uuencoded) file here?
Should I upload it to simtel-20.army.mil (and how to do that?)

Besides: Is anybody interested in a Risk-game at all, or is there a
reason, why nobody seems to talk about it...

The program, I made, was based on the following:

     1) It should have a better user interface than the two Risk-programs,
	that I know of: Virgin Risk for Dos (1988, I think) and RKEga for
	windows (a joke in my humble opinion).
     2) It should be able to play Risk at a level somewhat better than 
	a total novice.

I succeded in 1) and also in 2), although I would like it to play much
better. This, I would to happen with the help of all you guys (and girls, 
if any). To be quite frank, after playing 10 times or so, you seem to
quess some basics about the strategy. Thereafter you beat the computer
almost everytime.

Right now, the program uses an ad hoc playing strategy, based on local
observations. I would like to hear from any of you, who migth have 
interesting views on the possibility of using 
   
     1) Alpha/Beta-pruning (minimax?).
     2) Graph theory.
     3) Anything, that will make the program a better Risk-player.

So, if you have any suggestions on how to play Risk OR if you would
like to see my program on the net (however, whenever) OR if you have a
better game of Risk for free (maybe YOU made the perfect Risk game) OR
if you have some flaming to do (I have to learn somehow, right):
Either reply here or mail me directly.



My address is (and thanks for the attention) 


rael@diku.dk
From: halifax@sportster.ksu.ksu.edu (ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh)
Newsgroups: rec.games.programmer
Subject: Lemmings
Date: 7 Oct 1992 11:19:39 -0500
Organization: Kansas State University
NNTP-Posting-Host: sportster.ksu.ksu.edu
Summary: who's going to write it for the net?
Keywords: lemmings



I recently purchased lemmings for my genesis and fell in love with
it.  If you have ever played the two player mode you would realise
how intense this would be with several people playing at once.  I don't
know enough about programming myself to even attempt it but I was wondering
if anybody had or is working on a clone for the unix or even better something
playable by people on net.  If not is anybody out there interested in trying
it?


(halifax@matt.ksu.ksu.edu)

#sorry no .sig yet 
Newsgroups: rec.games.programmer
From: kennehra@craft.camp.clarkson.edu (Rich"TheMan"Kennehan)
Subject: Parallax Scrolling Demo at WUarchives
Organization: Clarkson University
Date: Wed, 14 Oct 1992 02:25:19 GMT



Hi.  There is a parallax scrolling demo at Wuarchives (128.252.135.4)
The file is "scroldem.zip" in the directory "pub/MSDOS_UPLOADS"

Let me know what you think of it!!! 

- Rich
  kennehra@logic.camp.clarkson.edu


Newsgroups: rec.games.programmer
From: kennehra@craft.camp.clarkson.edu (Rich"TheMan"Kennehan)
Subject: Re: PC Sprite Engine
Organization: Clarkson University
Date: Tue, 13 Oct 1992 23:52:39 GMT


David J Madura: PC Sprite Engine

>My idea was that the sprite card would genlock with whatever VGA card
>in use and that way, programmers could use the VGA as a background with
>the sprites in the foreground (eliminating the need for backgrounds in
>the sprite board and concentrating on sprites only).

VGA cannot produce a smooth scrolling background.  So the sprite engine is
going to have to do both scolling AND sprites.

>Remember, the sprites do not need a continuous bitmap.

What do you mean???

>Mind you, I think you people in no way even come close to starting this
>project (Like the killer graphics lib, sprites lib, etc...)

Speak for yourself.  

PLEASE keep in mind that the Super Nintendo can handle multiple backgrounds,
sprites, scaling and rotation at 2.15 Mhz!!!  

- Rich
  kennehra@logic.camp.clarkson.edu
From: dmatiske@dvorak.helios.nd.edu (david matiskella)
Newsgroups: rec.games.programmer
Subject: Re: Calling all graphics artists!\
Date: 14 Oct 92 20:43:47 GMT
Reply-To: dmatiske@dvorak.helios.nd.edu (david matiskella)
Organization: University of Notre Dame, Notre Dame

In article <1992Oct14.155255.29116@mnemosyne.cs.du.edu>, vputz@nyx.cs.du.edu (Victor Putz) writes:
|> 
|> No need to be rude, laddie; I think the concept of a PD tile library
|> is a pretty good one, impractical though it be.  It doesn't have to be
|> good, wonderful, production-quality art.  It's the idea that's the beauty
|> of it.
|> 
|> -->Vputz
	Why not shareware clipart. If you use it in a shareware game you pay the author a little cash.
	I think that their are some type of art ( explosions come to mind) having a PD clip art section would be possible. Other types of art are probraly too game specific. Why doesn't some one try to find a FTP site and see if anything gets uploaded.
Newsgroups: rec.games.programmer
From: hhanemaa@cs.ruu.nl (Harm Hanemaaijer)
Subject: Re: svga help
Date: Fri, 9 Oct 1992 13:30:44 GMT
Organization: Utrecht University, Dept. of Computer Science

In <81279@ut-emx.uucp> sill@hal.as.utexas.edu (Daniel Sill) writes:

>i posted the following a few days ago:

>>i found a vga kit called "VGAKIT41.ZIP"..
...
>>1)where i can find the author: john bridges?

I believe he is on compuserve; so it should be possible to contact him via
Internet. His compuserve ID and address are probably in VGAKIT's documentation.

>>2)is there a newer version (the 4.1 ver 
>>  has a date of oct 91) ?

Yes there is, I believe it is version 5.0 dated somewhere around June 1992.

>>3)is there any other documentation on how
>> to tell what svga card is installed (and
>> info on the bank switching required) ?

Take a look at VGADOC01.ZIP at the INFO directory of simtel and its mirrors
(ftp).  It is an excellent collection of SVGA register and BIOS info for most
popular SVGA cards, along with a test program in Turbo Pascal. I believe it was 
compiled by someone on the net (from Denmark?> more than one year ago.

>PLEASE POST A REPLY HERE!
>there are many people who want the same kind of
>information...

If you want to program in SVGA for a specific card, basically the only things
you need to know are how to set the mode (with a simple BIOS call) and how 
to page a 64K bank into the video buffer at a000:0000 (by writing to some SVGA
port registers).

But of course what you want is compatibility with as many SVGA cards as
possible. This leaves you with two options: providing mode setting/page
selecting routines for a large number of card chipsets (using VGAKIT for
example) or using the VESA standard interface which is fairly straightforward.
However, not all cards have a resident VESA driver included or VESA built into
the BIOS, and some are badly programmed, although mode setting and page 
selecting usually work well.  VESA can also be slower than direct access, but
that is only relevant in code that frequently changes banks like plotting 
random pixels. VGADOC01.ZIP contains info about the VESA standard, which was
probably extracted from some version of Ralf Brown's interrupt list.

The VESA standard also includes nifty things like changing the display start
address and logical screen width, which provide for hardware scrolling, but
many VESA drivers I have seen just do nothing; the one that came with my
Trident 8900c card simply returns an 'operation succesful' code.

Hope this helps some of you. 

H. Hanemaayer
hhanemaa@cs.ruu.nl
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Newsgroups: rec.games.programmer
Subject: Re: Sprite Engine News, VOL #1
Date: 11 Oct 92 17:03:00 GMT
Organization: University of Illinois at Urbana

kennehra@craft.camp.clarkson.edu (Rich"TheMan"Kennehan) writes:


>Maybe IBM defined a display memory just because they're IBM!  Think
>about it, their joysticks stink, and so do their video cards!  That's
>why we're trying to build the sprite engine!  To make up for their
>mistakes!  BTW, much of this project is weighing on whether or not the
>sprite engine can read DOS memory fast enough to send to a monitor! 
>Adding about a meg of ram to the sprite engine will drive up production
>costs considerably and might affect its marketablility!  If the sprite
>engine CAN read dos memory fast enough, then this card should'nt cost
>more than 50 bucks!!!  And that would be GREAT!!!

     The video refresh circuitry has to constantly be reading the
     sprite data from memory, 70 times per second according to your
     design.  Now, we all know that 2 devices *CANNOT* read/write
     data on the bus at the same time.... which means that your sprite
     engine would have control of the bus almost all of the CPU time, so
     you would not be able to do any other processing at all!!  The idea
     of video memory on the card is to prevent this from happening.
     So, plan on using on-card memory.... You would want to use SRAM,
     VRAM, and DRAM in that order for performance and ease of design. But,
     for cost, you would want to use DRAM, VRAM, SRAM in that order.  
     Basically, you guys will need to use DRAM since you should have
     quite a bit o' memory on that sucker. 
     I'd recommend figuring out exactly how the VGA card works, get to
     know what every little feature of it does... and then, you'll know
     what you need to do to build the sprite engine.
-- 
------------------------------------------------------------------------
  John A. Slagel, email: jas37876@uxa.cso.uiuc.edu
From: mduffy@aludra.usc.edu (Michael Duffy)
Newsgroups: rec.games.programmer
Subject: Music in games (was Re: Calling all graphics artists!)
Date: 14 Oct 1992 19:25:13 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu

In article <1992Oct14.095505.24308@hellgate.utah.edu> galt%peruvian.utah.edu@cs.utah.edu writes:
>In article <dmatiske-131092162120@archmacconsultant.architecture.lab.nd.edu>, dmatiske@larson.helios.nd.edu (David Matiskella) writes:
>>	On a related note what is the legality of using images taken from PD
>>source like GIFs in a Game? 
>> What about using old classical music from the 1800's in a game?
>
>If the GIFs are truly public domain, then there shouldn't be any problem.
>Also, any music written before 1922 is fair game, as copyrights run out
>in 70 years (or maybe its 50...).  Anyway, anything written before the 
>1900's can be used with out any problems.
>
>In fact, the neat thing about using music that is old is that you get
>professional quality music without having to pay anyone royalties.  

Not entirely true.  As a cinema student who has had to deal with the copyrights
of music before, I have a little bit if insight.  The 70 years part seems true
for the most part, but the copyright may be able to be renewed... You'll want
to check on that.  As for the part about "professional quality music without
having to pay anyone royalties", the music itself may not have a copyright, 
but the performance/performers does/do.  In other words, if you were to 
digitize a classical performance from Suchandsuch Orchestra, you would have
to track down EACH AND EVERY performer to get a release/pay royalties, unless
the performers have signed their rights over to a company that bought the
rights to the performance, in which case you would need to deal with that 
company.  And you wonder why most movies have new soundtracks written for 
them.... TOO MUCH TROUBLE TO TRACK DOWN ALL THE ^#%$*@ UNCOOPERATIVE PEOPLE
WHO OWN THE RIGHTS!!!

If you synthesize the music on your own computer... then that is a different 
story.......

Later,
Mike Duffy (mduffy@aludra.usc.edu)
(Question: If bees made white-out instead of honey.... would we be able to see
their hive?)
From: mike@sabrina.dei.unipd.it (Lorenzo Micheletto 260777/IL)
Newsgroups: rec.games.programmer
Subject: Re: PC Sprite Engine
Date: 15 Oct 92 11:02:44 GMT
Organization: D.E.I. Universita' di Padova, Italia

In article <Bw2z59.AM5@news.cso.uiuc.edu> jas37876@uxa.cso.uiuc.edu (John A. Slagel) writes:
>     2. Along the same lines, add another feature to the replace the logical
>	AND feature when writing pixels to something like IF, which only
>	changes the screen pixel if the one you're writing is non-zero.
>	This would allow the use of REP MOVSB with odd-shaped sprites. But
>	then, *GASP* we would only have 255 colors instead of 256 !!!!
Why not implement a skip/draw decoder ? 
It works this way:
a) set line_lenght register (note ,regular vga has a register like this
                             you just have to expand its use)
b) set pen_pointer register (kinda raster pointer)
b.1) set line_pointer (same value of pen_pointer so this can be set
     in the same access if the card designer has spare space for the
     support circuits needed)
c) send image description bytes to the display memory window using REP MOVSW
   ( this way you can move 16 bit in one shot)
   (an 8 bit card could serialize access, while a 16 bit card could pump
    in data at top speed)
   thru a decoder working this way:
     value:            action:          pseudocode:
   data byte == 0      go to next line (add line_lenght to line_pointer
                                        mov line_pointer to pen_pointer)
   data byte > 127     plot pixel      (mov (data_byte-127) to [pen_ponter++] )
   0 < data byte < 128 skip pixels     (add data_byte to pen_pointer)

A decoder like this could speed up odd-shaped sprite drawings
( more than an odd-shaped sprite drawing using a "don't draw" value)
and add a little sprite data compression ( a sequence of "null" pixels
becomes just one byte)
A sequential machine doing this decoding is easy to implement.
Sprites would have just 128 colors instead of 256
(but background would have 256 colors as usual)
think i can live with so little colors :-) .
Note:
Flipping left/right or upside/downs such sprites wouldn't be a big problem
(just add 2 direction flags to the decoder (one for lines & one for rows)
 the way the D flag works for MOVSB/MOVSW & thinker with the initial values
 of line_pointer and pen_pointer before drawing and when changing line )
Note 2: 
Yeah! this make the skip/draw sprite editor a little more complex than a
"plain sprite" editor,it needs an encoder/decoder routine added to the
usual code ( this way you edit a matrix of points & later you encode it
when saving to file or before animation).



Lorenzo Micheletto mike@sabrina.dei.unipd.it

p.s. Forgive my possible mistakes, usually i write in italian
     (but can understand english very well)
Newsgroups: rec.games.programmer
From: scarnie@esk.compserv.utas.edu.au (Stuart George Carnie)
Subject: Re: PC Sprite Engine
Organization: University of Tasmania at Launceston
Date: Thu, 15 Oct 92 03:34:08 GMT


Who said you can't scroll the VGA smoothy.  I've done it, on SLOW computers.
All you need to do is switch to 256k mode, and then change the start-address-
high/low registers and wait for a Vertical Retrace. If you keep changing this
offset, you will create a smooth scrolling background.

I believe the sprite engine should be connected to the VGA via a cable on the output (ie same way the video blaster works), and all it needs is some sprites, and one more level of scrolling (to create parallax scrolling). 512k min though.
Imagine this:

The VGA has a split-screen capability, so turn that on for scores, etc, then scroll around a super-bitmap on the standard VGA, and then on the sprite-engine,
chuck on the sprites and the other virtual screen and scroll it.  
We would even have time to play a 4-track mod in the background.

Look what we have...

A real arcade machine, and the sprites would even be useful in animation OR
windows would even benefit from it aswell.

Anyway, hopefully someone who can build a similar device reads these messages,
because they would DEFINATELY sell.

Someone reply to my creative labs message, and I'll get incontact with them.

Cheers, Stuart
-- 
scarnie@esk.compserv.utas.edu.au

"On a distant planet, a creature strums his guitar..." {:-)
------------------------------------------------------------------------------
Newsgroups: rec.games.programmer
From: ccastej@prism.gatech.EDU (Eric Jensen)
Newsgroups: rec.games.programmer
Subject: Tile systems that work?
Summary: What are the pro's and cons?
Keywords: graphics, tiles, easy, good
Date: 15 Oct 92 20:45:48 GMT
Organization: Georgia Institute of Technology, Behavioral Engineering Division

I am writing a tactical wargame in C++, and I was wondering 
what people's experiences with hex-maps vs. square-based maps 
have been.  If you've written a game using a tiled map system,
and you have thought long about this choice, I would really
appriciate it if you sent me mail or posted here, telling me
what your experiences with this have been.  I just need some 
pros and cons to help me decide.  
   From what I can tell, the hex-maps are better for true 
distance movements, etc.  While the square based system should
be much easier to deal with.  (Square array and all.)
All constructive replies are quite welcome.
    Eric Jensen

-- 
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!ccastej
Internet: ccastej@prism.gatech.edu
Correction: There is no deck 'Helllllllpppp.......'  Please select another.
Newsgroups: rec.games.programmer
From: donp@agora.rain.com (Don Park)
Subject: Re: Discussion starter
Organization: Open Communications Forum
Date: Tue, 13 Oct 1992 04:37:51 GMT

amitp@owlnet.rice.edu (Amit J Patel) writes:
>So let's try to figure out how to write this!  :)
Finally, some relevant games programmer talk! :)

>where I can put some objects in and let them run.  I think this will
>be fun!

I think you have some good ideas as to how to make objects interact
with the world. My problem is how to effectiveely save their state
on a moments notice and reload to where the program left off and
restore the state of all objects.



-- 
Don Park						donp@agora.rain.com
From: nak@cbnews.cb.att.com (neil.a.kirby)
Newsgroups: rec.games.programmer
Subject: Re: Tile systems that work?
Keywords: graphics, tiles, easy, good
Date: 16 Oct 92 21:11:50 GMT
Organization: AT&T

In article <Bw7tIy.MKL@rice.edu> amitp@owlnet.rice.edu writes:

[deletions]

>As a user, I think hex-based games look prettier.  :)
>
>I tried writing a hex-based game to see how the math worked out, and
>here is my coordinate system:
>
> /---\     /---\     /---\     /---\     /---\     /---\     /---\   
>< 0,0 >---< 2,0 >---<     >---<     >---<  A  >---<     >---<     >
> >---< 1,1 >---< 3,1 >---<     >---<  A  >---<     >---<     >---<
>< 0,2 >---< 2,2 >---<     >---<  A  >---<     >---<     >---<     >
> >---< 1,3 >---< 3,3 >---<  A  >---<     >---<     >---<     >---<
>< 0,4 >---< 2,4 >---<  A  >---<     >---<     >---<     >---<     >
> >---< 1,5 >---< 3,5 >---<     >---<     >---<     >---<     >---<
>< 0,6 >---< 2,6 >---<     >---<     >---<     >---<     >---<     >
> >---< 1,7 >---< 3,7 >---<     >---<     >---<     >---<     >---<
>< 0,8 >---< 2,8 >---<  B  >---<     >---<     >---<     >---<     >
> >---< 1,9 >---<     >---<  B  >---<     >---<     >---<     >---<
>< 0,10>---< 2,10>---<     >---<  B  >---<     >---<     >---<     >
> \---/     \---/     \---/     \---/     \---/     \---/     \---/
>
>The reason I picked this over several other methods was that it's easy
>to store, because it's just a rectangular array.  (x,y div 2)
>
>Vertical columns have the same x coordinate.
>The "A" diagonal has the same x+y.
>The "B" diagonal has the same y-x.

I've been using this for a few years now, and I call the numbering system
"rational" as opposed to "hex".  It makes lots of things much easier to do
- NOTE I USE *NO* FLOATING POINT.

>
>Distances are a bit tricky, because x isn't spaced the same as y:
>    
>   d  = sqrt( ((y2-y1) / 2) ^ 2 + 
>              ((x2-x1) / sqrt(3)) ^ 2 )
>

Can do better if your range is "map range" and not "real range."  Map range
is count the minimum number of hexes traveled.

If the difference in the column numbers is greater than the row difference,
the column difference is your range.  Else take a fraction (half or third,
I don't have my code handy) or the row difference that is greater than the
column difference and add it to the column difference.

Range is cheap.  Facings/relative bearings take work.

>(Look at the equilateral triangle {(0,0),(1,1),(0,2)} to see where
> I got that)
>
>but they're not that bad once with this coordinate system.  The
>shortest path algorithm (for moving a piece from one location to
>another) is what I'm working on --- I've started with the standard
>textbook algorithm (graph traversal), but the nodes are so regular
>that I thought I might be able to find something better.

SHould be, I worked out a hex LOS routine that computes what hex is the nth
hex from hex a to hex b for anyn such that 0 <= n <= range.
>
>I didn't get very far on my game because school started, but maybe
>I'll get back to hexes someday...
>
>
>		Amit

Good luck.

Neil Kirby
Newsgroups: rec.games.programmer
From: larsen@meena.cc.uregina.ca
Subject: A couple of questions:  2 page vs. 3 page,  C++ performance
Date: 14 OCT 92 23:47:03 GMT
Organization: University of Regina, Regina, Sask., Canada

I have done video games for other computers, but not for the IBM PC.  I have a
couple of questions.

1)  Do you recommend 2 page swapping, waiting for the interrupt, or 3 page swapp
1)  Do you recommend 2 page swapping, waiting for the interrupt, or 3 page
swapping?  I'm leaning towards 3 page for several reasons: a)  I don't know
how to do two page!  (It shouldn't be two hard to make an interrupt handler,
but I haven't seen any sample code.)  b) My background animations will be
smoother.  c) Since I can do redraws at leisure, the code should be simpler,
shouldn't it?  d)  It will make things easier to speed up and slow down -- but
I will have to compute the processor speed at the beginning.  Any ideas on the
I will have to compute the processor speed at the beginning.

2)  Is there any performance hit for using C++ rather than C?  My game will be
object oriented whether I use C++ or C -- it just depends on who is doing the
2)  Is there any performance hit for using C++ rather than C?  My game will be
2)  Is there any performance hit for using C++ rather than C?  My game will be


2)  Is there any performance hit for using C++ rather than C?

Thank you
Bryan Larsen   (Larsen@meena.cc.uregina.ca)
Newsgroups: rec.games.programmer