[EASY | MEDIUM | HARD] The Monolithic XNA4 Spec Thread about fna-mghistory HOT 16 CLOSED

While I haven't actually done any changes here, I did write a quick little program that uses reflection to attempt to find all surface API differences between XNA and FNA. You can find the source code and my results in this Gist: https://gist.github.com/nickgravelyn/9d4c966fdcf747aa8f56. Not the cleanest code but it works. The results text is a bit namespace heavy, but does the trick and should be a decent starting point as to the gaps in parity.

Edit: Just realized I only checked the x86 GAC and missed a few DLLs. Going to fix up the code/results and update the Gist.

Edit 2: Updated the Gist. It now runs against all the XNA 4 Refresh redist DLLs in the x86 and MSIL GAC folders.

from fna-mghistory.

A few months ago I added TextInput functionality to FNA/MonoGameSDL. Should this be updated to TextInputEXT (Along with the TextInputEventArgs -> TextInputEventArgsEXT)? XNA has no such functionality.

from fna-mghistory.

Yeah, we'll want to add EXT to those. (By the way, been using this with Skulls of the Shogun, works great!)

from fna-mghistory.

Just spent a bit of time getting rid of the types that were "extra" in FNA (as in, not extensions). At this point it should now just be down to the ContentReaders, TouchPanelState, MonoGameJoystick types, and extensions. Maybe there's a chance that those content readers are also extra and can be removed? I can totally see that TextureReader being useless, for example, but the stuff like Array/List/Enum seem like they'd be available in the content pipeline, right? The content pipeline is the component I know the least about, next to Input.Touch, so I wouldn't know.

There's also the concern of extra methods in FNA, so those will have to be either removed or reviewed as extension methods.

As for the comparison tool (thanks again to @nickgravelyn for that), it looks like the only thing that looks wrong in the output is that it sometimes thinks that FNA is both missing methods/properties, but notes them as extras found. Not a big deal, just adds extra lines to the output.

from fna-mghistory.

Is there a way for us to roll through the XNA libraries and pick out which ones use SerializableAttribute? Since DataContractAttribute was only for WinPhone, I might go back and revert all those back to Serializable for accuracy, but if there's a fast way to get all those classes without digging through the MSDN docs, that'd make things move a whole lot faster.

from fna-mghistory.

I just went through and reverted any DataContractAttribute with SerializableAttribute:

9c43105

But, I'd still like to know which classes/structs should have this Attribute.

from fna-mghistory.

I've made a small repo for Nick's test program, and fixed some things up in the process:

https://github.com/flibitijibibo/XNA4SpecTest

Additionally, I've got an updated copy of the output that I'll try to maintain over here:

http://flibitijibibo.com/fna/SpecMismatches.txt

Hopefully this will help people with finding something to fix. Or, if you want to get meta, you can fix the bugs in the test application itself (and it does have at least one).

from fna-mghistory.

With the magic of the spec test, I've taken out everything that was considered "Extra" in FNA aside from official extensions and the MonoGameJoystick config types*. At this point it's now a matter of implementing things we've not implemented yet.

A lot of the bigger types like the Vectors may be pretty easily solved by copying/adapting the funcs from the other Vectors where everything's implemented, so if you're looking for something easy, that might be one way to go. PackedVector's also pretty easy if you're familiar with the other PackedVector types that are already written.

*- Still excluding Effect/Shader/Net, and for now I'm also excluding Media.

from fna-mghistory.

The Spec Test has been updated for the FNA rebranding. The output will probably include things like SDL2 and OpenAL, but it should only show up as Extra Types.

from fna-mghistory.

Did a fresh build of the spec test using the mojoshader-cs branch, so now we look at Effect mismatches as well:

http://flibitijibibo.com/fna/SpecMismatches.txt

A lot of this is busy work (like the remaining Effect methods), but if you happen to be good at math, this is your chance to shine. I've been implementing a couple of functions for Codename OhGodNo and it's become abundantly clear how little I know about game-related mathematics (particularly the kind that's named by Microsoft). Some choice examples:

https://github.com/flibitijibibo/FNA/blob/master/src/BoundingFrustum.cs#L142
https://github.com/flibitijibibo/FNA/blob/master/src/Matrix.cs#L2063

Some of them (read: the ones that were in D3D9, back when Microsoft still sorta documented things) basically have the code on MSDN, some are just variants of methods we've already implemented for other classes of similar types (like Vector transforms), and the rest are kind of a mystery. I'll let you see for yourself.

from fna-mghistory.

With the Effect rewrite now in master, all folders except Utilities/ are now open for this task.

from fna-mghistory.

Did a bunch of work on this today, my SpecMismatches.txt now fits within a single page!

http://flibitijibibo.com/fna/SpecMismatches.txt

A couple things will probably need accuracy checks later on...

be26ba6

... some are just wholly unimplemented...

5e03a8d
2c54280

... but at least a lot of the busy work of implementing all those overloads is out of the way.

A lot of what remains is the Design converters and some features that we don't even support yet internally anyway (XACT Bank IsInUse property, MultiSampleMask, etc.), but there are still a couple easier ones left.

Two that might be easy to hook up are StorageDeviceNotConnectedException and the Texture2D.FromStream overload. The Design classes probably aren't too hard if you know how TypeConverters work.

from fna-mghistory.

Spent the afternoon on the Design namespace:

https://github.com/flibitijibibo/FNA/tree/master/src/Design

It's not 100% implemented, but the API is there if a project needs it. Note that some of the converters are weird and don't have ConvertFrom, only ConvertTo. For whatever reason this is by design, and as a result the classes that have ConvertTo implemented where ConvertFrom doesn't exist might actually be wrong for whatever reason - I sorta just aimed for whatever MathTypeHelper was supposed to be doing and filled in the blanks based on each structure's ToString() method. Aside from those specific scenarios, it should either work just fine or be blatantly incorrect via explicit Exception throwing.

from fna-mghistory.

I just implemented the Microphone class:

https://github.com/flibitijibibo/FNA/blob/master/src/Audio/Microphone.cs

All that's left is the Texture2D.FromStream overload and @SeanColombo's Touch work, then we should have 100% XNA4 API accuracy aside from the Media components that we can't reimplement.

from fna-mghistory.

Aaaand the Texture2D.FromStream overload is in:

e3ab8bb

Once #331 is complete, we will finally have 100% API accuracy for what's possible in FNA!

from fna-mghistory.

The unmaintained Touch namespace has been removed, and proper support is being examined in #331:

3eac457

With this now considered optional for 1.0, I'm marking this as complete. Only took over a year and a half!

from fna-mghistory.