Sprite limit problem

Started by proximity, Fri 08/04/2011 21:03:52

Previous topic - Next topic

proximity

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 ?
Proximity Entertainment

DoorKnobHandle

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?

Sephiroth

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

monkey0506

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.

DoorKnobHandle

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

Sephiroth

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

DoorKnobHandle

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

proximity

#7
...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
Proximity Entertainment

Knox

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).
--All that is necessary for evil to triumph is for good men to do nothing.

proximity

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 :



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

monkey0506

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.

Snarky

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.

dbuske

Wow, these games pushing the sprite limits must be some super big and long games.
What if your blessings come through raindrops
What if your healing comes through tears...

DoorKnobHandle

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

proximity

#14
...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.
Proximity Entertainment

Knox

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!
--All that is necessary for evil to triumph is for good men to do nothing.

Khris

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?

Calin Leafshade

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.

Snarky

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.

Gilbert

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

SMF spam blocked by CleanTalk