Operating System,C++,Hardware languages, etc...

[chris330 0]

Hi!

Just browsing through an amiga emulator site and I was looking at the release notes and the things they referred to. It got me thinking about how much I still don't know about programming and how it all fits together.

At present time there is no concept in my mind of how things like C++ and something like say a games graphics engine relate to each other in the programming pecking order.

I do know that C++ and C are very close to machine code which is the lowest language form you can input into a processor. I wonder though is 'machine code' a universally accepted standard throughout the globe which manufacturers of processors must make their equipment compatible with or are there several 'machine code' variants and if so what implications does this have on processor design? Is 'machine code' even a low enough language to be loaded into a processor or is there an even more rudimentary level it must go to before being dispatched to a processor?

My second main question lies in language translations:

I also know languages like Java and the like are more distant from machine code than C++ and thus have to be translated several times before going to a processor hence them being undesirable game languages. What actually does the translating though? For something to run a program coded in say Java or something do you have to have another program which specifically does the translating from Java language to machine code level stuff before sending tasks to the CPU on the host machine rather like say Internet Explorer or Netscape Navigator converts web based languages into CPU level instructions on your home machine to display pixel images on your monitor?

Third question:

Graphics and hardware. I know I can go and pick-up a book about C++ and other languages off Amazon or wherever or study a college course in them etc... but how the hell do you learn how to relate things like graphics rendering code to hardware devices? I've seen it on here before people talking about the specifics of how their graphics card handles code and the like and how all the hardware bits make a difference to this and to that. How do you learn about stuff like this, what discipline 'title' or 'categeory' does that kind of knowledge come under?

Also with regards to an operating system (Windows/Linux) how much are they responsible for graphically? For example does the graphics engine in your average game perform language translations down to machine code and then talk directly to the CPU or does the graphics engine only talk to the Operating System which then talks to the CPU?

I have other questions but I think I'll leave them for a bit. I'd appreciate any help thanks. Please keep your replies simple if you can as I don't know much about all this!

[echo1 0]

I wonder though is 'machine code' a universally accepted standard throughout the globe which manufacturers of processors must make their equipment compatible with or are there several 'machine code' variants and if so what implications does this have on processor design? Is 'machine code' even a low enough language to be loaded into a processor or is there an even more rudimentary level it must go to before being dispatched to a processor?

My second main question lies in language translations:

I also know languages like Java and the like are more distant from machine code than C++ and thus have to be translated several times before going to a processor hence them being undesirable game languages. What actually does the translating though? For something to run a program coded in say Java or something do you have to have another program which specifically does the translating from Java language to machine code level stuff before sending tasks to the CPU on the host machine rather like say Internet Explorer or Netscape Navigator converts web based languages into CPU level instructions on your home machine to display pixel images on your monitor?

Third question:

Graphics and hardware. I know I can go and pick-up a book about C++ and other languages off Amazon or wherever or study a college course in them etc... but how the hell do you learn how to relate things like graphics rendering code to hardware devices? I've seen it on here before people talking about the specifics of how their graphics card handles code and the like and how all the hardware bits make a difference to this and to that. How do you learn about stuff like this, what discipline 'title' or 'categeory' does that kind of knowledge come under?

Also with regards to an operating system (Windows/Linux) how much are they responsible for graphically? For example does the graphics engine in your average game perform language translations down to machine code and then talk directly to the CPU or does the graphics engine only talk to the Operating System which then talks to the CPU?

I have other questions but I think I'll leave them for a bit. I'd appreciate any help thanks. Please keep your replies simple if you can as I don't know much about all this!

