Also, you shouldn't use floating point variables for storing time values, since most of the system functions return time values as an unsigned integer. If you convert the system's time values to float, aside from that extra conversion, you're also just throwing away bits of precision, and forcing floating point operations where integer operations would be sufficient (and faster).
XNA's GameTime class uses TimeSpan structures, which return seconds as doubles.
And if that's not it, then it's most definitely because your "float time" variable is not static or global, so it gets set to 0 every frame (or every time you call the Attack() function), and then to the elapsed frame time, instead of accumulating the time since the collision was detected.
Posted by Dave Hunt
on 13 February 2015 - 02:42 PM
Read the comments from Shawn Hargreaves at the end of this article. He answers this question there. Basically, you would isolate the Reach vs HiDef content into separate library projects, so they can be pipelined with the appropriate profile. Your startup code would check for which profile was supported and set the GraphicsDevice accordingly. You would also (obviously) need separate code paths for any features not supported in both profiles.
Also, the belief that Reach is for Windows Phone and HiDef is for PCs is a common misconception. Shawn has pointed out many times (see this article and associated comments) that it's not about Phone VS Other, it's about commonly available device capabilities, regardless of platform. Reach happens to fit Windows Phone quite nicely, but it is also appropriate for many of the older generation video cards. This is because, even though many of those cards supported higher-end features, they all did that in a non-standard way that didn't always produce consistent results across cards. The two-profile mechanism provided a way to guarantee consistent functionality.
If it's a true .NET DLL, then you shouldn't need to do any DllImport at all. Just add a reference to the DLL (right-click References in Solution explorer and click Add Reference...). When the project builds, it will automatically copy the DLL to the correct output directory.
If it's not a true .NET DLL, then you will need the DllImport and you need to manually place the DLL in the same directory as your app's .exe directory. That directory will be under either the Debug or Release directory under your project, depending on whether you're doing a Debug or Release build.
If the DLL depends on other DLLs that aren't in your environment path, then you'll need to either add references to them (for .NET DLLs) or copy them to your .exe directory as well.