CMP Editor
-
**What model did you load? I’m only getting 393 megs usage without a model loaded….
Loading up the bretonia battleship it went to 409 megs.
The bottom black box will show the mesh if you select a ‘VMeshRef’, it will show a texture if u click on an image node ( MIPS, MIPx ).**
-
i rechecked again with no model loaded started up around the same (just over 1.7gb)
-
Ran it on my laptop, same result. It used a little less memory since it is a XP machine. It only has a 1/2 gig of mem as well.
-
I get the program can’t start because d3dx9_41.dll is missing from my computer. I assume that’s because I’m running Windows 7, though.
-
Run the latest dx redistributable to fix that…
-
It’d be nice if you could press Enter in the scale edit; it would be very nice if Exit wasn’t default.
It seems you’re both right about the memory usage. With no file loaded, I get 1.7G virtual memory with a working set of 383M.
Your copyright year is still 2008.
Are any of the script exporters working? Not much good being able to import a VMeshRef script if you can’t first export it.
-
**This is why I released it to be tested. The memory thing is the max amount of memory set aside for the program. The working set is what the current memory usage is…Unfortunately the size of some of the FL files caused me to set it that high, the dfm files for example.
The buttons can be edited to make those as default button, not a problem.
Check in the program folder/Output to see the exported scripts. All scripts are text files.**
-
Oops, my mistake. I ran it as CMP_Editor_0_001\CMP_Editor.exe, so it created Output in the current directory, which explains why CMP_Editor_0_001\Output was empty.
The Freelancer I have running now (sitting outside Manhattan) only has a virtual size of 245M, with a working set of 133M. Why can’t you use dynamic allocation? I noticed from that VMeshData code you posted you use very big variables. Shouldn’t you be doing something like this.
// This is bad. struct Type1 { //... Type2[A_REALLY_LARGE_NUMBER]; } Huge_var; // This is better. struct Type1 { //... Type2[0]; // or 1 if your compiler doesn't allow it } pVar; pVar = (Type1*)malloc( sizeof(Type1) + count * sizeof(Type2) ); -
**Do you mean the floats? If so that is standard float values, nothing special. They are 4 bytes in size. Each one has 10 digits of precision simply from the way it was formatted. You can simply replace anything such as 1.0000000000 with 1, my code knows its a float.
As far as using dynamic arrays, it would take nearly a year to rebuilt all of the array stuff to do that, most of the memory is set aside in my common code classes. The virtual memory is memory that is requested but unallocated until it is used, the VMM in Windows handles that and as long as I don’t go thru it and preset those arrays, it just sits in an allocation table until it’s needed.
Anyways, until the program is complete, understand that there is still bugs in the code, so if you find one, please let me know…**
-
This is a one of my best hope in this year. Is the sur works for the models like stargate or my quirky asteroid?
-
@LS: No, I mean the #define’s you use for the arrays (like UTF_VMDs Mesh[UTF_MAXVMD]). You create that as a global, which has to be initialised to zero. I’m guessing that’s why it takes so long to start up.
But speaking of floats, 10 digits precision is simply too many; floats have 7 significant digits at best.
As for bugs, well, it would be nice if you could recognise alpha in tga. Drawing them the right way up would be good, too (IrfanView also does it upside down, but i.Mage is right). My reference says the words at offset 8 and 10 are the lower left corner, so if that is (0,0) the image should be drawn bottom-up.
