HDTenEightyP/NetNews huggingface dataset:
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Subject: Re: Text Mode & ANSI Animation?
Organization: University of Illinois at Urbana
Date: Mon, 9 Nov 1992 00:28:01 GMT

K1N2 <K1N2@UNB.CA> writes:

>However, I tried doing this and it seems disappointingly slow. Of
>course this is probably because I was using the QBASIC interpreter
>that comes with DOS; but then again, this interpreter was on a
>386/33 PC.  Is it feasible to use text mode animation in the way I
>described, with some other language, perhaps?  Would it be in
>general faster than typical pixel-based animation?

    If you want speed, use C or Assembly.

    If you want to stick with Basic, try POKE'ing the video values 
    directly to video memory.  This is a lot faster than using PRINT.
    One other way to speed up QBASIC is to put a semi-colon on the end
    of every PRINT statement, so it doesn't have to do a line feed.

    To poke a value:
       DEF SEG = &HB800     'Point to the text screen buffer
       RowV = 12
       ColV = 36 
       CharV = ASC( "A" )   ' Display an A at 12, 36
       BackColorV = 7       'White
       ForeColorV = 15      '     on Blue
       POKE RowV*160+ColV*2, CharV
       POKE RowV*160+ColV*2+1, BackColorV*16+ForeColorV

    The video memory starts at segment B800.  It is in the form of
    character, attribute, ...etc.

    This speeds things up some in Basic.

-- 
------------------------------------------------------------------------
  John A. Slagel, email: jas37876@uxa.cso.uiuc.edu
From: mduffy@aludra.usc.edu (Michael Duffy)
Newsgroups: rec.games.programmer
Subject: Re: Aspect ratio in mode X
Date: 12 Nov 1992 23:27:07 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: usa
NNTP-Posting-Host: aludra.usc.edu

In article <2vdq+1a@lynx.unm.edu> blakely@triton.unm.edu () writes:
>
>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.
>
Yeah, Michael Abrash's code has a little bug in the mode setting routine.
the code:
mov  dx,MISC_OUTPUT  ; i.e. 03c2h
mov  al,0e7h
out  dx,al

needs to have the middle line changed to:
mov  al,0e3h

This is for Abrash's code from Dr. Dobbs Journal (July 1991), and for any code
based on his routines without this bug fixed.  As for what you can do about
your bgi library...... Can't help you there.  Maybe contact the library author.

Later and Good Luck,
Mike Duffy (mduffy@aludra.usc.edu)
/* Cinema Major and Computer Geek rolled into one.  Dangerous combination! */


Newsgroups: rec.games.programmer
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Subject: Re: using video-ram in mde 13h (ibm pc)
Organization: University of Illinois at Urbana
Date: Tue, 10 Nov 1992 23:07:42 GMT

etljmme@etlxd10h.etlxd (jim moore xd/nda) writes:

>Hi Paal.

>  Yes you can access a buffer which you declare in unused video ram but if you do,
>why not use page swapping rather than copy it across?  All page swapping involves is
>telling the VGA to start the next scan from another place in VGA memory anyway!

    [code deleted]

>I know this works in 320x400x256 mode so it should work in 320x200 mode.  Be sure to
>clear your buffer or page before you use it otherwise your screen will fill will
>garbage.

     I don't mean to say you're wrong, but unless you're using ModeX or
     a derivative of it, this won't work.  Standard VGA mode 13h takes
     up 64K (320x200x1byte) which nicely fits into the video memory
     page frame located at segment A000.  There is no way to write to 
     the rest of the video memory.  Which is why there is a modeX.  In
     this mode, there are 4 64K pages (0-3), where each page 'n' stores all
     pixels that OFFSET MOD 4=n, so the offset that you use into the 64K
     page frame is really divided by 4, so in the 64K page frame you can
     access all 4 pages of video memory, which is 256K.  So writing one
     byte will light up 4 adjacent pixels.  Then, to only light up 
     individual pixels, you turn on/off the cooresponding bit planes by
     using standard VGA port writes.  

     Then, and only then, can you access anything past the first quarter 
     of VGA memory and use the code that was posted for setting the
     starting address.

     Hope this clears things up.

-- 
------------------------------------------------------------------------
  John A. Slagel, email: jas37876@uxa.cso.uiuc.edu
