Mono 1.2.4 released

According to the Mono Project feed, Mono 1.2.4 has been released.  Check out the link as there are lots of improvements.

GraphicsDeviceCapabilities.CompareCaps

Implemented CompareCaps a few days ago, which are exposed via the AlphaCompareCapabilities and DepthBufferCompareCapabilities.  These indicate the comparison operators supported for the alpha and depth buffers.  Their OpenGL equivalents are glAlphaFunc and glDepthFunc respectively.

The implementation was easy, since they were all supported since v1.0 of OpenGL and therefore just return true.

As per MSDN documentation,

Represents comparison capabilities.

Property	OpenGL Extension or Minimum Version
SupportsAlways	v1.0
SupportsEqual	v1.0
SupportsGreater	v1.0
SupportsGreaterEqual	v1.0
SupportsLess	v1.0
SupportsLessEqual	v1.0
SupportsNever	v1.0
SupportsNotEqual	v1.0

MonoXna - what version of OpenGL?

A few posts on the MonoXna groups generated an interesting discussion related to implementing the GraphicsDeviceCapabilities API.  What is the minimum version of OpenGL we should (or even can) support?

There will be a number of features expected of the base Xna implementation, which will not be available in earlier versions of OpenGL. 

So far, from what I can tell we will need

• v1.5 with a significant set of ARB/EXT extensions
• 2.0 with the pixel buffer, and a few other ARB/EXT extensions
• 2.1+

Should we go straight for 2.0 or try to target 1.5?

Altap Salamander 2.5 has been released

I am a long time user of Orthodox File Managers, which can generally be categorised as a two pane view of a hierarchical storage system.  Examples of these include file, registry, archive (zip, rar, etc) ftp, nfs, etc.  I used Far for some time, which has a fantastic plug-in model, but was not progressing.  I changed to Salamander 2.5 Beta well over a year ago, and have never looked back.  Now that it has been released, you can pick it up for $30 USD.

Whilst Far is somewhat nostalgic of DOS file managers, like Norton and XTree, we live in a world of WYSIWYG, and I find character mode doesn't cut it when previewing files.  This is where the move to Salamander was welcomed.  It's still missing features a loved in Far, but if Altap ever release their SDK, I'll be the first to jump in.

 

For OSX I have been experimenting with Disk Order 2.5 - it still has a ways to go, lacking many of the standard key strokes one expects from a 2 pane file manager, but is by far the best option on the Apple platform today.

GraphicsDeviceCapabilities.BlendCaps structure

As per MSDN documentation,

Represents the supported blend capabilities.

There are 14 capabilities for this structure, as follows

Property	OpenGL Extension or Minimum Version
SupportsBlendFactor	V1.4 || ARB_imaging
SupportsBothInverseSourceAlpha	V1.0
SupportsBothSourceAlpha	V1.0
SupportsDestinationAlpha	V1.0
SupportsDestinationColor	V1.4
SupportsInverseDestinationAlpha	V1.0
SupportsInverseDestinationColor	V1.4
SupportsInverseSourceAlpha	V1.0
SupportsInverseSourceColor	V1.4
SupportsOne	V1.0
SupportsSourceAlpha	V1.0
SupportsSourceAlphaSat	V1.0
SupportsSourceColor	V1.4
SupportsZero	V1.0

If these are not correct or you can help fill in the blanks, comments are welcome.

Tao 2.0 and SDL.NET 6.0 released

Great to see that Tao 2.0 and SDL.NET 6.0 were released over the weekend. 

The pre-release versions are currently in use by MonoXna, so I look forward to updating to the released versions as soon as possible.

GraphicsDeviceCapabilities.AddressCaps structure

As per MSDN documentation,

Represents the texture addressing capabilities for Texture structures

There are 6 capabilities for this structure, as follows

