Lucky for me I had just been backing up my project, but I encountered a TGF glitch thats completely new to me;
When attempting to run the "Load game" loop, it ran out of memory O_O Now I thought its memory was allocated via the computer it ran on, not limited by TGF itself, and i have more room then I know what to do with, but I suppose something pushed TGF over the edge. So as soon as I try clicking on load game, it crashes.
Worse off, the memory appears to be writing over completely unrelated sectors; when I tried loading that .gam file into TGF's editor, I found lots of the coding and animations to be swapped and basically garbled beyond repair. So if that had been my only copy of it, Gridquest would be pretty dead.
But even though I can load an older save file, I'm a little concernicus that TGF is going to run out of memory again. Is there some cutoff on where it dies? Is trying to copy/paste 500kb of .ini files using the file object too much for poor old TGF to handle? Because the only thing worse then a critical error thats going to stop me from developing any further is one thats going to scramble the functional versions of Gridquest. A little sad when a project starts acting up right when ur 95% done with it.
Interestingly, trying to work with the pre-corrupted version seems to be too much for TGF- when trying to do tasks as simple as "Save game as" it will instantly crash. Seems like I just exactly pushed it over its memory cap, and now I won't be able to finish the project.....
not sure if this has anything to do with this cause ive never gotten that messege but sometimes when tgf closes it doesnt kill the process and it hogs memory. when this happens it just crashes mine. maybe that?
Yah some of the unstable crashes will not remove the TGF from your processes list, and it will churn away doing nothing until you manage to ctrl-alt-delete stop it. I've seen alot of those.
In this case, tho, it seems like it completely utterly ran out of a memory space and started writing data into the wrong places. Like if TGF was an array in C set to TGF[1000000], and I managed to write TGF[1000001]- the area in memory its writing to is pretty much random
so as soon as I tried loading up that version, I found several of the tiles to be replaced by random particle effects and a bajillion bosses spawned each time I swung a sword, scaring the crap out of my programming-pants.
I went and copy/pasted my changes between the last version and this one into it one by one, and nothing made it crash. The only code I have been hesitant with in the very last thing I edited before it went so spunky; I added a single 'nother .midi file; while it was only 6 KB, god knows it may have been the last pebble on the bridge before it went poof.
I guess when you consider theres over 7.5 mb of material in a single frame in TGF (not counting externally loaded 5+ mb), its kind of a miracle its been stable thus far
Well ok ive read the other posts now...
damn thats a shame you have pushed TGF pretty hard though.
Just out of curiosity, do you need to be loading all those inis for your game to function?
surely you could come up with a slightly more stable if not efficient method?
Well ingame it only loads one at a time, while during a load/save it copy/pastes an entire 1050kb or so of them from folder to folder, so the only problem I could see is that the file object is being a bit buggy; it should be able to deal with well over a megabyte of data anyway, so I highly doubt the copying is the problem.
At any rate, I certainly have been pushing TGF to its limits; and even with that Gridquest has been amazingly stable- I just tested it through by playing the entirety of the game in about an hour and a half, and in all that time it only crashed a single time. I could rattle off facts and figures about how gigantic the project is, and how much I'm abusing my poor tgf (over 3000 events in a single frame, now) but instead I'll be a little more modest and release it open source I'm thinking, so all the kiddies can dissect it and see what makes it tick
There aren't very many technical klik games open source out there
o yeah and I didn't get any problems after recovering it, so I think I'll be free to keep adding content without the big bad memory limit monster sneaking up on me. Seems just like one of those random "TGF decided to corrupt your game" moments- Thank god for over 850 megabytes of backed up versions.
Edited by the Author.
After some even more extensive testing, I've found this glitch to only kick in right after I try to add a new .midi file to the game. I have a feeling that it has some cache problems with a large amount of music files in 1 game; I already have 25 midis lined up, since I'm not using the DMC or mixer objects to load them externally, and to convert to external loading would be easy to program, but all the filesize already lost to music files cannot be reclaimed without transplanting the entire project.
I think I pinned this sucker down- using the memory tool in TGF it shows 3992 kb allocated to "Sounds" on the working version, and just over 4000 on the corrupted ones. It seems to be that I cannot add any more midi files in the current set up, and I'm going to need to change it to be an externally loading music system instead of internally saved. Looks like whenever it uses a a full metric 4 megabytes, the memory overflows and the project crashes.
does this mean gridquest will finally be nearing completion?
i remember you said something about wanting to redo the graphics when i was testing it.
im still greatly interested in this project
ive heard people say that once a Midi is inside TGF you can't reclaim the lost memory. However i'm fairly sure i didn't ever see that in any of my projects.
It was probably me that said that. I want to change all my midis to externally loading files, which I could easily program, but sometimes they get rather stuck inside the .gam file and refuse to free up the space, even if you delete them. And yup gridquest is about 95% finished; just needs the final boss, tutorial, and intro, and its done.
Cripers I finally managed to transplant the entire game by copy/pasting levels from the storyboard editor into a new one, and it did indeed shed the old music files (though memory usage still says 4mb- must just count sfx). It also crashed TGF about 70 times as I tried copy/pasting, so that was a hell of a fight.
this is some truly unusual crashing. I've found that my game will run perfectly fine from one backup file, loading it as much as I want, but if I simply save it to a new filename, the next time I open it things go buggy and I can't load. Not a single change in the coding. This could all just have been from my TGF editor itself needing a reinstall :X
-_- I can open/load a game as much as I want, but if I run it, the next time I open TGF that game will be corrupted. GOod thing I still got my TGF registration key
Edited by the Author.
Problem persists after reinstallation. Guess transplanting the entire game didn't work out so hot.
After seriously INTENSIVE testing, I have confirmed that the issue is SOUND MEMORY for TGF. Creating two copies of the same, uncorrupted version of Gridquest, I implement the two changes:
Version A: I add 3 new enemy types, all their data and routines, as well as their sound effects
Version B: I add 3 new enemy types, all their data and routines, but leave all the sound effects blank
Bam, version A instantly corrupts, version B stays clean. When corrupted, it experiences extremely annoying crashing problems; about 50% of the time the game starts, it crashes, about 50% of the time I click on load game, it crashes, and about 75% of the time I enter the event or level editors, whether from the storyboard or by returning from doing the in-editor "Play Game", it crashes. Every once in a while, when it crashes, it overwrites game data and various animations get out of place; I've seen animations be transferred from one object to another, and the font of every single text object get changed to a different font/size.
Looking closer, my memory button (the blue (I) in the editor) displays:
Even after adding in the new sound effects, it remains at "3992 Sound Memory", though the times I've gotten far enough into the game without crashing, those sound effects are properly implemented.
Hence I conjecture that TGF is limited to 4000kb of sound memory per frame, including both .mid and .wav files. While I can externally load the midis, the space of the already existing ones cannot be freed again, and I cannot transplant the game because copy/pasting frames results in instantaneous crashing.
If my theory is correct, I'll have to finish the game without adding any new sound effects, although I can now add new music files. If my theory is incorrect, adding ANY more data of any kind may result in a corrupted version. So progress on Gridquest got a little sidelined here :X
A little further testing:
As it says "3992" memory and I theorize it is capped at 4000, I did the following test.
Two copies of the same, non-corrupted version
Experiment A: Add a 10 kb .wav file from the "THIS GAME" menu, save game/exit
Experiment B: Add a 7 kb .wav file from the "THIS GAME" menu, save game/exit
Experiment C: Add a 3 kb .wav file from the "THIS GAME" menu, save game/exit
Experiment D: Add no sound effect, save game/exit
A: Corrupts instantly
B: Corrupts instantly
C: Corrupts instantly
D: Just fine
As such, I believe I cannot add even the TINIEST sound effect via the built-in player.
Advertisement
Post Reply
Edited by the Author.
