.net - Framework agnostic struct issue -

this going quite vague question wondering how around issue im facing...

i have many different projects have written while ago have similar framework deal spatial partitioning , sorting, each project has had own version of framework implemented. graphically based applications have implementations in:

• silverlight
• winforms (gdi)
• xna
• directx
• opengl (tao)

although there 5 different versions of framework same thing, accept different objects. example gdi uses system.drawing.point of drawing related tasks whereas xna uses vector2 both objects represent x/y, same other libraries, store x/y values int,float,double @ heart represent same data.

the main job of spatial partitioning framework work off these 2/3 dimensional values , generate trees or other sorting based tasks around these numbers.

im trying unify alot of distributed frameworks single centralised 1 can have single project, tests written prove working ok.

so first thought create agnostic objects deal x/y problem custom point2d, point3d, quaternion, rect etc. have convert them native version rendering, , if each point in each object every render cycle sounds massive performance penalty (especially when framework meant performant possible).

i thinking having interfaces solve problem , wrap native object internally on implementation part, im still not sure if best way go, ive never done cross platform based development never had solve these issues.

anyway stop waffling now, , advice great!

my recommendation implement own maths types , calculations using those. use xna's base. not because they're pretty good, because can open-source implementations of them mono.xna, silversprite or xnatouch. (and of course framework itself, in xna.) saving lot of work.

the major problem can see different platforms use different types. gdi uses integers, xna, directx , opengl use single-precision floats (generally), , silverlight uses double-precision floats.

if wasn't case you'd able assign type identically-laid-out native 1 , depend on jit optimise away.

the nice thing opengl, directx , xna (excluding things spritebatch) tell api data layout - , can use whatever internally.

for gdi , silverlight, you're going struggle ultra-high-performance graphics anyway. take hit of converting float , back. write simple conversion functions when go display data. converting types extremely tiny, minuscule percentage of cpu time, compared rendering.

(i've done silverlight - , really not worth worrying about.)