Humble request: Increasing Sprite Cache limit?

Knox · Wed 10/08/2011 17:16:33

Is there a way to increase the sprite cache limit? Right now the max is 100mb...it would be nice to put a higher value!

What do you guys think? Can it be done?

monkey0506 · Wed 10/08/2011 19:30:44

I haven't actually tested it, but you might be able to manually supply a different (higher) value. The acsetup.cfg file is written in plain-text, INI formatting. If it doesn't exist, then under [misc], you can add cachemax. It takes a value in KB, so if you wanted to increase it to 250 MB then you could set:

Code: ags

[misc]
cachemax=256000

That is quite a bit of memory, but I know how graphically complex that monstrosity of yours has become. Again, I don't know that this might not cause other issues, but you could try it out and see what happens.

Knox · Wed 10/08/2011 23:17:07

lol! Hehe...yeah, it is quite monstrous!!

Ok, Ill try that out! Just a question, will increasing the sprite cache limit make the game use more RAM or something? (*this may or may not be a stupid question.)

By increasing this limit, AGS will be able to store more sprites into memory, making heavier animations play smoother, right?

I'm working on a "crap-azz" script that kinda tries to pre-load huge view sprites into memory before it gets played, and its kinda working (amazingly)...I can share it with you if you want to see a semi-pooish script!

random meaningless smiley of the day:

Oh, btw, is the sprite cache just for the editor or for the game too? Check this post out here:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=21373.msg258745#msg258745

Iceboty V7000a had an awesome idea way back in 2005 for "PreloadSprite(int slot)"
and "ReleaseSpriteControl(int slot)"...any news on that?

monkey0506 · Thu 11/08/2011 01:58:05

Pretty much any time you're talking about loading things into memory you're talking about the RAM, and the sprite cache's memory is no exception. As a matter of fact, the default winsetup.exe makes mention of that.

Increasing the cache size won't affect how quickly AGS can access sprites that are already loaded into memory, but it could save time if it has to deallocate memory in order to load all of the sprites it may need for any given point in time, since the cache size would be larger and therefore less chance of having to deallocate other sprites when allocating new ones (perhaps even saving having to deallocate and reallocate the same sprites depending exactly how many sprites you're trying to use for this particular room/animation/whatever (and how big those sprites are). So with regard to your second question, it's a yes and a no, depending whether you were actually hitting the 100 MB cache size, and then your CPU would come into play as well...

The sprite cache doesn't apply to the editor at all, I don't know why you would think that. Anything you're setting in winsetup.exe applies only to the engine, not the editor.

Regarding Gilbot's suggestion, didn't he also at some point suggest that using DynamicSprites could force the sprites to be loaded into memory, and then that even deleting the DynamicSprite would leave the static sprite loaded into memory (at least long enough for you to use it the same way)? That would be kind of inefficient having to duplicate every sprite, but perhaps you could force sprites to be loaded if you loaded a ViewFrame or did something, say, with a DrawingSurface.

What method exactly are you using at the moment? It might be worth seeing how you're going about doing it.

Knox · Thu 11/08/2011 02:25:44

I added some various values (with a mb to kb converter I found online

) and in my case...uhh...hehe, 500mb was the perfect number! I tried 3 gigs for fun, and the game wont even start (hangs). Ive got 8gigs ram so I tried to see...didnt work!

With the cache to 500mb, I found that after turning the pages of my quickguides once, for the rest of the time, it was always running fast (50fps or more)...when before, it was like 15fps or lower!

I tried using an array (placing the sprites into dynamic sprites) method Mode7 suggested, however it only works if I downgrade to 16bit. I didnt notice any speed-up unfortunatly even in 16bit with his method.

The other method I tried was just playing the animation on the gui while the transparency is set to 100...then just resetting it to 0 and playing it again! Kinda of crappy, but it got the job done (although there is a delay while you wait for the 1st "preload" invisible animation is playing).

Want me to post that crap here? I can post a vid on youtube too if you wish. I also coded a nifty loading bar to go along with it...gee I wish I had your talents Monkey!

monkey0506 · Thu 11/08/2011 03:27:35

The MB -> KB conversion isn't that hard. I thought about mentioning it but I figured you would..well..aparently not. $:-\$

Code: ags

int MB = 500;
int KB = (MB * 1024);

