Request - removing dialog and sprite number limits

Started by Dave Gilbert, Fri 24/03/2017 14:22:44

Previous topic - Next topic

Dave Gilbert

Is there a reason why the sprites are capped at 30,000 and the dialogs at 500? I am currently at ~10,500 sprites and ~150 dialogs. I am taking preventative measures to conserve (multiple conversations within the same dialog topic, removing unnecessary frames, etc) but it would be nice not to have to worry about it.

Thanks in advance!

-Dave

Crimson Wizard

#1
Dialogs limit is easy to remove (I did that before in some experimental version), but sprites need some thinking. Specifically they may need different internal storage.

In short, the problem with sprites is that user can freely change their numeric ID. Currently AGS stores them in a continious array. When there is a limit, you know you just create array of that size, and restrict user's choice to range 0-max. But if you do not impose any arbitrary limit, how should program act if game has 2 sprites: one with ID = 10 and another with ID = 1.000.000.000 ? Obviously you can no longer store them in a simple array, because you would have to allocate 1 billion of entries just for 2 sprites in that case.

In the past I was considering hashmap, but one hashmap for the huge number of sprites can lead to higher memory requirements. Possibly, making hashmap of small arrays may be suitable for this. Each array size may either be hardcoded (like 1000 elements) or calculated based on how sprite IDs are spread.


BTW, for the sprites, I keep suggesting same workaround: import big sprite sheets, and cut sprites into dynamic sprites as you get a need to use them, then dispose them as you no longer need them.

Dave Gilbert

Ahh. So if I understand right, it's possible to INCREASE the sprite limit but not remove it entirely? Can that be done at least?

Crimson Wizard

#3
Quote from: Dave Gilbert on Fri 24/03/2017 15:55:51
Ahh. So if I understand right, it's possible to INCREASE the sprite limit but not remove it entirely? Can that be done at least?

Both is possible. I would rather say that it is technically easier to increase the limit, but dealing with possible consequences is easier if we remove it.
Because if we increase the limit without changing internal implementation, everyone who uses AGS will be impacted by same increased memory requirements. Not that this will be critical for everyone, but hard to tell what happens if we decide to, for example, extend sprite data structure.

If I were changing anything, I would try to remove it entirely first.

Dave Gilbert

Right. Well, don't put all that work in on my account. It's very unlikely we'll hit 30,000 sprites but in the unlikely event of us hitting 20,000 I'll start using sprite sheets as you suggested.

edit: Although removing the dialog limitation would be very very nice! :)

Monsieur OUXX

I was actually wondering: what's the point of letting people set their own ID for a sprite or object? Has that ever been used by anyone for anything? the purpose of IDs is to be unique identifiers. So as long as the engine gives away unique IDs, it's good enough. Therefore, removing the ability for the user to set his/her own IDs (i.e. removing the ability to create "holes" in their sequential generation) would remove the difficulty in managing the memory structure.

That said, if it's not possible to do that, then I'm wondering what would be the best solution.