Two answer your first question; both, to an extent. Machine code is specific to the underlying architecture, but many different CPUs might share the same architecture. For example, all common Windows/DOS PCs since the IBM 5150 of 1981 use the "x86" architecture (because the original PC used a variant of the 8086 CPU and most of Intel's CPUs are descended from that). However, the x86 architecture is different to, for example, the Motorola 68k architecture or the Power PC one, and thus the code is different. Machine code is a product of CPU design, not something that effects it. Because machine code is specific to architecture, 99% of software is written in higher level languages for the sake of being able to run on as many types of machine as is possible. So machine code isn't really important except to those designing hardware around the CPU, or those who are designing a compiler for higher level languages on that architecture type.

Machine code is as low a level as you can get, however, because it's just a string of binary values, it's too difficult for anyone to write anything substantial in it. That's why people write in what's called assembly language. Assembly uses words and punctuation to represent machine code commands and thus makes it much easier to write software. A piece of software called an "Assembler" breaks it down into machine code for use by the CPU.

The way in which higher level languages are translated varies widely from language to language. Some programs are compiled into binary instructions, some are interpreted, or translated on the fly. The compiled programs can run by themselves, interpreted ones need an interpreter to run them, there are advantages to both designs. C and C++ are compiled, so games and most software don't have to be translated as they run.

The area you're asking is quite vague, and it could cover several areas of computer hardware design and computer graphics. I think it falls under computer science in general.

Operating systems are an intermediary between hardware and software. Software never accesses hardware directly, (this is for stability reasons, all you would need otherwise is a badly written piece of software to crash your entire PC) it will do it through the OS's "hardware abstraction layer". Things like DirectX and OpenGL allow software to efficiently control the hardware through the operating system without ever having to directly interface with them.

[vektorboson 8]

Quote[/b] ]I do know that C++ and C are very close to machine code which is the lowest language form you can input into a processor. I wonder though is 'machine code' a universally accepted standard throughout the globe which manufacturers of processors must make their equipment compatible with or are there several 'machine code' variants and if so what implications does this have on processor design? Is 'machine code' even a low enough language to be loaded into a processor or is there an even more rudimentary level it must go to before being dispatched to a processor?

First you need to abstract programming languages from their actual implementations; it really depends on the implementation whether the 'programming language' is close to machine code or not. And additionally it depends whether the 'code' is executed in a virtual machine or on actual hardware.

To answer your question about 'machine code': There are many different kinds of machine code, or better 'Instruction sets'. As you mentioned the Amiga, you should know that the Amiga-series used the Motorola 68xxx-series processors; they are so called CISC-processors. Then there is the x86-architecture, which includes most of the Intel- and AMD-processors (and several others) which is also CISC. Machine code for 68xxx and x86 is not compatible so Amiga-emulators need to execute 68xxx-code in a virtual machine (unless the programmers go the hard way and translate 68xxx-instructions into equivalent x86-instructions).

As the name says, CISC-processors are pretty complex, and nowadays CISC-instructions aren't executed in hardware but are translated in the CPU into RISC-instructions since RISC-architectures are easier to design.

To come back to how low-level C/C++ are, well, you can construct a simple translation scheme from C to machine code, as C isn't such a complex language. C++ is almost completely compatible with C, so you could program in C++ like in C. the biggest differences lie within classes (with so called virtual functions) and within template programming. Because of template programming one line of C++-code can generate thousands of machine instructions and one cannot say C++ is very close to machine code.

If you really want to be close to machine code, you're better of with the assemblers (every architecture has its own), as every assembler instructions directly translate to a machine instruction.

Quote[/b] ]I also know languages like Java and the like are more distant from machine code than C++ and thus have to be translated several times before going to a processor hence them being undesirable game languages. What actually does the translating though? For something to run a program coded in say Java or something do you have to have another program which specifically does the translating from Java language to machine code level stuff before sending tasks to the CPU on the host machine rather like say Internet Explorer or Netscape Navigator converts web based languages into CPU level instructions on your home machine to display pixel images on your monitor?

