Sprite limit problem

[DoorKnobHandle]

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 ).

[David Ostman]

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.

[proximity]

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  

[Knox]

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.

[DoorKnobHandle]

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).

[Sephiroth]

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

[proximity]

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  

[monkey0506]

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.

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.

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.

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.

What 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.

The 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.

Plus 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.

...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.

[DoorKnobHandle]

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.

[monkey0506]

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.

[DoorKnobHandle]

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.

[proximity]

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.

[monkey0506]

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.

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 ).

[DoorKnobHandle]

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.

[monkey0506]

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! YAYYY!

[proximity]

Forget about episodic releases dkh, use my idea  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.

[Pumaman]

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.

[proximity]

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 

[Shane 'ProgZmax' Stevens]

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.

[Knox]

Personally, 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!!