As you said a hashmap for such a large structure is not ideal (if the data to hashmap ratio is too large, then there would be a lot of collisions, leading to an acces time of O(n). If it's too small, then lots of space would be wasted).

How is it managed in Javascript? (in that language, it works the way you described: if you have an array of size 1 and then set a cell value at position 1,000,000, it creates all the cells inbetween).

Would it actually be a big deal to have an array of size 1,000,000? The end-user already has the ability to create rather large dynamic arrays. And very few people use the ability to set the sprite's ID themselves. So yes, in a few cases there would be space wasted by the user's mishandling. But nowadays, a 1MB array of int (or pointer to object) is no big deal, is it?
 

Danvzare

Quote from: Monsieur OUXX on Wed 29/03/2017 09:39:08
I was actually wondering: what's the point of letting people set their own ID for a sprite or object? Has that ever been used by anyone for anything?
I think it's there to allow some coding wizardry. Such as assigning a certain sprite based on an algorithm and stuff like that.
But has anyone ever used it for anything like that? I don't know... I doubt it though.

Crimson Wizard

#7
Quote from: Danvzare on Wed 29/03/2017 12:34:03
Quote from: Monsieur OUXX on Wed 29/03/2017 09:39:08
I was actually wondering: what's the point of letting people set their own ID for a sprite or object? Has that ever been used by anyone for anything?
I think it's there to allow some coding wizardry. Such as assigning a certain sprite based on an algorithm and stuff like that.
But has anyone ever used it for anything like that? I don't know... I doubt it though.

Yes, this is actually the reason people set their own sprite IDs.



Quote from: Monsieur OUXX on Wed 29/03/2017 09:39:08
That said, if it's not possible to do that, then I'm wondering what would be the best solution.
I do not know what the best solution is... This needs some investigation and then testing. I once read that hashmaps start to work worse when with too large number of elements, but it may easily be that I did not understand that correctly, or overthinking the problem.
Maybe we may simply use hashmap. If that causes trouble, then we may use hashmap that stores smaller arrays as elements, thus making hashmap itself smaller at the cost of taking some extra memory. Or even simplier - array of arrays, where arrays of second level are not allocated unless required. (Latter would be almost like hashmap with preallocated storage)

One thing about hashmap solution is that - since 95% of sprites are usually created on game load, and since keys are already integers (no need to call hash function), it will be very fast hashmap.

Quote from: Monsieur OUXX on Wed 29/03/2017 09:39:08
Would it actually be a big deal to have an array of size 1,000,000?
IDK about others, that will be a big deal for me, because I do not want to allocate million elements to store e.g. 10 of them; unless there is no better way.

Dave Gilbert

You can set unique sprite IDs? I must be dense. I swear I never heard of this magic before. This sounds incredibly useful. I've looked through the manual and can't see any documentation for it. Under what topic should I be looking?

Crimson Wizard

#9
Quote from: Dave Gilbert on Wed 29/03/2017 14:14:37
You can set unique sprite IDs? I must be dense. I swear I never heard of this magic before. This sounds incredibly useful. I've looked through the manual and can't see any documentation for it. Under what topic should I be looking?

You can change sprite ID by choosing "Change sprite number" from context menu. And yes, this can be changed only in the editor.

I have no idea if it's mentioned in the manual. Maybe this info is missing.

Dave Gilbert

#10
Ohhh you mean change the sprite NUMBER? Yeah, I already knew you could do that. I thought you meant that you could actually give a sprite a unique name, like "eli_run_1." That would have been very useful. :)

edit: And just for reference, I change the sprite numbers all the time for the precise reasons CW mentioned.

Crimson Wizard

Quote from: Dave Gilbert on Wed 29/03/2017 14:21:29
I thought you meant that you could actually give a sprite a unique name, like "eli_run_1." That would have been very useful. :)

If you mean, assign a string ID, then AGS cannot do that. But what you can do is create a macro in your script:
Code: ags

#define eli_run_1 12345

And then use that macro in scripts like
Code: ags

oObject.Graphic = eli_run_1; // dumb example

Dave Gilbert

Thanks CW. I already do that. I was kicking myself that there might have been a much easier way that I had been missing all these years! :D Not a crazy prospect, as I only recently discovered the DoOnceOnly command exists. :shocked:

Gilbert

Quote from: Monsieur OUXX on Wed 29/03/2017 09:39:08
I was actually wondering: what's the point of letting people set their own ID for a sprite or object?
I use that A LOT. This is a very important feature for say display the appropriate sprite according to certain formula.
It's a pity that the audio clips in the renewed audio system couldn't be referenced by numbers without complicated methods, so IMO the current AGS versions are broken and thus I refuse to use the recent versions.

Danvzare

Here's an idea, although I'm not sure if this is technically feasible.
What if you could change the maximum sprite limit in the engine. That way if you're making a tiny game, you won't have a huge chunk of memory being used for no good reason, and if you're making a huge game you can increase the maximum sprite limit to whatever you need.
All without having to remove the sprite limit and incurring all of the problems that may cause.

Would it be possible to set the size of the array for the number of sprites in the compiled game engine rather than just the source code?

Crimson Wizard

#15
First of all, I see myself guilty in turning the discussion away from the original topic with the AudioClips. TBH at first I decided to not to reply to Gilbert's comment on that, but it kept bugging me as something that needs a solution.

What if we split the AudioClips talk into separate thread?
E: DONE: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54640.0

I need to time to read the latest posts before replying again.



Quote from: Danvzare on Thu 30/03/2017 11:56:28
Here's an idea, although I'm not sure if this is technically feasible.
What if you could change the maximum sprite limit in the engine. That way if you're making a tiny game, you won't have a huge chunk of memory being used for no good reason, and if you're making a huge game you can increase the maximum sprite limit to whatever you need.
<...>
Would it be possible to set the size of the array for the number of sprites in the compiled game engine rather than just the source code?

Hah. This is actually an alternative I was considering too once. It is dumb and simple when you first think of it, the only drawback is still that user is put into position of controlling game memory requirements in a very unclear way, which may not be critical ofc, but still... I mean, person can just increase the limit to 1 billion by mistake without realizing what they are doing (while keep using only tiny portion of it).
E: lol sorry, I first posted without finishing the sentence...

SMF spam blocked by CleanTalk