Newsgroups: rec.games.programmer
From: s026@brems.ii.uib.no (Paal K Holmberg)
Subject: Re: using video-ram in mde 13h (ibm pc)
Organization: University of Bergen, Norway
Date: Wed, 11 Nov 92 11:37:55 GMT

 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.
 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 ?

-- 
 Paal Krebs Holmberg
 UiB
 Norway
 
 "To program, or not to program - thats not a question " ;-) 

                               |                          
                               |                           
                               |              
                              (n)             
                   X-----====(.i.)====-----X  
                      X       +++       X    
                               ~             
  		   Good flying,and check six
Lines: 19
Date: Thu,  5 Nov 92 20:47:29 MST
Newsgroups: rec.games.programmer
From: KirkA.Baum@ernie.cs.byu.edu (Kirk A. Baum)
Subject: Re: Visual Lib
Organization: Computer Science Department, BYU

In article <Bx56ur.AxA@cen.ex.ac.uk> cs90mdh@cen.ex.ac.uk writes:
>From: cs90mdh@cen.ex.ac.uk
>Subject: Visual Lib
>Date: 3 Nov 92 13:30:26 GMT
>
>I plan on using a new shareware 3D graphics library called 'Visual Lib', for
>the Windows environment (Borland C++ V3) but dont have an email contact 
>address. Can anyone help me out?
>
>Thanks in advance.
>
>				Mark.H.

 Where did you get this library?  Let the rest of us know?

Thanks,

Kirk A. Baum
kirk@ernie.cs.byu.edu
Newsgroups: rec.games.programmer
From: edlee@chinet.chi.il.us (Edward Lee)
Subject: Re: Advice needed for fastest sort algorthm
Organization: Chinet - Public Access UNIX
Date: Mon, 9 Nov 1992 09:49:23 GMT


A radix sort has a time complexity of O(N), which means that it
operates in linear time on N units of data.  It is asymptotically
faster than a Quick Sort which operates in O(N*log(N)) time.  This
means that the more data you sort, the faster a radix sort will be
over a Quick Sort, as long as you have enough memory to continue the
radix sorting.  The time difference between the Quick Sort and a
radix sort is the log(N) factor times some other constant factor.

How does this relate to your problem?  If you have several or many
objects such as bitmaps or windows that you are displaying on a
screen, you can represent their distance from the front of the
screen or the observer as an integer.  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.  The existence of a path in the binary radix
tree indicates the existence of a particular integer.  Recursively
descending the binary tree and recording the path as you go along
will produce ordered list of integers in either ascending or
descending order depending on the direction in which the descent
begins.

I have written some radix sorting code but am not ready to release
it.  Perhaps you can write some of your own code based on what I
have written above.


-Ed L
Newsgroups: rec.games.programmer
From: gardabr@unix1 (Gard Eggesbo Abrahamsen)
Subject: Re: Fast compression
Organization: University of Trondheim, Norway
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 10 Nov 92 12:25:35 GMT

Chris (cbusch@ub.d.umn.edu) wrote:
: Hello
: 	What is the fastest compression technique?

The fastest compression techique is probably coding in this form:
if bit 7 is cleared, the following n bytes are to be read directly.
if bit 7 is set, the copy the next byte n times.
This is FAST but a really crappy packing, and you REALLY shouldn't use it.

: Chris Busch   CBUSCH@ub.d.umn.edu

Gard Eggesboe Abrahamsen  gardabr@unix1.mrih.no

"Why sort what you don't need to sort?"   Gard 1992
Newsgroups: rec.games.programmer
From: amitp@owlnet.rice.edu (Amit J Patel)
Subject: Re: Quicksort/quicksort()
Reply-To: amitp@owlnet.rice.edu
Organization: Rice University
Date: Mon, 9 Nov 1992 14:02:28 GMT

In article <32545@mavenry.UUCP>, the.maven@mavenry.UUCP writes:
|>  
|>  Regarding sort algorithms, you may or may not want to use the ansi 
|> quicksort() function. ANSI standards mandate the function's presence, but do 
|> very little to define it's implementation. I know of a couple compilers 
|> which implement a bubble sort as quicksort()... If you don't have the RTL 
|> source for your compiler (so you could check) you might want to find another 
|> Quick Sort routine and test that for speed against your compiler's... 

Even if it really is a quick sort, it's not too efficient, because it
has to make a function call for every comparison.  If you're sorting
ints, compare:


	int a,b;


						int foo(int a,b) 
						{
							return a<b;
						}

	if(a<b)			vs.		if( compare(a,b) )