Most compilers work in such a way that it first builds an AST (abstract syntax tree); it then performs semantic analysis and starts to translate the code into 'intermediary code', which is closer to the hardware. This intermediary code may be either optimized or translated directly to assembly/machine code; when you're using Java, what you're really doing is shipping the 'intermediary code' which may be executed on the Java Virtual Machine, or it is JIT-compiled (JIT = just-in-time) and executed as machine code.

As for web based languages: They are not converted into CPU-instructions, and god forbid they ever are. The scripts in your web browser are normally executed in a sandbox that should never ever have access to your hardware or system.

As for Java being undesirable for programming games. Well, there are indeed games that use Java - I think the Il-2 Sturmovik-series is Java-based, and don't forget all those mobile phone games.

One of the biggest problems with game programming is memory management; Java has the problem that everything memory-related is allocated on the heap (in C++ you can decide whether an object-instance should be allocated on the heap or on the stack). If you allocate memory on the heap, it'll take non-deterministic time to find a place in memory that can hold your object. For most applications this is OK as most people won't mind if an action takes a bit longer (although this led to the impression that Java-programs are sluggish/slow); but for games this is a no-go, as you expect to have your constant 60 FPS and don't accept the game to freeze for one second (well don't think further about flight control systems in real airplanes...).

Now, C++ has the same problem, but not as much, since small, short-living objects can be allocated on the stack and don't fragment the heap (heap fragmentation makes memory allocation non-deterministic). Thus games need to pre-allocate memory and resources before they go 'live' and never should require memory from the heap when running; every 'malloc' while the game is running may kill the game.

So, in Java you need to really plan your memory allocation scheme well out, whereas in C++ you have the stack.

Quote[/b] ]Graphics and hardware. I know I can go and pick-up a book about C++ and other languages off Amazon or wherever or study a college course in them etc... but how the hell do you learn how to relate things like graphics rendering code to hardware devices? I've seen it on here before people talking about the specifics of how their graphics card handles code and the like and how all the hardware bits make a difference to this and to that. How do you learn about stuff like this, what discipline 'title' or 'categeory' does that kind of knowledge come under?

Well, it's a lot of reading; you go to Nvidia's or ATI's developer website and download white papers and other stuff. You can also go to Gamedev.net and read through their articles and forums. Or go to the Ogre3d-forums as they often have discussions about graphics hardware.

And of course, you need to read Direct3D- and/or OpenGL-tutorials, so you get a view on how those architectures work. To say it in the most stupid manner: Graphics hardware is nothing more that a processor that does linear algebra (see also homogenous coordinates) really good and fast. Of course the GPUs are getting more general purpose and are used for other applications than graphics; protein folding is an example.

All I can say is, it's a lot of math. Depending of what type of game you want to develop, and in what detail, you're going to encounter the hardest problems in computing science (this includes games, compilers, operating systems, realtime systems).

First thing: You really need to know your algorithms and their complexity (time and space complexity); then you need to really know your toolset (compiler and profiler) to identify the bottlenecks (tipp: it'll be memory, unless you're doing it wrong...). Learn about memory allocation schemes.

Learn a lot about hardware and its inner workings. Forget about faster CPUs, it's more important to utilize the memory system efficiently. You need to learn about cache lines and cache hit/miss; you need to learn about branch prediction. CPUs are very fast, but memory is still slow.

Quote[/b] ]Also with regards to an operating system (Windows/Linux) how much are they responsible for graphically? For example does the graphics engine in your average game perform language translations down to machine code and then talk directly to the CPU or does the graphics engine only talk to the Operating System which then talks to the CPU?

The OS only provides an infrastructure for hardware drivers, for process management and memory protection (yes, yes and other low level stuff...). In the case of 3D graphics, the graphics driver provides the Direct3D/OpenGL implemenetation that your engine is talking to. For your engine it's nothing more than calling library functions and it's basically unimportant how the hardware is accessed, as it's the driver's job to access the hardware efficiently.

