30-10-2003 00:14									#1
	Sprite Limit Support Apolyton or Terrorists Win

Who'd have thought it'd be this easy?

code:

// from SpriteGroupList.h

#define k_MAX_SPRITES		200

... How likely is it () that there is no other code dependant on this number?

	30-10-2003 01:32									#2
	Re: Sprite Limit Help yourself to an AD-FREE life

quote: Originally posted by Immortal Wombat Who'd have thought it'd be this easy?

quote: ... How likely is it () that there is no other code dependant on this number?

Well, we'll find out as soon as the code compiles. But I'd say very likely...

	30-10-2003 01:38									#3
	Remove this text

very likely

you have to set up a number there are 68 main ctp units that’s over 130 for moding now how likely does it sound you must put a number in however I would recommend you replace it with one for the modern sys spec say 500

	30-10-2003 03:02									#4
	Suffering from ads?

quote: Originally posted by Immortal Wombat ... How likely is it (:rolleyes that there is no other code dependant on this number?

Do you mean other code that uses it or this line duplicated?

code:

//from SpriteList.h

#define k_MAX_SPRITES		200

	30-10-2003 03:09									#5
	Support Apolyton

Also need to consider too, that if we change this too high it'll take vital memory that we may need for something a little more critical than pretty graphics, like for instance, AI processing.

	30-10-2003 03:58									#6
	Enter the AD-FREE zone

I'd prefer dropping the #define all together and letting the program check the number of available sprites. That way it's scalable and you can slip in and out sprites you want/don't want. Why have a limit when you can just ask the program to count through the available sprites once at the beginning of the game and assign the total to a variable.

Since, IIRC all of the sprites have their specific numbers built into the file names, it shouldn't be a problem associating the right unit with the right sprite in the units.txt file.

Also, as Dale mentions this has the virtue of only using the amount of virtual memory you actually need.

	30-10-2003 04:20									#7
	Help yourself to an AD-FREE life

quote: All the sprite graphics must be available in the memory while CTP2 is running irrespective whether they are used or not. At least that is my guest from I have seen so far.

Yes, I think Pyaray mentioned this before.

Well, anyway, that's just dandy then. Woo!

	31-10-2003 01:04									#8
	Support Apolyton buy from Amazon

Will it be possible to rename sprites other than the number convention? I remember the big problem of new sprites sharing the same number.

	31-10-2003 21:06									#9
	Inflate your Upload Space

quote: Originally posted by E Will it be possible to rename sprites other than the number convention? I remember the big problem of new sprites sharing the same number.

Yes, but it might be to cumbersome to implement. We could maybe do it by not having a maximum at all but read in all sprites that exist in the folder (and are necessary to play the selected scenario/mod). That shouldn't be too difficult I reckon.

	02-11-2003 03:50									#10
	Support Apolyton

Hmm.. might not be that simple

If sprites are loaded onto a DD surface in GFX Card texture memory (limited resource, unless you have a latest and greatest graphics card, basically,) then we may have a problem with capacity, other than changing a number. It just depends how they did the DirectDraw stuff.

I'll take a look at some point soon.

	09-11-2003 19:18									#11
	Support Apolyton buy from Amazon

I'll just comment that additional sprite capacity would be very handy. No one is forced to use a higher limit, and I expect most serious mods will try and limit themselves to make the mod as playable as possible. But lets say 1000 sprites would be quite handy for the modder himself to have all sprites he's working on available for his test sessions and such.

I wonder, would it be possible for a mod to have a file listing all it's active sprites and for CTP2 to only load those at start? This assumes using mod swapper or a similar function. That way one could keep a huge sprite library but only load those needed for a particular game. In that case sprite ID might not require a numerical limit either, though I for one would would still use that feature for standardisation.

Marc aka Caran... with the usual disclaimer, I'm not a programmer, anything beyond a script and my brain starts smoking.

	09-11-2003 20:10									#12
	Support Apolyton, buy Galactic Civilizations

quote: Originally posted by Caranorn I wonder, would it be possible for a mod to have a file listing all it's active sprites and for CTP2 to only load those at start? This assumes using mod swapper or a similar function. That way one could keep a huge sprite library but only load those needed for a particular game. In that case sprite ID might not require a numerical limit either, though I for one would would still use that feature for standardisation.

newsprte.txt is such a library for unit sprites and there are also such files for city sprites, effect sprites and good sprites.

-Martin

	09-11-2003 23:53									#13
	Inflate your Upload Space

As far as I can understand from browsing the source, the sprite numbers in the newsprite.txt has no limit, it is only the constant k_MAX_SPRITES that cause the limit.

Therefore we could simply remove the constant and voila! No limit whatsoever!

	10-11-2003 00:28									#14
	Got spare money?

quote: Originally posted by DDowell As far as I can understand from browsing the source, the sprite numbers in the newsprite.txt has no limit, it is only the constant k_MAX_SPRITES that cause the limit. Therefore we could simply remove the constant and voila! No limit whatsoever!

Unfortunatly it isn't such simple, this constant is used to datamine how much space is reserved for the sprites that the game loads, so just removing it would prevent the code from compiling, increasing it means using more memory and more time to fill it. Maybe 300 sprites of each type is ok, but this isn't very intelegent. The best solution is to make it so that as much memory is used as needed. And that is a little bit more tricky.

-Martin

	10-11-2003 00:52									#15
	Support Apolyton, buy GURPS/ Alpha Centauri

is it martin when the game loads it looks in activsion\ctp2\gamedata\newsprites and there at the top is a model number

	10-11-2003 03:37									#16
	Support Apolyton, buy Civilization III: Complete

quote: Originally posted by Martin Gühmann Unfortunatly it isn't such simple, this constant is used to datamine how much space is reserved for the sprites that the game loads, so just removing it would prevent the code from compiling, increasing it means using more memory and more time to fill it. Maybe 300 sprites of each type is ok, but this isn't very intelegent. The best solution is to make it so that as much memory is used as needed. And that is a little bit more tricky. -Martin

I agree with that. But regarding the reservation of space it is merely used to created an array of pointers. Therefore, the amount of memory used up by that array is quite small.

	14-11-2003 14:52									#17
	Full PM-box? Change here!

You will always need a hardcoded constant for a maximum number of sprites somewhere.

Suppose we change the file to have the number of sprites read in from a TXT file. This would be good because we could reduce the amount of memory we use to just the memory that we are using.

Now suppose someone, in a fit of madness or with a malicious streak, decided to set the maximum number of sprites in this hypothetical text file to a very large value such as 2000000000 just to see what would happen. Without a hardcoded limit to check against, the game could crash rather spectacularly as it tried to allocate this much memory.

The constant will allow us to check the number of sprites in the scenario's sprite TXT file, and values that are too large could be rejected. (A message would appear on screen and the scenario wouldn't run.)

