Related
I'm a beginner with effectively 0 knowledge of programming in the typical sense (only programming I've done is Ladder for PLC's).
I'm a huge ADDer who has trouble staying focused on learning unless it's engaging (IE, with PLC's I was able to program, download to controller and immediately see an output change).
I have a lot of interest in python and other 'normal' programming and my most recent interest includes understanding the Google Assistant interface enough to figure out how to purchase basically any type of sensor (prox, moisture, etc) and interface it into Google Assistant to make my home automation do things for me...
IE - if light beam is broken on sensor 1, turn on output 2 (alarm).
I figured I can use Arduino but my lack of fundamentals make it incredibly hard for me to dive into some of these projects.
Does anyone have a good book that will help me get a good foundation into computer science AND something that might have some mini projects that will keep me engaged and lead me to where I want to be?
I struggled in school due to the concentration issues despite medicating, but did fantastic when doing PLC's. Unfortunately PLC's are really not used as often so 'real programming' is the way i need to go
Is VCL dead, or does it have a future as a GUI library? As CLX ended, is there any chance for cross-platform support in future releases?
I've had to do some work with legacy app that uses Borland's VCL(BCB6). Now that new features have to be implemented, it's necessary to revalue alternatives. Whether to stick with VCL or migrate to some other library/framework.
I've never read much what's happening in the field Embarcadero(Borland) tools. At least there seems to be only few VCL tagged questions here in SO and no much luck with google either.
Whether to continue using VCL in your project, or migrate to an alternative depends alot on your requirements. The VCL framework is powerful and mature, with lots of 3rd party components, which makes it a good idea to consider. The alternatives have been improving rapidly, and to point out one as the ultimate choice really requires you to carefully consider your requirements, and validate the strengths and weaknesses of the different frameworks.
Considering that cross platform is on the road map, I remind you that so has 64 bit support been for quite a while. We might see cross platform support, perhaps on schedule, perhaps delayed as we have seen with many previous features. I want to believe its coming because I truly like the VCL framework, but I always have a natural doubt concerning the official road map of the RAD studio series - sorry David. ;)
If you've researched the different alternatives, and found VCL to be the best choice based on its relevance to your project, then I'd consider using the VCL framework, especially if it is a framework you are familiar with. Learning a new framework can - while often a good idea - be a time consuming job. So even though there might be a risk of the framework not being held alive (as will there be with any alternatives) you might save a lot of work staying with the familiar framework, if it is the framework that suits your project the most.
If you do consider going with C++ Builder and the VCL, you might find that the C++ Builder Journal is a valuable source of information, they have a relatively quite forum, but with some interesting posts in it, and some free hints on their website: www.bcbjournal.com.
Of course there is also the embarcadero forums, and this site, it may be a good idea to search the Delphi forums and categories, since it seems there are more active users on these, and by far more posts. One good thing though, is that conversion from Delphi to C++ in VCL related questions is quite simple.
VCL is undergoing continued development.
Cross platform is on the current roadmap.
The embarcadero forums are still a valuable resource.
As a user of VCL I must say that your observations are truly correct. VCL might appeal to you, but the resources available compared to QT and other toolkits is poor at least esp. at SO. Our team have also found several bugs in their components, and have more than once patched components to make our application stable. Still for me the main reason to migrate is that VCL locks you in with a single set of development tools. I must admit that I have a hard time trying to find any really good reasons to continue to use it if you have the resources to migrate.
Given that bcc32 and its libraries is also very buggy, the lockin gets even more serious, The last months me and my team have spent more time fixing issues caused by the compiler than actually developing features. For me this is such a serious impediment that its cost overweight its benefits tenfold. Unfortunately the costs of migrating for us is so high that we at least for now have to endure its pains.
I really want to create a stunning-looking GUI desktop application that looks like, for example:
Mac OS X interface
Picasa desktop client on windows
IPhone apps
Office 2007
I've mostly been programming GUI using Qt/Swing/WinForm
and I'm tired of creating so plain looking GUI, lol.
So I was thinking about diving into stuff like:
jQuery
WPF/C#
iPhone SDK
Silverlight
Adobe Air/Flex
Just to get some ideas on how to create really cool looking UI.
Does that sound like a good list? Any developers here that could share what platform they use to create very cool looking desktop app?
On a sidenote, I really wonder what developers at Apple / Microsoft use to develop their own cool-looking software.
EDIT
A lot of responses talk about the importance of usability over "cool-looking"..
I totally agree that usability and simplicity are the most important aspects of user interface design. I've been doing GUI development for a while now (> 3 years), so that I understand.
But using cool-looking UI also improves user experience + it could make big difference on whether or not your software sells.
I mean, otherwise why would Microsoft/Apple try to make their OS UI look "cooler" everytime there's a new version? Why would websites like pragprog.com, or versionsapp.com. make their websites look like that? Basically you kill 2 birds with one stone: stunnning-looking UI + super usability (because it looks simple and intuitive).
That is what I'm striving for. And as far as I know, I cannot achieve that using Qt/Winform. Most of the books I have read just show you how to make average-looking (read: 1990's) UI. I want to learn how to create cool-looking UI. And the only place I see cool-looking UIs these days are the technology I list above. I'm not enamored with any technology; but I just want to know how things are done in other technology to see if I could apply them to the technology I'm using, or see if I could use those technology in my line of work.
An example: if I were to pick between this UI and this UI, I probably would pick the latter, if just based on looks alone.
Functionally, they are just the same UI; they both allow you to keep track of your time. They both contain buttons and textboxes, etc. But the fact that they look different, also differentiate them in terms of attractiveness.
So in all, I think the "ice on the cake" is very important. I would say it's the thing you strive for after you are certain you have a totally intuitive, usable UI.
I think that the major reason many people suck at designing interfaces is that they consider them to be graphic design. It is not. The core of creating a good user interface is a bit like creating a good API – the interface has to be conceptually consistent, hard to misuse, easy for common tasks.
Wanting to design something cool because you are “tired of plain GUI” is a perfect recipe for disaster. If for nothing else then because consistency is a crucial part of a good UI. If each application wanted to stay out of the crowd, the whole thing would be an unusable mess.
It is almost unfortunate that Mac OS X looks that good, because then people start to think you can create a good interface by animating it or sprinkling some graphics on the top of it. The graphical part, the “cool” of the design is just the icing on the cake. If you really want to design good interfaces, stay true to the environment, respect local human interface guidelines. And maybe read Apple’s Human Interface Guidelines to get a feeling where the problems are and what can be done to solve them.
I know this sounds much more boring than filling gradients in Photoshop, but it’s the only right approach to take if you really want to create a top-notch interface.
the key to a stunning graphical user interface is twofold:
it still has to be useful to the users, and that involves a lot of hard work, study, paper prototypes, user interviews, usability testing, et al.
hire a really really good graphic artist
Neither step is optional. If you -the programmer- also happen to be a really good graphic artist, that's fine - but the vast majority are not, and no amount of fancy tools and photoshop tutorials will replace the talent and training that real artists bring to the table.
I don't mean to sound harsh, but most programmers are terrible GUI designers. Myself included. It's ok to leave art to the pros. ;-)
I'm all for WPF/Silverlight, but it really about the platform that you need to support.
The real deal is your own talent, as WPF is a powerful tool, if you ain't got the talent to use it, it will look like improved winforms. (Also check out the Expression Studio from MS - which enhance what you can get out of WPF).
If you want to know more about UI you can read this books:
About Face 3: The Essentials of Interaction Design
The Inmates Are Running the Asylum
UI development is not about technologies. In some cases console is the best solution.
We can get commercial GUI add-ons like Telerik which also supports Mono as well.
Regardless of the UI technology, you will of course be well-served to adopt a programming style where the look and logic of the app are as decoupled as possible. This allows you maximal flexibility to design and evolve the look of your application (the View) while potentially requiring very few code changes in the back-end (the Model or ViewModel).
While possible using all UI technologies, it's particularly easy to execute this in the case of WPF/Silverlight/Moonlight via the MVVM programming style, due to the succinctness of databinding (very little boilerplate "glue" code).
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have experience writing console and network client/server applications in C and C++, but I know next to nothing about using the win32 visual API, MFC, Qt, wxWidgets, etc. Where is a good place to start, and what method should I specialize in, so as to be future ready and robust?
This is a rather broad question, as programming GUI applications in Windows can be done in so many ways.
There are two main parts to developing any GUI app: the language and the API/framework. Considering you're interested in learning to build Windows GUI apps, the language isn't really a point of focus for you. Hence, you should pick a language you already know and work with a framework or API that can be harnessed by your chosen language.
If you want to use C you're pretty much restricted to dealing with the Win32 API yourself, in which case reading Petzold or Richter would be great places to start. The Win32 API can be quite daunting, but it's well worth the effort to learn (imho). There are plenty of tutorials on Win32 on the web, and there's always MSDN, with a complete reference/guide to the Win32 API. Make sure you cover not just the API, but other areas such as resources/dialogs as they are building blocks for your Win32 application.
If you want to use C++ you have all of the options that you have when using C plus a few others. I'd recommend going with the Win32 API directly, and then moving on to a known framework such as MFC, Qt, wxWindows or GTK so that you can spend less time working with boilerplate code and instead focus on writing your application logic. The last 3 options I just listed have the added benefit of being cross-platform, so you don't have to worry too much about platform-specific issues. Given that you said you want to work with Windows, I'll assume you're keen to focus on that rather than cross-platform -- so go with MFC, but spend some time with the Win32 API first to get familiar with some of the concepts.
When dealing with MFC and the Win32 API, it's a good idea to try and get a solid understanding of the terminology prior to writing code. For example, you need to understand what the message pump is, and how it works. You need to know about concepts such as "owner-drawn controls", and subclassing. When you understand these things (and more), you'll find it easier to work with MFC because it uses similar terminology in its class interfaces (eg. you need to know what "translate messages" means before you can understand how and when to use PreTranslateMessage).
You could also use Managed C++ to write .NET GUI applications, but I've read in a few places that Managed C++ wasn't really intended to be used in this manner. Instead it should be used as a gateway between native/unmanaged code and managed code. If you're using .NET it's best to use a .NET language such as VB.NET or C# to build your GUIs.
So if you are going to use .NET, you currently have the choice of the WinForms library, or WPF. I personally feel that you'd be wasting time learning to build WinForms applications given that WPF is designed to replace it. Over time WPF will become more prevelant and Winforms will most likely die off. WPF has a much richer API set, and doesn't suffer from many of the limitations that Winforms does. If you do choose this route, however, you'll no doubt have to learn XAML, which is a markup language that drives WPF applications. This technology is coming of age, and there are many great places to learn about it. First, there are sites such as LearnWPF, and DrWPF which have some really great articles. Secondly, there are plenty of quality books on the topic.
So, to sum up, once you've picked your language and tech, the path is actually quite easy. Just pick up a book or two, read some blogs, get into some code samples.. and most importantly ... write code. Keep writing, keep making mistakes, and keep learning from them.
As a final note...
In other words, Silverlight. If you don't want to go the MS route you might give Adobe's Flash/Flex a look see. Both Silverlight and Flash/Flex build RIA's. Which I think is where we are headed. They days of Office like apps are numbered
I don't agree at all. Silverlight is not the same as WPF. Silverlight is web-specific, and only has a subset of WPF's features. Given that the question asks for Windows GUI apps, Flash/Flex Rich Internet Apps are not really a fitting suggestion. I also don't agree that the days of Rich Client Applications (such as office) are numbered at all.
I hope that helps. Good luck :)
I don't know if I'd call it a good place to start, but if you want to be future ready, take a look at the windows presentation foundation which is built entirely for the purpose of programming GUI's for windows
My first experience writing simple GUI applications for Windows was with C# and Visual Studio. The GUI-building interface is a simple drag and drop deal that generates skeleton methods based on potential user actions. I only did fairly basic programming with this, but I imagine it would be an excellent place to start to learn the basics and extend into the more advanced capabilities as you go.
There are plenty of online Win32 tutorials:
http://www.zeusedit.com/forum/viewtopic.php?t=1218
There are plenty of compilers to choose from:
http://www.zeusedit.com/forum/viewtopic.php?t=238
I would also recommend getting the Borland Win32 SDK documentation in WinHelp file format:
http://www.zeusedit.com/forum/viewtopic.php?t=7
It only covers the bare basics of the Win32, but when starting, this can be helpful as it is less daunting and less bloated than the MSDN.
I'd never go down the Silverlight, Flash/Flex or any similar route. It does look nice, but the main problem is that the code of the engine that runs it is completely closed-box and controlled by a single company. Take, for example 64bit versions of both of those. If some new platform emerges, you won't be able to migrate your existing code to it.
For business apps, Windows Forms is very mature. It provides a gentle path from auto-generating a lot for you into allowing fine-grained control and rolling your own. There are tons of high-quality third party controls and a large body of examples, docs, etc out there. It's hard to run into a problem that someone else hasn't solved. I highly recommend acquiring some background Win32 knowledge (e.g. Petzold) as the WinForms framework lives on top of it.
I have no WPF experience, but from the sample apps I've seen it looks like a good choice for apps whose interfaces would benefit from more graphical metaphors. So if you're doing a banking app, probably not worth the extra design overhead. But if you're doing, say, a warehouse management app it could be improved by dropping pretty boxes into pretty bins.
#StephenCox: wrong answer to the wrong question. OP is asking about desktop client apps, and moreover, WPF != Silverlight.
For a simple starting point to get your head around the "event-driven" nature basically all frameworks are created around look at FLTK.
Here are some quick starting videos Link
For professional use I'd recommend Qt, expensive but often worth it in commercial situations.
Since you are already familiar with C and C++ I would recommend learning how to write a simple Windows GUI app using Charles Petzold's book. It will give you the fundamental understanding of how Windows works. It's good to understand that most everything that you see is a window (a button is a window for example) and that these windows respond to messages. I wouldnt' spend a lot of time on this though and you don't necessarily need to do this first if you are going to chose WPF. I just think it's good to have a basic understanding of this.
There was a good podcast recently on .Net Rocks called "Kate Gregory Develops in C++ for Vista!" on there she recommends that someone starting out now should not use/learn MFC (even though it has been recently updated).
As far as getting ready for the future you need to learn WPF, but it isn't complete yet, so depending on the kinds of client side apps you want to create, you will probably need to learn WinForms. The majority of people aren't using WPF yet, so it's a good time to start learning. I think you will find it easier using C# to learn it instead of doing managed code with C++.
Get your basics right first. Best tutorial I've found is: http://winprog.org/tutorial/start.html
After that, although the homepage is hatefully distasteful, the tutorial pages are good in content and aesthetics: http://www.tenouk.com/cplusmfcdotnet.html
Then of course there's MSDN.