Of course, drivers are not perfect and often you need to code workarounds for specific hardware/drivers; perhaps the hardware does not have the capabilities, your engine is requiring?

Today, 3D-hardware is being programmed by using shader languages (like HLSL/Cg and GLSL, or frameworks like CUDA) which are translated into a hardware specific representation and executed on the GPU. The CPU isn't doing much, that is probably going to change again, when we see the unification of the GPU and CPU (think of Intel's Larabee).

[chris330 0]

These are extremely good replies. I've printed off this thread and I will reply much more thoroughly when I've digested all of it. Many, many thanks for both your input!

[BraTTy 0]

Picking up a book is fine , but you can get some real hands-on experience right now with "free" MS Visual Express Editions.

Easier to learn while going through some coding examples,not to mention the help files and msdn is full of information.

http://www.microsoft.com/express/download/default.aspx

[kavoven 4]

Still it might be usefull to start with a book and hello world from scratch...I started with C, then C++ and later moved on to Visual C++ (which is a great programm!

I think starting with Visual C++ makes the whole stuff look a bit like magic since you don't know, whats really behind the button you press.

[Balschoiw 0]

I guess it really depends on what you plan to do/work with in the future. While it may basically be a good idea to start from the scratch for indeep programming most companies that do software for midbusiness productions use packages for production. Totally selfprogrammed engines for customer used productions are rare these days, except for the highly values gaming sector. In fact it´s much cheaper and faster to use building engines that incorporate already existing segments like D3D, OpenGL (it´s not dead), all the millions of hardware inputs available or physics systems. The program I´m currently working with is Quest 3D. It uses all the features todays gfx standards can deliver, has hardware inputs from all thinkable devices, even VR gloves, uses the newton physics set but you don´t have to reprogram all these segments when creating a project. You "basically" use those segments by drag-and-drop for your own project. It´s a visual interface you work with. You start with a D3D renderer, attach your objects, behaviours, cameras, lighting, collisions, systems, calculations, interactions, real-time data from satellites, etc...basically per drag and drop. For sure all the offtheshelve things still have to be programmed C-style, but it´s very easy to learn as it´s a very logical and easy programming language to learn imo. With Quest 3D for example you more or less learn it by simply creating a project

I guess it took me about 4 months to understand and learn the whole deal and that was about the time where my first big project was released (Interactive FPS walktrough of a factory producing segments for houses, including liquids and interactive information-terminals that show mpg movies, pdf´s, jpg´s and much more). In fact it was the most complicated part to import Maya animated objects into this D3D engine as the coords swapped and alpha channel in animations wasn´t supported at the time.

Anyway what I´m trying to say is that with most modern applications you don´t necessarily have to be an old-school programmer. Look at me. I´m an ex-soldier with Abitur. That´s enough

[chris330 0]

Well what can I say, I really couldn't have asked for any more than that could I! Some great stuff there chaps. I've digested the first post completely but not the others yet, I've been too busy working and flying bombers in BGE

Many thanks for the help

[chris330 0]

Right I've pretty much managed to work through the first two replies and understood almost all of it. Vektorboson's reply is even deeper than the first one. I hope to have gotten through all of it by the end of the day and will have one or two questions later on. Many thanks to those who took the time to post big replies, and to those who posted suggestions and links too.

[chris330 0]

Right I've finally made it to the end of all that and very good information it was too. Here are my questions/conclusions:

To come out of the closet a bit I think I should mention I'm planning to use a pre-existing open source graphics engine (OGRE at the moment although I also looked at Torque) to make a very long term private project purely as a lifelong journey and interest into the wonders of software and man-made marvels. I have no interest in applying any timescale whatsoever to my work no any interest in ever using it in any commercial interest. This means I can take as long as I like and not have to worry about matching the space-age standards of modern graphics and timescales achieved by big teams with huge cashwads.

1)CPU architecture is not unique to any particular make of CPU. I assume CPU architecture are patented design standards which manufacturers have to buy a license for if they wish to base their own brand of CPU on a particular established architecture. Machine code is thus the offspring of a chosen architecture - not the parent.

