In Windows Phone XNA 4.0, I am receiving the following error when compiling: the windows phone platform does not support custom shaders.
This is really annoying, because I have an Xbox 360 version of the project, and a Windows version of the project as well.
I tried using the compilation based #if !WINDOWS_PHONE and #endif, but with no luck. It seems as if it ignores this.
How can I make this file be excluded or ignored when compiled in the Windows Phone project?
As a workaround, you could:
Create separate game and content projects for WP7 and Xbox
Manually switching the 'Build Action' from 'Compile' to 'None' on WP7 (for masochists only)
Since the asset build actions are defined in the .contentproj file, you could have 2 versions of it or write a script that modifies it (and the script could probably be run as a part of the compilation process automatically)
Since you might also want to use smaller textures etc. on WP7 than you are using on Xbox, I'd just create separate game and content projects for WP7 and Xbox and move the common game code to a library.
Oh, and tell me if you figure how to select a different content project based on, e.g., the solution configuration so that the separate game project is not needed :)
Custom shaders for XNA games, on Windows Phone 7, are not supported, but I don't know about any capabilities for SilverLight.
There are several built in effects that can be used in XNA however:
•SkinnedEffect
•EnvironmentMapEffect
•DualTextureEffect
•AlphaTestEffect
Games that target the XNA Reach profile are going to be cross platform as the Reach profile contains elements that are shared across all implementations of XNA. To use more advanced options the Hi-Def profile would need to be targetted. But Hi-Def doesn't have compatibility with Windows Phone.
Just a guess, but can you use #ifndef WINDOWS_PHONE instead?
Related
I want to use a Microsoft Surface 4 pro to test my app built with Unity, I can see there are 2 options, either through Windows Store or simply make a PC standalone .exe file and run it on the device.
My question is will it make a difference in terms of how touch inputs or any other aspect of the app are handled?
Thank you,
It depends on requirements.
If your App is traditional window based with title bar etc and it only supports simple mouse events click, double-click, right-click, scroll etc you should go with Stand-alone build. If it contains features of smart app like multi-touch input, pinch etc. go with Windows store App.
NOTE: For Windows Store App there are certain requirements like Windows 10 SDK etc. And there are few things that are not supported. Read More
You should ask this type of questions on Unity 3D forum, as this is not a programming related question.
Hope this helps
kudan community. I'm developing an application where I need to use augmented reality, but my application will run on windows computer with two monitors (where one is projecting the augmented reality), connected with a webcamera. Also I need to track an object (not a marker).
I was testing this with the vuforia library and it works on the unity editor, but doesn't work when I try to compile the application on windows. (I know that now vuforia support universal windows apps, but I can't make this works and also from what I see doesn't support multiple monitors).
So I saw that kudan support windows and object tracking but I read the tutorial and wikis and I can't seem make it work.
Any body can guide me on the right track on how achieve this?
PD. I'm using unity engine 5.4 and windows 10 os
I'm looking for source code (as I bet a lot of others are / were and will) for learning purposes of DirectX. I would like something similar to the vs2013 Graphics Editor when dealing with *.fbx files, etc. Every thing I find is old and outdated, or way to simple and does not show the basics like transformation cursor, picking objects or points on objects. I'm just looking for something basic.
many thanks in advance
The DirectX Tool Kit is a good place to start and includes some tutorial content as well. It supports loading models using the VS 2013 content pipeline that produces CMOs from FBX files.
You didn't state if you were looking to write a Windows desktop application (aka a Win32 application) or if you were looking to write for Windows Store / Windows phone. DirectX Tool Kit supports either, although the tutorial is written using a Windows desktop application template so that developers using Windows 7 could also utilize it.
You should also refer to the DirectX SDK Samples Catalog for locations of updated versions of the legacy DirectX SDK samples that build fine using VS 2013 only.
I've currently built a service layer and API which I'm consuming from an ASP.NET website, Windows Phone app, and a Windows 8 metro app - the key to all of them being a project containing model classes which is a portable class library project, and is shared as a reference between all of them. This architecture works fine and without any issues.
However, I've recently started experimenting with Xamarin - specifically the iOS functionality (with a view to moving onto Android later). My initial assumption was that I would be able to utilise this model library as I do with the other projects - however, I've since realised this this isn't the case.
When I first added a reference to my model class library to my Xamarin.iOS project (in Visual Studio), I was greeted by the error:
'The current project does not support references to Portable Library projects'.
Strange - as I thought this would be a scenario that would be supported. I found a post here which suggested a fix that forced Visual Studio to detec the Monotouch (Xamarin) framework as supporting Portable Library Projects. Seemed to be exactly what I needed - but no. When I added the reference again, I was greeted by a different error:
'The current project's target framework is not compatible with that of the Portable Library project'.
And it suggests I change the target framework in the project properties. Except I can't, as the Xamarin iOS project needs to support Monotouch (and I can't change it to anything else from the GUI anyway). So I tried to change the model library's properties instead - maybe I can do something there. And it looked like I could. I can check Monotouch (Xamarin) as a supported platform here (where Windows phone, Windows store, etc are already checked), but it won't let me save. It just shows the message:
'There is no additional functionality that is supported by the target frameworks you have selected'
After some research, I discovered that the only way Xamarin suggest to share code is to use separate projects with linked code files (so in effect, a pseudo-single code base. Which I have tried and works - but it seems a hack. See here:
http://docs.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options
So is this the only option? Or is there any way to have a true single class (model) library across all platforms, including Microsoft and Xamarin?
It is currently possible to use Portable Library Projects - e.g. profile 104 - across all of .Net4.5, WP, WinRT, Xamarin.Android and Xamarin.iOS
It is also currently possible to use the output binary assemblies across .Net4.5, WP, WinRT and Xamarin.Android - but not current against Xamarin.iOS.
This situation is changing 'very soon' now with Xamarin adopting full PCL support - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html and listen to http://hanselminutes.com/362/ios-and-android-apps-with-xamarin-studio-20-and-miguel-de-icaza
I personally deliver MvvmCross (and a lot of apps that use MvvmCross) using PCLs - and have done for the last 6 months - but there is some setup pain involved in this currently. For some info see my blog:
http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
http://slodge.blogspot.co.uk/2013/03/xamarinios-with-mvvmcross-in-vs2012.html
I do hope to provide an update on this in the very near future - it should work 'out of the box' soon.
The future is bright on Xamarin side, as it is going to support .NET 4.5 profile on all its platforms,
http://blog.xamarin.com/brave-new-async-mobile-world/
The only problem as far as I can see comes from Microsoft side, who refuses to unify its own platforms to a common profile (Windows 8 and Windows Phone 8 are still messy tailored versions no better than CF or Silverlight in my own situation).
Portable class libraries are out there, but as a library author (#SNMP) I rather build separate project files for my own projects as Xamarin suggests.
Fist of all I want to say that I've read these two discussions:
How to organize Windows Phone code base to target both 7.x and 8 platforms and
Windows Phone 7/WPF - Sharing a codebase. So, I know about Portable Class Librariy project type which might be an answer to my question. But it isn't an answer for my case.
Problem
I have some old code-base in my project WindowsClassLibraryNetFw35. I need this project to be a class library which targets .NET Framework 3.5. The reason for it is that some dependent applications are deployed on customers' machines which don't have .NET Framework 4+ installed. Unfortunately I can't force my customers to upgrade their environment.
Now I create new project(s) for Windows 8 and Windows Phone 8. As you know, Windows Phone 8 projects will fail when I attempt to reference my old library because it is not a compatible Windows Phone project (see screenshot).
Question
What is the best way to reorganize my project type(s) in order to be able to support both my old and new projects?
I would still aim to get a PCL working, but if that fails, you can use the same code in two different projects.
Create two different projects, one Windows Phone, the other a Windows Store App. Add a file to one, then add that other file as a link to the other project. This means you have a single source file between two different projects, but will be compiled with each respective runtime tools. Then you can do things like this in your code:
void Foo()
{
#if WinRT
//WinRT specific code here
#elif WindowsPhone
//Silverlight specific code here
#endif
}
Just add the respective compiler constants on the Build tab of your Windows Phone and WinRT projects. This is far a more tacky solution, but sometimes its the only approach that works.