It might be possible to determine this maximum number of sprites at runtime, thus relieving us of the need to hardcode a constant, but that's not something I know how to do.

	14-11-2003 18:38									#18
	Support Apolyton, buy Civilization: The Boardgame

You know, you can't prevent people from wrecking their computer anyhow. I bet there are quite a few features in the official CTP2 text files that could be turned into a nasty system crash. All that is usually done is to add a warning to such lines that putting values beyond a certain level into those lines could lead to unexpected even dangerous results. A similar warning could be added in this case and if it's no more then saying that putting a number above 500 (just an example) is not recommended.

In the end this limit is also based on the end user's system configuration.

The more technical aspects I will leave to those who actually understand the math and programming involved (unlike me;-).

Marc aka Caran...

	14-11-2003 20:24									#19
	Increase the size of your Attachments

quote: Originally posted by star mouse Now suppose someone, in a fit of madness or with a malicious streak, decided to set the maximum number of sprites in this hypothetical text file to a very large value such as 2000000000 just to see what would happen. Without a hardcoded limit to check against, the game could crash rather spectacularly as it tried to allocate this much memory.

It depends on the computer you are running the game on. If you are running CTP2 on BlueGene or MCR you could handle an exponentially larger number of sprites. About a year ago I created an enormous map by playing with the values in the map.txt file without crashing my system. It took five minutes to load and shutdown the game and it probably would have crashed an older computer. My preference is to set no maximum and if your computer can't handle the memory requried, lower the number or buy a faster computer.

	14-11-2003 21:50									#20
	Support Apolyton buy from Amazon

