A bug of bitarray?

A bug of bitarray?

Anonymous
Not applicable
1,081 Views
7 Replies
Message 1 of 8

A bug of bitarray?

Anonymous
Not applicable

 

Hi ,guys.Why are there so many problems in 3ds max SDK? Hope someone be able to  deliver me from the trouble.

 

			PolyObject* ply = dynamic_cast<PolyObject *>(obj);
			MNMesh& pMesh = ply->GetMesh();
			MNEdge eg = pMesh.e[stEg];
			int egf1 = eg.f1;
			int egf2 = eg.f2;
			int fcsCnt = fcs->GetSize();
			egs.SetSize(pMesh.nume);
			egsBd.SetSize(pMesh.nume);
			egs.ClearAll();
			egsBd.ClearAll();
			MSTR info = _T("");
			info.printf(_T("NumEgs=%d\n"), pMesh.nume);

			MSTR x;
			int j = 0;
			for (int i = 0; i <egs.GetSize(); i++){
				if (egs[i])
				{

					x.printf(_T("%d,"), i);
					info += x;
					j += 1;
					if (j % 10 == 0){
						info += _T("\n");
					}
				}


			}

 this is a snippet of codes of a gup plugin ,

I declared a bitarray and set all bits to 0 with clearAll(),but after printed the value of the bitarray ,some bits is still 1,why?

how to fix this problem?

thanks

0 Likes
Accepted solutions (1)
1,082 Views
7 Replies
Replies (7)
Message 2 of 8

Anonymous
Not applicable
Accepted solution

Run into the same problem a few days ago. The solution is really simple.

You have to define the WIN64 preprocessor definition to your project as stated in the docs here: http://help.autodesk.com/view/3DSMAX/2015/ENU/?guid=__files_GUID_34ED0855_EEDA_4B15_830E_E6E0FB11F7B...

Message 3 of 8

Anonymous
Not applicable

Thank you very much,it does work.

 

there is an unresolved problem   ,the returned value of a MaxScript function ,published by function publishing system, is always incorrect .

 

To watch the reason ,I put the returned value to a messagebox beforehand ,then compare the value  with  that value returned in maxScript 

 

just like what showed by below picture. Can you help me with this problem? thanks.

 

 

 

0 Likes
Message 4 of 8

istan
Advisor
Advisor
what does this mean? the bitarrays have problems, when WIN64 is not defined?! I must not define it in my projects, as it would create bigger troubles with older PhysX libs. Could you please enlighten me?
0 Likes
Message 5 of 8

Anonymous
Not applicable

thank you ,i have a resolution ,which  is because of wrong returned data type. when i use TYPE_BITARRAY_BV,the problem is fixed.

0 Likes
Message 6 of 8

Anonymous
Not applicable

You have to define WIN64 only if you want to compile a 64bit (!) plugin which uses the BitArray class. That's because of the usage of some preprocessor directives in the class that lead to different code in 32bit/64bit.

 

#ifndef WIN64
    //code compatible with 32bit only
#else
    //code compatible with 64bit only
#endif

 

Therefore you have to either add the WIN64 preprocessor definition to you project settings in Visual Studio (Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions) or insert it directly into the code BEFORE your <max.h> include

 

#define WIN64
#include <max.h>

 

If that causes problems with other libs add #undef WIN64 after the <max.h> include.

0 Likes
Message 7 of 8

istan
Advisor
Advisor
This is sort of interesting, as I use bitarrays a lot and did not define win64 in my x64 plugins from Max9..Max2015. I will have to further investigate, why none of my customers report troubles..
0 Likes
Message 8 of 8

istan
Advisor
Advisor

Ok. Up to 2015 there can not be a problem in bitarray. In 2015 only the Swap() function is different between x32 and x64, which I am not using.

0 Likes