and


	temp = a;		vs.		memcpy(&temp,&a,sz);
	a = b;					memcpy(&a,&b,sz);
	b = temp;				memcpy(&b,&temp,sz);


Writing your own qsort, radix sort, merge sort, or heap sort would be
better than using their library because the compiler can use inline
the comparisons and swaps.




		Amit


P.S.  C++ templates seem to be the way to write qsort() once and not
	lose efficiency.
Newsgroups: rec.games.programmer
From: hal@gateway (Hal Feinstein)
Subject: Re: Software Pinball Machine
Organization: Mitre Corporation, McLean, VA
Date: Thu, 5 Nov 1992 16:40:17 GMT

In article <18899@ucdavis.ucdavis.edu> f110019@hamlet.ucdavis.edu (Julian Burger) writes:
>In article <1992Nov2.204624.24267@u.washington.edu> goble@hardy.u.washington.edu (Brian Goble) writes:
>wanted to write a Pinball simulator that would accept table definition files.
>In other words, you would have a pinball-table description language which
>would be parsed and a table created from it.

This would definitely be something interesting I bet, to the industrial type
who have to build pins for a living. I think it would be a lot harder to 
simulate the dynamics of a pin in action because of all the effects on the
playfield. I painted a stripe on a ball and used it in my much abused 
8Ball Champ to get a feel for how the many axis the ball was  spinning on.
Brr....  the motion is not simple! Some of the gimmics on the playfield
are sensitive to certain types of spin and ignore others and yet other gimmics
are sensivite only to the non-rotational movement of the ball. (try taking the
rubber off a post a see what happens). I suppose it could be done.

Now, there is a PC game called "Night Mission Pinball" that seems to have gone
through a lot of trouble to simulate a pin using only a PC screen.  The ball
motion is a lot better then the "bing bing bing" type reflections from the
game "break out" and feels more dynamic but nothing like the real thing.
The parameter screen is loaded with things like initial velocity settings
flipper force, coefficent of elasticity and other kinds of parameters you'd 
expect to see in a dynamic simulation. It's nice to fool with but it any't 
the real thing.  But if your interested in see how to begin you could start by 
checking out this PC game.       
Newsgroups: rec.games.programmer
From: u519876@csi.UOttawa.CA (U. N. derGrad)
Subject: Re: Card Shuffling
Organization: Dept. of Computer Science, University of Ottawa
Date: Fri, 13 Nov 92 20:00:33 GMT


I recently requested a card shuffling algorithm, and have received
a good deal of replies.  Thanks!  If anyone wants a brief summary of these,
send me an e-mail.

A new problem has arisen:  finding an acceptable random number generator.
Suggestions, please...  

Programming is in C (love that language!).  I don't need code, really.
Just a description of possible solutions.

Much appreciated.

--
Kevin Coughlan
u519876@csi.uottawa.ca
--
Newsgroups: rec.games.programmer
From: etljmme@etlxd10h.etlxd (jim moore xd/nda)
Subject: Re: using video-ram in mde 13h (ibm pc)
Reply-To: etljmme@etlxd10h.etlxd
Organization: Ericsson
Date: Tue, 10 Nov 1992 17:51:28 GMT

Hi Paal.

  Yes you can access a buffer which you declare in unused video ram but if you do,
why not use page swapping rather than copy it across?  All page swapping involves is
telling the VGA to start the next scan from another place in VGA memory anyway!

Here's how to flip the visual page from the default (at $A000:0000) to another.

Let's assume we have a page in video ram at $A000:8000. To select which page we want
to make visual, we can use this code (where p = page number, 0 or 1):

  PROCEDURE VisualPage(p:byte);
  VAR ofs : word;
  BEGIN
   ofs:=$8000*p;            { These lines calculate the offset for page 0 at 0000  }
   ofs:=ofs + $0C;          { or page 1 at 8000, the +$0C is arbitrary             }
   asm
    mov  dx,03d4h           { These lines redefine the VGA CRTC registers so that  }
    mov  ax,ofs             { the next scan starts at ofs, thereby making the page }
    out  dx,ax              { visual.  This is faster than copying from a buffer   }
   end;
  END;

I know this works in 320x400x256 mode so it should work in 320x200 mode.  Be sure to
clear your buffer or page before you use it otherwise your screen will fill will
garbage.

