System Limit Problems

[Yeppoh]

- This applies for the total number of Sprites in AGS. -
One of the actual solution I would try to go around the issue of the System Limit Problem with sprites (if I have to) is to split the game in many executables and use RunAGSGame().
Each .exe having the basic redundant global sprites (like the main character's, the GUI's, etc...), and the sprite slots left are for the local exe.

So technically for N AGS executables you have : (N*30'000)-((N-1)*TOTAL_GLOBAL_SPRITES) slots.
Example : 5 AGS executable, main one included, with 700 global sprites you'll have : 147'600 sprites for the whole game. Jinkies! Who needs that many?!

Of course this depends how the game is designed.
For instance :
I'm designing a game with six distinctive worlds. I could split the game into 6 exe and one world for each respectively. And I go from one world to another using RunAGSGame().

This is a theory I didn't try yet with RunAGSGame(). I'm not even sure if it could work.
I don't know how the global variables are managed, if I every .exe can share the same variables (if it isn't possible, I could use a external temp file - or I design a game that doesn't need to share variables and that all events are local).

[Trent R]

One of the actual solution I would try to go around the issue of the System Limit Problem with sprites (if I have to) is to split the game in many executables and use RunAGSGame().

That's what I said above!

But who know's if it'd work, but wouldn't be that hard to throw together a test.


~Trent

[monkey0506]

That would work, and the save game files would even properly load the correct executable file so that wouldn't even be a problem either.

Sprites that would have to be shared would of course be GUI sprites, player character sprites (and any NPCs which would appear in that executable's rooms of course), and any inventory items which could possibly have conceivably been acquired at this point (i.e., if the room can only be entered once then any inventory gained after that point (from another executable) wouldn't have to be included in this executable (and so forth)).

So I would say that the RunAGSGame idea is probably the best idea for averting these system limits without a lot of work on Chris' part having to change this limit for a one-off situation. Realistically most authors would never come close to this limit.

Further, I can personally attest that RunAGSGame runs very quickly and smoothly...in my tests it's extremely comparable to just loading another room...

[JpSoft]

30 controls per GUI is a limit than can be easily solved. You can just add as many GUI´s as you need. Actually, the minimap in the RTSI'm working have 3 GUIs in the same position of the screen, and the main GUI to control the game have 4 different GUIs. In mi opinion, there are some limits more difficult to solve (for example, objects per room)

Jp

I forgot to mention that you could use characters as objects if you want, even when this solution could be very painful to implement.

E

[Yeppoh]

One of the actual solution I would try to go around the issue of the System Limit Problem with sprites (if I have to) is to split the game in many executables and use RunAGSGame().

That's what I said above!

~Trent

Oh! You're right. Sorry. Somehow I didn't see it. =P

[Shane 'ProgZmax' Stevens]

If these limits were all dynamic values it would place the burden on the game developer (where it belongs) rather than the engine author to maintain a reasonable balance between content and performance.  It would also completely eliminate the semi-frequent requests for extensions to x limit and would allow games that use much less than the current static limits to be more efficient (unless these limits are already dynamically allocated memory within a preset upper limit, which is possible!).

[RickJ]

I agree with what Progz says but realize it may not be practical to eliminate thes elimits at this point.   Perhaps, instead  the limits could be specified in a configuration file that is read by the editor on startup?   

[Pumaman]

Most of the limits that remain in AGS are related to the file formats that AGS uses and the way data is persisted between rooms.

If it was just a simple matter of configuring a limit in the editor and allocating memory based on that, there'd be no point having a limit at all -- it had may as well be unlimited. This was the case with things like the Max GUIs, Max Characters and Max Views limits, which have been removed from recent versions of AGS.

The ones that remain are more tricky to deal with which is why they're still there.