Open source projects and demos
Procedural Texture DLL (C -> C#)
Author
I''ve just updated my procedural texture generator to produce planet textures that map onto spheres with no distortions! The problem is that the code is writen in C# and not optimized at all. So it takes about 40 seconds to generate a 1024x1024 planet texture. I''m planning on generating these textures on the fly in my space exploration game (in a background thread), but I don''t really want to tone down the quality (since I spent so long making the textures look really good).
So I''m thinking that if I rewrote the code in C and optimized the hell out of it (or at least refrain from using 64 bit doubles everywhere), I could improve performance by an order of magnitude. I''m writing my game in C#, though, so I still need to be able to access the functions from C#.
Can I compile a C source file into my C# project? That would be the best solution for me. How do I do this? Examples?
Otherwise, I guess I will have to write a DLL... Which I think I know how to do, except for one thing.
If I have a function called GenerateTexture() that returns a Bitmap object in C#, and I want to put GenerateTexture() in a DLL writen in C, how should I return the generated texture?
Can create an empty Bitmap object in C#, lock it, get a pointer to its pixel data, pass that reference to the GenerateTexture() function, and just have the DLL use that memory to draw the texture on? I think that would be the best way. How do I do that?
Any examples of any of this would be great. I want to keep everything as simple as possible.
As soon as I get this issue addressed, I''ll release the source to my updated Perlin Noise Planet Generator which is general purpose enough to have lots of uses (even mundane things like making webpage backgrounds...)
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Shedletsky''s Code Library:
Open source projects and demos
Open source projects and demos
well, I don't know exactly how you'll pass the info back and forth as I'm not sure what sorts of data types will transfer back and forth (perhaps a GDI handle of some sort??)
What I can tell you is that you will have to look into interop services for .NET. Yes, you will have to write your non-.net code into a .dll ... you can then use p/invoke to call your C function.
reference: http://msdn.microsoft.com/msdnmag/issues/03/07/NET/default.aspx
Good luck,
Joel Martinez
http://www.codecube.net/
[edited by - joelmartinez on April 14, 2004 1:31:52 AM]
What I can tell you is that you will have to look into interop services for .NET. Yes, you will have to write your non-.net code into a .dll ... you can then use p/invoke to call your C function.
reference: http://msdn.microsoft.com/msdnmag/issues/03/07/NET/default.aspx
Good luck,
Joel Martinez
http://www.codecube.net/
[edited by - joelmartinez on April 14, 2004 1:31:52 AM]
Optimize the C# code first. Use profiling, and do some searching to look for common preformance difficulties under .NET
A memory allocation profiler(Microsoft's CLR profiler at here should do) should be usefull for finding unneeded memry allocations. Avoid boxing & unboxing like the plague in preformance sensitive areas.
Microsoft isnt joking when they say that thunking from managed to unmanaged code is slow .
[edited by - ggs on April 14, 2004 8:51:17 AM]
A memory allocation profiler(Microsoft's CLR profiler at here should do) should be usefull for finding unneeded memry allocations. Avoid boxing & unboxing like the plague in preformance sensitive areas.
Microsoft isnt joking when they say that thunking from managed to unmanaged code is slow .
[edited by - ggs on April 14, 2004 8:51:17 AM]
Here are some of my tips while browsing the available sourcecode on your website.
The private struct, ColorPt, in NoiseGenerator.ColorPalette should be a class. Cos you are using boxing & unboxing everytime you access anything stored in the private 'colors' variable.
Casting from an object type to another object type is a shitload faster than boxing(create a new object & copy the data) everytime you access it. Especially considering you use it in a tight loop!
In NoiseGenerator.MainForm.PerlinNoise:
You have the signiture:"private double PerlinNoise(int x, int y)"
But in a tight loop later in the function:
"InterpolatedNoise((double)x * freq, (double)y * freq)"
Change the function signiture to (double, double) and get the caller todo the cast(if at all!)
The current implementation of Delegates is slow , up to 50 times slower than making a interface call, and several thousand times slower than a direct call.
This is easily the biggest hit, calling a a bunch of delegates in a tight loop. With boxing and type convertions as other major issues.
[edited by - ggs on April 14, 2004 8:39:28 AM]
The private struct, ColorPt, in NoiseGenerator.ColorPalette should be a class. Cos you are using boxing & unboxing everytime you access anything stored in the private 'colors' variable.
Casting from an object type to another object type is a shitload faster than boxing(create a new object & copy the data) everytime you access it. Especially considering you use it in a tight loop!
In NoiseGenerator.MainForm.PerlinNoise:
You have the signiture:"private double PerlinNoise(int x, int y)"
But in a tight loop later in the function:
"InterpolatedNoise((double)x * freq, (double)y * freq)"
Change the function signiture to (double, double) and get the caller todo the cast(if at all!)
The current implementation of Delegates is slow , up to 50 times slower than making a interface call, and several thousand times slower than a direct call.
This is easily the biggest hit, calling a a bunch of delegates in a tight loop. With boxing and type convertions as other major issues.
[edited by - ggs on April 14, 2004 8:39:28 AM]
Author
Thanks for the input on code optimization. I have to admit, as someone who knows C/C++ inside and out, I don''t really have much patience for learning how to optimize code in other languages. But .Net seems to be the future, so no doubt it is a valuable skill.
My chief concerns, however, are the floating point ops. I know that the current version of .Net does not optimize floating ops very well at all. This was why I think it would be much faster in C. Plus, if I have to go through contortions to make this code fast by making my C# code look like C code, I might as well have writen it in C in the first place.
Really, I love C#, and it''s good enough for most anything. But it''s never going to beat straight C when it comes to stuff like this.
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Shedletsky''s Code Library:
Open source projects and demos
My chief concerns, however, are the floating point ops. I know that the current version of .Net does not optimize floating ops very well at all. This was why I think it would be much faster in C. Plus, if I have to go through contortions to make this code fast by making my C# code look like C code, I might as well have writen it in C in the first place.
Really, I love C#, and it''s good enough for most anything. But it''s never going to beat straight C when it comes to stuff like this.
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Shedletsky''s Code Library:
Open source projects and demos
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
