Tuesday, October 17, 2006
Direct3D tutorials
I'm beginning to the get the hang of C++ now, and have been messing about with 3D graphics. I had to do quite a bit of work with Direct3D for my PhD, but of course I did it all in C# and Managed Direct3D. Now I've started using 'proper' Direct3D and found an excellent series of tutorials here http://www.two-kings.de/.
Furthermore, the first tutorial actually gives a pretty good intro to Win32 programming, certainly the best that I've seen, so it's doubly worth checking out.
My plan in the next few months is write a little game that I can put up on my website, along with my PhD stuff, as an example of my work. I've noticed that many jobs in computer programming (especially in graphics, which is where I'm thinking of moving towards) require samples of your work to be submitted with any application, so it will be good to have some well-written software ready for such an eventuality.
My current plan for the game is a hovercraft racing game, which might include some weapons that you can pick up, WipeOut style, around the track. Okay it might not sound like your first choice of genre when perusing for a new game down the high street, but I'm doing it really to show off my madskillz, and realistic hovercraft and weapon physics would be a good way of doing this. First things first though, I have to get my terrain rendered and a proper camera moving around. I'll let you know how it goes.
Furthermore, the first tutorial actually gives a pretty good intro to Win32 programming, certainly the best that I've seen, so it's doubly worth checking out.
My plan in the next few months is write a little game that I can put up on my website, along with my PhD stuff, as an example of my work. I've noticed that many jobs in computer programming (especially in graphics, which is where I'm thinking of moving towards) require samples of your work to be submitted with any application, so it will be good to have some well-written software ready for such an eventuality.
My current plan for the game is a hovercraft racing game, which might include some weapons that you can pick up, WipeOut style, around the track. Okay it might not sound like your first choice of genre when perusing for a new game down the high street, but I'm doing it really to show off my madskillz, and realistic hovercraft and weapon physics would be a good way of doing this. First things first though, I have to get my terrain rendered and a proper camera moving around. I'll let you know how it goes.
Thursday, September 28, 2006
C# to C++ - learning C++ with wxWidgets
The invention of C# was a really clever move by Microsoft. It is similar enough in syntax to appeal to Java users, just as easy to use as VB, and only a fraction (5% IIRC) slower than C++. I started using it because I was taught Java, but wanted something that was faster and easy to use with regards to Windows programming, and C# is that. The bottom line is that for Windows programming, C# is by far and away the easiest language to use, unless you really need that extra 5%. This is borne out by the amount of C# software that is being written these days. Many companies don't advertise for MFC developers anymore, they want C# developers, and even ATI write their GUI for controlling their graphics drivers in .NET. And thanks to the efforts of the mono-project (which I've yet to try but apparently works quite well) C# programs can now be compiled and run on linux.
Yet there is no getting away from the fact that, sticking with our example of ATI, the graphics drivers themselves are almost certainly not written in C#. C# and .NET neatly hide away a lot of under-the-hood information about how software interacts with hardware, and how a program actually works. This is fine, but out in the wide-world I feel it's probably a good thing to get a broader view, and so I've finally taken the plunge and make the effort to start learning C++.
So, from my experiences in the last week or so, here are few bullet points with advce for those people who want to transfer their C# to C++:
Yet there is no getting away from the fact that, sticking with our example of ATI, the graphics drivers themselves are almost certainly not written in C#. C# and .NET neatly hide away a lot of under-the-hood information about how software interacts with hardware, and how a program actually works. This is fine, but out in the wide-world I feel it's probably a good thing to get a broader view, and so I've finally taken the plunge and make the effort to start learning C++.
So, from my experiences in the last week or so, here are few bullet points with advce for those people who want to transfer their C# to C++:
- Learn the basics: go to http://www.cplusplus.com/doc/tutorial/, and using Visual Studio create a new C++ console program, and work through the tutorials. Much of it is familiar from C#, but it gives you an idea of the how objects, class and function definitions, and memory referencing and pointers work in C++. Java and C# are very similar in terms of object orientation, and so this page contains a good overview of converting to C++, especially with regards to the use of header files, which puzzled me a little to start off with.
- Don't use MFC!: Assuming you're used to programming Windows software with C#, the first rule of C++ is not to use MFC!! It is, quite frankly, a nightmare. I spent one afternoon working through a couple of tutorials before giving up in disgust. Fortunately, there are several 'widget' toolkits that are much easier to use. The two big 'completely free' ones are SmartWin and wxWidgets. I started using both for evaluation, but it didn't take long to choose to concentrate on wxWidgets, as it is a bit more object-orientated (fewer macros), rather C#-like in the way it uses components, easier to set up, and there are more discussion lists and forums dedicated to it. There is a really superb newbie wxWidgets tutorial to be found here. Also wxWidgets is pretty platform independent, and you can use it to write GUIs for Windows, Linux and even (pah!) Mac.
- Decide on your compiler and IDE: Unless you use some form of setup wizard, creating a new C++ project and correctly compiling/linking C++ programs with Visual Studio (I use 2005) is, quite frankly, a pain in arse. There are a million and one options, debug/release/unicode, and you can waste a LOT of time doing it. Also, seeing as you don't want to use MFC using a different compiler IDE may be a good idea. I started using Dev-C++, it does integrate plugins very well, but if you're used to the feature-rich IDE like Visual Studio, it feels like stepping back in time to the stone-age. Fortunately, Code::Blocks is easy to setup and compile (much better than VS2005) and has quite a lot of very good features. It also runs on linux (built with wxWidgets, see?!) and it's what I'm using.
Thursday, August 17, 2006
C# - Recording audio to a Wave file using DirectSound
In my work recently I used Microsoft's DirectShow API to create a video frame grabber from any Windows video input. in C++, DirectShow is a bit of a pain, but with the Managed wrapper classes from http://directshownet.sourceforge.net/, it's actually very pleasant to work with, and I've rather got the hang of it. So I was a little disappointed to find out it's not the best method of messing about with audio files - you can do it, if you find and install the WavDest filter, but naturally this hasn't been wrapped by the DirectShowNet chaps yet, and I couldn't be arsed to wrap it up myself. Anyway, it turns out that the recommended way of saving audio is to use another MS API, DirectSound.
All this meant that I was going to have to learn another API, doh, still I guess it keeps my brains working.
Anyway to get DirectSound you have to download the DirectX SDK, which fortunately contains a sample for capturing audio from any audio device recognised by Windows, to a file. Unfortunately, it's pretty complex
(grumble it was bloody simple in DirectShow grumble, if only I had the filter grumble). There some more info on what the sample is doing here, right at the bottom.
I'll be honest, I started going through the sample line by line and copying the relevant bits but, in the end, I realised I couldn't be arsed. So I ripped the GUI out, and with a bit of tweaking I was left with a fairly functional wave file recorder object. The only real thinking required is to hard-code which audio input device is required (just a matter of setting an int), and also code the details of DirectShow WaveFormat structure to 'default' wave information. This replaces the two 'intro' forms in the sample and lets you use the code as an object in your own program.
Why do I need to record wave files, I hear you cry? (tumbleweed...) Watch this space for information of my fully fledged chat bot - that actually lets you chat, rather than type!
All this meant that I was going to have to learn another API, doh, still I guess it keeps my brains working.
Anyway to get DirectSound you have to download the DirectX SDK, which fortunately contains a sample for capturing audio from any audio device recognised by Windows, to a file. Unfortunately, it's pretty complex
(grumble it was bloody simple in DirectShow grumble, if only I had the filter grumble). There some more info on what the sample is doing here, right at the bottom.
I'll be honest, I started going through the sample line by line and copying the relevant bits but, in the end, I realised I couldn't be arsed. So I ripped the GUI out, and with a bit of tweaking I was left with a fairly functional wave file recorder object. The only real thinking required is to hard-code which audio input device is required (just a matter of setting an int), and also code the details of DirectShow WaveFormat structure to 'default' wave information. This replaces the two 'intro' forms in the sample and lets you use the code as an object in your own program.
Why do I need to record wave files, I hear you cry? (tumbleweed...) Watch this space for information of my fully fledged chat bot - that actually lets you chat, rather than type!
Thursday, August 03, 2006
C# - Formatting text in a RichTextBox by parsing the Rich Text Format (RTF)
I've written a short article on this subject for The Code Project. Read it here!
Wednesday, July 26, 2006
C# - Redirecting output and input from a Process
So one of things I'm currently working on is running a separate, command line process from within my main C# program, interacting with it completely. There are loads of potential uses to this, but I'm using it effectively for reading and writing to a Linux CLI running on Cygwin, which means I can control a Linux program from a Windows Form.
It uses System.Diagnostics.Process, which is quite well represented in the MSDN library.
The key things to use, for a Process called myProcess are:
// first two hide myProcess' window
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.CreateNoWindow = true;
//Redirect input and output to parent program
myProcess.StartInfo.RedirectStandardOutput = true;
myProcess.StartInfo.RedirectStandardInput = true;
Inputting data to the process is easy - to write to the input stream we just use myProcess.StandardInput.WriteLine() after calling myProcess.Start() - but grabbing the output is not so simple. If we wait for myProcess to terminate before we carry on running our main program, we can use myProcess.StandardOutput.ReadToEnd()or similar. However, if we want to continuously read from the Output stream, we need to create a new thread for it, and that means using: mProcess.BeginOutputReadLine() instead - and to use this, we need to have defined:
myProcess.OutputDataReceived += new DataReceivedEventHandler(myProcess_OutputDataReceived);
where myProcess_OutputDataReceived contains some code (such as Console.WriteLine(e.Data); that deals with the output data.
Writing to the console is thread safe, but writing to a Windows Form control (e.g. a RichTextBox) is not thread safe. The work-around for that is a little tricky but fortunately it's covered in detail here.
It uses System.Diagnostics.Process, which is quite well represented in the MSDN library.
The key things to use, for a Process called myProcess are:
// first two hide myProcess' window
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.CreateNoWindow = true;
//Redirect input and output to parent program
myProcess.StartInfo.RedirectStandardOutput = true;
myProcess.StartInfo.RedirectStandardInput = true;
Inputting data to the process is easy - to write to the input stream we just use myProcess.StandardInput.WriteLine() after calling myProcess.Start() - but grabbing the output is not so simple. If we wait for myProcess to terminate before we carry on running our main program, we can use myProcess.StandardOutput.ReadToEnd()or similar. However, if we want to continuously read from the Output stream, we need to create a new thread for it, and that means using: mProcess.BeginOutputReadLine() instead - and to use this, we need to have defined:
myProcess.OutputDataReceived += new DataReceivedEventHandler(myProcess_OutputDataReceived);
where myProcess_OutputDataReceived contains some code (such as Console.WriteLine(e.Data); that deals with the output data.
Writing to the console is thread safe, but writing to a Windows Form control (e.g. a RichTextBox) is not thread safe. The work-around for that is a little tricky but fortunately it's covered in detail here.
