I'm planning on doing an interactive AR application that will use a laser sensor (for distances), GPS technology to get a location, and then use compass/gyroscope for tracking 6DOF viewfinder
movements. The user can choose from a number of ready-made 3D-models, and should be able to place them by selecting the desired location on the screen.
My target platform will be a 8"-handheld-device, running on windows8.
Any hints what would be the best AR-SDK or 3D-viewer to work with?
thanks in advance!
There are quite a few 3D viewers that are working in the browsers. But most recently and most notably: va3C viewer
It is webgl based app and doesnt require a server, so if your handheld device supports webgl, then you are good to go, however, whether it works on IE or not is questionable ;).
Although based on my experience and your usecase, I believe client side JS libraries do not provide enough access to the device's hardware. So you might have to serve the information like GPS, Gyroscope, from the server side, then gather this on the client using something like socket.io and then mash it up alongside the geometry.
I am trying to do something similar, although havent quite done it yet. Will keep you posted.
Another approach I am exploring is X3DOM, which gives the ability to write 3D data like XML alongside HTML, which is quite declarative and simple to pickup. X3DOM derives from X3D.
Tell me if you need more info.
Also, worth exploring for its motion abilities, is Robot Studio, which is a desktop app with SDK.
I've done a bit of XNA work, and I'm now trying to work in MonoGame. Previously, for all my input and output needs, I used Microsoft.Xna.Framework. I'm now trying to make one version of my game to deploy on as many platforms as possible (excluding, at the moment, touch interfaces), but I don't know what I should be doing regarding the mouse, for example.
Does MonoGame make Microsoft.Xna.Framework platform-agnostic or do I have to use other frameworks and switch between them depending on the platform?
MonoGame is designed to make it easy to port your game to other platforms, you shouldn't need to use any other frameworks to achieve that goal. However, it's not as simple as simply recompiling the code for each new platform.
For the most part all of your code will remain the same, but you'll need to put together a project for each platform and link all of the code files in each one. I won't go into detail about this, but I'll just say that you can do it and it's not that difficult.
Now, what you will find is that you may have to write some platform specific code to handle device specific stuff like screen scaling and input handling. What exactly you need to do will depend on your game, so I can't really explain that in detail either.
To make your life easier, it can be helpful to think about how your game is going to work on other platforms and write your code accordingly. For example, a touch on mobile device is very similar to the click of a mouse so you could wrap this functionality in a method of your own to minimize the code changes required when porting. On the other hand, some things you can do with a mouse simply don't work on touch interfaces, like right click, and hover. Similarly, touch interfaces have commonly used gestures that don't really map to a mouse on a PC like long press, swipe and pinch.
So the short answer is, you don't HAVE to do anything special, but you should at least think about it if you plan to port your game in the future.
I want my program to be able to launch any Windows game, and while the user is playing it, intermittently display some text or pictures in some part of the game window. The game may be in windowed or full-screen mode. From what I have been able to figure out from online resources, this could be done using a graphics library that supports overlays and using Windows Hooks to keep track of the target application's window. In this context I have some questions.
Will the overlays affect the game's performance?
How will hooking the application affect performance?
Is there any other way one could achieve this? For example, how do you think PIX, the DirectX debugging and analysis tool, work?
Fraps is the archetypal example of doing this sort of thing to a fullscreen DirectX application from a third-party app. It works by hooking some system calls and inserting itself into the call-chain between an app and DirectX. There is some performance hit, but in general its minimal.
This page seems to have some details and sample code on how to hook the app in this way.
If I recall correctly, from other forum discussions (can't find the link at the moment. search for things like "how does fraps work", it's a popular question), Fraps hooks a few things to force the app to load its DLL, then hooks Present() calls and executes a device->Clear() call before calling the real Present(), with a list of small rectangles to set to a different color, which can spell out the FPS number that it displays. This has a minimal performance impact and is widely compatible with whatever rendering the app is doing. Overlaying a bitmap would be more complicated since it wouldn't be as easy to do at Present-time. Perhaps if you could hook EndScene, then you could do more, but you would have to be careful to not change the device state.
PIX has privileged access to the DirectX driver, so I wouldn't expect to be able to use that as a model to emulate.
If an the target app is running in windowed mode, hooking DirectX still work, but you could also just use GDI instead.
Edit: I think this is the link I was originally thinking of.
There are many more technologies and tools available to build the front end for an application.
Which is the best technology/tool/platform available using which I can build a better GUI, by which I'll be able to build a nice looking as well as an efficient GUI?
Definition of "better" includes factors such as efficiency,user friendliness,better content control mechanism, navigation and many more.
I know this is a question about which GUI toolkit you should use, but your first technology for producing a user-friendly UI is pen and paper. Sketch out some mock-ups. Draw buttons and menus on construction paper, cut them out, and glue them together. Then try your mockups on about a half-dozen people. You'll quickly find out what makes a good UI.
It doesn't matter how good the UI looks or whether it uses the latest snazzy effects -- if your users can't figure out how to use it, they'll go elsewhere. You need to learn what works for your target audience before you write a single line of code.
Read Don't Make Me Think to learn how to make mock-ups and do user testing.
If' you're tracking an IP address, you'll definitely want to create your GUI Interface in Visual Basic.
Use the .NET framework in Visual Studio 2005/2008/2010 Studio. I haven't developed in any other environment, but I have been able to create nice looking apps in this IDE / Framework.
"Best" depends on what your evaluation function is.
For ease of development, and high quality UI, in a non-web based app it's hard to beat C#/VB or any other .NET language and environment for a windows-based app. Depending on the quality of the UI, MPF will give you greater flexibility and control, whereas windows form will make it easier to develop.
Having used Windows Presentation Foundation for a while now i would highly recommend it. There is a pretty big learning curve and, to be honest, MSFT should have included some controls (the datagrid being the biggest one) that were not included by default (but will be in .NET 4.0). Where WPF and XAML exceed is providing a foundation from which you can build just about anything. You can style ANY part of ANY control and build your own composite controls from scratch. A lot of thought went into binding and value converters and once you get used to the declarative nature of XAML you wont want to turn back. The company I work for has been using it for a couple of years now and the difference between the GUIs we used to develop (mainly winforms and asp.net) and what we develop now are night and day in terms of both look-and-feel and functionality. My two cents anyway...
It depends.
What device will the GUI be used on, hand held, PC, Mac?
What platform Windows, Linux, Web?
What kind of application will it be, accounting, email client, web application?
What audience will be using the application (a GUI aimed at a child may be different than one aimed at an adult)?
All of these things must be taken into account before even starting to formulate an answer to your question.
You have several choices for developing a GUI.
first, if cross platform is an issue consider using Java or Python.
you can also use Adobe AIR and develop the gui in Flex.
If you direct the product to windows only users .NET WPF is the best solution, with a very rich set of control and examples.
You can also use .NET with mono for cross platform compatibility, but WPF isn't currently supported.
Desktop, Mobile, Windows, Linux, Database, OpenGL: Nokia Qt. Wiht Python - PyQt development process is shortest and easy. Application containing all required python & qt libraries and modules is around 30MB with Inno Setup installation is 8MB and will work on Windows 2000 and newer for Python 2.6.x, Python 2.5.x based application will run from Windows 95 to Windows 7.
I think all the attributes you list -- efficiency, user friendliness, etc -- are attributes of a good design rather than a good toolkit. Just about any toolkit can be used to meet those goals. I think the question might be different if you were asking about eye candy, fancy multi-media, etc. There are definitely some toolkits that do that better than others.
If you're interested in usability first (and it sounds like you are), focus on the design then pick whatever toolkit meets your current abilities and can handle your design. For example, if you require 3D images that might narrow your choices; likewise if you need to show videos, that will influence which toolkits you can choose from.
So, start with a good design. From that, create a list of requires for the toolkit -- rich editing controls, video, 3D, etc. And then look for a toolkit that provides what you need.
The best toolkit in the world won't make up for poor design.
Personally after having used Win32, Forms and WPF then going to Mac/iPhone GUI development, I very much prefer the flexibility and high quality of visuals in the Mac/iPhone GUI.
One of the most useful examples is the fact that in NSTable/UITable controls (ListViews or similar in Windows), every cell is a fully customisable View (a Control in Windows).
Where in a ListView you have very little customisation for each cell/item in the view since you only provide details, not an actual control, an NSTable/UITable asks you for a table cell which you can add anything to, such as buttons, switches and image views.
Mac OS GUI development to me is a LOT more flexible and more consistently flexible in that regard. Everything is a View so I can my own contents to anything.
Have you considered Silverlight?
It can be used to create internet applications, but it can also be run out of browser to create desktop applications. It's has significant overlap with WPF though there are differences which might catch you out when swapping from one to the other.
Expression Blend 3 is a very good visual designer and the code it produces is quite efficient.
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.