I am developing an in-house app that would use XInput or DirectInput to read from the Xbox 360 controller. (I think it'll be the cheapest/easiest way to get multiple controls in the operator's hands.)
I will need to source-control all source and tools, which means also the SDK's. I'd rather not take all of DirectX -- is DirectInput and XInput separable from the whole DirectX SDK?
The short answer is no. Technically it would be possible to extract the required portions of the runtime, but if you look at the SDK EULA and redistribution agreement you will see that you're only allowed to install the full DirectX runtime.
Related
In my simple mind, it seems useful to ship a nice image of your joystick with an index of the button and axis locations on the image. Can such a thing be queried through the XInput or DirectInput APIs? Would it be driver-specific, and if so which drivers support this?
In particular, I want to support Logitech wheels and XBOX 360 controllers. The Logitech Profiler seems to come with this information (or pull it from the driver). Is it accessible in my code as well?
I see the image of the joystick show up in the game controller properties, but I assume that entire property page is reported from the driver?
XInput does not supply this and it is not supposed to, XInput is an interface for accessing the state of the controller and the capabilities of the controller. This is something that you would detect manually in your code, finding the correct device id and I believe this is what the Logitech Profiler does as well (since it is a custom application for Logitech), it simply has the images as resources in the program itself.
What is commonly done is that you contact Microsoft, Sony, Nintendo or Logitech and they will have high quality images of their controllers that are approved for use in games. Specifically for images of the controller in console games there are certain requirements that you need to follow. The same requirements do not follow for games for windows and other operating systems but you should still be able to retrieve this information from Microsoft and Logitech.
By retrieving the resources yourself you can also convert them to a format that suits the interface where you are presenting them.
Since the Windows XInput API was created specifically for the XBox 360 controller, it's possible to make a great deal of assumptions about the controller layout. Even now, after the release of official drivers for the XBOne gamepad, the official API documents go out of their way to explicitly limit discussion to the 360 pads.
If I write a DirectX 11 application using the DX11 SDK, and I don't have a DirectX card, will I be able to run the application?
I can't find the requirements for actually using the DX11 SDK.
Thanks!
Yes you can. What you are looking for is called Direct3D feature levels. With this
paradigm you can write an application with the features supported by your graphic card. Before the creation of the D3D device you can query the card and find the feature level supported, then you use this level in the device creation.
Of course you cannot use the new features provided by DirectX 11 on your hardware.
This tutorial site states that when setting up a device and swap chain, a D3D_DRIVER_TYPE of D3D_DRIVER_TYPE_REFERENCE can be used to allow DX11 features
to be explored even if you don't have a DX11 graphics card.
For further reading, click that link and scroll down halfway until you see D3D11CreateDeviceAndSwapChain().
I'm working on a project that will use an AMD GPU for processing data. I noticed AMD has two different SDKs available on their website for using the GPU: ATI Stream Technology and
OpenCL™ and the AMD APP SDK. It looks like both support OpenCL but I haven't found anything on the site explicitly pointing out why one would use one over the other. What's the difference between these two?
The AMD APP SDK is here: http://developer.amd.com/sdks/AMDAPPSDK/Pages/default.aspx
The website should also answer your question about the difference between Stream and APP:
AMD Accelerated Parallel Processing (APP) SDK (formerly ATI Stream)
It used to be called AMD Stream SDK, they probably renamed it after adding support for non-Firestream hardware (namely OpenCL)
stream is the higher level amd-specific project (hardware and software) that includes opencl as the current software implementation. stream originally used the "brook" language, but switched to opencl in 2011. since then opencl became more popular (because it is a cross-platform standard that has been particularly well supported by apple) and these days amd doesn't seem to mention stream much. you can see this in a link like http://www.amd.com/us/products/technologies/stream-technology/opencl/pages/opencl.aspx where opencl is a "child" of stream (or the menu on the left of that page, where the higher level group is stream; other children are related to hardware).
in short, you want opencl. and despite the confusing mess that is amd's site, their opencl implementation is pretty solid.
hmmm. re-reading your question you seem to say there are two separate sdks. do you actually drill down to two different packages? my understanding is that opencl is the stream sdk. if you have found two different sdks (that are both current) can you link to them?
I've been reading about Andrew Russell's ExEn project and I'm wondering what the flow would be like for creating a WP7 accelerometer-based game and then porting it to another platform, say iOS. Here's what I hope would happen:
Create fully functional game in XNA, avoiding dependance on device
specific items like the 'back' button.
Run the project through ExEn (I have no idea on how this would
happen), creating fully functional iOS game.
Run game on iPhone.
Sorry for that pitiful outline, but I just don't have a solid high-level view after reading about it.
Also, being software conversion, surely it wouldn't totally work. How would you iron out the wrinkles? I assume you'd have to know iOS or Android fairly well to pin it down.
Anyway, if anyone can move me one step closer I would appreciate it.
ExEn is an implementation of a subset of the XNA API that runs on different platforms (including iOS and Android). Put simply, it makes the classes and methods that you use when writing XNA code available to you on these other platforms. (Plus appropriate instructions, examples, etc.)
When using ExEn, the bulk of your code should simply "just work". However in most real-world cases you will need to write at least some platform-specific code (and probably provide some platform-specific assets). In particular to support different device resolutions, and also in cases where you use XNA features not available in ExEn.
At time of writing, ExEn does not implement the XNA/WP7 APIs for accelerometer support. At some time in the future they may be added (either by me or anyone who wants to contribute a patch). ExEn is distributed as source code, so you could even add the necessary support yourself.
The alternative would be to write platform-specific code for the parts of your game that query the accelerometer. Using ExEn does not prevent you from also using the APIs of the underlying platform.
ExEn (on iOS and Android) runs on top of Xamarin's MonoTouch and Mono for Android products. These two products provide C# bindings for the underlying platform APIs. Also, much like ExEn implements the XNA APIs, Mono implements the .NET APIs. These products also provide you with the tools you need (IDE, compiler, debugger, etc).
So the iOS API that you would use is UIAccelerometer (doc). This is exposed in C# via MonoTouch.UIKit.UIAccelerometer (doc). I'll leave looking up the Android equivalents as an exercise.
You can't expect:
porting a game to other platform and don't modify it.
porting a game with special platform inherent abilities to other platform that lacks this abilities, or vice versa
Every indication I have, based on my experience in embedded computing is that doing something like this would require expensive equipment to get access to the platform (ICE debuggers, JTAG probes, I2C programmers, etc, etc), but I've always wondered if some ambitious hacker out there has found a way to load native code on a Blackberry device. Anyone?
Edit: I'm aware of the published SDK and it's attendant restrictions. I'm curious if anyone has attempted to get around them, and if so, how far they got.
I've seen this question pop up in a number of different forums over time. The original Blackberries were programmable in C++ but I think that RIM ran up against the problems of trying to implement a secure platform in the C/C++ compile to native paradigm.
The devices do have JTAG ports, but unless one could get hands on the RIM code as a place to start the problem is enormous.
I also have to wonder how useful a Blackberry with a replacement FOSS operating system would be, since it would not likely have the protocols to connect to BES or BIS, send PIN's etc. If one was simply looking for a the power of the hand held computing platform I suspect there are many more likely candidates available.
No, C++ is no longer a supported RIM development tool, as they phased it out a number of years ago. Client applications can be developed in Java (or one of a few 5GL frameworks), and web + sever-side apps can be developed using standard tools.
For those looking for updated information, the new Playbook os, also known as QNX, also known as Blackberry 10 (or it will be when the phones running it come out) is in fact c/c++ based, also using QML and a C++ add on called Cascades.
Unfortunately the official SDK website only seems to mention Java. According to wikipedia, different versions of the BlackBerry use different processors. Combined with the fact that RIM uses a proprietary operating system for the devices, it becomes pretty difficult to develop native code without official tools. There is also a partial API-level security restriction which would further prohibit advanced tinkering.
Just randomly searching for an answer to this and came across http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Native-C-C-SDK/td-p/778009 which mentions that BB intend to release a C/C++ SDK soon, more details will be provided at the 2011 Game Developer Conference.