Hi folks, i'am having problem with my game in development. I guess my sprites will exceed 30.000 and i don't know what to do. I PM Chris but he didn't replied back, may be he is busy. Is there anyone knows how to remove this sprite limit ? Or how to raise it ?
I might actually run into the same problem for a project that uses pre-rendered graphics with lots of animation so I'm kind of interested in the same!
How trivial is upping that limit?
A wonderful way to switch between two ags games like it was just a ChangeRoom() has been demonstrated by monkey_05_06 and Khris in this thread:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=42667.20
If you used 'RunAgsGame' and manage to write a 'SaveGameStateToFile' and 'LoadGameStateFromFile' function, you could technically split the game in two or more parts without the player even knowing, in this case it would allow you to have more than 30k sprites right? I hope they can change the limit.
Still... 30.000 sprites... I guess you never know what a user may need, after all Bill Gates used to say, 640K is more memory than anyone will ever need ::)
I do have to question whether you have actually encountered the limit of 30k sprites..
Regarding the idea of using RunAGSGame, I still think Khris underestimates its usefulness. AGS already supports sharing save game files between two AGS games in the same directory, so you would not have to create your own save game system (baring the exception I note below). As far as sharing information between EXEs, the best thing to do there would probably be to do something like what RickJ did with the MiniGame module. AGS already has built-in functions for writing data to files, and temporary files could be deleted..
With that route you would need to basically save the script state to a file (what inventory items the player has, any global variable values..and that should pretty much be it). Even if you have a lot of global data, it's not actually that difficult. You would just save the script state to a file, load the next game, read the save state, and then you could delete the file.
It might be a viable option for you, and if you're using more than 30k sprites then it's probably not a bad idea to split your resources anyway. ;)
I think, although I could be wrong, that the 30,000 sprite limit is embedded in the engine, not just the editor/compiler. Still, if you have actually reached the 30k sprite limit, it might be possible to have it raised..but probably only if you have actually reached it.
The RunAgsGame workaround is clever but a pain in the *** no matter what way you look at it. :D
I have not yet reached the 30k sprite limit indeed (at 10k at the moment) but it is closing in and it's very easy to make estimates regarding how many sprites are needed. 30k is a number nobody will ever reach with hand-drawn sprites I'm sure but I'm working together with a professional senior artist at a real gaming company and we are shooting for a very modern visual style. An NPC has 8 walking and 8 talking loops as well as quite a bit more depending on their role. Say 20 loops on average with lengths between 32 and 64 frames mostly, say 48 on average. 16 of these NPCs already bring us to half the 30k limit, and 16 NPCs is certainly not all that much for a decently long game. Combine that with lots and lots of graphical animation for the various rooms (animated smoke overlays for example) and we are closing in on 30k very quickly. That's the power of rendered graphics and the bane of the programmer. :D
EDIT: And I forgot that each NPC also has an idle view for all directions. Then there's the player character with pick up animations for different heights (low, mid, high) in all 8 directions. Theres the animated cursors, menus and interfaces and so on.
Quote
The RunAgsGame workaround is clever but a pain in the *** no matter what way you look at it. :D
If you can show a list of all the Global variable names/types, I'll gladly write you the save/load functions along with inventory saving. But I understand why you don't want to bother with that. Who knows, AGS' God himself might make your wish come true ;D
There's much more involved in that approach than just inventory items and global variables. What if I want to make a change in the interface? I have to remember to open and make the change every game. What if I want to change the player walk animation a bit for example? Need to commit the changes multiple times and test run every game individually to make sure it is all 100% in sync still.
What about translations? I'd have to save the user selected translation as well and then find a way to start the next game with that translation. What about room variables holding whether or not some door was opened or whatever? Needs to be saved.
The game options (music, sound fx, speech and ambiance volume levels, text reading speach, voice enabled, gamma and so on) all gotta be saved.
Plus it makes it very easy for people to modify those textfiles and cheat.
Unless there's solutions to these issues (just the first that come to mind really) I really won't be impressed or convinced... :D
...and what if a clever player tries to open second game in the folder ? He would start the game not from the beginning, from the half of it. monkey explained it well but i still have suspicions someone manage to break it.
Chris says "If you think any of these limits is a serious problem, contact me and I can probably increase it." We have to trust Chris ;D
I would also be interested in increasing the limit of sprites...but also increasing the limits of inventory items too!
(Whitout hijacking) is it possible to make the limits user-defined? As in, just type the limit number you want in the editor or something? (of course limiting super-silly amounts, like 1 gazillion).
I wanted to see what would happen if sprites overreach 30K and that's why i prepared a test game. I created 2x2 pixels 1000 sprites and imported them in AGS 30 times. Here is the result when you overreach 30K :
(http://img862.imageshack.us/img862/649/testrp.jpg)
...and when i try to save the game with 30002 sprites, i get this error :
Error: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Version: AGS 3.2.0.103
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at save_sprites(Boolean )
at save_game(Boolean compressSprites)
at AGS.Native.NativeMethods.SaveGame(Game game)
at AGS.Editor.NativeProxy.SaveGame(Game game)
at AGS.Editor.AGSEditor.SaveGameFilesProcess(Object parameter)
at AGS.Editor.BusyDialog.RunHandlerOnThread()
--- End of inner exception stack trace ---
at AGS.Editor.BusyDialog.Show(String message, ProcessingHandler handler, Object parameter)
at AGS.Editor.AGSEditor.SaveGameFiles()
at AGS.Editor.Components.FileCommandsComponent.CommandClick(String controlID)
at AGS.Editor.ToolBarManager.ToolbarEventHandler(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
The issues suggested in having a single game split across multiple projects could actually be dealt with a lot simpler than it might seem..and I'm not just talking out my rear, I've done it myself when looking into further developing the MiniGame module by RickJ. Anyway, that's not really the point. It's a significantly less user-friendly workaround than the proposal of increasing the limit.
As I said before, I believe that the limit is actually specific to the engine code, not just the editor. This is actually somewhat supported by the fact that the compiler crashes in the native C++ code.
Quote from: General_Traitor on Sat 09/04/2011 16:35:23
(Whitout hijacking) is it possible to make the limits user-defined? As in, just type the limit number you want in the editor or something? (of course limiting super-silly amounts, like 1 gazillion).
At that point you might as well go ahead and make the whole thing dynamically assigned, which I think is CJ's long-term plan for all the built-in limits.
Wow, these games pushing the sprite limits must be some super big and long games.
@monkey:
I didn't mean to imply that you were talking out of your rear, but it certainly would help your case if you could maybe address my concerns that I expressed earlier - even if its just a couple of one-liners!
@dbuske:
The calculations I posted earlier show that you don't actually need to make a big game at all in order to reach the 30k sprite limit. When you have the freedom to render out sprites for your characters with a 3d art package such as 3D Studio Max it is very tempting to actually go for smooth animations which, in a fluid 60 frames per second game for example, mean you need somewhere between 32 and 48 individual sprites for a single loop of a walk animation.
...and i'm actually doing it in my project in development : Bizarre Earthquake. I have 31 walking frames for each direction. 31x8=248 sprites for one room, just walking. If you have 20 rooms for example, walking sprites take 4960 of 30K. Nearly % 16,5 of total. Think you have 1000 sprites for each room for player character. You would easily reach the limit and you wouldn't have a big-long game.
I hope CJ aready think to fix this issue in his long term plans.
QuoteAt that point you might as well go ahead and make the whole thing dynamically assigned, which I think is CJ's long-term plan for all the built-in limits
Way beyond my abilities doing something like that! Hopefully this could be done one day; dynamically assigned, that is!
Quote from: proximity on Mon 11/04/2011 19:20:2031x8=248 sprites for one room, just walking. If you have 20 rooms for example, walking sprites take 4960 of 30K.
Unless each room uses different sprites, the number of rooms is irrelevant; why would additional rooms add to the player character sprite count?
Quote from: Khris on Tue 12/04/2011 00:07:48
Quote from: proximity on Mon 11/04/2011 19:20:2031x8=248 sprites for one room, just walking. If you have 20 rooms for example, walking sprites take 4960 of 30K.
Unless each room uses different sprites, the number of rooms is irrelevant; why would additional rooms add to the player character sprite count?
It would if the perspective were changed for each room.
But really guys, my question is this:
*Why are you using AGS for this?*
Use wintermute and make an actual 2.5D game.
It's absurd to go through all the trouble of making and animating 3d models to then render them down to 2D and lose all the lighting and perspective information that youve gained.
Also, 60 fps? Unless I'm very much mistaken, AGS only runs at 40 cycles/second, so that's a waste of time and sprites.
You can use SetGameSpeed() to change the frame rate (provided the system is fast enough to handle it), but for normal use, it's an overkill for adventure games.
For 3-D games though, higher frame rate may mean smoother animation (provided the system is fast enough to handle it).
40 fps is *just* enough for basic point-and-click games to not feel unresponsive - even then gradual camera pans or fades work much better at a slightly higher framerate. The actual need for more than 40 fps, however, arises as soon as you include any kind of arcade sequence into your game (as is the case in my game), try playing any kind of action/arcade game capped at 40 fps (a shooter, a platformer, a real-time strategy game or anything like that) and you have to admit it is not really playable/responsive at all. Games that rely on quick reflexes usually run at 70 (vsync on) or, even better, 100 frames per second without vsync - for a very good reason.
I don't know why Proximity multiplied his sprite-needs by the number of rooms but my calculations don't do that and also show the need for an increase anyways so no need to focus on his (I assume) mistake.
Rendering 2D sprites from 3DS Max is a super common technique that has a similar history to that of pixel art, Calin. In fact, some adventure games even today use the same technique as it still allows for more detail on characters and a much wider audience (they don't need kick-ass systems to display the millions of polygons you need to render a 3d character with the same detail as a 2d one).
Lighting information is not necessarily lost, you can bake some awesome lighting (including the ambient occlusion term) into your models that would otherwise be either impossible to correctly calculate in Wintermute or any 3D engine or, once again, require some kick-ass end user systems. There's a ton more reasons why using a 3d program to render out 2d sprites is a legitimate way to create game graphics, it really isn't 'absurd' one bit. For your reference, I could call working hours on pushing pixels around absurd (but I won't because I understand and love pixel art as well :p ).
I did some calculations before and it looked like I was going to hit the limit, too, but then made some tests and realised if I just rendered every 3 frames I'd be fine with some room to spare, and the result is also more "hand animated".
If you're proficient in 3D modeling, animation, and rendering, you might as well go that route. I can set up a shader perfectly and render it out to 2D, not having to rely on whatever half-assed solution there is in e.g. Wintermute.
Ideal would be a full 3D framework for Unreal, or Unity, but until we get that, this is the next best thing for some of us.
As Calin said, i use different perspectives for each room and character views and sprites have to be different to be looked physically correct angle and lighting . Calin also has a good point there that why don't we use another engine.
I will explain my personal reasons why i continue with AGS. There are great 3d engines like DX Studio and Unity3d to make 3d adventure games. Because of 5 reasons i don't want to use them.
1- If you make commercial games using them, you pay lots of money as a licence fee. AGS is free.
2- When you export your skeleton systems of your characters from 3d Studio Max to a 3d engine, it causes some technical troubles and some character animations don't look right.
3- You can't use high poly 3d models in 3d engines because they use lots of RAM. Even if you use, your game has no more than 10 FPS.
4- I'm really used to AGS scripting so i don't know if i want to learn other engines' scripting languages.
5- You can't use 'indirect illumination', 'displacement', 'refraction', 'caustics' features in 3d engines, so your game's graphics will eventually look bad if you are not a professional artist.
AGS has too much missing features compared to 3d engines but they don't bother me, except 30K limit ;D
I would say I choose to render in 3d for the same reasons...however, Im also crazy enough to draw over the 3d renders frame by frame to make it look more painted...
In my opinion though, I dont think every frame needs to be rendered at 29 or 30fps, I got good results at around 15 or less, depenfding on the anim.
As for the perspective changes, that is something I also thought of doing, but my main character has so many animations/different clothes/ages that it would be way too many sprites for 1 character...so for now I chose 1 perspective for the whole game.
If you want/need different perspectives for each room I can see why you'd be better off with a full 3d engine, proximity. :p Personally, my needs are different though and, once again, I presented very reasonable calculations that show that even only 16 characters just with idle, walk and talk animations already are well above half of the sprite limit.
Reducing the framerate of your animations (like going down to less than 25 fps where it will start looking choppy) is a matter of style, it might look good in a more cartoony setting for example (or as David Ostman and General_Traitor both mentioned, a handdrawn or painted look). I'm working in a realistic setting though and I'd really like fluid animation. I think AGS should deliver.
I assume changing the sprite limit isn't as trivial as it could or should be and I respect that. Just asking for a little heads up on if we can ever expect a raise (in the near future).
Well you will need CJ or one of the AGS developpers to answer the question of raising the limit or even making it dynamically assigned. If you PM'ed then you will eventually get an answer.
Just in case the request isn't accepted, you can rely on people here to help you find a workaround, like the one we were discussing earlier, and make the process as painless as possible for you by providing code, suggestions etc :-*
Just one thing, I wonder if having like 60k sprites in one exe would alter the performances compared to 30k, but regardless of the method or the difficulty involved, I think it would be nice to split the resources.
Regards
Quote from: Sephiroth on Thu 14/04/2011 06:18:19
Just one thing, I wonder if having like 60k sprites in one exe would alter the performances compared to 30k, but regardless of the method or the difficulty involved, I think it would be nice to split the resources.
Regards
As far as i know, AGS loads sprites only the game needs in real time and delete them from memory when they are no more used. I don't think any PC has at least 1 GB RAM would be affected no matter how many sprites the game has.
If sprite limit won't change in the future, i think General Traitor's same perspective for each room and reducing frames ideas may be solution to make a long game, and you shouldn't have very much NPCs though :)
Quote from: dkh on Sat 09/04/2011 11:57:36There's much more involved in that approach than just inventory items and global variables. What if I want to make a change in the interface? I have to remember to open and make the change every game. What if I want to change the player walk animation a bit for example? Need to commit the changes multiple times and test run every game individually to make sure it is all 100% in sync still.
I should have said global variables and settings. You wouldn't necessarily need to commit temporary changes to every project, only to those that they would be relevant to. Besides, how many project files are you planning to need here, really? The idea, ultimately, would be to try and create a template with your basic interface and such to prevent having to make later changes as much as possible.
If you did change the global script, or any shared modules, you could simply copy/paste the ASC and ASH files and overwrite the existing files. Some resources, such as GUIs or Characters can always be exported/imported if permanent changes are required.
As for testing, you wouldn't need to test each game individually. Simply commit some change to the global script for debugging purposes to load a specific game.
Quote from: dkh on Sat 09/04/2011 11:57:36What about translations? I'd have to save the user selected translation as well and then find a way to start the next game with that translation.
That would fall under global settings, which as you said, need to be saved. It would be saved to the data file when a new game is loaded. You can then simply use Game.ChangeTranslation to persist the translation change..not that hard.
Quote from: dkh on Sat 09/04/2011 11:57:36What about room variables holding whether or not some door was opened or whatever? Needs to be saved.
That has to do with your organization. Are you really going to need to go back that far through your game? If you really need room variables to be persisted between projects, you could simply save those variables (globally) to the data file, they could be read into a global structure persisted across all the games. It's not really that difficult, RickJ did exactly this in the MiniGame module. I still question whether or not you need more than 30000 sprites for a single contiguous segment of your adventure game. But yeah, it could be done pretty easily.
Quote from: dkh on Sat 09/04/2011 11:57:36The game options (music, sound fx, speech and ambiance volume levels, text reading speach, voice enabled, gamma and so on) all gotta be saved.
Right..game settings. Forgot to make a distinction there.
Quote from: dkh on Sat 09/04/2011 11:57:36Plus it makes it very easy for people to modify those textfiles and cheat.
Uh..no.
First off, the "text" files wouldn't be written in plain-text at all. They would be written out by AGS. If you're really that paranoid, you could encrypt the data too. Then, on top of that, the data file would only exist while you were switching between game files. The data would be saved, the new game loaded, data loaded, and the data file deleted. Not a lot of time for the user to try and modify it to cheat.
Quote from: proximity on Sat 09/04/2011 15:16:09...and what if a clever player tries to open second game in the folder ? He would start the game not from the beginning, from the half of it. monkey explained it well but i still have suspicions someone manage to break it.
Sorry, but if you even remotely think that this is a real, viable concern, then you have absolutely no business using AGS, period. The method I suggested was to check the game.previous_game_data variable in game_start. The only way that would be non-zero in game_start is if the game was launched via RunAGSGame, otherwise it would always be zero there. So if you're suggesting that a user might go out of their way to create a custom EXE in AGS in order to load the separate game file without having to go through the rest of the game, and then might miss out on a portion of the game because they did so, well, that's pretty much their problem by that point, isn't it?
If it really bothers you that much, you could pair that with checking for the existence of the aforementioned data file, which would only exist if your game created it. Then, as an additional step, you could abort if the format of the file was invalid. So at this point the user has essentially had to recreate a significant portion of your game's framework in order to launch the other game files.
By this point, if you're still concerned, I'm really interested what you're doing to prevent the user from using Print Screen (or more advanced screen capture software) to steal your graphics, or prevent them from using sound recording software to steal your audio. Seriously, this doesn't even remotely sound like a serious concern for me.
It's not as simple or as friendly as the proposal to increase the limit, I've already said that, but it's not nearly as difficult as some people seem to think. Once you're actually doing it, it becomes comparable to the rest of your project development flow.
Another concern that has come up (not necessarily here) is save games..I'd just like to point out that given the aforementioned data structure and temporary data file, you wouldn't have to create your own save game system. The script state is saved already, and save games are shared between game files in the same folder (provided they have the same save game directory set of course). The correct game file is automatically loaded when you load a save game.
I never meant to suggest that this was a fitting solution for everyone, but as a viable workaround until the limit can be increased, I still hold that it fits.
As I also pointed out, the limit is embedded in the engine, it's not something that can just be increased by the editor.
Okay, to shorten the discussion: we both agree that working around the 30k sprite limit using more than one actual game is 100% possible in every way. I say, however, the workaround itself is so daunting, adds so much dead weight to the development process and opens so many holes for possible bugs and problems that, in a large-scale project (!), it simply isn't feasible - it's technically possible but unrealistic with the constant need to update interfaces, characters, rooms and scripts and the need to keep all versions between games 100% in sync (making any of these once and turning them into templates is a great approach in theory but, in my amateur experience working on big projects, absolutely unrealistic).
To the voices that still doubt it's reasonable to go over 30k sprites in a game, once again, I have presented calculations that show who and how I'm going over the limit. If you see anything wrong with these, let me know. From my time working on tons of adventure games using pixel art, 30k sprites indeed sounded like WAY enough and I never came close to it once. This project, however, is different due to the workflow of rendering 2D art from 3D models, working together with an actual professional senior artist at a medium-size American game development company who is able to put out wonderful, richly-animated character art. Somewhere between 32-64 frames per walking animation loop is not overboard with these specs at all.
I'm not contesting that the 30k sprite limit presents a problem for the scenario described, but I do question how much of it is necessary to have access to at any given time that it would become such a logistical problem to work around it.
Again, I wasn't saying this was an optimal solution, I never did..I just wanted to elaborate on the technical feasibility of it.
As far as using 3D models..why the aversion to using the 3D plugins that would allow for 3D backgrounds or characters? That's what I don't get really.
Looks like we're on the same page really. :p Both agreeing on the fact that it is possible to work around but a bit of a hassle. Just me saying it's so much of a hassle I wouldn't want to do it on a large-scale project and you saying the opposite. I can live with that haha!
About the 3D plugins:
(1) I don't know of any AGS plugins that allow for decent quality character rendering and animation (skeletal-/bone-based that is) as well as rendering of backgrounds. As far as 3D plugins go, I'm pretty sure the Razerblade 3D plugin I wrote myself is a pretty good attempt, but it still lacks character animation. It would also require me to re-write a pathfinder and such. Basically resulting in a shit load of work to make it work in an adventure game way (as it is build for shooters and the such).
(2) 3D models and backgrounds either look undetailed or are actually high-poly and make use of shaders and then require the player to have a kick-ass system. 2D can show a lot more detail with a lot less processing power.
Quote from: monkey_05_06 on Fri 15/04/2011 21:31:05
As far as using 3D models..why the aversion to using the 3D plugins that would allow for 3D backgrounds or characters? That's what I don't get really.
Because plugins you mentioned or any other 3d game engines don't provide quality graphics compared to pre-rendered. They just provide plain lighting and shadow systems which can never compete with 3d Studio Max. Additinally, don't forget anti-aliasing and texture filtering issues. In fact, there is a solution to that called "texture baking". It is an illusion that displays pre-rendered background images in real time render to make viewer think background is illuminated real time. I'm not defending anything against your question, i just told that as an info.
I don't want to be misunderstood. I respect you monkey_05_06 and grateful to your helps. I don't want to be seen a trouble maker, i'm just asking questions about things that i don't know. Obviously you have a deep knowledge of programming and nobody can say the opposite. I just wanted to know whether this limit is removable or not and i got the answer thanks to you. I think discussion about sprite limit will be useful to anyone who wants to make a game with lots of sprites, and thank you for joining discussion to share your experience and knowledge.
I came up with an old school idea. Do you remember Flashback ? The game was giving player passwords between levels and if you start a new game and type any pass given, you would continue the game from beginning of desired level. How about we adapt it to AGS.For example, divide your game to 5 with each one has 30k sprites. Give player a password at the end of each section and if the player starts next section, he must type correct password to continue game. What do you think ?
There is only a small issue about it. Passwords you give should be random in case player find it from somewhere i.e. internet. Is it possible to make some plugin-module about creating random passwords between sections ? I think sections should be connected to each other somehow to recognize passwords. If it is not possible, it is still a good idea don't you think ? You wouldn't mess with variables at least.
Okay, fair enough, it just seems to me that if you're making each room have a different perspective,!having to use simulated versus real-time lighting, and the sheer number of renders you're doing to get a smooth animation that it would save a lot of time and trouble to just use actual 3D. But then I guess that's sort of like comparing modularizing every idea that pops into my head to actually making games. :P
Of course I have no aversion to making games, or to specialized code, but if a bit of extra effort on my part can help others then why not? I'm sure the same principle applies to your time spent modelling and rendering in order to get the ridiculously high quality graphics you want.
So, all good there. I think CJ said somewhere that he wants to make a more streamlined way for contributors to make changes than just having a bunch of people checking in random changes that the community as a whole, or perhaps even just that he as creator of AGS don't necessarily want. I bring that up coz unless I'm mistaken he also said he wants to take care of that organizational step before releasing the editor code. The tie-in being that unless CJ does it himself, an increase in the sprite limit would have to wait until the editor source is opened up (that is unless someone knows something I don't and has just failed to correct me in believing that the sprite limit is linked to the engine :P).
Yeah, I don't really expect an increase any time soon either, unfortunately. Oh well! Might force my project into episodic releases but that doesn't have to be a bad thing I guess.
And unlike TellTale's episodic releases, you could even make it so that if they're "installed" to the same folder, they could be loaded directly from within each other! :D YAYYY!
Forget about episodic releases dkh, use my idea ;D Divide your game into sections. Give a password to player at the end of each section to play next. I will do it that way so i can have 100 K sprites easily :) Player can't know password unless someone tells him :)
This way you don't split your screnario which shouldn't be indeed.
The limit could easily be increased to 32767 sprites, but the problem is that the AGS Engine internally uses a 16-bit int in various places when dealing with sprite numbers. So to raise it higher than that or remove it completely, would require the engine to be changed to use 32-bit ints for sprite numbers.
So basically, yes it can be done, but it's a non-trivial change.
Quote from: Pumaman on Sun 17/04/2011 15:55:41
The limit could easily be increased to 32767 sprites, but the problem is that the AGS Engine internally uses a 16-bit int in various places when dealing with sprite numbers. So to raise it higher than that or remove it completely, would require the engine to be changed to use 32-bit ints for sprite numbers.
So basically, yes it can be done, but it's a non-trivial change.
So do you have plans to change the engine to 32-bit ints in the future ? I don't care how long it takes, i would be very satisfied even if you would do it 3 years later :)
This is probably something that could be tackled by someone when/if the engine is open-sourced. Personally, I'd like to go in and make all the limits dynamic just to end the limit issue once and for all.
QuotePersonally, I'd like to go in and make all the limits dynamic just to end the limit issue once and for all.
...keeping my fingers crossed!!
Quote from: ProgZmax on Wed 20/04/2011 04:24:53
This is probably something that could be tackled by someone when/if the engine is open-sourced. Personally, I'd like to go in and make all the limits dynamic just to end the limit issue once and for all.
Wonderful ! I'll be waiting that day :)