🚀 go-pugleaf

From: Owner-OS2News@teamos2.org

Subject: OS2News: SimCity 2000 for OS/2 Facts

To everyone,
  SimCity 2000 for OS/2 is being distributed by MAXIS. The port was 
done by WinWare corporation.  Those of you who are alert souls will 
remember that we also did the classic port.  There are a couple of 
things I would like to mention about the two ports:

SC Classic was hobbled by three things: OS/2 sound system bugs, no 
DIVE support (it was not available at the time), and it was basically 
released by DUX as a beta (they did not do any Q/A).  Since there was 
no DIVE support, classic used the GPI interface in PM.  This is why 
it is a memory pig and has poor performance.  We do have a version 
that supports DIVE.  It is very fast and does not swap anymore.  DUX 
is aware of this version but I have not heard back from them as to 
whether or not they will upgrade existing users.

SC 2000 uses a new direct screen interface developed by us to replace 
DIVE.  Dive does not have support for blitting rectangles to the 
screen, you must blit entire dive windows.  This is unacceptable for 
a game like SC2000.  This library (and the fact that SC2000 is 
written in 'C', not C++), is why it is so fast.  We also worked with 
IBM to work around some sound problems in OS/2, so the sound support 
is working a little better.  MAXIS handled the Q/A tasks and is also 
responsible for support. 

I would like to say that while DUX does deserve some flames for 
support (or lack thereof), Classic was the first real performance 
game to be ported to OS/2, and suffered more from being in that 
position than it suffered from being released by DUX.


FYI. Here's a repost of a reply I posted that was hard to find....


First, SC2000 was extensively tested for memory leaks and we are 
99.9999999% positive it does not have any.

The 'memory leak' everyone is seeing is most likely caused by a weird 
interaction between the OS/2 multimedia subsystem and the sound 
driver.  During development we observed certain situations that 
caused the sound driver to allocate 120Mb of non-committed memory.  
We could only observe this problem intermittently and there was no 
scenario that made it reproducible.

The memory allocation problem is not the direct performance culprit 
however.  In most circumstances, users experiencing this problem will 
not see any side effects.  This is because non-committed memory does 
not reserve physical memory or swap space.  In most situations, the 
sound driver does not use this memory.  But under some circumstances 
(again, we cannot pin this down), the sound driver begins to use this 
allocated memory.  When this starts happening, performance decreases 
and the swap file increases.  The reason that the 'out of swap file 
space' error does not display has to do with the way the OS/2 swapper 
is monitoring the swap drive.  It does not seem to monitor ring 0 
activity, which is where the driver is running.

We do not have a fix for this, but we need to gather more information.

You can email me directly with more detailed information regarding 
this problem.  I will read everything.  I will also be out here from 
time to time to see what's new.


Thanks for all your comments and suggestions.  I appreciate them.

Jim Thomas  -  SimCity 2000 for OS/2 Development
               WinWare Corporation