2)DirectX/OpenGL are a kind of go-between between a game's graphics engine and the computer's hardware. This makes me wonder though how much speed can potentially be lost here. Is it possible to have a well written well optimised game including its graphics engine, which then loses rendering efficiency due to a bad interface between game and D3D/OGL entities even though both entities are working fine on a standalone basis?

In other words - can you tune your game's graphics engine to get max efficiency by biasing it towards a particular hardware handler, i.e. D3D or OGL?

3)As for operating systems I'm thinking long-term of running stuff in Linux due to the improved stability and reputation it has compared to Microsoft's Windows legacy. I have all the time I want so I can go for ultra-optimum performance which means I'm really not interested in getting something to run on Windows.

4)With regards the virtual machine mentioned exactly what is a virtual machine? Can you program a language to handle another language's code in the same way it would be handled if it were sent to a dedicated piece of software/hardware?(I'm a bit confused on this one).

5)As for C++ I've already read one 300+ page book on it so I'm familiar with the basic concepts so I've decided to stick with it given how useful it will be long term especially given the open-ended timescale. I realise though that this is the 'jedi-master's' code and will take a long time to learn given it's purity compared to other languages, but I want that extra choice and sacrificial potential towards stuff I don't need.

6)I liked hearing about what you're up to Balschoiw with the Quest3D stuff it sounds great! My personal choice will be to opt for the building block level stuff though so I can get as much performance orientated stuff into the architecture right from the word go.

Lastly thanks again for the help in this thread it's exactly what I was looking for

[vektorboson 8]

1)CPU architecture is not unique to any particular make of CPU. I assume CPU architecture are patented design standards which manufacturers have to buy a license for if they wish to base their own brand of CPU on a particular established architecture. Machine code is thus the offspring of a chosen architecture - not the parent.

The instruction format (what you call machine code) is a part of the architecture. When you design a CPU, you need to define what instructions your CPU supports, and how those instructions look like.

Quote[/b] ]

2)DirectX/OpenGL are a kind of go-between between a game's graphics engine and the computer's hardware. This makes me wonder though how much speed can potentially be lost here. Is it possible to have a well written well optimised game including its graphics engine, which then loses rendering efficiency due to a bad interface between game and D3D/OGL entities even though both entities are working fine on a standalone basis?

In other words - can you tune your game's graphics engine to get max efficiency by biasing it towards a particular hardware handler, i.e. D3D or OGL?

You're worrying too much about that type of performance too early. As you're rather kind of a beginner you're going to encounter other performance bottlenecks.

First you should get your algorithms and data structures right.

If you're dissatisfied with your game's performance, you run a profiler over a sample session. The profiler tells you which code runs most often and which code takes away most of the time. That's where you should optimize for performance.

Premature optimization costs a lot of time an you're never gonna see any results if you worry so much about performance before you've written a single line of code.

Quote[/b] ]

3)As for operating systems I'm thinking long-term of running stuff in Linux due to the improved stability and reputation it has compared to Microsoft's Windows legacy. I have all the time I want so I can go for ultra-optimum performance which means I'm really not interested in getting something to run on Windows.

It never hurts to write platform-independent code; write only platform-dependent code if the profiler says so.

I find Linux to be a very nice development platform and a very nice Desktop OS (especially with the KDE 4.x series), so I'm a bit biased when I say go for it. But don't restrict yourself unnecessarily to a single platform.

Quote[/b] ]

4)With regards the virtual machine mentioned exactly what is a virtual machine? Can you program a language to handle another language's code in the same way it would be handled if it were sent to a dedicated piece of software/hardware?(I'm a bit confused on this one).

