I already know that iTunes has an interface that I can control, but the API is a bit opaque and I can't find it documented anywhere. Does anyone know of any good open-source or at least well-working media players that can be programmatically controlled?
In particular, I would like to be able to search a media library for a song by title or artist, and play, pause, resume, stop the song.
Ruby would be nice, because I'm working in it, but C would work too. I could write a wrapper.
Edit: My solution has to work on Windows, as that is the environment I am developing in.
XMMS works on a server / client basis. This means that it is relatively easy to control the playback, and the song queue. I'm not sure how easy is to handle file metadata (song info), but maybe that part can be handled independently.
Check this guide to get an overview of functions you can use.
Back in the day, I used MPD.
There are many applications for Windows these days that don't use native windows controls, don't have standard window frames and generally look different. What are some recommended techniques for creating such interfaces?
There are good reasons not to. Like that you will most likely not do a better job than Windows does. (Maybe it will look better (in your opinion), but will it behave?). Or that it's not what most users expect. Or that it will look like s**** on Windows 2011.
That said, it's not hard. You simply handle the WM_NC* events like WM_NCPAINT or WM_NCHITTEST. NC stands for Non Client (window area). And of course, there is a trick on Vista/Win7 (you have to announce it to the DWM).
From an implementation aspect, you could employ WPF (Windows Presentation Foundation) assuming you code for .NET :) It has pretty bunch of skinnable controls, that may look like native and may not.
From a design aspect, if your interface isn't going to follow documented standards (like the Windows UI guidelines), it has to be intuitive. I think the new generation of Windows applications will go through a growing phase in a manner similar to the early days of the Web. After a time, some standards or common themes will evolve.
Can you give us some sample applications? Some apps that don't use native windows controls use cross-platform GUI libraries, like Qt for C++ or Tkinker. These maintain the same look across different platforms.
I wouldn't really recommend making your user interface different deliberately. You don't stand to gain much. Your controls are almost always going to be buggier than native controls, and you are requiring the user to learn something new. Now, if you're controls add a large enough value to be worth the users' time it can be okay. But making them get used to different looking buttons is rarely worth it.
I`m not sure if this answer your question.
You can use third party skinning controls like from Infragistics, or SkinSoft for example.
But like Bubba said I`d recommend going for WPF.
Model-View-Controller! It's as valuable here as in web apps or anywhere else. Be sure to keep the part of your program that generates the custom UI separate from the part of your program that flashes the BIOS.
I know this question is 10 years old but none of the answers mention using an option in visual studio, dont know if it existed at the time.
Theres an option to remove the border of the window in visual studio (called borderStyle). Thats the easiest way to do it, using C#. After removing the border, all you have to do is create a new interface. If you're looking to do it in C++, i think you need to use DWM. I will let an example i found here.
https://github.com/melak47/BorderlessWindow
Another example (maybe without DWM? didnt test):
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b98c4c06-9581-44d3-8e5a-4adb2316e653/win32-about-styles-how-can-i-do-a-borderless-window?forum=vclanguage
There is a lot of people disencouraging to do it in this thread but there's no reason to not do it, if you know what you're doing your application can look great.
I'm starting a hobby game project on Windows that will make heavy use of 3D graphics effects. It will most likely be written in C++.
Should I use OpenGL or Direct3D for my graphics backend? Why?
Or should I use a ready-made graphics engine such as OGRE 3D? Which one?
Some "how to get started" links would be useful. (On either technology, or both.)
Edit - Yes I really meant Direct3D, not DirectX, thanks to graham.reeds for clarification
Edit - Mihai Lazar pointed out that I could also use a graphics engine such OGRE 3D. Edited the question to reflect this alternative.
Start with OpenGL because there are good textbooks and other online references on it. Once you get the hang of writing 3D game, you would be able to make the judgment for yourself.
Finishing a game, even if it's really stupid and simple just to get you going, is more important than picking the right library. With glut, you can get some 3D object to show up on your screen in a day. Start with NeHe's tutorials.
If you're willing to consider C#, take a good look at XNA. For hobby projects, assuming what you want is to actually get a game up and running instead of tinkering with complex API code, I cannot recommend it highly enough. It is increasingly mature, well-documented, and, compared to D3D/OpenGL, very quick and easy to use. As a bonus, with a $100/year Creators Club membership, you can even use it to develop games for the Xbox 360.
You could also base your work on ogre they provide the abstraction themselves and they have really nice tools. Since this is a projects that's been around for over 6 years I think. The base library is not really for beginners since you need to know a bit about software design, but I found a lot of people that have written games using it.
It would be safer and quicker than learning the heavier stuff since it's already been abstracted. Plus after a couple of month you'll be talking 3D jargon anyways. There is also a book to get you started with Ogre, I think it's kinda old by now but a starting point anyways.
You must remember that DirectX is a collection of technologies - Input, Audio and Graphics. However to most people DX is synonymous with the renderer.
In my opinion D3D (or DirectGraphics) has not really been that hard since DX8. I have not tried DX9 or DX10.
Bernard is right - try to abstract as much as possible. Try to keep DX or OGL calls outside your object classes.
I have no previous OpenGL, DirectX or videogame experience and i have made have an open source race videogame with Ogre3d. Is a very good framework to start in videogames: well done code, plenty of docs and info in the net and very good starting tutorials.
The rendering engine is DirectX/OpenGl agnostic, you can later select to render your game with OpenGL or DirectX (withouth changes in your code)
I did my dissertation at uni on a comparison of OpenGL vs Direct3D. The real benefits of Direct3D are that it has a regular release schedule - it's always being updated to take advantage of the latest advances in graphics hardware. How long has it taken between the OpenGL 2.0 and 3.0 releases? Also, a lot of work has been done in extensions for OpenGL, which means only some rendering will work on some cards.
Having said that, OpenGL will be easier to start programming with. As Direct3D is based heavily in COM, it has a steep learning curve.
If it were me, I would be choosing DirectX over OpenGL. That's at the cost of non-platform independance.
Best thing to do would be to abstract over your renderer as much as possible, to make porting to the other technology as painless as possible.
For the situation that you describe, I would recommend Direct3D.
The primary reason to use Direct3D instead of OpenGL is that often video card vendors only do a good job on the OpenGL drivers for their "high end" cards.
The low end game type cards tend to get poor and generally buggy drivers, causing problems on your end user's machines.
If portability is important, then that would be a big reason to look at OpenGL or Ogre instead.
But if you never plan to port, then focus on Direct3D since it is a more widely stable platform with better IHV driver support.
The thing you should consider is the decision of platform independence. Do you want to tie your game to Windows, or would you like to release it to Mac OS X or Linux at some point. If you decide that you want to support Linux, OS X in the future, you will need to use OpenGL.
There seems to be a lot of goodwill by the Linux community if the game is at least semi-released for Linux.
To answer this question well requires more information about you:
what is your programming ability?
If it's high, I would probably start with Ogre (the best strictly rendering open source engine, IMHO) or another open source game engine, such as Delta3D, if you want additional features (sound, physics, etc.) that a game engine brings.
If you don't want to go with an engine, I would go with Direct3D, because it's being updated much quicker than OpenGL. I don't want to get into all the issues, but version 3.0 of OpenGL was announced during SIGGRAPH and most in the community were very disappointed with it. Direct3D puts you in a much better position to take advantage of shaders and other uses of the programmable pipeline.
If your programming ability is not too high, and you are doing this to learn programming, I would start with OpenGL, because it is easier to learn and there are more resources on the web (see http://nehe.gamedev.net for example).
It is my understanding that in Direct3D you must handle all resource allocation and management yourself, whereas the OpenGL specification leaves this to the driver/implementation rather than the application.
This allows Direct3D developers to use the best allocation and management methods suitable to the application, but is also extra work.
I have done the typical "Hello World" applications in each, and I prefer OpenGL over Direct3D, but that is just my opinion. You should try out both, spend a day or two learning and playing around with each, and decide for yourself.
I really agree with those telling you to learn Ogre3D. You said you'd use C++, so Ogre3D is a great choice. XNA uses C# and you'd have to learn the differences between it and C++, apart from learning the very XNA. Also XNA is neither Open Source nor cross platform, so if you wanna have a wider knowledge about game development, I'd suggest first learning SDL, and then Ogre3D.
To start with, we've got the Wikipedia comparison of OpenGL and Direct3D.
But I'd really like to hear some practical viewpoints, especially in the light of recent developments of OpenGL 3.0 and DirectX 10.
The suggestions for abstraction of an engine are good, assuming that you know what you are doing. It's difficult to write a good abstraction layer for graphics without having done it already.
I would suggest that you just pick one. You will pick up the concepts from either easily enough -- enough so that you can potentially work on an abstraction layer, or the other library easy enough. But just do it. I really wouldn't worry so much about which is the right one. They are both good, solid performers. DX10 (if you have Vista) may have the slight advantage of more up to date shader models, but for someone starting now, that is pretty irrelevant I think. GL has the advantage that some of the nigglier matrix/vector math operations are either hidden from you, or provided for you (although I think DX has some of these as well.)
While OpenGL is by far easy to start with and as some people already wrote - getting a triangle to show on screen and from there move to textures, particles and more can be done within a day.
I do however think that a good question to ask is what is your final goal.
If it is a simple game, no skeletal animation, and simple 3D - OpenGL is definitely the answer. If you aim way higher and don't want to put the time in developing all the technology from scratch (or go hunting for free libraries and putting all together) then DX is a good choice, I would go for DX9c until DX11 comes out.
If you don't mind messing with other languages other than C++ you should also take a look at the XNA development environment - it became quite mature and good.
Just as well, using an already existing engine is good if you know that it'll give you most of what you need, for the right price and will save you the time to develop it yourself, the main problem is that you'd need to go over several game engines (Ogre, Game Studio, Torque, etc..) and then make your choice based on limited experience - read as many reviews from casual developers as you can before you proceed, and try to take a look at the code if you intend to change it.
Hope it helped.
You have to think about what you want out of it, as it's a hobby project I'm assuming that "learning stuff" will be a major part of the experience so avoid picking up something that hides things from you and does stuff behind the scenes as this will only give you a fraction of the picture.
I'd go with Direct3D because it's got the better support, I find the docs easy to read and there are decent samples that come with the SDK. You can even use these samples as the base to build on if you want to get a kick start without the initial steep learning curve of getting things set up.
I started with OpenGL for the record, and after about a month went onto Direct3d (version 7 at the time). I found Direct3D forced me to be more aware of what I was wanting to do and how I was setting things up but I preferred this level of understanding.
Importantly IMO, whichever way you choose, take it step by step and get things on screen regularly. There's all sorts of reasons why something isn't on screen (it's transparent, the camera's inside the object, etc...) so by taking baby steps and getting stuff to display regularly you're both verifying things are still moving along and getting a little visual reward.
Don't start with Ogre.
Start with OpenGL GLUT (Win32), and a tutorial or two.
As soon as you can move to Win32 and take a look at this site, which is pretty old now, but still, quite good.
Clearly from the responses you've been getting, you can reasonably start with either D3D or OpenGL for your 3D graphics API. Triple-A gaming titles have been developed using both technologies, and they both have their strengths and weaknesses.
If you're already reasonably proficient in C++, either one will serve, however there's a number of other considerations to make in your selection:
Portability: OpenGL (and OpenGL ES) is available on Windows, Linux, OS X, iOS, Android, and other systems. D3D/DirectX locks you into MS platforms only.
Game Input: In DirectX, the DirectInput API gives you access to controllers. OpenGL doesn't have an equivalent here.
Sounds: DirectAudio supports sounds, OpenGL has no equivalent (however OpenAL is often used)
Physics: Depending on your game needs, you may need some advanced physics simulation
Typically the actual "gameplay" focus is on the AIs, combat, storyline, etc.
If you're still climbing the C++ learning curve (worthwhile, but takes some time), you might instead use C# and OpenTK. This would provide you with the benefits of a "gaming framework" like Ogre, reasonably direct access to OpenGL, and the significant benefits of using managed code (and IDE) for the game logic. OpenTK is cross-platform via Mono, so your code can run on OS X and Linux as well.
Have fun!
Ogre3D is great if you want to do cross platform coding and if you want to leave all the rendering to the engine. OpenGL is also great for cross platform coding, but it also makes you do all the boring parts -- however it provides greater control.
I would avoid DirectX in case you want to port your game to other platforms. Plan for the future. DirectX 10 may provide some advantages compared to OpenGL, but I really don't think you'll feel them unless you're a professional development. Otherwise, if you're pro-Microsoft, you should use XNA anyway, since as an amateur developer you won't need control provided by DirectX.
I'm coding with OpenGL for quite some time now and with Ogre3D for a few months now and I can't say I want anything else. I recently got a book on DirectX 7 and I consider it messy. Perhaps things changed, but from what I observed I don't find DirectX, and by extrapolation Direct3D, attractive.
My opinion is that OpenGL is best.
OpenGL SuperBible: Comprehensive Tutorial and Reference is a good reference.
We provide a web application with a frontend completely developed in Adobe Flash. When we chose Flash 6 years ago, we did so for its large number of features for user interaction, like dragging stuff, opening and closing menus, tree navigation elements, popup dialogs etc.
Today it's obvious that AJAX/JS offers roughly the same possibilities and because of the number of frameworks that are readily available, it's very feasible to implement them.
Is there a technical reason one should choose either technology over the other? By "technical", I mean performance, security, portability/compatibility and the like. I don't mean aspects such as the very non-programmer way development is done in Flash or whether it makes sense to switch an app from one to the other.
As I just explained in another question, it seems to me that JS is way ahead in terms of market share and I'm wondering whether we are missing some important point if we stick to Flash.
In addition to what others have said, Flash is constrained in the "rectangle" and cannot be added to a normal html page in an un-obtrusive manner.
#Gulzar I think when more browsers will support the video tag like mozilla 3.1 does we'll see even more adoption of ajax/js over flash.
Adobe Actionscript is a statically typed language, Javascript is dynamically typed. Depending on your point of view, this may be a good thing or a bad thing.
With Javascript/HTML/CSS you're going to be heading into cross-browser compatibility hell, especially if you want to support older browsers. This can be mitigated by the libraries that are available, but it's still a big headache. With Flash, you write the code once and it just works in all browsers.
Even with the libraries available, Flash user controls are simply more advanced than anything you can find in the world of Javascript/HTML. In Javascript, you are not going to find anything that comes close to the simplicity and power of a databound user control that Flash provides.
I don't see how Javascript has more of a "market share" than Flash. Pretty much anyone with a web browser has a Flash plugin installed. I'd be curious to know how many people disable Javascript but have a Flash plugin.
Also keep in mind that you're going to be in for a huge learning curve and lots of development time if you decide to switch your technology base so you'd really better have a good business reason to do it.
This decision also has a lot to do with what your application does and who your install base is.
Edit: I see people have mentioned that the iPhone doesn't have Flash support. I would expect this to change with the install base of the iPhone - Adobe would be crazy not to support it.
Correctly designed AJAX apps are more googleable than Flash
Correctly designed AJAX apps are more easily deep linkable than Flash
AJAX doesn't require a plugin (Flash is pretty ubiquitous, so it's not really a big deal)*
AJAX isn't controlled by a single company the way Flash is
Edited to add:
* Except for the iPhone, as Abdu points out.
JS and Flash both have great presence on the web with overlapping capabilities. One area JS is still lacking is in rendering video.
Flash, used well, allows easy localization and internationalization.
Furthermore, it is much easier to use Flash in an accessible manner; you can feed screen readers the right text, instead of having them iterate over all of the possible form elements.
I think Flash should be limited to online games, videos and animation. Otherwise use html and Ajax. It's a web standard and supported by almost all devices.
AFAIK, the iPhone doesn't support Flash. That's a fast growing segment you're blocking out already. Keep it simple and efficient.
Although flash is pretty ubiquitous on desktop browsers, mobile support is very limited (flash lite? yeah, right). I get really frustrated looking up a restaurant on my phone only to find the entire site is flash based and I can't even get a phone number or address!
One benefit of Flash is that it has a few facilities to help do cross domain type operations safely, which can be helpful. Flash also has (limited) support for some hardware, which is not possible with Javascript.
Personally, I'd try to use as much Ajax as possible before turning to something like Flash. From the UI perspective, it is better in that the controls and basic authoring is a little more developed. The Sound Manager project is a good example of effectively using a small amount of Flash while keeping the remainder in Javascript.
I suspect one of the reasons javascript is becoming more popular is that it's more easy to retrofit into an existing application.
As I can't accept two answers, I'm going to merge Christ Upchurch's and 17 of 26's answers in my own post. I think, these two together pretty much sum up what I wanted to know. Thanks guys!
If you're dealing a lot with polygons, then Flash is still easier to program and debug. With AJAX there are a lot of libraries to handle polygons, but the more libraries your app uses, the slower it gets.