DivideByZero error bug while adding sprites

[nightmarer]

Hello.
I'm getting this error while trying to add new sprites to my game. I got backwards many times and tried to add them in a different ways, saving them in smaller packs but I'm getting the same error.

Code: ags

An error occurred whilst trying to save your game. The error was:
Attempt to divide by zero.
If you cannot resolve the error, please post on the AGS Technical Forum for assistance.

Error details:System.DivideByZeroException: Attempt to divide by zero.
 in SpriteCache.SaveToFile(SpriteCache* , SByte* , Boolean , SpriteFileIndex* )
 in SaveTempSpriteFile(Boolean compressSprites, String* saved_spritefile, String* saved_indexfile)
 in SaveNativeSprites(Boolean compressSprites)
 in AGS.Native.NativeMethods.SaveGame(Game game)
 in AGS.Editor.AGSEditor.SaveGameFilesProcess(Object parameter)
 in AGS.Editor.BusyDialog.RunHandlerOnThread()

My acsprset.spr is 4,346,425 KB but I guess that since 3.5.0 there is not limit with this.
I have the compression of sprite file in General settings is set tu True.
BTW, why does the acsprset.spr get 3 times the size of the PNG folder?

Please, let me know if there is a solution. We have working many time in this game and if we cannot go further then we won't be able to finish it.

Regards.

[Crimson Wizard]

BTW, why does the acsprset.spr get 3 times the size of the PNG folder?

Because AGS converts everything into raw bitmaps. Compression fixes this to certain degree, but its not ideal, especially not for sprites with many colours. (Compression is RLE which works best for limited palette)
BTW, this is the first time I hear about AGS game where compressed sprites exceeded 4 GB. I fear that will really be a test of AGS capabilities, both as a tool and a runtime engine.

To be honest I do not know what to answer on the problem itself. I'd have to test 3.5.0 to see how it works when sprite file is above 4 GB. My only guess right now is that there's some remaining piece of code that was not updated to support large values.

Could you also tell, how many sprites in *numbers* do you have?

[nightmarer]

We had more than 35.000 sprites so far, so we guessed than we had enough left to finish the game.
We are sad because we did't know we were reaching the top so close to the end.

[nightmarer]

32470/90000 sprites
845 sprites folders
446 views
14 GUIs
56 characters

[Crimson Wizard]

I will check this out, there might be a way to fix this.

In the very worst case, there's a workaround to put image files in the game folder (or subfolder) and load them up into DynamicSprites in script.

[nightmarer]

Hello.

How can I use dynamic sprites in order to asign it as a view into an object in a room?

Regards.

[Crimson Wizard]

How can I use dynamic sprites in order to asign it as a view into an object in a room?

You create a dynamic sprite, store it in a global variable of DynamicSprite* type, then assign like oObject.Graphic = myDynSprite.Graphic;

If you are assigning it to an object or character with a view, then you need to set it to particular ViewFrame:

Code: ags

ViewFrame* vf = Game.GetViewFrame(view, loop, frame);
vf.Graphic = myDynSprite.Graphic;

If you have alot of these, or need to fill whole loop or view with dynamic sprites, it may be worth to create an array of DynamicSprites instead, and do this assignment in a loop, for simplicity sake.

[Crimson Wizard]

Meanwhile I did a test, been importing very large images into the project until reaching 5 GB. There were occasional crashes because AGS kept running out of memory, but this may be because the sprites themselves were so big that it became impossible to accomodate all the newly imported ones before they got saved. Nevertheless, I got a kind of working project with 5 GB of uncompressed sprites.

Then I switched to compressed sprites and kept adding again, and the error actually reproduced at around 4.3 GB. So this is something related to compression. I will continue investigating.


EDIT: Ah, I am sorry, there's actually one place where I missed to update the variable size, it's might be what breaks at over 4 GB file.
I must make another patch to 3.5.0.


EDIT2: Also, I really recommend to check out all your game sprites, or maybe take a backed up version from before you got this error, because apparently when this error happens there's certain chance that editor wrote a faulty data into sprite file. At least this is what happened to me couple of times during the test.

[Crimson Wizard]

There's an Editor build with a fix that may be acquired here: https://cirrus-ci.com/task/5493593751158784
(you may choose to download either an installer or zip archive)

Would you be able to try it out? I suggest doing this on a project copy if possible to keep things safer, but I tested it on dummy project with lots of big sprites.

[nightmarer]

Thank you in the name of my whole team for your help and being so fast.

We are going to test your solution.
We will provide you feedback about it asap.

Kind regards.

[Crimson Wizard]

I noticed your game production thread: https://www.adventuregamestudio.co.uk/forums/index.php?topic=58589.0
Is this the same game that has this problem?

What I wonder, what is the game's resolution and are all these cutscenes seen in videos made from sprites? Reason I ask is that 4+ GB of compressed sprites sounded way too much, so thought maybe there are also ways to reduce that by replacing long animated cutscenes with Theora videos for example.

[nightmarer]

Yes, this is the same game that has the problem, but also we are developing a second one in bigger resolution that reached that problem aswell (not yet annonced).
Black Rain is runing in 320x200. Yes, these cutscenes are made from sprites. We discarded to do it by video, because the result is not the same. When we switch from video to sprites we notice the difference.
Our other project it is 640 x 400. BTW, I entered new sprites to this last project and I didn't get that error anymore. Now the acsprset.spr file is 5,9 GB.

Thanks and regards.

[Crimson Wizard]

Black Rain is runing in 320x200. Yes, these cutscenes are made from sprites. We discarded to do it by video, because the result is not the same. When we switch from video to sprites we notice the difference.

Well, ofcourse there will be differences (depends on video compression), but using video may significantly reduce your game size and system requirements.

