dl2n+@andrew.cmu.edu (Daniel Edward Lovinger) (12/02/90)
XBZONE is now avaliable by anonymous ftp to expo.lcs.mit.edu. It is /contrib/xbzone.tar.Z. The archive contains both the original fortran source, and C source obtained by running the fortran though f2c. It also contains a truly hacked GPR graphics library emulation for X11 (tested under R3 and R4). XBZONE is a version of the arcade classic Battlezone, and was written by Justin Revenaugh at MIT (dated May 1986). dan
dnb@meshugge.media.mit.edu (David N. Blank) (12/04/90)
> XBZONE is now avaliable by anonymous ftp to expo.lcs.mit.edu. It is > /contrib/xbzone.tar.Z. The archive contains both the original fortran > source, and C source obtained by running the fortran though f2c. It > also contains a truly hacked GPR graphics library emulation for X11 > (tested under R3 and R4). Has anyone been able to compile this and get it working on a Sun? Thanks. Peace, dNb
jmunkki@hila.hut.fi (Juri Munkki) (12/04/90)
In article <DNB.90Dec3223806@meshugge.media.mit.edu> dnb@meshugge.media.mit.edu (David N. Blank) writes: >> XBZONE is now avaliable by anonymous ftp to expo.lcs.mit.edu. It is >> /contrib/xbzone.tar.Z. The archive contains both the original fortran >> source, and C source obtained by running the fortran though f2c. It >> also contains a truly hacked GPR graphics library emulation for X11 >> (tested under R3 and R4). > >Has anyone been able to compile this and get it working on a Sun? Thanks. I haven't tried to compile it on a Sun, but I compiled it on a VAX and some friends now regularly run it on Sony News workstations. It was fairly easy to port: mainly changes in the makefile. Some comments on the game: * It looks a lot like BattleZone * It isn't really BattleZone: - The player tank is quite a bit slower than in real BattleZone - Player missiles fly longer than they should. - Hit testing of shots is not accurate enough. - The gunsight reacts even if the gun is not loaded. Annoying. - Missile zig-zags have a smaller amplitude than they should. - If a supertank is behind you, there's very little you can do. - You can't use the technique of moving past a tank, backing up and killing it while it is still turning. If a tank is behind you, it seems to be able to run really fast. Usually you get killed even before you get past the enemy and even if you back out to confront it, its gunsight is pointing right at you. - There are no destructible obstacles. - When a tank hits an obstacle, it backs up (as it should) and and moves only a short distance forward. Also, I think that the tanks shoot while doing this. In real battlezone, they can not shoot while trying to avoid obstacles. * Well done anyway, who wants to improve it? * Suggested improvements: - Make it feel more like real battlezone. - Add a keyboard mode with controls for left and right treads. - Show highscore list after every game and make it graphical. Of course, I don't have time to do any of this and I'd hate to touch anything written in Fortran. I was pleased to see this game, but slightly disappointed when you couldn't use the same skills as in real BattleZone. ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uk1@fabry.rice.edu (Paul A. Scowen) (12/05/90)
yep, I got in and working on a Sun 3/280. Howvever, it is not working corrctly. Right now you can play OK, but you will after a while lose control of the left/ right capability, leaving you will just forward/back. Also the high scores table doesn't work at all, and the program crashes when the games over. I've spoken to Dan Lovinger about the problem and he's looking into the left/right problem, but has anyone dealt with the other problems? -- Paul Scowen Department of Space Physics Rice University (uk1@spacsun.rice.edu)
dl2n+@andrew.cmu.edu (Daniel Edward Lovinger) (12/05/90)
dnb@meshugge.media.mit.edu (David N. Blank) writes: > > XBZONE is now avaliable by anonymous ftp to expo.lcs.mit.edu. It is > > /contrib/xbzone.tar.Z. The archive contains both the original fortran > > source, and C source obtained by running the fortran though f2c. It > > also contains a truly hacked GPR graphics library emulation for X11 > > (tested under R3 and R4). > > Has anyone been able to compile this and get it working on a Sun? Yes - Sun 3/60s running SunOS 3.5. In addition ... As I noted in the README, you will need to retrieve f2c, the Fortran to C translator, from some nearby archive site. One particular one (I should have noted this in the README ... *bonk*) is research.att.com. Send mail to netlib@research.att.com with send help send index for f2c in the body of the message. This will send you all of the gritty details on how to retrieve it. f2c contains the two Fortran emulation libraries in c (libi77.a and libf77.a) as well as the translator. You will need all of it for xbzone. dan
rpotter@grip.cis.upenn.edu (Robert Potter) (12/05/90)
In article <1990Dec4.164013.5165@rice.edu>, uk1@fabry.rice.edu (Paul A. Scowen) writes: >yep, I got in and working on a Sun 3/280. Howvever, it is not working corrctly. >Right now you can play OK, but you will after a while lose control of the left/ >right capability, leaving you will just forward/back. I got it to run on a Sun 4. The file "f2c.h" didn't seem to come in the tarfile, I had to get that elsewhere. I have the forward/back problem too. The workaround is to hit the middle mouse button, which restores the joystick to the center. As far as I can tell the bug is that when you move the joystick outside it's "normal range", the horizontal offset is set to zero. Moving back into range usually fixes the problem. BTW, is there any way to quit the game, short of dieing enough times?
rpotter@grip.cis.upenn.edu (Robert Potter) (12/05/90)
In article <1990Dec4.150916.26196@santra.uucp>, jmunkki@hila.hut.fi (Juri Munkki) writes: >Some comments on the game: > * It isn't really BattleZone: > - Missile zig-zags have a smaller amplitude than they should. Seems like zero amplitude to me. No challenge at all. > - There are no destructible obstacles. Did the original BattleZone have these? I don't remember that. Also: - No "short" obstacles that you can shoot over. - Player shots are too slow. - You can't hide from missiles behind obstacles. - There are helicopters. - Enemy tanks seem much stupider, they tend to ignore you entirely. - You can't see as far. - I don't think the perspective calculations are correct, distant objects are not small enough. Pretty fun game anyway.
stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (12/05/90)
In article <cbKyroO00VpJ4sXopA@andrew.cmu.edu>, dl2n+@andrew.cmu.edu (Daniel Edward Lovinger) writes: |> dnb@meshugge.media.mit.edu (David N. Blank) writes: |> > > XBZONE is now avaliable by anonymous ftp to expo.lcs.mit.edu. It is |> > > /contrib/xbzone.tar.Z. The archive contains both the original fortran |> > > source, and C source obtained by running the fortran though f2c. It |> > > also contains a truly hacked GPR graphics library emulation for X11 |> > > (tested under R3 and R4). |> > |> > Has anyone been able to compile this and get it working on a Sun? |> |> Yes - Sun 3/60s running SunOS 3.5. In addition ... |> |> As I noted in the README, you will need to retrieve f2c, the |> Fortran to C translator, Alternatively, you can compile the Fortran source files directly with f77, provided you have that on your system. Specifically, on a Sun4 with Sun Fortran1.2, I compiled everything in the f/ subdirectory with f77, gpr.c with cc (after commenting out a reference to the "moon" external variable), and linked everyhting with f77 -lX11. Seems to work just fine. -- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
jack@nagel.gatech.edu (Tom Rodriguez) (12/05/90)
In looking at the source i discovered that press buttons 1 and 3 at the same time ends the game. tom
SML108@psuvm.psu.edu (Scott the Great) (12/05/90)
In article <34057@netnews.upenn.edu>, rpotter@grip.cis.upenn.edu (Robert Potter) says: > >In article <1990Dec4.150916.26196@santra.uucp>, jmunkki@hila.hut.fi >Seems like zero amplitude to me. No challenge at all. > They zig-zag somewhat, but are awfully easy to kill... >> - There are no destructible obstacles. > >Did the original BattleZone have these? I don't remember that. > I believe some could be destroyed. The source code indicates that this CAN happen, but I have yet to see it. >Also: > - No "short" obstacles that you can shoot over. > - Player shots are too slow. > - You can't hide from missiles behind obstacles. > - There are helicopters. > - Enemy tanks seem much stupider, they tend to ignore you entirely. > - You can't see as far. > - I don't think the perspective calculations are correct, distant > objects are not small enough. > >Pretty fun game anyway. I believe the US Army authorized version had helicopters... Nice addition in any event... For those of you having trouble getting it to run. I compiled the fortran code straight and combined it with gpr.c. this required me to comment out three lines referencing the variable moon in gpr.c, but otherwise it works just fine on a multiflow computer. The problem with shot accuracy is that the thing determines whether you have hit something or have been hit by using the distance between objects. In other words, consider yourself and everything else to be disks. This routine needs to be modified such that when it detects a hit it should use a more accurate routine to determine if the hit is for real. Overall, a neat game though. A multi-user version would be a lot of fun... Scott Le Grand aka sml108@psuvm.psu.edu
uk1@sirius.rice.edu (Paul A. Scowen) (12/05/90)
Control C seems to work OK, anyone get a highscore table at the end yet? I think its supposed to have one. -- Paul Scowen Department of Space Physics Rice University (uk1@spacsun.rice.edu)
grywalski@idicl1.idi.battelle.org (12/06/90)
In article <1990Dec4.150916.26196@santra.uucp>, jmunkki@hila.hut.fi (Juri Munkki) writes: > In article <DNB.90Dec3223806@meshugge.media.mit.edu> dnb@meshugge.media.mit.edu (David N. Blank) writes: > I haven't tried to compile it on a Sun, but I compiled it on a VAX and --- Is this VAX/VMS or VAX/ULTRIX? I am in the process of porting it to VAX/VMS/DECWidows and have had some success, every thing works except the high score stuff and I'm having a few font problems. Anyhow if a polished VAX/VMS/DECWindows already exists I would like to get a copy, and save myself some time. If anyone knows if such a beast exists I would appreciate know where. Thanks in advance... BTW, I am using the FORTRAN source and not the C translation. Most of the changes I have made for VMS have been in the GPR.C code. * Roger Grywalski - Software Developer GRYWALSKI@IDICL1.IDI.BATTELLE.ORG * Information Dimensions Inc. * 655 Metro Place South * Dublin, Ohio 43017
pds@lemming.webo.dg.com (Paul D. Smith) (12/06/90)
[] Control C seems to work OK, anyone get a highscore table at the end
[] yet? I think its supposed to have one.
The high-scores table has been circumvented in the source: the code is
still there but the relevent function returns before it gets executed.
I commented out the return and got a high scores table.
Unfortunately, it seems to generate the table in the working
directory. I suspect this would be trivial to solve by putting in a
pathname instead of just a filename.
Here's what you do (note I don't recall my FORTRAN from 8 yrs. ago, so
I just modified the C output from f2c):
In file bzone_scores.c, search for "dl2n" (the user who modified the
code). You will find a code segment like:
/* but, why bother with the scorefile ... (dl2n) */
/* terminate gpr after 7.5 seconds wait (this is repeated below) */
timewait_(&timerelative, clock, &status);
gprterminate_(&c__1, &status);
return 0;
/* print out player's score */
I just put `#ifdef 0' / `#endif' around the whole thing and I got a
scorefile.
Also note the scores are printed, etc. after the game ends, so they're
just put out to the Xterm or wherever you started the game from;
they're not drawn on the screen. Bummer. :-)
Hope this helps ...
--
paul
-----
------------------------------------------------------------------
| Paul D. Smith | pds@lemming.webo.dg.com |
| Data General Corp. | |
| Network Services Development Division | "Pretty Damn S..." |
| Open Network Systems Development | |
------------------------------------------------------------------grywalski@idicl1.idi.battelle.org (12/07/90)
In article <1990Dec5.153749.5544@rice.edu>, uk1@sirius.rice.edu (Paul A. Scowen) writes: > Control C seems to work OK, anyone get a highscore table at the end yet? I > think its supposed to have one. In the copy of the source I have, someone changed the program to terminate before the high score keeping is done. excerpt follows... c but, why bother with the scorefile ... (dl2n) c c terminate gpr after 7.5 seconds wait (this is repeated below) c call timewait (timerelative, clock, status) call gprterminate (.true., status) return If you comment out the above three lines from bzone_scores.f the high score stuff will begin working. -- * Roger Grywalski - Software Developer GRYWALSKI@IDICL1.IDI.BATTELLE.ORG * Information Dimensions Inc. * 655 Metro Place South * Dublin, Ohio 43017
stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (12/07/90)
In article <18.275e2dae@idicl1.idi.battelle.org>, grywalski@idicl1.idi.battelle.org writes: |> In article <1990Dec5.153749.5544@rice.edu>, uk1@sirius.rice.edu (Paul A. Scowen) writes: |> > Control C seems to work OK, anyone get a highscore table at the end yet? I |> > think its supposed to have one. |> |> In the copy of the source I have, someone changed the program to |> terminate before the high score keeping is done. excerpt follows... |> If you reenable the score file business, you might also want to fix the caldecodelocaltime_() function which is only a dummy in the original gpr.c, like this: #include <time.h> void caldecodelocaltime_ (array) long *array; { time_t clock; struct tm *lt; (void) time(&clock); lt = localtime(&clock); array[0] = lt->tm_year + 1900; array[1] = lt->tm_mon; array[2] = lt->tm_mday; } -- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
uk1@sirius.rice.edu (Paul A. Scowen) (12/07/90)
Or alternatively you could replace the caldecodetime call with idate and change the sequence of the printouts from decodedtime to 2,1,3 and it works fine too. This is a quicker change. -- Paul Scowen Department of Space Physics Rice University (uk1@spacsun.rice.edu)