Property	OpenGL Extension or Minimum Version	Notes
SupportsBorder	GL_ARB_texture_border_clamp	Gets a value indicating whether the device supports the setting of coordinates outside the range [0.0, 1.0] to the border color.
SupportsClamp	GL_EXT_texture_edge_clamp	Gets a value indicating whether the device supports the clamping of textures to addresses.
SupportsIndependentUV	Unknown	Gets a value indicating whether the device can separate the texture-addressing modes of the texture's u and v coordinates.
SupportsMirror	GL_EXT_texture_mirror_clamp	Gets a value indicating whether a device can mirror textures to addresses.
SupportsMirrorOnce	GL_EXT_texture_mirror_clamp + GL_ATI_texture_mirror_once	Gets a value indicating whether a device can take the absolute value of the texture coordinate (thus, mirroring around 0) and then clamp to the maximum value.
SupportsWrap	Unknown	Gets a value indicating whether a device can wrap textures to addresses.

If these are not correct or you can help fill in the blanks, comments are welcome.

GraphicsDeviceCapabilities and OpenGL

Part of the process of implementing GraphicsDevice and GraphicsAdapter involve a number of related classes.  The first I'm going to tackle is GraphicsDeviceCapabilities.

As per the MSDN documentation, this class represents the capabilities for the hardware.  It is made up of no less than 18 structures, defined with the GraphicsDeviceCapabilities class definition.  I expect I may run in to a few cross platform issues whilst implementing some of the queries, so it will be an interesting exercise.

Over the coming days / weeks / whenever, I'm going to document each structure as a separate article and on the Mono.XNA groups as to how I've obtained the capabilities, with references to articles, etc - hopefully garnering feedback from the Mono.XNA team and other OpenGL / DirectX experts.

I've also created a page on the mono.xna discussion group, to track and document our implementation of the various GraphicsDeviceCapabilities structures.

C# partial classes and file naming conventions

I find that partial classes in C# have more uses than just the automatic .Designer.cs created by numerous designers in your IDE of choice.

In certain scenarios, I will create partial classes and use multiple files.  I consider the [Class Name].cs as the primary file and [Class Name].[Name].cs as the satellite files.  The name is up to you, but should succinctly indicate the function and preferrably is one word.

I've found in practice it has worked very well, with regards to maintenance and reducing the time to understand a class.  I've been using this convention for a while, and felt it was time to review, given a few ideas I've been tossing around.

Currently I only use it for classes that are large enough to warrant separating out functional areas.  Additionally, if the class implements a complex interface or a related set of interfaces I may move these to a separate file.

I consider this is appropriate for larger classes and therefore you would always start off with a single file and as your implementation grows, reconsider if it is worth separating.

• Limiting the public interface of the class to the primary file, so it is very easy for a developer to view the file and determine the public API
  • Move protected and private members to a separate file
    • [Class Name].private.cs
  • When a class has a significant number of private and protected members, separate as
    • [Class Name].private.cs
    • [Class Name].protected.cs

I know regions can provide similar functionality, assuming your editor supports outlining, but I tend to see them either overused or not at all.  When viewing a file in [insert simple text viewer of your choice], regions provide little value.

I usually limit regions to:

#region private fields
#region constructors
#region public members
#region protected members
#region private members

Thoughts?

GamePad and Color implementations for Mono XNA

Just posted some updates to the repository tonight, now that I have write access.  This is really going to help me, in moving things along whilst I have a little time to contribute right now.

• GamePad
  • As previously mentioned, GamePad has a preliminary implementation of the two dead zone algorithms now
  • Unit tests (where possible) have also been submitted
    
• Color
  • The initial source appeard to come from the System.Drawing namespace in the mono implementation of the BCL, so it was a little heavy for XNA.  I've submitted a revised versions that is greatly simplified and is now 100% complete, with associated unit tests.
  • These unit tests helped me figure out a few things about the MS implementation, including the fact that Vector3 / Vector4 conversions use rounding rather than truncation.

I've started work on GraphicsDevice and Graphics adapter, but these will require acquiring a more thorough knowledge of OpenGL.  To assist with this process, I've ordered the Red Book and OpenGL Distilled. 

Update: I've added the OpenGL: Reference Manual to that order

I'll post some discovery in the coming days.