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.
Given my nasty habit of answering my own questions and spamming a million posts in a row, I did enough testing to finish this off:
Step 1: Copy the 3992 kb NOT corrupted version
::Copy is not corrupted
Step 2: DELETE a sound effect that only occurred ONCE in the editor
::Copy is not corrupted
::Memory now displays 3962 kb used; the SFX was 30 kb (roar1.wav)
Step 3: ADD a sound effect that DID NOT already occur in the editor (15 kb)
::Copy is not corrupted
::Memory now displays 3980 kb used; where the extra 3 kb comes from, IDK, but I'll assume its overhead
Step 4: DELETE that same sound effect
::Copy is not corrupted
::Memory now displays 3968 kb used; yet another 3 kb has been added. Looks like each time one is added or deleted, 3 kb is added permanently regardless of size of the file.
Step 5: ADD a sound effect that ALREADY occurred in the editor (7 kb)
::Memory now displays 3968 kb used; this DID NOT add to the total memory
SOLUTION TO PROBLEM:
Many of the sound effects in my game were ripped from the Warcraft III World Editor; they ranged from 50 to 150 kb in size. By deleting several of these, I can reduce the total memory used dramatically, well away from that 4000kb maximum. Then I can replace them with other, smaller, sound effects, and not worry about the game corrupting due to memory issues, just to normal TGF suckage.
Speaking of TGF suckage, the memory from the MIDIS cannot be reclaimed.
CONCLUSIONS:
TGF is capped at 4000 kb of midi/wav per frame
TGF WILL reclaim the memory freed by deleting all copies of a SFX
TGF WILL NOT reclaim the memory freed by deleting all copies of a MIDI
TGF WILL NOT take additional memory for an occurrance of a SFX that already exists elsewhere in the frame
TGF adds 3 kb permanently to your memory whenever you add a new SFX that doesn't already exist in the editor, or delete all occurances of one, on TOP of the normal filesize of the SFX.
Once TGF exceeds 4000 kb, the world asplodes
TGF sucks major balls.
Edited by the Author.
Err and finally; Converting all the WC3 ripped SFX from 22.05 HZ 16 bit Mono encoding to 11.025 HZ 8 bit Mono encoding (1/4 the size for each file) resulted in a folder that totaled 720 kb. Hence the total size of those SFX was ~2880 kb, and I will be freeing up ~2160 kb of memory from my 3992 used.
Hence, you really gotta watch the filesize of the sounds you put in your game. Thats the moral of de story.
after hours of work, I reduced it from 3992 to 2062 memory for sound. I converted tons of files, and replaced well over half of the games sound effects.
Everything worked well
I try adding NEW sound effects (well more of the same ones that already existed in the .gam file)
BAM IT CORRUPTS AGAIN.
Gridquest is effectively dead in the water. I can't add new sound effects to the game or it corrupts, even if I remove all the old ones. For some reason, REPLACING old ones with new ones doesn't make it crash.
Yup this is definitely the issue. Adding even a SINGLE more sound effect to the game, anywhere, will result in corrupted game. It seems there is a finite amount of sound effects you are allowed in the event editor, and I have hit it EXACTLY on the dot. I'll count up how many I have
EXACTLY 512 EVENTS WITH SOUND EFFECTS (512 = 2^9)
its definitely a cap on the amount of calls to the .wav player, perhaps on every object.
Thus when you add a 513th, it crashes.
I am now replacing all redundant sound effect events with flags that trigger that SFX later in the code, dramatically reducing the amount of calls involving the SFX object.
yarr, looks like I should be able to finish it up, I just reduced the amount of events that used the sound player, so I doubt I'll hit 512 again. I posted Blobquest under the DL's in the meantime, so that should be up tomorrow
Advertisement
Post Reply
Edited by the Author.