This is ironic, only recently someone was arguing that we should not have raised these limits, because game developers will begin to create unoptimized games, and now I actually feel guilty about it. Maybe we should've worked more into better video streaming support and similar things...

[eri0o]

We read bitmaps instead of png to prevent lags, but maybe png->bmp on spritecache wouldn't lag as much since the second read would be from spritecache which would be bmp already?

CW, we can only manipulate bitmaps, if you want videos, we need a way to hold textures - see the Direct3D plug-in for example. This would allow something like a video background.

Full HD videos can't run fine on AGS currently unfortunately - my experience is things are slow.

Nothing is free though, video players aren't as simple and it's a new thing to maintain and the decoders will take space in the engine - do we want to support Subtitles? Multiple audio streams? Depending on the library used this can be easier or harder to do.

Other thing that takes a lot of sprites is fullscreen effects need to be pre-rendered because we don't support shaders. At least now with blendmodes and unlimited overlays particles can be more fun.

[Crimson Wizard]

CW, we can only manipulate bitmaps, if you want videos, we need a way to hold textures - see the Direct3D plug-in for example. This would allow something like a video background.

We already have persistent textures for everything on screen that are updated when room background or object view is updated. Video playback we have right now works very similar to Direct3D plugin, at least from the first look: it takes the filled video buffer in bitmap format and copies to ready texture. The difference is that ags's one is coded to be blocking and fullscreen. We could make video to read its frames right into DynamicSprite, which is applied to an object, which in turn has a texture, at least this seem as a good first experiment. In the future we could look into e.g. coupling DynamicSprite itself with a texture, and maybe even writing video directly into one if it's possible to match formats.
It seems that the real problem here is making proper API if we want to let them play non-blocking, perhaps similar to audio, as video may need to be run, stopped, paused, etc, also may or not come with an audio, which maybe should be placed on one of ags own channels, and so on.
Except, if we go this route, I'd rather redesign audio API first the way Alan v.Drake was suggesting (I think?), with something like AudioPlayback object returned from Play function rather than a channel pointer; and then design video playback object to match same concept.

Full HD videos can't run fine on AGS currently unfortunately - my experience is things are slow.

The above for instance is 320x200 game, HD video is not necessary in such games. For HD video maybe optimizations are necessary, but that's separate problem and I did not look that far.

Nothing is free though, video players aren't as simple and it's a new thing to maintain and the decoders will take space in the engine - do we want to support Subtitles? Multiple audio streams? Depending on the library used this can be easier or harder to do.

I worked with video libraries before, ffmpeg for instance, was writing realtime video streaming with it.
But again, we could even begin with the one we have right now (ogg theora) and see how much is possible to pull from it.

[nightmarer]

Good morning all.

In the second project we are experiencing new bugs approaching 7GB in acsprset.spr. Yes 7GB, this game is being developed in 640 x 400.
Now it is able to save the project but when you open it back again the project tells you that there are sprites missing, and I had any problem while saving it (just that it takes a while to save it).
I have search for these missing sprites but everything seems to be ok as far as I tested the views, and everything seems to work. I tried to redo it again, and if I delete the last sprites added I go back to normality, but the threshold seems to be now somewhere near 7 GB.
Maybe we are try to do something beyond of what is expected in AGS capacity and it is showing errors where there is no error at all.
Any idea?

Regards.

Update:

Wait, now I am receiving this error when I reopen AGS.

An error ocurred whilst trying to load your game. The error was:

getSpriteAsBitmap32bit: Unable to find sprite 0

If you cannot resolve the error, please post on the AGS Techinical Forum for assistance.

If I restore the backup I go back to a version where it just says that there are sprites missing, but at least now I received an error message.

acsprset.spr >= 6,967,015 KB - OK
acsprset.spr = 6,981,384 KB - It says when opening the project that there are sprites missing, but all the sprotes are there
acsprset.spr <= 6,984,112 KB - It shows the error shared above and it doesn't allow you to open the project.

[Crimson Wizard]

I did not test that far. I could try again and see what breaks ofcourse.

But I'd like to say, all this is rather concerning. There were high-res games (1280x720 and higher) made with AGS before, but I've never seen anyone reporting getting to this much of sprite data size. I am in no position to tell you what to do with your game, but to be honest I think that it may benefit from some optimization. Like, reusing sprites, reducing sizes of animated objects to acceptable minimum, using scaled-up objects with smaller sprites, and so on. Even if engine would be capable of working with that amount of data (and modern engines are), this is just so unusual to see that much in a low-res point and click game...

EDIT: Just making random comparisons:

Thimbleweed Park: 1 GB on disk (not sure which resolution, but it uses oldschoolish gfx style)
Unavowed: 3 GB on disk (this is 640x360 AGS game)
Deponia: 5 GB on disk (high-resolution p'n'c game)
Doom 3: 11 GB on disk

[Crimson Wizard]

I did more tests and successfully reached 7.2 GB (with compressed sprites), with no errors.

I can't tell what exactly is happening in your project. My only suggestion is that maybe AGS Editor is running out of memory because it has to cache alot of sprites, but that's only guess.
To double check, you are using the patched version of the editor to work with this game?

The error saying that sprites are missing means that some sprites were referenced in the project file (Game.agf) but are missing in the sprite file. In theory you may ignore it infinitely or until you find out which sprites are actually missing. The missing sprites are replaced with sprite 0 image to prevent crashes - that is how they may be identified. Unfortunately at the time I did not make editor display their actual numbers in some way, which would be more useful ofcourse. I could maybe add this now in a patch.

The second error, in getSpriteAsBitmap32bit, was already reported couple of times before, and last time just couple of weeks ago:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=38298.0
https://www.adventuregamestudio.co.uk/forums/index.php?topic=58814.0
I think this may mean that sprite file was not saved properly and got corrupted.