Publish shock (again...)

I found out the hard way that the known "memory leak" is much worse then i thought...(23:00 to 8:00 with AI)


Only the published version will crash (without error message or acklog-entry) if you play for at least 5 minutes and reloading the level 5-10 times!
Edit: Note: if you play and respawn if you died, you can almost play for ever. It is the combination of "massive reloading" and "playing"! Never seen it crash without loading of any kind
First of all i hate that the published version of every Acknex project acts different in 1000 ways to the sed start, but sadly thats not new (no matter what warn_level etc).

I tryed everything...i did manage to call level_load only once(thought level_load itself is the problem in combination with shadec), building the map by script manually (yes, terror), managed the nexus by hand via
level_mark and level_free etc...still crashing. Nexus in this project atm 100-150mb max. So no "over 200" b*s*!

I guess the problem is deep in the shadec connection between Acknex and DirectX. Boh's "sc_reset" and "sc_destroy" functions
just dont work(!) if you call them once after you called sc_setup.

It seams not possible to end shadeC evo if it started once...because its engine-pointers are "async" to GPU for one frame.
I tryed to end it with new functions: it always ends in "invalid memory area" or "script crash in sc_forward_destroy / area_sc_reset ....".
It seems to be a fundamental problem with the connection between Shadec and DirectX. I'm just guessing.


The only possible way to use shadeC with massive "world reloading" / level switch seams to use a extern process (like my starter app) to control level switch from outside
of Acknex and hide the whole thing via a loading screen on the desktop.
The only way i see to really clear the "corpses" from shadeC in the GPU: end engine - restart engine in new level/with new content.
Without another process it could be done via exec and -nwnd option i guess...
Anyway...its a ugly hack!


3run did modify shadec evo once, i dont know if he came to the same results. Would be interesting what he modified exactly in his shadec evo verson back then.


Maybe im wrong, but i say ShadeC evo needs to be rewritten from scratch to get rid of this "destroy" problem.
I guess the mastermind Boh_Havoc did not test massive reloading/level switching in a published version. It seams like shadec was only tested like a techdemo in a
single WMB with not much happening around it (will run forever).
edit3: I was genuinely serious about "Mastermind"; I still take my hat off to the performance Boh_Havoc delivered here.

Just wanted to let you guys know.

edit2: Im pretty sure Dead Taste will show this behaviour too, when playing and clicking "new game" 5 times instead of clicking "Respawn" ...or how i called it back then.


If I'm talking nonsense here, I'm grateful to anyone who corrects me.

So i have implemented the "dirty hack"...i have to say...it looks good and works like a charm.
(Engine swap means it reloads itself with other content/same content, not another acknex exe)

Its done via a created file and intern exec. my own starter app checks for this file. if it does exist it shows a loading screen to hide the engine swap.
i also made a security timer, if starter crashes, it removes the loading screen. if user press ESC or click the screen its removed (showing the engine start window if it still exists).
So its "soft hidden" not "malware style" (while progging i locked my desktop XD ...good i had my second screen on).
In window mode it just adds a loading info on top of the engine starter window while still showing it. The engine start window is modified to match the starter app's look.
In fullscreen mode it fills the desktop in black color with a loading info label on top to hide the engines fullscreen switch. Before i exit the game i fade into a black screen,
desktop is already black, new game loads in and fades the black screen out.
If the starter detects an engine swap interruption, it asks the user whether they want to try reloading or not.

The cool thing is, it reloads very quick. only the first start / loading of WRS takes a bit longer.
This engine swap is almost invisible to the user and stable (as long as engine has read/write access on hd...and starter checks for this before starting the game).

This way every click on new games "cleans" the memory so the game can run for ever
And use a lot of content in theory...

I use this starter since Dead Taste anyway, so it's another nice feature.
Starter combines installation (downloading and/or installing of physicX etc), game and video settings and the game launch itself.
A single START.exe with a sub folder (engine files WRS etc).

Small Update

My starter reads the values from the engine starter like the progressbar etc and displays them on the loading screen.

Even outside of lite-c acknex fights back...it is a witch work to get the percentage of the 8bit old school starter window. it only works with Tricks
(Width measurement) because Conitec used a custom class "class_WrProgress - the most efficient way possible".

Now iam trying to do the same thing for the next, so i can directly read the start infos like cancel etc to react even more stable to engine start events.


edit:
I can really only chuckle at this point... everything in Acknex always puts up a fight XD ...even the measly starter text from the custom "class_wrTextF" can't be read out via message hook or RAM sniffing...crazy XD
...okay, so the only option left is "acklog sniffing." Thank god i can get the percentage from the starter...