Metro Status?

Topics: Windows Metro
Apr 25, 2012 at 4:06 PM

I'm new here. I just saw that metro was added to the roadmap.  I downloaded the latest source and see that some work has been done already for metro support.  What is its current status?  Is there any way it currently runs?  I'm just getting into the new metro apis but I have a lot of .net and xna development experience.  I could possibly help with parts if needed.

 

Thanks 

Developer
Apr 25, 2012 at 4:51 PM

hi

The Metro port is in development. Currently it will display a blue windows ( I think) the graphics, audio, content loader etc are all still to do.

TomSpilman is the project lead for the Metro port, he can fill you in on what is being developed and which areas we need people to work on.

Dean

Coordinator
Apr 25, 2012 at 10:03 PM

Currently there are a few areas where people can help:

  • Graphics - Tom Spilman
  • Audio - Bill Reiss
  • Input
  • Video and VideoPlayer
  • Content & Storage
  • Network & GamerServices

Currently the build can initialize Game and GameWindow, can clear the screen, and take some keyboard input.  I'm deep into the shader/effect side to get rendering working.  The rest is not getting any attention yet, but should go quick after I get graphics worked out.

Really there is very little to port to get things working... the majority of the MonoGame code is not platform specific.   It is mostly just #ifdef'ing in an alternate OS call.

Let me know if you decide to tackle any of the unassigned areas.

 

Coordinator
May 1, 2012 at 5:01 AM

Tom, I've got some free dev time at the moment, so I thought I would make a start on some of the unassigned areas.  I'm grabbing the repo now and see if I can get it all compiling and running to a clear screen first.

Coordinator
May 1, 2012 at 5:02 AM

Cool.

Let me know if you run into any issues.

 

Coordinator
May 1, 2012 at 5:53 AM
Edited May 1, 2012 at 6:13 AM

Having a few issues.  I had to fix the references to SharpDX.  The assemblies added to the Libs submodule had Windows and Windows 8 Metro subdirectories, but the project references did not have those directory names.

I have now come across some compile errors.

Error 9 'string' does not contain a definition for 'Intern' D:\Git\MonoGame\MonoGame.Framework\Graphics\Effect\Effect.cs 228 35 MonoGame.Framework.Windows8

Error 13 'System.Array' does not contain a definition for 'ConvertAll' D:\Git\MonoGame\MonoGame.Framework\Graphics\Effect\DXShader.cs 122 38 MonoGame.Framework.Windows8

Error 20 'Microsoft.Xna.Framework.Graphics.GraphicsDevice' does not contain a definition for 'Current' D:\Git\MonoGame\MonoGame.Framework\Graphics\Effect\DXShader.cs 246 44 MonoGame.Framework.Windows8

 

Edit: It's really strange, because I can find the MSDN documentation for Array.ConvertAll and String.Intern, but it won't compile in a Metro project.  GraphicsDevice.Current just seems to be missing.

Coordinator
May 1, 2012 at 6:00 AM

I also found a flaw with our plan to have devs build 2MGFX locally.  VS11 Express supports Metro apps only, therefore it cannot build 2MGFX.

Coordinator
May 1, 2012 at 6:20 AM

Also, what does your test app code look like?  Did you create a new Blank project and then added what to it?

Coordinator
May 1, 2012 at 6:43 AM

>  I had to fix the references to SharpDX.

Yea... I just fixed that locally too.

> Error 9 'string' does not contain a definition for 'Intern'

Yea... string.Intern() is unsupported in Metro.  Should have that fix submitted tomorrow.

> Error 13 'System.Array' does not contain a definition for 'ConvertAll'

Yep... replaced it with a manual array copy as Metro doesn't support that either.  In my next pull.

> Error 20 'Microsoft.Xna.Framework.Graphics.GraphicsDevice' does not contain a definition for 'Current'

That shouldn't have been checked in... you can comment out references to it.  I'll fix it in the next pull.

> VS11 Express supports Metro apps only, therefore it cannot build 2MGFX.

I think that is temporary and VS11 will support non-Metro projects as well eventually.  For now i depend on having an install of VS2010 as well as VS11.

> Also, what does your test app code look like?

I was using our game, but lately switched to the old "Simple Animation" project...

http://create.msdn.com/en-US/education/catalog/sample/simple_animation

... while i get rendering up and running.

Dan just fixed up a MonoGame VS11 template project and submitted a pull request for it...

 https://github.com/mono/MonoGame/pull/440

... you should give that a try as a starting point.

 - Tom

Coordinator
May 1, 2012 at 7:08 AM

Cool.  I had just found references to those APIs not being supported in .NET for Metro.  I'll replace String.Intern and Array.ConvertAll locally for now so I can build.

Coordinator
May 1, 2012 at 7:46 AM

I submitted a pull request should should get everything compiling for you...

https://github.com/mono/MonoGame/pull/441

... you just need to avoid loading any Effects for tonight... i'll have those at least loading if not working tomorrow.

If you have time maybe go look to fix the GamePad API... at least making it compile... as it blocks the Metro VS11 template from compiling out of the box.

  - Tom

 

Coordinator
May 1, 2012 at 8:08 AM

I got it compiling and running to the point where it tried to load an effect (when creating the SpriteBatch object).  That's easy enough to work-around for now.

Input sounds like a good place to start.

Coordinator
May 2, 2012 at 2:19 AM
Edited May 2, 2012 at 7:30 AM

Status update for those following the Metro port:

- Initial mouse, multi-touch and stylus input support done and pull request submitted.

Currently working on gestures, gamepad and casting an eye over keyboard input.

Update: Remote debugging to a Samsung developer tablet over wi-fi for testing touch gestures is very cool. :)

Coordinator
May 3, 2012 at 8:38 AM

Update...  after a lot of effort I finally got MonoGame rendering under Metro...

  http://farm9.staticflickr.com/8165/6991470384_e065ea870f_b.jpg

… looks simple, but behind this we have most of the rendering systems working.  I have a few issues to address with constant buffers and textures in the effects then I should be able to run complex 3D scenes.  I hope to post much nicer screenshots tomorrow.

  - Tom

 

Coordinator
May 3, 2012 at 11:58 AM
Edited May 3, 2012 at 11:58 AM

Sweet.

Not often that would be said about a simple green triangle. :)

May 3, 2012 at 4:25 PM

This is awesome.  Great job guys.

Developer
May 3, 2012 at 8:46 PM

nice job Tom :)

Coordinator
May 3, 2012 at 9:03 PM

Another update...

http://farm9.staticflickr.com/8151/7139805897_0d120f42b1_o.png

… the windowed render on the left half is plain XNA.  The fullscreen render on the right monitor is MonoGame running under a Metro app.

Next up is getting textures working!

  - Tom

 

May 3, 2012 at 9:21 PM
Edited May 4, 2012 at 5:47 AM

Awesome! That's pretty amazing progress.

Coordinator
May 4, 2012 at 3:26 AM

Tom, are you planning to submit a pull request with the work so far?

Coordinator
May 4, 2012 at 4:36 AM

I do... but it will probably be another day or so.

One bigger problem I have right now is with content loading... it periodically fails if I sit at a breakpoint too long and I have to avoid Disposing() the BinaryReader and Stream.  I suspect that i may have to completely rethink content loading to fix this, but i don't know yet as i don't even know what the problem is really.

  - Tom

 

Coordinator
May 4, 2012 at 4:50 AM
Edited May 4, 2012 at 5:00 AM

Possibly something to do with the WinRT underpinnings.  If you don't sit at a breakpoint, it appears to work ok?

 

Edit: Possibly something to do with this (also this).  A known issue with blocking I/O performed on the UI thread.

Since the standard XNA content loading is synchronous and many people block the UI thread while loading assets (because that's how all XNA sample code does it), the WinRT everything-potentially-slow-is-async approach could be interesting to work with.

Coordinator
May 4, 2012 at 5:04 AM

Yea... no breakpoints during loading and it works fine.  This smells of some sort of thread starvation or race condition.

Because we want to try to maintain MonoGame's XNA api… we cannot use C#'s new async/await keywords.  So instead i'm manually hooking up OnCompletion events and fetching results of async operations.  One of these happens to be the one which returns a normal looking .NET Stream reading.

The problem seems to be that there is something "magic" under the hood of the Stream returned from the async calls.  It seems like some dispatch needs to be pumped periodically even while i'm using the non-async Stream object.  Or maybe the returned Stream is not intended to be used from the UI thread at all?

Unfortunately there are zero docs, so I don't know what the limits are.

And the exception I get is one that gives little hints...  "index out of range".

If we're lucky what we're doing there is ok and this is just some bug related to debugging only.  Or my code is a little incorrect, but generally we can work the way we are.

If we're unlucky I have to make all stream reading code work from the async callbacks which will require a overhaul of ContentManager.  One trick to get past this might be to load the entire file into a MemoryStream in the async callback then read the memory stream in the UI thread.

While going async here is a good thing long term.  It isn't something I look forward to fixing today.... our game has async loading already where it counts, so it is a little annoying to be forced to make something async that is synchronous on WP7 and runs fine.  Still I totally understand that this move is a good one for Windows and development in general.

 But first... rendering. :)

  - Tom

 

Coordinator
May 4, 2012 at 5:15 AM

