[SPARK2] Questions about Graph Entries and SPKObject::copy

Hi i have a questions about the graph entries.How do you access them ? Like theres an addEntry() an clearGraph() but nothing to retreive data (by and index system like get the groups emitter count by index)
(I started implementing my own binary save format . )

Also Copying a System works fine , but if have a class with additional custom data (position , rotation , rendering state of a system and one Ref<System> sys , the program crashes . Here is a small example :

Code:

class CCustomData
{
    Ref<System> SystemRef;
    bool updateState;
    bool renderingState;
    etc...
}

//and a function
CCustomData  * CopySystem(CCustomData * cdata)
{
    CCustomData * newData = new CCustomData ;
    newData->updateState = true;
    newData->renderingState = true;
    //etc...
    newData->SystemRef =  SPKObject::copy(cdata->SystemRef);      // the program crashes at this line
    Systems.push_back(newData);
    return newData;
}

i dont know what should be the problem as anywhere in my code using CCustomData works perfectly.
Thanks in advance !

PS:Maybe adding getUserdata() and setUserdata() to SPKObjects would be a nice feature in future versions.
Regards

Hi,

To retrieve the entries of the GraphInterpolator, there is a method called getGraph which returns a reference on the inner std::set of entries of the interpolator which you can manipulate directly.

For the crash of the copy, are there any log dumped ? Will the crash happen with an empty system (a system with no group) ? I think the easiest way to find the problem is to compile SPARK in debug and see what exactly causes the crash. Sorry about that. Note that I have changed the copy a bit on the svn yesterday, are you using that version or the previous one ?

For the addUserData and setUserData, I wont do it as the preferred way to manipulate system and extend it is to use a wrapper as you did. In that way you dont use SPK::Ref for the wrapper and are free to handle its memory as you want to.

PS : I have edited your title so that readers know we're talking about SPARK 2

Creating a copy of an empty System works.Also i can add groups to this newly created System( i'm using an older version of SPARK2 the version which corrects the DX9QuadRenderer's PARAM_TEXTURE_INDEX )

I tried the newest version from SVN and the DX9Buffer has some invalid member called skipNextTexCoords
so i can't compile it.

oh and i didn't notice the getGraph() because (for some reason) it wasn't listed in the autocompletion box in VS2008 nor in the Code Definition Window. Maybe it's a problem with my IntelliSense...(but the code builds when getGraph() is used)
And as you said i will build a debug version of SPARK2 it will make things lot easier to track...

And about the mem leaks posted in the another topic ...well i'm not 100% sure but it seems it is an OS specific Garbage Collection thing... Spark objects are released , however the memory held by objects is not( at least not immediately) when lot of systems are created and deleted rapidly (like Explosions)

Thank you for the help i really appreciate it !

Ok, thanks for the info.

Maybe you can try to copy a system with no renderer, so that i can know if the bug in the copy is within SPARK or within the DirectX module.

I ll check the skipNextTexCoords thing this evening.

For the memory being still held, yes it is OS specific and even if the memory is freed it can be kept by the process, this is not a memory leak. However if creating lots of explosions make the memory always grow linearly, there is a problem but if it becomes stable after some time it is a normal behaviour.

In SPARK 2 there is a way to trace memory leaks. You need to recompile the lib with the macro SPK_TRACE_MEMORY defined (it is automatically defined when compiling in debug). Then having a call to SPK_DUMP_MEMORY will write the SPARK memory state at that time in a file called SPARK_Memory_Dump.txt at the root of your app.

Thanks for the detailed help , it really helped me a lot ! (And your answer about the mem leak really assured me)
Copying an empty system works however the app start crashing immediately if has only 1 (empty) group.

Hi, I have found the bug in the copy of System and corrected it on the svn. I also fixed the problem with DX9 module compilation. So you can get the latest version on the svn and it should work fine.

Thank you ! You're helping me a lot by using a code that is not yet fully stable and reporting the issues. It helps me identify and fix the main bugs.

Hi Juff Thanks a lot for the correction , and now the copying works fine. Ok now i'm going to build a Debug lib and do few tests. Tested the rapid creation and deletion of systems and after a while the mem usage become stable , so it seems there's no memory leaks !
Regards.

Hi ! I have tested the memory management and it works very well. (didn't find any mem leaks... but not all object tested yet.)

also i find few new bugs :
-The DX9LineRenderer crashes at DX9LineRenderer::create();
-Plane zone acts as Point zone (or NULL zone ?) (and theres also a copy bug when this type of zone is used)
here is a screenshot of the copy bug :
(A System with 1 Group 1 SphericEmitter with Plane zone )




The LineTrail Quad Point renderers works fine.

And is there a way to port the SPARK1 zones to SPARK2 ? (AABBox ,Line ,etc...)
Thanks.

Hi, it seems there's a problem with the direction of the emitter. I have checked quickly and made some tests but havent been able to reproduce the issue. Can you save an xml for both the original system and the copied system and upload them (or copy their content in the forum). You ll have to either register the renderer class your using or set it to null before saving the system :

Code:

SPK::IO::IOManager::get().save("original.xml",originalSystem);
SPK::IO::IOManager::get().save("copy.xml",copiedSystem);

For the zones, i am working on them.
For the plane acting as a point, it is normal for the emission : as the plane is infinite and is defined by a point and a normal, only the point is used for emission. However for collisions it will act as a plane. I m thinking about adding a finite plane to the zones.

Thx

Hi ! There was a mistake in my previous post. it was not a SphericEmitter but a straight emitter that causes the problem... sorry about that

I have saved the files , but it would take too much time to modify my save function and rebuild the dll so i saved the systems with no renderer... i hope you can test it. But i spot the problem in the files :
In the sys1.xml StraightEmitter has the correct direction value saved. but the copy_of_sys1.xml the direction is always 0,0,0

here are the files

sys1.xml
copy_of_sys1.xml

And the Line Renderer... The crash happens exacly when i set it to a group

Code:

Ref<DX9Renderer> renderer = DX9LineRenderer::create();
group->setRenderer(renderer);

Thx

Ok knowing the issue was in the straight emitter, the bug was obvious to fix. I have commited the fix on the svn. Thx.
Apart from that, I'm currently working on new zones for SPARK 2.