Think of a virtual machine as a program that emulates a CPU: It emulates registers, a stack, memory, a.s.o. The VM takes instructions in a binary format but those aren't executed on the real CPU, but interpreted by a program which manipulates the virtual registers and other pieces of 'virtual hardware'.

A VM may emulate a real CPU / real hardware (like ZSNES or those Amiga-Emulators), but it is not necessary. Many scripting languages have a VM that does not resemble any real hardware.

Virtual Machines are mostly designed in such a way that it should be possible to build a CPU/hardware that behaves exactly like their software counterpart.

In this way you can already program for hardware that does not exist yet.

Quote[/b] ]

5)As for C++ I've already read one 300+ page book on it so I'm familiar with the basic concepts so I've decided to stick with it given how useful it will be long term especially given the open-ended timescale. I realise though that this is the 'jedi-master's' code and will take a long time to learn given it's purity compared to other languages, but I want that extra choice and sacrificial potential towards stuff I don't need.

The problem with C++ is that it is a curse because of the complexity of the language (and the pitfalls); otherwise it is a bless because of the huge amount of available, mature libraries.

But don't restrict yourself to C++; you should also learn some other languages like for example Python (or Ruby) as those are quite useful utility languages. Learning a functional programming language like Scheme (or LISP) can give you a lot in terms of algorithmic thinking, especially regarding recursion.

[Synide 0]

Hi Chris,

Machine Code is literally 0's and 1's. You probably will never, ever have to write any - ever. Unless, you get into some embedded programming and even then, the likelyhood that you'll actually do some machine code is less than you winning your country's national lottery. (probably...lol).

The lowest you're ever likely to go in the heirachy of 'languages' is assembly language. It's not for the faint of heart and is becomming more and more prevalent again in the last several years.

Specifically the SIMD & SSE extensions are very much to the for front again.

1)CPU architecture is not unique to any particular make of CPU. I assume CPU architecture are patented design standards which manufacturers have to buy a license for if they wish to base their own brand of CPU on a particular established architecture. Machine code is thus the offspring of a chosen architecture - not the parent.

A lot of the CPU architecture is unique to any particular make of CPU. AMD x86 & Intel's x86 based CPU's are what's called binary compatible. Which means a 'movapd xmm2,xmm0' assembly language command ends up being exactly the same binary machine code on both Intel & AMD microarchitecture.

Quote[/b] ]

2)DirectX/OpenGL are a kind of go-between between a game's graphics engine and the computer's hardware. This makes me wonder though how much speed can potentially be lost here. Is it possible to have a well written well optimised game including its graphics engine, which then loses rendering efficiency due to a bad interface between game and D3D/OGL entities even though both entities are working fine on a standalone basis?

In other words - can you tune your game's graphics engine to get max efficiency by biasing it towards a particular hardware handler, i.e. D3D or OGL?

There are efficiencies to be had with using any software. DirectX is better with some things and OpenGL better with others.

By and large most gaming engines favor DirectX over OpenGL.

Quote[/b] ]

3)As for operating systems I'm thinking long-term of running stuff in Linux due to the improved stability and reputation it has compared to Microsoft's Windows legacy. I have all the time I want so I can go for ultra-optimum performance which means I'm really not interested in getting something to run on Windows.

Since you have all the time in the world perhaps it would be prudent to design your software to target both platforms. It would be fool hardy to assume that greater efficiencies or performance would be had on the Linux platform over the Windows platform.

Quote[/b] ]

To come out of the closet a bit I think I should mention I'm planning to use a pre-existing open source graphics engine (OGRE at the moment although I also looked at Torque) to make a very long term private project purely as a lifelong journey and interest into the wonders of software and man-made marvels. I have no interest in applying any timescale whatsoever to my work no any interest in ever using it in any commercial interest. This means I can take as long as I like and not have to worry about matching the space-age standards of modern graphics and timescales achieved by big teams with huge cashwads.