> Possibly something to do with this 

 Yep... that seems to be exactly it.  For the life of me when i was searching for the cause the other day i couldn't find these threads.  Thanks!

 From those post they may fix it.... I can cross my fingers and hope for the June release to solve it.  I think in the mean time I will try my hack...  read the whole file into a MemoryStream… as it would be the least invasive hack and will be easy to remove and test for the fix later.

If after the June release this is either not fixed or won't be fixed... i'll have to try putting the whole file operation into the thread pool and fix all the thread-unsafe code I find.

  - Tom

 

May 4, 2012 at 5:46 AM
Edited May 4, 2012 at 5:47 AM

As kind of a small aside. If you're adding new information rather then fixing a mistake in a discussion on codeplex, try and post a new reply to the discussion rather then editing an existing one. A lot of people follow the discussions via email and edits to existing replies are not included. :D

Coordinator
May 4, 2012 at 9:33 AM

So this is what I ended up with to work around the async issue...

https://github.com/SickheadGames/MonoGame/commit/99fd0f36bda35a7c55870091d097f2bced41b902

… i probably have one too many Tasks in there, but from all my tests here it works.

Thanks again for the links Steve.

  - Tom

 

Coordinator
May 4, 2012 at 12:40 PM

Looks like a worthy work-around for now.

Coordinator
May 4, 2012 at 5:46 PM