Good luck, Jim.

Newsgroups: rec.games.programmer
From: colin.buckley@rose.com (colin buckley)
Subject: Code for Loading.
Organization: Rose Media Inc, Toronto, Ontario.
Date: Sat, 7 Nov 1992 05:22:05 GMT
X-Gated-By: Usenet <==> RoseMail Gateway (v1.70)


Date Entered: 11-07-92 00:14
JA>>  JNC  @@Even
  >>  MOVSB
  >>@@Even:
  >>  REP MOVSW
  >>| Colin Buckley -- 486 Powered (Packing Extra Socks) |
  >                    ^^^ This is why its faster on yours... On 386 or 286,
  >                        that isn't the case.

Actually, I tested it with Abrash's STIMER before I had the 486.  I tested
it on a 16mhz 286, and the JNC was faster than another rep overall.  I
tried small odd/even, and large odd/even.  But like I said, I believe
I used ADC CX,0.  Then I tried it on a XT, and the JNC was faster aswell,
and since most optimization is directed at 8088/6 I used that.  I have
no idea what the processor demographics are, and even so, unless
they listed game usage specifically, I'll stick with what's best for XT's
and 286s.  I will test the ADC CX,CX version though.  Optimization will
be important later, right now I just want to see my game up and running to
inspire me.  I'm really losing motivation like usual.