In that case I think a good way to go would be...

  C++ and C and Assembly Language

  Windows/Linux 64bit OS

  Ogre (Dunno if there is a native x64 build, but I'm sure there's probably people doing one if not)

  Make heavy use of 64Bit CPU/OS features via C++/C/Assembly.

  Whether AMD or Intel CPU download there CPU instruction set manuals and SDK's.

  Read/Play with all you can find on 'good' design/software architecture techniques.

  Read/Play with all you can find on multi-core sorftware design.

  Read/Play with all you can find on DirectX and OpenGL.

 

 

  There is so much more to all of this that it's mind numbing, everyone posting in this thread could appreciate the vast cacophony of related topics and sub-topics... don't foget to have a life too !

 

  PS. Perhaps have a look at the 'Smoke' demo recently released from Intel to highlight the advantages of multi-core programming techniques on their new Core i7 CPU's. They provide the source code also...

      It makes use of Ogre as the Render Layer, but I imagine you won't relish that it's Windows based code...

     

      The reason I mention targeting native x64 code on an x64 OS is you can aim for greater perf. by using the 64bit and 128bit media extension assembly language commands etc. interspersed with your C/C++ code (sorta) when you compile.

PS2. Don't forget those functional languages vektorboson mentioned too... very necessary imo.

[Daddl 10]

I think one of the most important things to consider is that you'll need years of dedication and experimenting to reach a level where you can master all the technologies (DirectX, Sound, Controls, etc. - and most importantly: writing performant and reliable code) required to produce a game using C++ and assembly. If you want to go this way, then I recommend thoroughly learning C++ and algorithm theory first, before starting to use technologies like DirectX. Without good knowledge of this you probably won't even understand many of the examples and write inferior code.

If you want to get faster results I'd like to point you to Microsoft's free XNA Studio. Yeah, it's not Linux, but it's a dedicated platform and development environment for games, allowing the use of .Net and C# (although I think you can still use C++ if you really want to), and offering higher productivity at little to none performance costs(*). It also comes with a ton of examples. A solid knowledge of the language and frameworks used and algorithms in general is still required for good results, so don't expect to go from non-programmer to game-guru in 24h.

*) .Net assembly code can either be compiled into machine code on installation or (the more common approach) it will be compiled just in time when the respective assemblies (i.e. libraries or executables) are accessed for the first time during a session. Once the code is compiled it's native machine code that performs about as fast as the equivalent C++ code. Only it's faster to write and safer in regards to memory leaks and stability.

[chris330 0]

Wow another load of studying for me to do!! As before I'll print those replies off, digest them and then return with questions! Thanks again chaps.

[Daddl 10]

Oh, btw: a good book reference for learning about common algorithms and their implementation in C++ is R. Sedgewick: Algorithms in C++. I can highly recommend these books.

[chris330 0]

Apologies for my disappearance I have been very busy taking care of financial matters of late and I will reply to this thread properly again as soon as I can.

[chris330 0]

Ok finally I have read through all those replies and properly reached the end of the thread doing the amount of input from other users justice not just skimming it and going 'ok'.

I printed it off again and have just finished digesting it on the dining room table downstairs.

Hardly any pen notes made on it this time, the information provided has gone beyond the point where I can structure any questions about it I am instead now just reading it and preparing to take the steps advised.

I'd like to thank everyone who posted, I appreciate greatly the amount of lost time this has prevented (potentially years!!! ) by getting me on track nice and early and by also giving me a good feel of the scale of the stuff involved. Feels a bit like I'm about to have my own version of the industrial revolution.

Thanks again

[chris330 0]

Hi just to add I have followed some of this up and I've been learning about C++ and DirectX. Here's a link to a compressed file that contains source and ready to run binaries (they run fine on my PC anyway). They're very basic DirectX programs. But I tinkered with them successfully eventually.

They're slight modifications to some of the lessons on the DirectX Tutorial site.

http://rapidshare.com/files/394991506/Read_Only_Completed_Programs.zip.html