I know my computer is kind of ancient *grumble* but I don't think we shall not put a limit. It would make it a bit easier to keep an overview for moders, if they know there is a limit. Also we would prevent to many 'complaints' because of no limits (maybe).

But putting the limit into a .txt file might be easiest to adjust.

	14-11-2003 22:18									#21
	Increase the size of your Attachments

quote: Originally posted by Gilgamensch I know my computer is kind of ancient *grumble* but I don't think we shall not put a limit. It would make it a bit easier to keep an overview for moders, if they know there is a limit. Also we would prevent to many 'complaints' because of no limits (maybe). But putting the limit into a .txt file might be easiest to adjust.

I agree. That way as computers increase in speed, you can add extra capacity without being required to alter the source code.

	15-11-2003 04:57									#22
	Increase Your PM Length

I recommend the first line of newsprites

	15-11-2003 21:55									#23
	Support Apolyton, buy GURPS/ Alpha Centauri

I don't like to set a limit somewhere in the text files, in my opinion it is better to have something like just using as much memory as necessary. So if there are only five sprites at programm start only memory for five sprites is assigned. If you 1000 then memory for 1000 sprites is assigned, so no hardencoded limit or set somewhere. And if it needs to be a value somewhere then the const.txt is the right place for it, we have also city, good and effect sprites.

-Martin

	16-11-2003 03:20									#24
	Suffering from ads?

quote: Originally posted by Martin Gühmann So if there are only five sprites at programm start only memory for five sprites is assigned. If you 1000 then memory for 1000 sprites is assigned, so no hardencoded limit or set somewhere. -Martin

It would be prudent to check the number of sprites against some suitably large number so that people don't shoot themselves in the foot. (Crash!) By "suitably large", we can choose a power of 2 and don't allow the number of sprites to go over that limit. Any power of 2 between 1024 and 32768 would be a good "absolute maximum". However, 32768 does not quite fit into a signed 16-bit integer, so that needs to be taken into account.

	17-11-2003 03:52									#25
	Enter the AD-FREE zone

how about we get the game to count the number of entry in the newspr file then that we no real number is coded

	17-11-2003 04:07									#26
	Support Apolyton buy from Amazon

Actual I thought of counting the number of sprite files in the sprite directory. For a number like 32768 I wouldn't call this really a limit. My point is just to use as much space as needed to store the sprites in the memory and not 32768 as it would be if I just change the number in the according file.

-Martin

	18-02-2004 04:41									#27
	Support Apolyton, pre-order Civilization IV

Quick question.

Has anyone managed to increase the number of unit sprites available in the game?

I would have thought 250 or 300 would be about the max to allow some new units as well as civ specific plus possibly other special units such as leaders tec?

	19-02-2004 23:22									#28
	Support Apolyton or Terrorists Win

quote: Originally posted by stankarp Has anyone managed to increase the number of unit sprites available in the game?

Managed?

I thought it is obvious in this thread how to do it, if you accept that you use more cpu time and memory for all the sprites. But if you mean considering increasing it in a more intelegent way, no one managed it. But a temporal sollution could be to increase this number.

-Martin

	13-04-2004 21:53									#29
	Support Apolyton, buy Call to Power 2

Has it been decided what the max number should be for the upcoming Apolyton Edition?

	13-04-2004 22:48									#30
	Put an end to popups!

Well, I would think that Martin's solution from a few posts above is the most reasonable:

quote: Actual I thought of counting the number of sprite files in the sprite directory. For a number like 32768 I wouldn't call this really a limit. My point is just to use as much space as needed to store the sprites in the memory and not 32768 as it would be if I just change the number in the according file.

With, well, probably adding some sanity check to make sure that no more than x sprites are loaded into the memory, where x could, as said, be any power of 2 between 1024 and 32768... though I can't really see us ever having more than 2^11 sprites, say = 2048.