Just to keep people updated the latest status on areas of work for the Metro port...

  • Graphics - Tom Spilman
  • Audio - Bill Reiss
  • Input - slygamer
  • Video and VideoPlayer
  • Content & Storage
  • Network & GamerServices

    … if anyone else wants to jump in and help reply here.

     

  • Coordinator
    May 5, 2012 at 12:23 PM

    How is Bill going with audio?

    May 5, 2012 at 5:38 PM

    I'll take a quick look at audio today if that helps.  I have not ported  my game over to here, so I will probably take a bit there.

    Coordinator
    May 5, 2012 at 7:12 PM

    I haven't heard from him since he offered to take that part over.  I'll try to get in contact with him today and see.

      - Tom

     

    Coordinator
    May 6, 2012 at 2:14 PM

    I have a bit of clean-up to do on gestures and testing to make sure I've covered all bases.  Then implement gamepad support.

    Coordinator
    May 6, 2012 at 10:15 PM

    Very cool...  I could use gestures and touch events badly now that we have rendering working.

    I should have a pull request for the working renderer later tonight.

      - Tom

       

    May 6, 2012 at 10:32 PM
    Edited May 6, 2012 at 11:00 PM

    Can I help at all here?

    I am connected as good as it gets and know that I can get help on anything I am sure.

    Also, I am not sure how to get to this branch. 

    Your help is appreciated.

     

    Patrick Dengler

    Microsoft / Windows

     

     

    Coordinator
    May 6, 2012 at 11:01 PM
    Edited May 6, 2012 at 11:03 PM

    All the work is landing in the develop3d branch at github...

    https://github.com/mono/MonoGame/tree/develop3d

    As far as help...  it depends on what you can do.

    I would say one area that needs someone to lead on is the network and gamer services side of things

     

    Coordinator
    May 7, 2012 at 2:05 AM

    Network will be interesting, as socket connections are dropped once the app is suspended.  Hence Microsoft's push for asynchronous multiplayer on all titles where app suspension does not matter as much.

    Coordinator
    May 7, 2012 at 5:43 AM

    Gesture support now has a pull request (#450).  A difference to XNA's Pinch gesture is noted in the pull request.

    Coordinator
    May 7, 2012 at 1:49 PM

    Nice screenshot on the front page too, Tom.

    Developer
    May 7, 2012 at 2:09 PM

    I added the screenshot yesterday. The progress on the WinRT port by everyone concerned is very impressive!! Pity I don't have Win8 installed, or the urge to install it, just yet.

    I look forward to more news.

    Coordinator
    May 7, 2012 at 10:57 PM

    @slygamer - So I tested your gesture support on our Win8 port of our game. 

    Using the WP7 gesture/touch code as is things don't work correctly.... we sometimes get "stuck" in a drag modes and pinch behaves strangely.  The first is probably some simple bug... the pinch case may be more serious, but I don't know yet.

    I suspect either TouchLocation.Id or TouchLocation.State isn't working the same as on WP7 or gestures are stealing from the TouchCollection.

    If we get some time we'll debug this more closely, but I wanted to let you know.

      - Tom

     

    Coordinator
    May 8, 2012 at 12:34 AM

    The screenshot on the front page appears to now be broken.

    The gesture code is completely separate from the touch collection at this stage.  Though I didn't test to see if gestures are stealing pointer events on the Win8 side.

    Coordinator
    May 8, 2012 at 12:42 AM

    Oh... I didn't consider that WinRT itself could be stealing touch events when gestures are enabled.  That would put us in a similar boat to iOS.

     

    Coordinator
    May 8, 2012 at 2:09 AM

    If so, I will port the iOS touch code to be a platform-agnostic module.

    The front-page screenshot reports "Access Denied" if I try to show the image by itself.

    Developer
    May 8, 2012 at 10:12 AM

    Steve, I'm not getting that screenshot error. Could it be because I'm pulling the image from TwitPic?

    Coordinator
    May 8, 2012 at 12:08 PM

    The image has worked for me here at home, but I could not get it to show at all at the office.  Looking the source URL for the image, it is now being source from codeplex, but earlier it was sourced from a very different URL.  Never mind, it now works and I can show the bosses Tom's great work.

    Developer
    May 8, 2012 at 12:33 PM

    Yeah I changed it to an embedded image, in case TwitPic was causing problems. Glad it is all working now.

    Coordinator
    May 10, 2012 at 11:26 PM

    Ok... progress on WinRT:

      - Switched all Effects to use the new ConstantBuffer class DX11 and GL.
      - We now only update effect properties that have changed into the ConstantBuffer reducing CPU overhead on all platforms.
      - Fixed depth writes disabled state for DX11.
      - DynamicVertexBuffers and SpriteBatch are working correctly for DX11 now.
      - ScissorRectangle now works in DX11 (also fixed it for GL).

    On the rendering side what I have left is the DrawUserPrimitive() implementation then I think we're "feature complete" for DX11 rendering.  I still have some improvements to make, but its all working.

      - Tom

     

    Coordinator
    May 11, 2012 at 12:07 AM

    Excellent.

    I so wish I could dedicate more time to this port.  I'm currently juggling several projects, one of which will require this port.  That's why my input stuff is taking a bit longer, but I'll get it there.

    Coordinator
    May 11, 2012 at 4:35 AM

    @slygamer

    No prob... I totally understand that.  I'm just in a good place to focus all my time on it which is why i'm making good progress.

    Speaking of input...  I think maybe we either should a) not redirect touch events into mouse state or b) make it an optional toggle for the developer.

    First off it seems "IsPrimary" is a bad thing to test for.  On my Win8 PC which has both  a mouse and touch screen connected... both mouse events and touch events return IsPrimary as true.  Not sure if that is the intended behavior for that value or a bug in WinRT.  Time will tell.

    Still for our game how the input is tuned for mice vs touch is different... so we need to know that when we get mouse input that it really is the mouse and not coming from touch.  Also strange is a sudden touch becoming a mouse click with a large deltaXY…  in our game a this becomes camera jump as it sees what it thinks is a sudden drag with the mouse button held.

    We could work around these issues, but I think for some games fake mouse state is a bad thing.  So maybe it is worth making it an optional toggle on MouseState?

      - Tom

    Coordinator
    May 11, 2012 at 5:14 AM

    I was directing primary touch events to the mouse state because that is how it works on Windows Phone.  But then, Windows Phone has no option for a mouse whereas Windows 8 does so it might make sense not to redirect primary touch input to the mouse state.

    Developer
    May 11, 2012 at 2:55 PM
    Edited May 11, 2012 at 2:57 PM

    Is anyone looking to see if these render changes also work on Android or Mac? Just wondering so I can answer questions on twitter. I know everyone is flat out atm.

    Tom when you say OpenGL do you mean just ES, or deskop variety too?

    Coordinator
    May 11, 2012 at 4:08 PM

    I mean all of GL... desktop and mobile.

    I've been testing all rendering system changes on the OGL Windows build as well as iOS as I know the changes i'm making are sensitive.

    I have no ability to test Android or Linux...  but I could test MacOS, but just haven't yet.

    I really miss mgbot.

      - Tom

     

    Developer
    May 11, 2012 at 4:56 PM

    Thanks for the clarification Tom.

    Yeah mgbot really helped :(. I know the MacOS one builds, but I've not had time to test it out properly.

    D.

    Coordinator
    May 12, 2012 at 12:22 AM

    Android has also been working.  I haven't tested the latest changes though.

    Coordinator
    May 12, 2012 at 1:03 AM

    slygamer - Good to know.

    So today I got all the DrawUserPrimitive path working for DX11 which was the last of the known unimplemented features for DX11 rendering.  All that remains is bugs and optimization passes which I intend to do over the next few weeks.

    Also after getting the DrawUserPrimitive working I decided to convert the DX11 implementation of SpriteBatch to use that instead of managing its own DynamicVertexBiffer and IndexBuffer.  I think its better to have a singular path there instead of having duplicate functionality.  I think the performance is basically the same... the only difference is 2 or 3 more function calls per-Draw().

    I'm working on a new pull request now.

      - Tom

     

    Developer
    May 12, 2012 at 10:36 AM
    Edited May 12, 2012 at 10:37 AM

    I also like the idea of having a single path to optimise over multiples. Sounds like it shouldn't be a massive overheard, but some benchmarks down the line will show us if it is that bit a deal.

    Will this unified DX11 change make it into the GL code path of iOS etc?

    Btw, did Bill get back about the state of Audio?

    D.

    Coordinator
    May 12, 2012 at 9:43 PM

    > Will this unified DX11 change make it into the GL code path of iOS etc?

    It can really easily...  I just haven't spent the time to try it yet.  I'll take a look next week.

    > Btw, did Bill get back about the state of Audio?

    Nope... and I haven't been able to contact him.  I think we're gonna have to find someone else to jump in there.

      - Tom

     

     

    May 13, 2012 at 11:36 PM

    Ok, well slower to the draw than I thought, I finally got this up and compiling in Metro.  I am now taking a look at GamerServices.  I wouldn't rely on me but I will definitely take a crack at getting this started at least.

    Also, I will probably push .zip for code as I don't trust myself with Git :)

     

    -Patrick

    Coordinator
    May 14, 2012 at 5:01 AM

    I'm not a fan of git myself, and trust is not a word that comes to mind when using it, but it would be easier to merge the changes if you could try to use the pull requests.  The next alternative would be creating a patch as this has some version information in it, e.g. what version of the file was used as the base.

    Developer
    May 14, 2012 at 10:13 AM

    Patrick

    are you going to be working on the networking side of things? or just GamerServices?

    I was thinking of taking on the Networking stuff once I get some spare time later this month.

    Dean

    May 14, 2012 at 4:47 PM

    Hi Dean,

    I'm thinking there might be a dependency here but I am not sure.  I was going to focus on GamerServices.  I will see what comes up.

    As far as GIT goes, I think I can work almost exclusively in separate .cs files so maybe my changes will be safe. 

    I'll let you know what I learn over the next few days.

    Question: I am not familiar with iOS; is the gamerservices suppose to work for all platforms?  i'm doing win8 first.

    Developer
    May 14, 2012 at 7:47 PM

    hi Patrick

    I think the iOS gamer services stuff is only for apple os's / products.

    We currently dont have an independent gamer services system, but we are thinking about it.

    Dean

    May 14, 2012 at 9:07 PM
    slygamer wrote:

    I got it compiling and running to the point where it tried to load an effect (when creating the SpriteBatch object).  That's easy enough to work-around for now.

    Input sounds like a good place to start.


    Are you working on the input part? I need to understand how MessageHooker is going to be handled (or already is handled?)

    Coordinator
    May 15, 2012 at 1:40 AM

    I have been working on input.  I'm not familiar with MessageHooker, as in I haven't come across it as a required item in processing input.

    Coordinator
    May 15, 2012 at 4:38 AM

    @slygamer

    So another issue I've been having with touch input is lost pressed events.  What is happening is we get both Pressed and a Moved events before a TouchPanel.GetState() occurs.  So what happens is any Pressed event becomes a Moved event and as far as the game can see... no Pressed events ever occur. 

    I think what has to happen here is we need to accumulate events between TouchPanel.GetState() calls....  but i'm not totally sure.  All I know is this isn't an issue with XNA on WP7.

     

    Coordinator
    May 15, 2012 at 5:14 AM

    @slygamer

    I put in a hack here, but i think what has to happen is more complex.

    I think you need to gather all the events between TouchPanel.GetStates()... one of each type for the same id.  When TouchPanel.GetStates() is called generate a final state for the data you've accumulated.  If a state update contains a press... throw away any moves you have and hold back the release for the next update.  If a state update contains a release and no press... again throw away moves and return it.

    It is a lot more complex than what is happening now, but i think its required for things to behave like XNA proper.

     - Tom

     

     

    Coordinator
    May 15, 2012 at 5:16 AM

    @slygamer

    If you want i can take a crack at this...  i'm to the point that i don't have any pressing graphics issues.

     - Tom

     

    Coordinator
    May 15, 2012 at 6:46 AM

    I have seen the case where the Pressed event appears to get lost.  I think this is in our code, but I wasn't able to track it down yet.  I'm happy if you want to have a go at it.

    Coordinator
    May 15, 2012 at 12:34 PM

    So after a lot of false starts i finally put together a new TouchPanel.GetState() which makes our game feel identical to WP7 behavior.

    We now only have a TouchPanel.AddEvent() which is all the platforms need to push new pressed/released/move events into the system.  All the rest is done by TouchPanel.GetState(). Currently this all depends on the platforms having touch events that arrive in logical order and that no event is ever "lost".  While this is the same assumption made by the previous code... we could maybe put some extra exceptions/assertions/protections against platforms that behave badly if needed.

    I fixed up all the other platforms to use new internal api… but i cannot test Android or PSS.

    iOS gestures were broken by my change... i will fix that, test it, and then get a pull request in.

      -Tom

    May 21, 2012 at 12:55 AM

    I noticed that touch input is not mapping properly in Snap/Fill scaled run modes.  I also encountered problems when running mouse input against resolutions different than screen size (1024x768 preferred back buffer under 1280x800 actual screen resolution).   

    We may need some code to detect Snap/Fill or resolution differentials vs desktop settings.

    Coordinator
    May 21, 2012 at 1:04 AM

    @KidsAndIDev

    > I noticed that touch input is not mapping properly in Snap/Fill scaled run modes.

    Well the question is what should the behavior there be?

    So far we're not remapping input to the back buffer resolution when scaled.  I'm not totally sure if this is a good thing or not. 

    One thing to check out is how XNA on WP7 behaves when using a back buffer lower than the native 800x480 resolution...  does it scale the input events or not?  I suspect it does not, but I haven't tested it.

    > We may need some code to detect Snap/Fill or resolution differentials vs desktop settings.

    What we've been doing is setting our backbuffer resolution to the Window client size.  I haven't looked at the snapped mode yet, but I suspect we need to hookup some events for when that mode occurs.

      - Tom

     

    Developer
    May 23, 2012 at 12:08 PM

    I mentioned this on Urkle's last PR, but I'm putting it here for higher visibility as that PR is now closed....

    We have a problem gents
    delete mode 100755 MonoGame.Framework/MacOS/Audio/OALSoundBuffer.cs
    delete mode 100755 MonoGame.Framework/MacOS/Audio/OpenALSoundController.cs

    Therefore sound on iOS and I assume MacOS will no longer work as these files were deleted in this commit instead of dereferenced.

     

    D.

    Coordinator
    May 23, 2012 at 12:26 PM

    Dom, from the changelist it looks like the same named files in Desktop/Audio were the same, so the files in MacOS/Audio were removed and the files in Desktop/Audio added to the MacOS project.  It does look like the iOS project will need updating as well as it was using those MacOS files, and make sure it still works.

    May 24, 2012 at 5:17 PM
    Edited May 24, 2012 at 5:47 PM

    I did a quick connect of SharpDX XAudio2 to MonoGame in the Windows8 project yesterday.  I did get it running in a Windows 8 project going off the app store using .WAV files.  Here are a few things I noticed.

    First, the XAudio2 implementation in SharpDX appears to have significant limitations.   These include no MP3 support, and, more significantly for my project, the durational length member, AudioBuffer looping controls, and SourceVoice looping call backs do not appear to function.   I had to use <cring> manual durational assignments and manual loop restart threads in my project code.  So long term we may need some SharpDX updates for effective MonoGame attachment.   Or perhaps a different Audio interface should be used?

    Second, the MetroHelper check for file existence routine did not find .WAV content files in my project.    I did not take time to debug the method, but instead used secondary stream access in ContentTypeReader and a new stream MetroHelper method.   This should probably be fixed and refactored back to one function.

    If anyone is interested in source, here it are some links, as I do not have Git installed on my Win8 test system and cannot submit to GitHub now.   Feel free to use all, any, or none of the source in the MonoGame project.

    Kevin Howard

    KidsAndI Software

     

     

     

    Coordinator
    May 24, 2012 at 7:12 PM

    @Kevin

    Thanks for sharing that.  Since no one else has stepped up on sound yet i'll probably get one of our guys on it next week.  I'll be sure to point him to your work as a starting point.

    If you could do me a huge favor... go to the SharpDX bug tracker and submit bug reports on the broken XAudio2 functionality:

      http://code.google.com/p/sharpdx/issues/list

    … it will help tremendously if Alex could get a head start on fixing these issues.  I've also submitted an issue to consider added the Media Foundation APIs to SharpDX:

     http://code.google.com/p/sharpdx/issues/detail?id=203

      - Tom

     

    May 25, 2012 at 1:18 AM

    Hi,

    Is there any chance of getting some type of quick start guide for getting "hello world" up and running with this? I've downloaded the latest source, but installing the templates as detailed in post #9 isn't working for me.

    This project is exactly what we've been looking for and we can't wait to get started with it... and possibly even contributing if we can! :)

    Thanks!

    Coordinator
    May 25, 2012 at 2:11 AM

    @Tom, yes we will need MediaFoundation if we want video playback.

    Coordinator
    May 25, 2012 at 2:56 AM

    @UberGeekGames

    Fantastic to have you guys aboard.

    > Is there any chance of getting some type of quick start guide
    > for getting "hello world" up and running with this?

    It is actually fairly simple... simpler than one would think.

    I knocked up a quick wiki page for you...

    https://github.com/mono/MonoGame/wiki/MonoGame-on-Windows-8-Quick-Start

    … let me know if you're still stuck.

     - Tom

     

    May 25, 2012 at 4:48 PM

    Many thanks for that, I've got the project template working now but am encountering an error from DXShader.cs on attempting to run it: http://i46.tinypic.com/2e492cy.png

    This may or may not be due to the fact that I'm running windows 8 inside of a virtual machine, but it can run other 3D apps just fine so it shouldn't be an issue. I'll try deploying to my tablet later and see if the same thing happens.

    Coordinator
    May 25, 2012 at 8:06 PM

    Oh...  I bet it is the virtual machine and that it needs "dx9" compatible shaders.  I'll be sure to rebuild the shaders with that flag on by default and get a pull request that fixes it.

     

    Coordinator
    May 25, 2012 at 8:32 PM
    Edited May 25, 2012 at 8:34 PM

    @UberGeekGames

    Actually if you get a chance test this on your virtual machine and see if it fixes things...

    1. Open 'Tools\2MGFX\2MGFX.sln' in VS2010 and compile the debug build (it places binaries in 'Tools\bin\Windows').
    2. Open 'MonoGame.Framework\Graphics\Effect\Resources\Macros.fxh' and change the references to "vs_4_0" and "ps_4_0" to "vs_4_0_level_9_3" and "ps_4_0_level_9_3".
    3. Run the 'MonoGame.Framework\Graphics\Effect\Resources\RebuildMGFX.bat' to rebuild the shaders.
    4. Rebuild MonoGame.Framework and run your game.

     

     

    Developer
    May 26, 2012 at 10:49 PM

    Tom

    I'm doing a screencast on getting up and running for Metro development, I have the basic CornflowerBlue screen working :) I'm now looking as including assets like .png. I must be missing something because I tried adding a Content folder and the ,png to both the root of the project and in the Assets folder but it doesn't seem to ever get copied over  ( I have set the type to Content and copy if newer) .

    Also there seems to be a missing file MediaQueue.cs which I will commit a fix for unless you have that covered already

    Dean

    Coordinator
    May 26, 2012 at 11:11 PM
    Edited May 27, 2012 at 3:05 AM

    @dean

    You need to run content thru the content processors and then add it to the Win8 project.  Just like the other platforms games on Metro will require offline content processing.  The only content that really needs a special content processor is custom Effects...    all the rest including sound and music I suspect will work using the stock content processors.

    > there seems to be a missing file MediaQueue.cs

    I got that fixed in this pull request already...

    https://github.com/mono/MonoGame/pull/481

    … just waiting on someone to look it over and merge it.

      - Tom

     

    Developer
    May 28, 2012 at 3:25 PM

    So Tom , did you install the XNA Game Studio under windows 8 ? and then use the content pipeline?

    Dean

    Coordinator
    May 28, 2012 at 8:28 PM

    @Dean

    Yea..  I have the Windows Phone SDK installed on Windows 8 which gives me the full content pipeline. 

    I don't think the content pipeline will run under VisualStudio11 yet, so i've been building our desktop XNA build then copying the content from out of the bin folder.  I suspect one could setup a msbuild script that could be executed as a pre-build step in VS11 that can process all the content.

    The Windows Phone team has promised that the Windows Phone SDK will work with VS11 before it officially ships.  I expect that at that time we should be able to simply include the content project into your VS11 solution and make it work like it does for regular XNA.

      - Tom

     

    Coordinator
    May 30, 2012 at 1:48 AM

    For anyone having trouble running MonoGame under Win8 on a VM...

    https://github.com/mono/MonoGame/pull/485

    … that should fix it.

     - Tom

    Coordinator
    Jun 1, 2012 at 12:34 AM

    Would you believe they changed the name of Visual Studio to Visual Studio 2012 after calling it Visual Studio 11 for the previous two releases?

    Coordinator
    Jun 1, 2012 at 12:36 AM
    Edited Jun 1, 2012 at 12:41 AM

    @slygamer - Yea... it looks like the flirted with the idea of VS11, but with the RC its now VS2012 again.

    Also we're about to push some fixes to make things compile under the latest Win SDK.

      - Tom

    Coordinator
    Jun 1, 2012 at 12:58 AM

    Pull to fix it for the new Win8 RC...

    https://github.com/mono/MonoGame/pull/489

    ... it will no longer run on the old Win8 release after this.

     

    Coordinator
    Jun 2, 2012 at 9:14 AM

    Can someone take a look and merging this pull request...

      https://github.com/kungfubanana/MonoGame-Dependencies/pull/7

    ... its been open for quite a while now and is required for content building.

      - Tom

     

    Developer
    Jun 2, 2012 at 9:22 AM

    Tom I've Pulled the PR.

     

    D.

    Coordinator
    Jun 4, 2012 at 9:24 AM

    @Dom - Can you take a look at this pull request as well...

    https://github.com/mono/MonoGame/pull/495

    ... I think that correctly updates the 'libs' reference in MonoGame to point to the new head.

      - Tom

     

    Developer
    Jun 4, 2012 at 12:15 PM

    Done.

     

    D.

    Coordinator
    Jun 7, 2012 at 3:51 AM
    Edited Jun 7, 2012 at 3:53 AM

    A little update for anyone interested in the Windows 8 Metro port.

    We've gotten SoundEffect working...  i expect that to be merged into develop3d by Friday.  Good news is that we can read Microsoft ADPCM format... so no content changes need for sound effects on Metro.

    Music should be working next week and committed.  We depend on work Alex is doing in SharpDX to get access to the native MediaEngine for doing wma/mp3 playback.  I think that again we won't require any content changes here, but I don't know for sure yet.

    With this and all the rest of the work we've done...  things should be close to being stable enough to ship most games on.  I'm sure there are things we've missed, but we need to get others using it to help find them.  We expect to be doing a public beta of our game within the next 2 weeks and plan to fix bugs in MonoGame until we ship.

      - Tom

     

    Developer
    Jun 7, 2012 at 9:08 AM

    Fantastic work Tom,

    Well done to you and your team. :)

    Developer
    Jun 7, 2012 at 10:29 AM

    I second Dean's emotion. Awesome sauce all round!!

    Coordinator
    Jun 8, 2012 at 4:05 AM

    Thanks guys.

    We got a pull request up with the first of the SoundEffect code for WinRT:

    https://github.com/mono/MonoGame/pull/507

    We're waiting on some stuff from SharpDX to get 3D positional sound working as well as music.

    Also James is taking some time to merge all the copies of SoundEffect and SoundEffectInstance into a single source file again.  We should have a branch for people to test in the next few days.

      - Tom

     

    Coordinator
    Jun 8, 2012 at 5:04 AM
    Edited Jun 8, 2012 at 5:05 AM

    Tom, what approach did you take for code that used IsolatedStorage in ARMED?  I started on a compatibility library (implementing the used bits of System.IO.IsolatedStorage as a wrapper around the WinRT functionality), but found that it is not that much fun.  I'm considering re-writing the bits of my game code that use IsolatedStorage to use the WinRT functions natively.

    p.s. Do codeplex forum threads ever become multiple pages?

    Coordinator
    Jun 8, 2012 at 5:21 AM
    Edited Jun 8, 2012 at 5:22 AM

    We wrote a small "FileSystem" wrapper for our game long ago so we could run on both Windows desktop and WP7.  We just extended it to support WinRT...

            /// <summary>
            /// Opens a file for reading.  Will check for and 
            /// return a null stream if the file does not exist.
            /// </summary>
            static public Stream ReadFile(string path)
            {
                path = MakeUserPath(path);
    
    #if WINDOWS_PHONE
                using (var store = IsolatedStorageFile.GetUserStoreForApplication())
                {
                    if (!store.FileExists(path))
                        return null;
    
                    var stream = store.OpenFile(path, FileMode.Open);
                    return stream;
                }
    #elif WINRT
    
                var stream = Task.Run(
                    async () =>
                    {
    
                        try
                        {
                            var storageFile = await ApplicationData.Current.LocalFolder.GetFileAsync(path);
                            return await storageFile.OpenStreamForReadAsync();
                        }
                        catch (IOException)
                        {
                            return null;
                        }
    
                    }).Result;
    
                return stream;
    
    #else
                if (!File.Exists(path))
                    return null;
    
                var stream = new FileStream(path, FileMode.Open, FileAccess.Read);
                return stream;
    #endif
            }

    The main trick there being the Task.Run() wrapper around the async call with a blocking wait for the 'Result'.  Technically Microsoft doesn't want you to hack around async like this...  but it does work.  Our file operations in our game were already tuned to be fast and not block the UI... so the async for us wasn't totally nessasary.

    Still... if we were designing the game from scratch for WinRT we would use async in the first place.

      - Tom

     

    Coordinator
    Jun 8, 2012 at 5:33 AM

    Added two feature requests to the Codeplex team...

    http://codeplex.codeplex.com/workitem/26295

    http://codeplex.codeplex.com/workitem/26296

    ... vote on them if you agree.

      - Tom

     

    Coordinator
    Jun 8, 2012 at 6:14 AM

    Our previous solution for having the game running on Windows, Windows Phone, iOS and Android is

            static public IsolatedStorageFile GetUserStore()
            {
    #if WINDOWS
                return IsolatedStorageFile.GetUserStoreForDomain();
    #else
                return IsolatedStorageFile.GetUserStoreForApplication();
    #endif
            }
    
    

    This doesn't work on WinRT.  Your code above has given me some tips on how to progress with my compatibility library though.

    Jun 8, 2012 at 3:49 PM

    Great work on the Metro Port! I'm very excited to see where this goes.

    I have a quick question related to ContentManager. It appears to be searching for content in the AppData Local Directory, correct?

    How am I supposed to place Content in the Local folder at build  time? Is there a build flag I have to set on the content, or am I completely wrong here?

    Thanks!

    Coordinator
    Jun 8, 2012 at 4:12 PM
    Edited Jun 8, 2012 at 4:14 PM

    > It appears to be searching for content in the AppData Local Directory,

    Yes and no.

    The Metro port first tries to find the content file in the "app package" which is the files installed with your app.

    After that there is this fallback which tries to load content from the user data area, but that code is sort of old and i'm not sure it will live much longer... at least not how it is now.

    > How am I supposed to place Content in the Local folder at build  time?

    How we do things on our project is we have a separate dummy XNA project that we run in VS2010 that compiles a normal .contentproject producing a 'Content' folder in its bin with all your content run thru the content pipeline into XNB files.

    Then we copy that Content folder from bin into a folder where our WinMetro .vcproj is and include it using hand written wildcard syntax in the .vcproj file...

        <Content Include="Content\**\*.*">
          <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        </Content>

    We then reload our WinMetro project and build it.  When its deployed it includes all the compiled XNB files which the ContentManager can load.

    This so far is our best method, but I hope for it to improve soon as the final bits for the WP7 SDK for VS2012 ship and content projects can be built in VS2012.

     - Tom

     

    Developer
    Jun 8, 2012 at 11:17 PM

    Tom

    have you managed to install XNA studio on the latest windows 8? If failed on my version when trying to install the VS 2010 Windows Phone Express.

    Dean

    Coordinator
    Jun 8, 2012 at 11:30 PM

    @Dean

    Try installing this....

    http://www.xbox.com/en-US/LIVE/PC/DownloadClient

    ... then restarting the Windows Phone SDK install in repair mode.  This worked for me, but in my case i had VS2010+SP1 installed first.

      - Tom

     

    Developer
    Jun 8, 2012 at 11:35 PM

    Cheers Tom,

    I will give that a go

    Dean

    Developer
    Jun 10, 2012 at 8:45 PM

    Thanks Tom it worked. I can not build content on Windows 8 via a Windows Phone project.

    Next issue though.

    I'm using the SimpleAnimation Sample to render the standard Xna Tank, and like on the android stuff the normal's seem messed up, its probably a state thing like it was on android. I'm going to have a look through the code and see where the fix for the android stuff was its probably in the same area, but if you have any ideas in the mean time :)

    Dean

    Coordinator
    Jun 10, 2012 at 9:27 PM

    > I'm using the SimpleAnimation Sample to render the standard Xna Tank

    Interesting... one of the first things I got working was that same sample.  It must be something new that has cropped up.

    If you email me the converted WinRT project for that and I can take a look and fix it.

      - Tom

     

    Coordinator
    Jun 12, 2012 at 4:19 AM

    Someone that has merge access give these a look over...

    https://github.com/kungfubanana/MonoGame-Dependencies/pull/8
    https://github.com/mono/MonoGame/pull/507
    https://github.com/mono/MonoGame/pull/512

      - Tom

     

    Coordinator
    Jun 12, 2012 at 8:11 AM

    If no-one has done so by the time I get onto it tonight, I'll have a look then.

    Coordinator
    Jun 12, 2012 at 8:17 AM

    Thanks!

    Coordinator
    Jun 12, 2012 at 11:29 AM

    Done.

    Jun 12, 2012 at 7:06 PM

    MonoGames for Metro pass Windows Store  certification ??

    Coordinator
    Jun 12, 2012 at 11:10 PM

    We just got back from the Microsoft offices here in Dallas...  games using MonoGame will pass Windows Store certification.

      - Tom

     

    Developer
    Jun 12, 2012 at 11:22 PM

    Tom

    excellent work, that is really good news and will please allot of people. :)

    Dean

    Jun 13, 2012 at 12:38 AM
    Edited Jun 13, 2012 at 8:14 AM

    I make game for Windows8 RC, and this is great news. Great Job. I have one question : Is possible put pubcenter advertising in MonoGames Windows8 ?? Maybe somethig tips how i can do it. Really thanks for help.

    Developer
    Jun 13, 2012 at 11:26 AM

    This is great news Tom!! Not only for MonoGame, but also for XNA and I hope that community will think this is awesome as well.

     

    D.

    Jun 13, 2012 at 2:54 PM

    This is great ! Good job team :)

    @pmym : Where are you put your content folder ?

    Developer
    Jun 14, 2012 at 11:55 AM

    @slygamer or @TomSpilman : Does DrawUserPrimitives work for you on iOS? I just tried the VectorRumble demo with develop3d and the Assert in SetData fails. Ideas?

    Coordinator
    Jun 14, 2012 at 5:25 PM

    Well our game uses various calls to DrawUserPrimitives() and things seemed to work at least a week ago on iPad/iPhone.  Maybe something got broken since then.  I'll be sure we run thru things today and i'll let you know.

      - Tom

     

    Coordinator
    Jun 28, 2012 at 8:35 AM
    Edited Jun 28, 2012 at 8:37 AM

    We have a milestone today!

    On 02-28-2012 I made my first commit to MonoGame.

    On 03-02-2012 I made the first commit for the Windows 8 port of MonoGame.

    Just an hour ago... 4 months to the day... we submitted our game to the Windows 8 Store for certification!

      -Tom

     

    Developer
    Jun 28, 2012 at 12:41 PM

    Awesome Sauce news Tom!!!

    Coordinator
    Jun 28, 2012 at 12:56 PM

    Sweet! Can't wait to see it.

    Coordinator
    Jun 28, 2012 at 5:08 PM

    Aside from being excited to get our game on the platform...  once its in the store it once and for all proves MonoGame is Metro compatible.

    Also more good news from Alex on SharpDX...

      "I have been able to play a mp3 and a video (projected on a D3D11 Texture) with the MediaFoundation.MediaEngine"

    ... so look forward to MediaPlayer/Song working for Metro next week!

      - Tom

     

     

    Jul 1, 2012 at 4:31 PM

    Hi,

    What screen resolution are you using for your game ? My desktop use 1680x1080 and it's work on Metro too, but I can't leave this resolution for the final game ;)

    Do you think that I must use a fixed resolution (like 800x480 or 1024x600 ?)

    Yann.

    Jul 1, 2012 at 7:51 PM

    So it is possible to port a game like this?

    http://create.msdn.com/en-US/education/catalog/sample/roleplaying_game

    thx for reading

    Maybe a small tutorail on a sample game would help a lot of people

    Coordinator
    Jul 1, 2012 at 8:33 PM

    @CYannick

    What I've seen so far is that Metro games all play at the native screen resolution...  so if your desktop is 1680x1080... that is the default resolution of games.  Now that said there was one game in the developer preview release of Windows 8 that had a "resolution slider".  The slider would scale the game resolution...  but the UI would stay at the full desktop resolution.

    So what I would suggest is if you have a game that is fillrate intensive... you should render your game to an offscreen surface that can be scaled... then composite it to the back buffer and then render all your UI over it at full resolution (or use XAML uis which are always at desktop resolution).

    @funkyj4ever

    Absolutely!  It is possible to port any XNA game to MonoGame and have it run on multiple platforms including Windows 8 Metro.

      - Tom

     

    Jul 1, 2012 at 11:19 PM

    Is there a tutorial how to do that?

    thx for reading

    Jul 2, 2012 at 6:53 AM

    @TomSpilman

    Ok thanks !

    @funkyj4ever

    Checkout the wiki on gihub, there are a lot of ressources https://github.com/mono/MonoGame/wiki/_pages 

    If French devs are here, i've written a guide to setting up a MonoGame Project for Windows 8 Metro (http://www.demonixis.net/blog/creer-un-projet-monogame-pour-windows-8-metro/).

    Developer
    Jul 2, 2012 at 10:21 AM

    funkyj4ever

    The roleplaying game has already been ported to Windows and Mac on MonoGame, its in the Samples or StarterKits folder (you will need to initialize and update the git submodules to get the code down)

    Dean

    Jul 6, 2012 at 11:15 PM
    Edited Jul 6, 2012 at 11:34 PM

    sorry i am a newb with git, how van i download those samples?

     , i found it  but i cant find the roleplayingame, is used this urls

    https://github.com/kungfubanana/MonoGame-StarterKits.git

    https://github.com/CartBlanche/MonoGame-Samples.git

    ohh found it in samples

    thx for reading

    Jul 9, 2012 at 10:05 PM

    I got a problem i followed this tutorial http://www.youtube.com/watch?v=-ycmeVYm_gI   (around 8min)   but when i add the reference i got a error,

    a reference to MonoGame.FrameWork.Windows8 could not be added. Adding this project as a reference would cause a circular dependency.

    When i build it without adding the refence, errors come up that namespace xna does not exist.

     

    thx for reading

    Coordinator
    Jul 9, 2012 at 11:24 PM

    @Dom/Sly

    Can one of you take a look at these pull requests...

    https://github.com/mono/MonoGame/pull/566
    https://github.com/kungfubanana/MonoGame-Dependencies/pull/10

    @funky - Sounds strange to have a circular dependency on MonoGame.FrameWork.Windows8.  Are you somehow adding your own assembly as a dependency to the MonoGame.FrameWork.Windows8 project?

     

    Developer
    Jul 16, 2012 at 4:57 PM

    Not sure if this has already been mentioned, or addressed in your own branches, but under iOS, SpriteFonts render as black rectangles under iOS.

     

    D.

    Coordinator
    Jul 16, 2012 at 8:13 PM

    @CartBlanche

    Weird... we run iOS here for our game and do not see that problem. 

    I suspect this is someone who is trying to load XNBs created via Microsoft's SpriteFontProcessor which is no longer supported for iOS.  You absolutely must use the MGSpriteFontProcessor as iOS only supports uncompressed and PVRTC textures now.  DXT textures are fully unsupported.

      - Tom

     

    Developer
    Jul 16, 2012 at 11:33 PM

    Ah ok, I forgot about the MGSpriteFontProcessor for iOS. Does it spit it out with a different name?

    Coordinator
    Jul 16, 2012 at 11:45 PM
    Edited Jul 16, 2012 at 11:46 PM

    No... it works identical to the default XNA processor, but instead of having a DXT texture inside the XNB... it has a PVRTC texture.

    See my docs here...

       https://github.com/mono/MonoGame/wiki/MonoGame-Content-Processing

      - Tom

     

    Jul 17, 2012 at 5:51 PM

     

    Hey I the developer of CraftWorld www.craftworldgame.com and am about to start porting the game to metro.

    I have a few questions however.

    I have downloaded the latest develop3d source and compiled against sharp dx 2.2 and have managed to port the split screen sample from xna to metro.

    There are however 3 things I was wondering.

    First of all the state of the depth buffer seems to be ignored when drawing in 3d (i am most likely doing something wrong...)

    Here is a screenshot of the problem http://i.imgur.com/hJuDA.jpg (Sorry about the jpg-ness)

     

    Second this metro build seems fairly complete, but is it possible to get an update on what remains to be done and how I can help? My game generates a ton of textures, and meshes etc... will I have any major issues that you guys know of?


    Third I am wondering what to do about the removed "Thread" class in metro... I used alot of threads for many tasks, and also my physics engine (a heavly modified bepu) uses many threads too. How should I go about fixing those issues as I need to have multiple background threads running to generate terrain etc...

    Also what about file saving and loading, like isolated storage and save devices (which are both supported on xna PC) are these going to be ported? Whats the way people are handleing things with this currently?


    Thank you all for you amazing work on this project and I will be sure to help out wherever I can!

    And sorry for the large post...


    Thanks!

    Jul 17, 2012 at 8:08 PM
    This framework is coming along AMAZINGLY.  Armed is INCREDIBLE (I am showing it so some folks)

    I've done my game, in fact 2 of my games I ported within a few hours (absent some audio work I have to do).

    So, just a big ole congrats.

    Coordinator
    Jul 17, 2012 at 8:27 PM

    Thanks Patrick.

    Let us know if you run into any issues.  We're trying to get a 3.0 version wrapped up and shipped before Win8 RTMs.

      - Tom

     

    Jul 18, 2012 at 6:23 AM
    Edited Jul 18, 2012 at 7:18 AM

    @Danthekilla

    I have similar issues with depth buffer in my port (windows phone to metro). Didn't have much time to test but the code ported as it was form the phone had issues, trying to reset states, rearranging draw calls etc.. didn't work. In our case it looks like every single object we draw is drawn correctly but each object ignores the depth buffer resulting from the previous draw, so each new object is drawn in front of the previous, independently of the correct depth.

    You can see a comparison here (shadows and env.shader are disabled for now in metro): http://goo.gl/0OU3n

    This and the missing Vertexbuffers/Indexbuffers GetData (we need to get data from models that we use to build a complex model on the fly depending on te level) are the 2 biggest issues remaining in our case

    @TomSpilman

    Sorry to answer here but I don't want to derail the Armed thread with technical stuff. Thanks for the good news for the Game+Xaml combo, we will wait a bit then and see what happens. Thanks for the support.

    Jul 19, 2012 at 9:06 AM

    Hi, can I ask you, if the monogame for Windows Metro using DirectX feature level 9.1?

    Coordinator
    Jul 19, 2012 at 10:13 AM

    @klapi - It is... or at least it can and is supposed to be.  We've have had some issues with Intel integrated GPUs which might indicate we've missed something there.  Should have a fix committed soon.

      - Tom

     

    Developer
    Jul 19, 2012 at 11:22 AM

    Hi Gents ( and ladies if you are about ),

      Looks like Windows 8 is due for release on October 26th. It would be great for us to be able to be able to get v3.0 out around that time.

    With the awesome progress Tom and his team have made on Metro, iOS and Android it seems like we should be able to release quite a stable version.

    Just need to get MacOS and Linux and possibly PlayStation Mobile up to the same level.

    Exciting times!!

     

    D.

    Jul 19, 2012 at 1:48 PM

    Hi Tom and Klapi

    The feature level 9.1 is very important for the functioning of the MonoGame on Windows 8 for ARM - see section 3.10 in http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx.

     

    3.10 Direct3D apps must support a minimum feature level

    This requirement applies if you depend on specific 3D graphics hardware features.

    If your app includes an ARM or a Neutral package it must support Direct3D feature level 9_1. If your app does not support ARM it must support the minimum feature level chosen on the Store portal.

    Because customers can change the graphics hardware in their computers after the app is installed, if you choose a minimum feature level higher than 9_1, your app must detect at launch whether or not the current hardware meets the minimum requirements. If not, the app must display a message to the customer detailing the Direct3D requirements.

    In addition to supporting the chosen minimum Direct3D feature level, your app may use higher feature levels when available.

     

    Michal

    Coordinator
    Jul 19, 2012 at 11:46 PM

    @CartBlanche

    Yep... all that seems very doable.  It would be nice to ship 3.0 before Win8 RTM, but still plenty of time.

    @Sirall

    I am aware of the 9.1 minimum feature level.  There is no reason why MonoGame wouldn't work at that level... all the stock shaders already function under those constraints

    Now i'm currently fixing a bug related to 9.1 feature level hardware... as soon as I have that fixed i'll report back.  Should be later tonight.

      - Tom

     

    Coordinator
    Jul 20, 2012 at 7:49 AM

    @Danthekilla

    Sorry I missed your post before.

    >  what remains to be done and how I can help?

    Things are pretty complete... most common stuff works fine.  When you start dealing with multiple render targets, instancing, custom effects, and gamepad/joystick/wheel is when you might start having issues.

    If you run into something that is not implemented or doesn't work... report it.  If you know how to fix it... fix it and submit a pull request back to github.

    > what to do about the removed "Thread" class

    You should use the Task system to create a new task with your thread entrypoint.  See Task.Factory.StartNew().

    > Also what about file saving and loading, like isolated storage

    Isolated Storage is outside of the XNA library, so it probably won't be in MonoGame for now.

    You need to wrap your file system access yourself.

      - Tom

     

    Coordinator
    Jul 20, 2012 at 12:14 PM

    I had started on a version of Isolated Storage for Metro.  Agreed that it wouldn't go in MonoGame, but it's a nice helper to keep code compatibility.

    Jul 20, 2012 at 3:20 PM

    Hi Tom/All

    I installed a daily drop of Windows and I am having troubles getting the underlying frameworks installed.  MonoDevelop seems to install, Gtk# won't install, and then MonoGame stops installing (the MSI) and hangs on "MonoDevelop not installed".  This is new since last weeks build.  Before I flatten my machine and see if this was a user error, can anyone post me a /bin of develop3d?  I cannot build Mono from develop3d either (Media Foundation library errors?).

    If the binary works then I'll know it was me; if it doesn't I will flatten and try again anyway.

    Also, do you guys have access to Windows Builds and if not would that help? I'm thinking you must.

    Lastly, I was asked to do GamerServices and I got swept away into my day job; I see that some code was pushed out.  If there is anything that I can look at and help with on this framework, without being critical path, let me know.  I thought I would check out Video/Audio but I believe you have an expert on this.

    -Patrick

    (I don't represent Microsoft here)

     

    Coordinator
    Jul 20, 2012 at 4:49 PM

    Why are you installing MonoDevelop and GTK#?  You don't need them.  You only need MonoGame and Visual Studio 2012 Express.

    The Media Foundation APIs are in the latest updates to SharpDX.  You will need to update the ThirdParty\Libs submodule to get the latest SharpDX libs.

    We only have access to the publicly released Release Preview of Windows 8.

    Coordinator
    Jul 20, 2012 at 4:51 PM

    @Patrick

    The trick is...

      git submodule update

    ... which updates all the referenced submodules including the one with the updated SharpDX libraries which have Media Foundation support in them.

      - Tom

     

    Jul 20, 2012 at 5:01 PM

    Thanks for that. I was quite sure that was the case, but when installation hung on "Can't find MonoDevelop" I think I went sideways.


    From: slygamer [notifications@codeplex.com]
    Sent: Friday, July 20, 2012 8:49 AM
    To: Patrick Dengler
    Subject: Re: Metro Status? [MonoGame:353549]

    From: slygamer

    Why are you installing MonoDevelop and GTK#? You don't need them. You only need MonoGame and Visual Studio 2012 Express.

    The Media Foundation APIs are in the latest updates to SharpDX. You will need to update the ThirdParty\Libs submodule to get the latest SharpDX libs.

    We only have access to the publicly released Release Preview of Windows 8.

    Jul 20, 2012 at 5:01 PM

    I am not an experienced git user so I will push through that (perhaps the Web UI might give me that packaget).

    Thanks!


    From: TomSpilman [notifications@codeplex.com]
    Sent: Friday, July 20, 2012 8:51 AM
    To: Patrick Dengler
    Subject: Re: Metro Status? [MonoGame:353549]

    From: TomSpilman

    @Patrick

    The trick is...

    git submodule update

    ... which updates all the referenced submodules including the one with the updated SharpDX libraries which have Media Foundation support in them.

    - Tom

    Jul 20, 2012 at 5:27 PM
    patrickdengler wrote:

    Thanks for that. I was quite sure that was the case, but when installation hung on "Can't find MonoDevelop" I think I went sideways.


    From: slygamer [notifications@codeplex.com]
    Sent: Friday, July 20, 2012 8:49 AM
    To: Patrick Dengler
    Subject: Re: Metro Status? [MonoGame:353549]

    From: slygamer

    Why are you installing MonoDevelop and GTK#? You don't need them. You only need MonoGame and Visual Studio 2012 Express.

    The Media Foundation APIs are in the latest updates to SharpDX. You will need to update the ThirdParty\Libs submodule to get the latest SharpDX libs.

    We only have access to the publicly released Release Preview of Windows 8.


    When installing MonoGame, the installer gets stuck and the details say: MonoDevelop not found.

    This didn't happen on my other Win8 machine, so I am not sure what is going on.  I couldn't find any of this in issues. 

    I am installing it to the k: drive which is the only different thing.

    Jul 20, 2012 at 5:34 PM

    Yeah, I am not finding this :(

     

    In the github webUI, can I grab these?

    Thanks again in advance!

    Jul 20, 2012 at 6:22 PM
    patrickdengler wrote:

    Yeah, I am not finding this :(

     

    In the github webUI, can I grab these?

    Thanks again in advance!


    I am not sure why you are 'installing' MonoGame... are you trying to install the 2.51 version? because the 3.0 is the only one with Windows8 support as far as I know and it doesn't currently(unless I am mistaken) have an installer. All you need to do is set up a local clone of the develop3d branch of MonoGame on your computer, install Visual Studio 2012 and then rework your project to use the MonoGame FrameWork instead of the Microsoft XNA libs.

    For the ThirdParty stuff, In another thread CartBlanche suggested that I try doing a 'git submodule init' before the 'git submodule update'. I am not home to try this out yet but you could give that a shot.

    If that all doesn't work then I suppose you could just download the whole thing as a zip or tarball using the Download button on the github repository page. Just make sure that the develop3d branch is selected.

    If I've stated anything in error then please dont punish me too harshly.

     

    Rob

    Coordinator
    Jul 21, 2012 at 4:25 AM

    I submitted a pull request tonight which includes the fixes to get MonoGame to work on those 9.1 feature level GPUs like the Intel GMA integrated chipsets...

    https://github.com/mono/MonoGame/pull/604

    ... as long as your using the stock effects, keep your textures under 2048, and not dipping into multiple render targets or instancing... a MonoGame for Windows 8 Metro will run on all Windows 8 desktops and tablets.

      - Tom

     

    Jul 21, 2012 at 4:55 AM

    Rob: I was installing MonoGame to "get the right binaries" which was obviously wrong :)

    I have my game up running super!!

    Where can / should I ask questions about Audio (.e.g converting my model from soundbank to wav easily)?  I'm thinking it is not on this thread and I cannot find where I should look.

     

    Thanks all.  I'm looking forward to trying video.

    Coordinator
    Jul 21, 2012 at 8:22 AM

    @Patrick - Just start a new thread and mark it as a general question.

      - Tom

     

    Jul 23, 2012 at 7:01 AM
    TomSpilman wrote:

    @Danthekilla

    Sorry I missed your post before.

    >  what remains to be done and how I can help?

    Things are pretty complete... most common stuff works fine.  When you start dealing with multiple render targets, instancing, custom effects, and gamepad/joystick/wheel is when you might start having issues.

    If you run into something that is not implemented or doesn't work... report it.  If you know how to fix it... fix it and submit a pull request back to github.

    > what to do about the removed "Thread" class

    You should use the Task system to create a new task with your thread entrypoint.  See Task.Factory.StartNew().

    > Also what about file saving and loading, like isolated storage

    Isolated Storage is outside of the XNA library, so it probably won't be in MonoGame for now.

    You need to wrap your file system access yourself.

      - Tom

     

    Thanks for your reply.

    I have recently ported a medium sized 2D game to metro using the metro develop 3d branch and haven't had many problems so far. My biggest few questions now are about touch input, will the Win 8 tablets map to the WP7 touch api's?

    And the only other thing I couldnt get working was music (sound effects work fine) is their any known issues with playing songs?

    I have just commented it out my music for now, but will look into it in the next week or so.

    I plan on "porting" a huge project in a few weeks, also one other question. If I get the game running perfectly in metro on the develop 3d build I should also be able to move the game to linux, mac and iOS shouldn't I with reletive ease? Is it typical to just have a project file for each and a set of defines in the game code for each platform? Also monogame runs on sharp dx which runs on dx11 on windows yes? How is its performance compared to regular XNA? should I look at doing my pc release using monogame too? Does it run on any lower end hardware?

    Thanks!

    Coordinator
    Jul 23, 2012 at 7:16 AM

    There were recent updates to allow music on Metro.  Tom will be able to clarify that.  It uses WMA I believe (same as XNA on PC and Windows Phone).

    Usually you would have a different project file per platform, referencing the same source code.  Having a conditional symbol per platform is a good idea because there will usually be some small sections of your game code that are specific to one platform.

    At this stage, the Metro port is the only one that uses DX11.  The Windows version of MonoGame is primarily for testing and currently uses OpenGL via OpenTK.  We have talked about using the DX11 work for a Windows version as well, but there has been no movement on that yet.  The DX11 version uses the 9.1 feature level, so it runs on all cards that support Direct3D 9.1 features.  It is your choice whether you want to use MonoGame for Windows, or the real XNA for Windows.

    Jul 23, 2012 at 2:59 PM

    Do you know of any benifit to using MonoGame for Windows rather than the real XNA for Windows?

    What are the dependencys for a windows monogame game? Just a few release DLL's would be easier than having to make sure the user has the XNA redistro installed?

    I am assumeing that OpenGL via OpenTK would be similar in performance to XNA which wraps directX9.?

    Coordinator
    Jul 23, 2012 at 4:25 PM

    I don't think anyone has done real performance comparison tests on the Windows version of MonoGame.  It was primarily intended for easy development (it's a lot easier to develop and debug on Windows than on a mobile device).

    Making sure the user has the XNA runtime installed is simply a case of running two installers (.NET Client Framework 4 and XNA 4.0 Runtime installers).  You would need to ensure they have the correct .NET framework installed anyway.  May as well run the XNA runtime installer along with it.

    You are welcome to try using the Windows port.  I don't really see why though when XNA is fully supported on Windows and is more complete than MonoGame (it has a full content build pipeline and Visual Studio integration).

    Coordinator
    Jul 23, 2012 at 8:11 PM

    > There were recent updates to allow music on Metro.

    Yes... Song and SoundEffect are both fully working on Metro.  They even use the same XNB content files as desktop XNA.

    > Do you know of any benifit to using MonoGame for
    > Windows rather than the real XNA for Windows?

    I see no performance benefit to using MonoGame using OpenGL on a Windows platform.  As Sly said the purpose of the Windows version of MonoGame so far has been for easier GL development.

    Moving forward we expect to contribute a MonoGame for Windows Desktop using DX11.  This should be as fast as stock XNA if not faster and will allow MonoGame to evolve past the XNA4 APIs where needed.

      - Tom

     

    Jul 26, 2012 at 3:44 AM
    TomSpilman wrote:

    @slygamer

    No prob... I totally understand that.  I'm just in a good place to focus all my time on it which is why i'm making good progress.

    Speaking of input...  I think maybe we either should a) not redirect touch events into mouse state or b) make it an optional toggle for the developer.

    First off it seems "IsPrimary" is a bad thing to test for.  On my Win8 PC which has both  a mouse and touch screen connected... both mouse events and touch events return IsPrimary as true.  Not sure if that is the intended behavior for that value or a bug in WinRT.  Time will tell.

    Still for our game how the input is tuned for mice vs touch is different... so we need to know that when we get mouse input that it really is the mouse and not coming from touch.  Also strange is a sudden touch becoming a mouse click with a large deltaXY…  in our game a this becomes camera jump as it sees what it thinks is a sudden drag with the mouse button held.

    We could work around these issues, but I think for some games fake mouse state is a bad thing.  So maybe it is worth making it an optional toggle on MouseState?

      - Tom


    I think not directing it to mouse is the right way to go as you are noting here. (I am only catching up to this part of the thread as I have started implementing touch and mouse). I'll try to look into why the primary flag is set on both.

    Since Windows8 auto-scales to the screen dimensions, does it makes sense that the input coordinates are still at the resolution of the screen? 

    e.g. setting preferredBackBufferWidthHeight to 1024/720 gives me that view port and all drawing goes through that view port.  But if I click on the far right of my screen, I get the furthest width of the screen (1600).

    Since this is my first time doing mouse/touch in XNA, perhaps I am missing a scaling somewhere in the input library?

    Thanks in advance for any help.

    Coordinator
    Jul 26, 2012 at 3:49 AM

    We should do what XNA on Windows does when in fullscreen mode in regards to mouse coordinates.  I haven't tried it myself, but I imagine it would return mouse coordinates in terms of the back buffer (since in Windows it is actually changing video mode).  Even though on Windows 8 it is scaling the back buffer to the native display, we should still return the mouse coordinates in terms of the back buffer rather than the screen.  The same would also apply to touch input.

    Jul 26, 2012 at 3:58 AM
    That is correct. I have indeed did this to my framework on win8. If I remember correctly, you just need to divide the x and y by the ratio of the real screen size by the backbuffers's size. Its an easy fix.

    From: slygamer
    Sent: 7/25/2012 23:49
    To: azchohfi@hotmail.com
    Subject: Re: Metro Status? [MonoGame:353549]

    From: slygamer

    We should do what XNA on Windows does when in fullscreen mode in regards to mouse coordinates. I haven't tried it myself, but I imagine it would return mouse coordinates in terms of the back buffer (since in Windows it is actually changing video mode). Even though on Windows 8 it is scaling the back buffer to the native display, we should still return the mouse coordinates in terms of the back buffer rather than the screen. The same would also apply to touch input.

    Jul 26, 2012 at 4:37 AM

    I agree; since it is always "fullscreen" on windows8.


    From: slygamer [notifications@codeplex.com]
    Sent: Wednesday, July 25, 2012 7:49 PM
    To: Patrick Dengler
    Subject: Re: Metro Status? [MonoGame:353549]

    From: slygamer

    We should do what XNA on Windows does when in fullscreen mode in regards to mouse coordinates. I haven't tried it myself, but I imagine it would return mouse coordinates in terms of the back buffer (since in Windows it is actually changing video mode). Even though on Windows 8 it is scaling the back buffer to the native display, we should still return the mouse coordinates in terms of the back buffer rather than the screen. The same would also apply to touch input.

    Coordinator
    Jul 26, 2012 at 7:31 AM

    > We should do what XNA on Windows does when in fullscreen mode

    Agreed....  someone should test the behavior and report back.  Might also want to see what WP7 does when the backbuffer is set to a lower resolution.

      - Tom

     

    Coordinator
    Jul 26, 2012 at 7:54 AM

    One thing I do know for Windows Phone for touch input is that you can set the TouchPanel DisplayWidth and DisplayHeight properties and it will scale the touch inputs to those dimensions.  This is separate to the back buffer dimensions.  Will do some more investigation.

    Coordinator
    Jul 26, 2012 at 1:53 PM

    TouchPanel behaviour on Windows Phone.

    • TouchPanel.DisplayWidth and DisplayHeight are 0,0 before the GraphicsDevice is created.
    • When the GraphicsDevice is created, TouchPanel.DisplayWidth and DisplayHeight are set to the back buffer size, e.g. setting preferred back buffer size of 320x240 results in TouchPanel having a size of 320x240.
    • After the GraphicsDevice is created, TouchPanel.DisplayWidth and DisplayHeight can be set to any values greater than zero and TouchLocation.Position values returned by TouchPanel.GetState() will be scaled to 0 <= x <= DisplayWidth - 1 and 0 <= y <= DisplayHeight - 1.
    • An oddity in the scaling.  The values returned will be clamped between zero and one less than the width and height.  For example, setting DisplayWidth to 2 will return fractional values between 0 at the left edge and 1 at the centre of the screen, and the value will be clamped to 1 all the way to the right edge of the screen.  Setting DisplayWidth to 4 will return fractional values between 0 and 3 for the left three-quarters of the screen and the right-most quarter of the screen will return exactly 3.
    Jul 26, 2012 at 4:07 PM

    Silly question,

    Can I do this on top of the Monoframework, or does this have to be done IN the framework. I cannot find screen size other than Viewport which always seems to be the same size as the backBuffer.

    -Patrick


    From: azchohfi [notifications@codeplex.com]
    Sent: Wednesday, July 25, 2012 7:58 PM
    To: Patrick Dengler
    Subject: Re: Metro Status? [MonoGame:353549]

    From: azchohfi

    That is correct. I have indeed did this to my framework on win8. If I remember correctly, you just need to divide the x and y by the ratio of the real screen size by the backbuffers's size. Its an easy fix.

    From: slygamer
    Sent: 7/25/2012 23:49
    To: azchohfi@hotmail.com
    Subject: Re: Metro Status? [MonoGame:353549]

    From: slygamer

    We should do what XNA on Windows does when in fullscreen mode in regards to mouse coordinates. I haven't tried it myself, but I imagine it would return mouse coordinates in terms of the back buffer (since in Windows it is actually changing video mode). Even though on Windows 8 it is scaling the back buffer to the native display, we should still return the mouse coordinates in terms of the back buffer rather than the screen. The same would also apply to touch input.

    Jul 26, 2012 at 5:23 PM
    I'm gonna check this and send you my code, but I'm almost sure that I use only what monogame gives me, so you should be able to do it inside the framework.

    From: patrickdengler
    Sent: 7/26/2012 12:07
    To: azchohfi@hotmail.com
    Subject: Re: Metro Status? [MonoGame:353549]

    From: patrickdengler

    Silly question,

    Can I do this on top of the Monoframework, or does this have to be done IN the framework. I cannot find screen size other than Viewport which always seems to be the same size as the backBuffer.

    -Patrick


    From: azchohfi [notifications@codeplex.com]
    Sent: Wednesday, July 25, 2012 7:58 PM
    To: Patrick Dengler
    Subject: Re: Metro Status? [MonoGame:353549]

    From: azchohfi

    That is correct. I have indeed did this to my framework on win8. If I remember correctly, you just need to divide the x and y by the ratio of the real screen size by the backbuffers's size. Its an easy fix.

    From: slygamer
    Sent: 7/25/2012 23:49
    To: azchohfi@hotmail.com
    Subject: Re: Metro Status? [MonoGame:353549]

    From: slygamer

    We should do what XNA on Windows does when in fullscreen mode in regards to mouse coordinates. I haven't tried it myself, but I imagine it would return mouse coordinates in terms of the back buffer (since in Windows it is actually changing video mode). Even though on Windows 8 it is scaling the back buffer to the native display, we should still return the mouse coordinates in terms of the back buffer rather than the screen. The same would also apply to touch input.

    Aug 1, 2012 at 4:58 PM

    Here is the adjustment:

                    Vector2 pos = new Vector2(mouseState.X, mouseState.Y);
                    float propX = this.GraphicsDevice.Viewport.Width / (float)this.Game.Window.ClientBounds.Width;
                    float propY = this.GraphicsDevice.Viewport.Height / (float)this.Game.Window.ClientBounds.Height;
                    pos.X *= propX;
                    pos.Y *= propY;
    

    This will make sure that Mouse input is on the correct location, no matters the resolution.

    Aug 1, 2012 at 6:15 PM

    Excellent! Thanks!

    -Patrick

    From: azchohfi [email removed]
    Sent: Wednesday, August 1, 2012 8:58 AM
    To: Patrick Dengler
    Subject: Re: Metro Status? [MonoGame:353549]

    From: azchohfi

    Here is the adjustment:

                    Vector2 pos = new Vector2(mouseState.X, mouseState.Y);
                    float propX = this.GraphicsDevice.Viewport.Width / (float)this.Game.Window.ClientBounds.Width;
                    float propY = this.GraphicsDevice.Viewport.Height / (float)this.Game.Window.ClientBounds.Height;
                    pos.X *= propX;
                    pos.Y *= propY;

    This will make sure that Mouse input is on the correct location, no matters the resolution.

    Aug 1, 2012 at 6:20 PM

    Someone should submit a PR to fix this on develop3d branch.

    Coordinator
    Aug 6, 2012 at 8:08 AM

    Sorry... gmail was throwing all these discussion emails into the spam folder, so i'm playing catchup.

    Take a look at my thread here...

      http://monogame.codeplex.com/discussions/390041

    ... I have a branch there people interested in this scaling issue should test.  I want to get it finished up and submitted in the next day or two.

      - Tom

     

    Aug 9, 2012 at 9:03 PM

    Quick question: how far off is simple video playback? I was looking at the MediaPlayer and I am suspicious that it is super close:

    What would I need to send to the TransferVideoFrame function (or is this all wrong?)

                var folder = Windows.ApplicationModel.Package.Current.InstalledLocation;
                var file = folder.Path + "\\videos\\" + "v.mp4";
                Uri videoURI = new Uri(file);
                _mediaEngineEx.Source = file;
                _mediaEngineEx.TransferVideoFrame(); // ComObject dstSurfRef, VideoNormalizedRect? srcRef, Rectangle dstRef, ColorBgra? borderClrRef)
                _mediaEngineEx.Play();
    

    If anyone has an idea I can try, please let me know, though I don't think I want to keep transferring frames on my part.

    Coordinator
    Aug 9, 2012 at 9:08 PM

    @Patrick

    In theory with the work that Alex did in SharpDX to expose MediaEngine we should have everything we need to implement video playback.  I couldn't tell you how to do it really...  i've never even looked at the video APIs in XNA. 

    Really all we need is someone with the need and time to implement it in MonoGame.

      - Tom

     

    Oct 21, 2012 at 6:48 AM

    @TomSpilman  I am facing one issue with the MonoGame . When i run the project in "build " mode then it works fine but when i turn on to "release " mode then it gives error in loading the contents and also the whole project is not showing the option of creating the app package , I mean the "create app package" option is disabled .

    Any clue.?

    Thankyou

    Ojas Sinha