lenny@icus.UUCP (Lenny Tropiano) (01/27/88)
Hmmm.. Figured I would compile the distribution of Omega on my UNIX pc
and ran into the normal conversion problems from BSD to System V.
Also I had to rename the files that were over 14 characters long ;-)
#include <strings.h> -> #include <string.h>
#include <sys/timeb.h> -> #include <time.h>
srandom() -> srand()
random() -> rand()
After all that and this I had this linking error.
[...]
ld: can't allocate output section *group*, of size 36ae08
ld fatal: internal error: audit_groups, findsanode failure
*** Error code 13
Stop.
Hmmm... Then I tried linking it with the shared libraries, it linked
with a size of:
-rwxr-xr-x 1 lenny icus 420708 Jan 26 19:24 omega
Ugh! Then after all that, I wanted to see if it was all worth it ...
$ omega
sh: omega: too big
Double Ugh! Oh well... I guess it isn't worth it :-) ... Not for 800+
of executable (stripped, and linked with shared libraries ???)
-Lenny
--
============================ US MAIL: Lenny Tropiano, ICUS Computer Group
IIIII CCC U U SSSS PO Box 1
I C C U U S Islip Terrace, New York 11752
I C U U SSS PHONE: (516) 968-8576 [H] (516) 582-5525 [W]
I C C U U S AT&T MAIL: ...attmail!icus!lenny TELEX: 154232428
IIIII CCC UUU SSSS UUCP:
============================ ...{uunet!godfre, harvard!talcott}!\
...{ihnp4, boulder, mtune, bc-cis, ptsfa, sbcs}! >icus!lenny
"Usenet the final frontier" ...{cmcl2!phri, hoptoad}!dasys1!/matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) (01/28/88)
In article <232@icus.UUCP> lenny@icus.UUCP (Lenny Tropiano) writes: >$ omega >sh: omega: too big On a Pyramid 90x, Omega is 344K code 106K initialized data 3428K uninitialized data ---- 3878K total Unless you have at least 4 MB of virtual address space don't even bother to compile it. Having shared libraries will not help. The uninitialized data is dominated by the "Dungeon" array, which is 40x64x64x20, or 3200K. If just the town level and the current level were kept in memory then this would drop to 160K, reducing the total memory needed to just 838K. This would fit in a 1MB machine. Now all that is needed is somebody to make the changes. -- Matt Costello <matt.costello@SanDiego.NCR.COM> +1 619 485 2926 <matt.costello%SanDiego.NCR.COM@Relay.CS.NET> {sdcsvax,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matt
ries@trwrb.UUCP (Marc Ries) (01/29/88)
Unfortunately, I get core dumps all the time (Pyramid 98x running
4.0 OSX).
FYI, adb says that they are occuring during a call to "time_clock".
Otime.c passes lint, but I have not gone through all of the other
calls (to time_clock).
--
Marc A. Ries
sdcrdcf!---\
ihnp4!------\----- trwrb! --- riessteve@polyslo.UUCP (Steve DeJarnett) (01/30/88)
In article <4710@trwrb.UUCP> ries@trwrb.dsd.trw.com.UUCP (Marc Ries) writes: > Unfortunately, I get core dumps all the time (Pyramid 98x running > 4.0 OSX). > It's up and running on our 98x w/OSx 4.0 (soon to be 4.1, if we're brave enough :-). The only problem we have is with the ~4 Meg run sizes. It's really annoying when you try to start the game and you get a "Not enough memory" exit from the game. I didn't do the install here, but if you send mail to trwind!polyslo!games, the Games master can tell you what (if any) mods he made to make it run. ------------------------------------------------------------------------------- | Steve DeJarnett | ...!ihnp4!csun!polyslo!steve | | Computer Systems Lab | ...!{csustan,csun,sdsu}!polyslo!steve | | Cal Poly State Univ. | ...!ucbvax!voder!polyslo!steve | | San Luis Obispo, CA 93407 | | ------------------------------------------------------------------------------- #include <std_disclaimer.h>
davids@iscuva.ISCS.COM (David Schmidt) (02/02/88)
In article <2012@ncr-sd.SanDiego.NCR.COM> matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) writes: > >The uninitialized data is dominated by the "Dungeon" array, which is >40x64x64x20, or 3200K. If just the town level and the current level >were kept in memory then this would drop to 160K, reducing the total >memory needed to just 838K. This would fit in a 1MB machine. Now >all that is needed is somebody to make the changes. If you don't have the time to re-do the entire dungeon array, you can recover a lot of space by changing ints to shorts in a number of the arrays. This assumes of course that your C compiler uses 32 bit ints and 16 bit shorts. Someone here did that and dropped the size by ~800K, which was enough to get it running on his machine (4mb virtual). Sorry, but he hasn't passed me any diff files yet! -- David Schmidt UUCP: davids@iscuva.ISCS.COM ISC Systems Corporation (uunet!iscuva!davids) East 22425 Appleway Phone: +1 509 927-5479 Liberty Lake, WA 99019