By the way, depending on how much you might have going on in the background (of your system and your game), AGS is a 32-bit program, which means that it can't really utilize anything above 4 GB of RAM. 4 GB is 4 * (1024^3) bytes, which is equivalent to 2^32. An unsigned 32-bit integer has a maximum value of (2^32) - 1. Sorry if I'm talking a bit of gibberish to you, but the point is that 32-bit programs simply can't use more than 4 GB of memory (the first 4 GB as the system allocates it).

Trying to force AGS to allocate 75% of the memory it has access to solely for the sprite cache, might very well make it explode.

Depending how long it is, sure, post the code here. I saw the post you had before related to this, but I thought you'd reached a conclusion. Apparently your desire to have your game burn up everyone's graphics cards has become utterly insatiable.

Anyway, 500 MB is a lot. Like a lot a lot. My computer that I own only has 512 MB of RAM (it was free, so sue me

). And you wonder why I had to discontinue working on your project directly. :

Knox · Thu 11/08/2011 04:25:41

Heheh...well I did reach a conclusion however you're right...I wont rest until I know everyone who plays the finished game in 23 years from now will need a 5000$ system

I just retested with all my quickguides visible and its "slow" again, so Ill post the code+youtube vids first thing tomorrow...but if its just 1 guide at a time, its nice and fast

ps: I can also upload the whole thing for you aswell, but I'd be afraid your computer might melt, hihihi.

Calin Leafshade · Thu 11/08/2011 05:03:26

You must remember that all the drawing functions in AGS are *not* hardware accelerated, even in D3D mode.. If you have a hi res game that uses alot of drawing functions it will kill systems with a slower cpu.

Knox · Fri 19/08/2011 17:02:54

1) No preload: http://www.youtube.com/watch?v=8eUHfb2xuXw

2) Preload each page: http://www.youtube.com/watch?v=ayhEUnKuDa8

3) Preload bar: http://www.youtube.com/watch?v=dxJFYUOUXBk

Ok, so this is what Ive got as results...the first clip shows the animation of the page flipping without preloading the views at all...the fps gets pretty low (13-14fps).

The 2nd clip, I preload the page flip view everytime the player flips the page...much better fps cause the view is played on an invisible gui first...then I replay it visible

The 3rd clip, I just preload all the views for all the pages of the booklet in one shot...with a progress bar. The best fps here (34-44 fps), but do you guys think it can be annoying for players to wait a few seconds for the preload each time before being able to use the booklet?

Sonny Bonds · Sun 21/08/2011 15:48:42

In my opinion the first one is the best. From a gamers point of view I would be annoyed by the preload bar in the third option. Especially when accidentally using your booklet. Having said that, the GUI looks amazing and the booklet looks very authentic. I am certainly looking forward to this game!

Shane 'ProgZmax' Stevens · Sun 21/08/2011 16:03:55

Second option seems fine. The main issue as I see it is that you're playing an animation when turning these pages, but it's also a blocking animation (hence the wait animation). You could probably gain a little more speed by not making it a blocking animation so if a person feels they made a mistake while turning the page they could just click back and it would stop and play the animation backwards. All you'd need to do is keep track of the current frame to do this, really.

Knox · Wed 24/08/2011 03:18:36

Alright, so you both seem not to go for option 3. You know what, I think the full preload bar is annoying too...I just wish I could find a way to preload those suckers quicker before using the booklets...and having the fastest page flipping fps possible!

Thanks for your suggestions/comments Sonny + ProgZmax...

@ ProgXmax: hmmm, good idea. Ill fiddle with that and see what I can come up with...makes sense!

@ Sonny: Thanks for your enthusiam...I really really hope to finish one day (cause who nows with life getting in the way, you know how it is)...and make a realistic and cool cop game that even real police officers would enjoy!

Sonny Bonds · Thu 25/08/2011 00:22:04

Quote from: General_Knox on Wed 24/08/2011 03:18:36
Alright, so you both seem not to go for option 3. You know what, I think the full preload bar is annoying too...I just wish I could find a way to preload those suckers quicker before using the booklets...and having the fastest page flipping fps possible!

Thanks for your suggestions/comments Sonny + ProgZmax...

@ ProgXmax: hmmm, good idea. Ill fiddle with that and see what I can come up with...makes sense!

@ Sonny: Thanks for your enthusiam...I really really hope to finish one day (cause who nows with life getting in the way, you know how it is)...and make a realistic and cool cop game that even real police officers would enjoy!

You're very welcome. Making a game like this requires hard work and dedication. I understand it can be very demanding after a hard day of labor but I am sure you'll manage! Good luck!