I'm trying to do some profiling on my OpenGL ES code. Somewhere in my GPU pipeline (a shader I believe) is causing a huge delay. Which is the best profiler I can use? Is this one a good option? is there one I can use directly within Visual Studio?
If you have a GPU performance issue on IOS, the best is to use XCode tools to profile it directly on device, running the app from Xcode and then doing a frame capture to look at the timings for each draw call / the number of cycles used by each shader (more info here)
You can also profile on Windows if you are also able to simulate your graphics pipeline in classic OpenGL in your Windows version, but this may not be a good idea as the iPhone's GPU is very different than a classic desktop GPU so the bottleneck might not be the same on Windows than on IOS.
To profile on Windows I would suggest using either Nvidia PerfKit (if you have a Nvidia card) or AMD's GPU PerfStudio if you have an AMD card.
There is also RenderDoc which is a nice tool but not sure if it provides much profiling information (it is more for debugging graphics issues than profiling)
Is there a "Best" version of Windows that runs AIR the best?
The AIR application mainly plays MP4s and still images in a loop.
Also, when publishing for AIR 3.4 for Desktop what are the best settings?
What should be selected from the below?
Hardware Acceleration:
None
Level 1 - Direct
Level 2 - GPU
Render Mode:
Auto
Direct
CPU
Thanks!
The GPU is to use with graphic objects (besides that normally responds faster).
The CPU When your code makes many calculations.
In my opinion, you should then use:
Level 2 - GPU
Render Mode: Auto
I am developing an Android application with jQuery Mobile, Phonegap and the jQuery plugin for Google maps. The emulator takes too long to load a web page, making the test of my code a painful operation. I have installed Android x86 on a virtual machine and linked it to Eclipse to debug my application.
This solution is faster than the emulator but the problem is that my application always crashes, which is not the case in the emulator. This leads me to question: is Android x86 on a virtual machine a stable alternative to the emulator?
In my experience, the answer is definitely Yes.
Unlike the situation you are describing, my application never crashes on the Android-x86 VM and since the SDK's emulator doesn't support microphone input, it is actually the only way to test my app without having to purchase a real device for each variant of Android.
Also, as you noted, it runs much faster. Contrary to Google's claim for "near native speed", Android's SDK runs extremely more slowly than Android-x86 and it is certainly slower than a real phone or tablet.
The fact that your application crashes when run on an Android-x86 VM may actually be a good thing: An opportunity to check for ways to make your application more robust in unforeseeable circumstances (you know, there are many types of devices out there).
The only downside to Android-x86 is that it is only available up to ICS (Android 4.0.4) which means that you cannot test your application in Jelly Bean (Android 4.1.x). That may be solvable by building your own VirtualBox-AOSP.
A lot of virtualization software and systems depend on hardware virtualization capability of the CPU (VT and such), but VirtualBox runs Android x86 (eeepc iso) great (fast) even without it. There are obvious limitations, but bear in mind that any emulator can only go so far.
If your CPU has no support for hardware virtualization, it is a very good alternative.
Google's Android SDK Emulator went native since version 17.
Google said in their ADT version-17 changelog
One of the new features is a big update
to the Android emulator – contributions to AOSP from Intel mean that
the emulator now runs at near native speed on Windows and Mac OS X.
So you shouldn't be seeing huge differences In speed of the application running if you are using the latest version of sdktools and emulator.
I am looking for tools and techniques for prototyping (virtual prototyping), simulation, and testing of deeply embedded C code on desktop Windows, including building realistic embedded front panels consisting of buttons, LEDs, and LCD displays (both segmented and graphic).
I'm specifically interested in a possibly low-level approach, using pure C code and raw Win32 API rather than MFC, .NET/C#, vxWidgets or Qt. I'd also like to use free development tools, such as Visual C++ Express with Platform SDK and ResEdit for editing resources.
I'm looking for code examples to render graphic LCDs (from monochrome to 24-bit color) with efficient pixel-level interface, multi-segment LCDs, and owner-drawn buttons that respond both to "depressed" and "released" events.
I am surprised that my original question triggered so many misunderstandings and adverse comments. The strategy of developing deeply embedded C code on one machine (e.g., a PC) and running it on another (the embedded microcontroller) is called "dual targeting" and is really quite common. For example, developing and testing deeply embedded code on the PC is the cornerstone of the recent book "Test-Driven Development for Embedded C" by James Grenning.
Avoiding Target Hardware Bottleneck with Dual Targeting
Please note that dual targeting does not mean that the embedded device has anything to do with the PC. Neither it means that the simulation must be cycle-exact with the embedded target CPU.
Dual targeting simply means that from day one, your embedded code (typically in C) is designed to run on at least two platforms: the final target hardware and your PC. All you really need for this is two C compilers: one for the PC and another for the embedded device.
However, the dual targeting strategy does require a specific way of designing the embedded software such that any target hardware dependencies are handled through a well-defined interface often called the Board Support Package (BSP). This interface has at least two implementations: one for the actual target and one for the PC, for example running Windows. With such interface in place, the bulk of the embedded code can remain completely unaware which BSP implementation it is linked to and so it can be developed quickly on the PC, but can also run on the target hardware without any changes.
While some embedded programmers can view dual targeting as a self-inflicted burden, the more experienced developers generally agree that paying attention to the boundaries between software and hardware is actually beneficial, because it results in more modular, more portable, and more maintainable software with much longer useful lifetime. The investment in dual targeting has also an immediate payback in the vastly accelerated compile-run-debug cycle, which is much faster and more productive on the powerful PC compared to much slower, recourse-constrained deeply embedded target with limited visibility into the running code.
Front Panel Win32 GUI Toolkit
When developing embedded code for devices with non-trivial user interfaces, one often runs into the problem of representing the embedded front panels as GUI elements on the PC. The problem is so common, that I'm really surprised that nobody here could recommend an existing library or an open source project, which would provide a simple C-only interface to the basic elements, such as LCDs, buttons, and LEDs. This is really not that complicated, yet it seems that every embedded developer has to re-invent this wheel over and over again.
So, to help embedded developers interested in prototyping embedded devices on Windows, I have created a "Front Panel Win32 GUI Toolkit" and have posted it online under the GPL open source license (see http://www.state-machine.com/win32). This toolkit relies only on the raw Win32 API in C and currently provides the following elements:
Dot-matrix display for an efficient, pixel-addressable displays such as graphical LCDs, OLEDs, etc. with up to 24-bit color
Segment display for segmented display such as segment LCDs, and segment LEDs with generic, custom bitmaps for the segments.
Owner-drawn buttons with custom “depressed” and “released” bitmaps and capable of generating separate events when depressed and when released.
The toolkit comes with an example and an App Note (see http://www.state-machine.com/win32/AN_Win32-GUI.pdf), showing how to handle input from the owner-drawn buttons, regular buttons, keyboard, and the mouse. You can also view an animated demo at http://www.state-machine.com/win32/front_panel.html.
Regarding the size and complexity of the "Front Panel Win32 GUI Toolkit", the implementation of the aforementioned GUI elements takes only about 250 lines of C. The example with all sources of input and a lot of comments amounts to some 300 lines of C. The toolkit has been tested with the free Visual C++ Express 2010 (with the Express Edition Platform SDK) and the free ResEdit resource editor.
Enjoy!
The appliances you mention in your comment clarification to the question will never be using a windows PC, so low level windows programming is not a requirement in that case. In fact, I'd say its undesirable. Prototyping is about speed. It's about how fast you can put something together to show potential investors or upper management or some other decision maker.
You wouldn't want to spend the extra time with low level C and Win32 api until the project requirements were flushed out enough that you knew that was an absolute requirement for the final project deliverables (perhaps a server/PC monitoring tool?). Until then you want speed of development. Lucky for you the industry has tools for rapid prototyping and development of hardware like you describe.
My Preference for Prototyping with Embedded Development
As for my opinion as a developer, I like the .net microframework (.netmf) simply because I'm already a Microsoft .Net developer and can transfer a lot of my existing skills. Therefor I prototype with a FEZ microcontroller using C# under Visual C# Express 2010 (free as you required). Its fast, easy and you are working on the core of your project in minutes.
If your experience as a developer is different, you may look for a micro controller which is programmed using BASIC, Java or some other language to help with the speed of development by reusing your core skill set.
Addressing your Question Bounty Comments
Astonishingly large portions of the embedded software can be developed
on the desktop computer as opposed on the deeply embedded target. This
avoidance of the "target system bottleneck" can potentially improve
productivity by an order of magnitude, if done right. However, to
develop embedded software on the desktop, one needs to simulate the UI
components, such as displays (both segmented and increasingly
graphical), LEDs, knobs, and buttons. I'm looking for such UI
components written in plain Win32 API in C for easy integration with
embedded code to be developed and tested on the desktop Windows.
I did embedded development full time professionally for well over 4 years as well as many years surrounding that part time. While what you said above is somewhat true, it will not save you time or money which is why everyone is confused about the motivation for this strategy. We spent years trying to put out a windows emulator for this company's hardware devices that would theoretically save time for prototyping. It was always a pain and we spent many more hours of work trying to emulate the experience than if we just went straight from sketched UI drawing specs to real development. The emulator lagged behind hardware development and often wouldn't support the latest features until 6 months or more after the hardware was released. It was a lot of extra work for very little value.
You will spend more of your time developing non-reusable win32 platform code and hardware emulation components than actually writing the code for the core project itself. This only ever makes sense for hardware vendors who provide this emulator as a 'value add' tool to potential 3rd party developers, but it does not make sense for prototyping new hardware designs.
Modern development environments like Visual C# Express 2010 with a FEZ microcontroller can compile, push the project output to the microcontroller, and then begin debugging just as fast or faster than you could compile and run a low level windows app in C emulating LCDs or LEDs or switches, etc... So your comment, "improve productivity by an order of magnitude", is simply no longer true with modern tools. (It may have been prior to the last 10 years or so.)
If you really, truly just want to simulate the embedded hardware visually on a PC use something like adobe flash to mock up a UI. But don't duplicate code by coding for windows when the final device you are prototyping won't be running windows (maybe it will be, but you didn't say that). Use the fastest most reliable prototyping tools available today, which is unequivocally not low level C and win32 api!
Maybe use StackExchange for Electronics?
Because this is a development oriented site, discussion about the merits of specific embedded hardware isn't really relevant. If you decide to refocus on using microcontroller electronics for prototyping (Arduino, FEZ, Propeller, Basic Stamp, Pololu, etc) you might ask for electronics hardware advice on stackexchange for electronics. I will say that most of those platforms are designed to facilitate the prototyping of LCDs, LEDs, buttons and interfaces as you outlined. You can usually assemble a few pre-built modules in a matter of minutes and be ready to start coding your project. Huge time savings can be had here.
You are asking for too much you need to take a look # proteus.
http://www.labcenter.com/products/vsm_overview.cfm
As Mahmoud said, you may find your code solution with prototyping example in proteus professional. It is one of popular software for prototyping, simulation and coding, you can download proteus professional for free and check their manual.
Best of luck
What is the relationship between XNA and XNA for Windows Phone?
Is that latter a true subset of the former like the .NET Client Profile?
Mostly a subset (like Silverlight vs Silverlight for Windows Phone)?
Or is it simply a similar API like WPF vs Silverlight?
They're identical in terms of the XNA API, and both are developed using the same download, typically XNA + C# + Visual Studio.
There are differences in what each platform supports though. For XNA in general I'd always consult Shawn Hargreaves blog first, and this article is most relevant: http://blogs.msdn.com/b/shawnhar/archive/2010/03/10/xna-game-studio-on-windows-phone.aspx
The biggest differences vs Xbox 360/Windows are display resolution, input methods available, and the fact that Windows Phone 7 doesn't support programmable shaders (so you can't write your own velvet/Fresnel shader for WP7, but you can for Windows and the 360).
Performance also varies: on Windows XNA performs well without much effort as it runs on the full .NET Framework. On the 360 and WP7, it runs on the .NET Compact Framework, so whilst you get the full XNA API you only have access to a subset of the full .NET Framework (though in a typical game you won't miss much of it) plus its garbage collection is shocking so depending on your game you may really have to watch memory allocation.
According to the following MSDN page, it's a subset of full XNA:
http://msdn.microsoft.com/en-us/library/gg490768.aspx
If you're considering writing XNA games for Windows 8, you may want to hold fire, as it's none too clear if XNA is still a long-term strategy for Microsoft (at least, if their comments at the recent BUILD conference are anything to go by):
http://www.rabidlion.com/2011/09/opinion-why-xna-isnt-dead-yet.html