No, I don't have a date for Gal Civ 1.2 yet. Some of the stuff that will go into 1.2 also has to get into the Altarian Prophecy, so they should be done about the same time.
But, I don't understand from what you said how sutting the game down ad restarting it made room for more graphics
End of quote
Pretty much all the other systems are built off of the data manager, or use a instance (copy) of it.
Except for the pcx and tga files, all of the other graphics in the game are encoded into .mdl, .mtd, .tiles and .fnt files. By encoded, I mean that the file contains both the graphical data and data that tells Gal Civ how to display it. We call the files libraries and the sets of graphics within them books, and each book has at least one page which is a distinct image (although not necessarily unique). So the game screen is a book, and the turn button is a page. Each ship is a book. We also call the pages of the books Sprites, because that's the term used by most of the game industry.
Now we have a Sprite Manager that takes care of all the sprites. It loads them into memory, paints them, etc. The Sprite Manager is a child of the Data Manager; ie it has all the same code as the Data Manager, plus more code that is specific to the Sprite Manager. Most of the Managers are children of the Data Manager, because they need to handle data and the Data Manager gives them a consistent way to do it. Now that's great, because that means that we don't have to re-write code for every different system in the game. Unfortunately, it means that if there's a bug in there, it'll be in all of them, and that can make finding and fixing the bug tricky.
So the data manager has a data container for the books called an array. Arrays are like CD towers. CD towers have a bunch of slots for CDs that will only fit CDs cases, not DVD cases. You can pull a CD out from any slot in the tower without having to go through the entire tower to get to it. (That's called random access, by the way.) And there's a set number of slots. The data manager has a variable called ulNumOfBooks, which really should be named ulNumOfSlots or ulMaxNumOfBooks, because it's really the number of slots in the array, not the number of actual books in the array. Anyway, deep in the guts of pear, that number is initially set to 256. So when you click on the Gal Civ icon and it creates the window and it's all black, one of the things that it's doing is creating the array for 256 books.
Now when Gal Civ goes to load a graphic, it checks the array to find an open slot for the book. If it finds a spot, it puts the book in that slot, and when the painting code goes to paint that graphic, it gets the information from the book. But it doesn't put anything in a slot until it goes to use that graphic, and it's supposed to remove it from the slot when that graphic is no longer being used. For now, let's assume that it's doing what it's supposed to do, but it's still filling up all 256 slots. That's not too unlikely. There's all the screens in Gal Civ, and most of the ship models have 11 different versions for the various races, and the logos for the stars, the stars and planets, etc.
So as soon as the game went to load book #257, it was in trouble. The person who wrote Pear was usually overzealous about putting in debug messages, and things that will bring the game to a halt if something bad is about to happen in memory (force asserts for those of you who know about programming). Anyway, he missed this spot. So the data manager would look for an open slot, and couldn't find one. But it didn't have a debug message ("Hey, I need more memory here!") , it just quit trying to load it. Hence the invisible ship or planet or whatever.
So I had to find all the places in the code where something was looking for an open slot for a book, and make it increase the number of books if it couldn't find an open slot. This was simpler to fix than if it had been a byte overflow, which is what I was afraid it was.
There is a byte overflow in the data manager, but so far it has only shown up in the string tables. I was able to fix that relatively easily by making a copy of the data manager, fixing just that copy, and making it the parent of the string tables instead of the old one. But to fix it for the managers that deal with the graphics, like the sprite manager, I'd have to write a bunch of conversion routines so that we could still use the graphics that we have encoded. Luckily for you guys, that bug didn't turn out to be the cause of the invisible ships. With any luck, I won't have to fix the rest of the time bombs in there for Gal Civ 2, because Gal Civ 2 will be using 3D graphics so we'll be using differnet systems.
Stardock Forums
) and on the map : same thing, I see a blue light indicating that there is a ship there but no nice picture of it re 
I'm just trying to cut down on the amounts of it that I consume.
.