Abrash uses JNC which is where I first found it.  Sutty and Blair
(Advanced programming guide to SVGA (They did EGA/VGA aswell) provided the
additional REP method.  Most people think Abrash is god.  Although personally
I tought PGP sucked, and I don't know why people beg for copies.

I'm not trying to convince you I'm right just why I originally posted and
my view of optimization.
.----------------------------------------------------.
| Colin Buckley -- 486 Powered (Packing Extra Socks) |
| Toronto, Ontario, Canada                           |
| InterNet: colin.buckley@rose.com                   |
|                                                    |
| So Eager to Play, So Relunctant to Admit it...     |
`----------------------------------------------------'
---
   RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285
Newsgroups: rec.games.programmer
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Subject: Re: Advice needed for fastest sort algorthm
Organization: University of Illinois at Urbana
Date: Tue, 10 Nov 1992 23:17:07 GMT

   John Slagel (Me!) 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).
>>>
>>>   In other words, if you're sorting n objects, QuickSort takes "on the Order
>>>   of" n*log n steps, while bubble sort takes "on the order of" n*n steps.
>>>

   Dave Roberts chokes at my stupidy:
 
>Ack!!! People, remember that bubble sort has a *worst* case time of
>n!.  It can be quite fast if most things are sorted.

>Dave Roberts
>Advanced Micro Devices, Inc.
>Network Products Division
>david.roberts@amd.com

   Ack!!! Me, John Slagel, who is a soon-to-be-interviewing senior
   in C.S., gives up all hopes of getting a job with AMD :-)

-- 
------------------------------------------------------------------------
  John A. Slagel, email: jas37876@uxa.cso.uiuc.edu
Organization: Queen's University at Kingston
Date: Wed, 11 Nov 1992 14:28:33 EDT
From: Jeff Boyd <BOYDJ@QUCDN.QueensU.CA>
Newsgroups: rec.games.programmer
Subject: Re: Card Shuffling


I'll add one comment to this discussion;  I'm coming in part-way, so it
may have been stated already:

   Be EXTREMELY cautious in your choice of random number generator
   and seed, particularly if 1) you will be dealing a large number
   of hands, 2) you must be certain that every possible hand can
   occur, and 3) every possible hand must be equiprobable.


jeff (now leaving part-way :-))

Newsgroups: rec.games.programmer
From: sfought@mcs213j.cs.umr.edu (Shane Fought)
Subject: Re: Software Pinball Machine
Date: Thu, 5 Nov 1992 15:32:16 GMT
Organization: University of Missouri - Rolla

In article <1992Nov5.135235.7388@meiko.com> gordon@meiko.com (Gordon Henderson) writes:
>In article <1992Nov2.204624.24267@u.washington.edu> goble@hardy.u.washington.edu (Brian Goble) writes:
>>
>>I have programmed many arcade style games but never anything like a
>>pinball machine.  It seems very challenging and I am interested in hearing
>>what others have done or how they might go about it.
>
>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!
> 
>All this was ... Oh ... 8 years ago ...
> 
>--
>  Gordon Henderson

There was a similar program out for the Commodore 64.  Pretty extravagent 
program for such a limited machine...

Newsgroups: rec.games.programmer
From: dstampe@psych.toronto.edu (Dave Stampe)
Subject: Re: Advice needed for fastest sort algorthm
Organization: Department of Psychology, University of Toronto
Date: Sun, 8 Nov 1992 14:18:48 GMT

 scd@cs.brown.edu (Steven C. Dollins) writes:
>
>The bubble sort takes, in the asymptotic limit, 1/2 N^2 time, which is
>nowhere NEAR N!.  Where on earth did you get that idea?
>
>Quick sort is O(n log n) on average, O(n^2) in the worst case.  With a
>good randomized quick sort, the worst case will be extremely unlikely.

A point about quicksort, as implemented in the C libraries: you can get
about 4x speedup by hand-coding assembler for the routine.  Even 
a direct C implementation runs faster.
If you are sorting 6 or less items, I'd still use something like an
insert or bubble sort, because the overhead is less (no recursion).
It turns out to be faster, especially when coded in assembler.  For
10 or more, it's worth using the quicksort.  For 4 or 5 items, I 
often hard-code the tests and swaps of the sort as this is very
fast-- no indexing or looping (great for drawing polygons).


--------------------------------------------------------------------------
| My life is Hardware,                    |         Dave Stampe          | 
| my destiny is Software,                 | dstampe@psych.toronto.edu    |
| my CPU is Wetware...                    | dstampe@sunee.uwaterloo.ca   | 
| Am I a techno-psychologist, or just an engineer dabbling in psychology?|
---------------------------------------------------------------------------
From: sonix@schunix.uucp (Duane Morin)
Newsgroups: rec.games.programmer
Subject: Help building a game?
Date: 12 Nov 92 18:30:48 GMT
Distribution: usa
Organization: SCHUNIX Public Access Unix for Worcester County, Massachusetts, USA

Often at work the senior engineer and myself discuss AI and such topics as
computer game strategy.  He proposed a game that he suggests I attempt to 
code an "optimal" strategy for.  What I'd like to ask the net is some 
suggestions on whether or not I'm taking the right approach, and if so how
to go about getting something concrete written.

The game:  Many people will know this game, usually played on a piece of 
paper with a few pencils.  A grid of 5x5 dots is drawn on the paper.  The 
players (usually 2) take turns connecting lines either horizontally 
or vertically.  If a player succeeds in creating a box (i.e. four connected
lines) he gets to move again.  The player with the most boxes at the end 
of the game wins.  (I've pointed out to him that a 5x5 grid creates 4x4
squares, thus allowing for the possibility of a tie).

Problem:  There are certain layouts that the board can fall into where one 
player, given the chance, can chain together enough moves to cover the 
board (or, at least, get the maximum number of squares).  Thus, a computer
strategy would have to see this possibility and guard against it.

Strategy:  Here's my initial thoughts:  Look at the grid as a 4x4 array
of boxes.  Each box can be described in 4 bits, representing the status
of its 4 walls.  Any line that can be placed on the grid will effect 
either one or two boxes (only one if its on an edge).  A box's value can 
be weighed something like this:  

	See the possibility of making  4, take it.
	Don't make any 3's.  Your opponent can turn them into 4's.
	Conversely, make lot's of 2's.
	Except early on in the game, avoid 1's.

This weighting strategy is simple, and might work.  Unfortunately, it has
no lookahead or any capacity for learning.  What I'd like to try is 
something that learns from it's mistakes...for example, let it play 
against itself again and again and develop it's own strategy.  Anybody
got an idea of how I'd do that?  I really can't see doing anything where
I have to represent all the states of the board (40 lines on the grid, 
on or off, yields 2^40 states, correct?)

Or perhaps, something with lookahead?  At any given time, there are 40 or 
less moves that the computer can make.  Temporarily make each one
(recursing if necessary, if the move yields a 4), and then for each one 
weigh the possible moves that the other player could make.  I don't know
how far down I could do this, though...maybe some sort of minimaxing?

As you can probably tell, I'm somewhat familiar with the theory behind writing
such a game strategy.  However, having never actually coded it, I'm in a 
bit of a bind as to how to approach the problem.  Any help would be 
wonderfully appreciated.

Thank you,
 Duane Morin
 sonix@schunix.uucp