Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Jun 2002
Offline Last Active Mar 13 2014 08:55 AM

Posts I've Made

In Topic: Are some people not cut out for programming?

11 March 2014 - 08:05 AM

The way you become 'good' is by:

  1. Coming up with a 'good design' you think will work.
  2. implement the code.
  3. Ship the result
  4. Spend the next 6 months fixing all the terrible flaws in your 'good design'

No one is born a software engineer, it's just something you get better at with experience....

In Topic: casting an expression: what exactly casts the compiler?

24 February 2014 - 01:23 PM

it should only cast the result afaik.


I hope not! It should cast whatever is directly in front of the cast operator. So, in this case:

int a=1, b = 2;
float f = (float)a/b;

It will convert both a and b to floats prior to computing the division. The cast itself will only actually force 'a' to be converted to a float, but since 'a' is a float, 'b' will in turn be converted to a float (due to the rule that the operand on the left of the operator determining the operation used). As proof, the ASM looks like this:

cvtsi2ss xmm0, DWORD PTR _a$[ebp] // convert a to float
cvtsi2ss xmm1, DWORD PTR _b$[ebp] // convert b to float
divss<span> </span>xmm0, xmm1
movss<span> </span>DWORD PTR _c$[ebp], xmm0
In this case however, it will evaluate a/b using integers, and then cast the result.

int a=1, b = 2;
float f = (float)(a / b);
The ASM: 

mov<span> </span>eax, DWORD PTR _a$[ebp]
idiv<span> </span>DWORD PTR _b$[ebp] // integer division
cvtsi2ss xmm0, eax // convert result to float
movss<span> </span>DWORD PTR _d$[ebp], xmm0

In Topic: Building a header file from libraries

17 February 2014 - 08:36 AM

Yeah, you can utilize a combination of dumpbin & dbghelp to do this (and possibly other tools such as libtool). **IF** your DLL is well formed (by that I mean, has a purely functional interface - i.e. you are not able to access member variables in your DLL classes/structs; and you have properly exported the ctors and all objects are allocated on the heap from within the DLL - no stack allocation allowed!), then it will work. Chances are though, your DLL is probably NOT well formed, and so the code that is generated is likely to be horribly broken. If you have the original headers, and you just want to clean them up, then it's best to take this as an opportunity to refactor your headers. It is the safest and easiest option. 

In Topic: Is today programming a games easier or harder than in 8,16- bit era?

09 February 2014 - 12:44 PM

The development tools do make things far easier now than they did back then (where you'd be writing your own HEX->Machine code editors in BASIC). 

The difficulty of game development today though, is simply because the machines are so much more capable, which means you'll be using a lot of 3D/4D mathematics because the users have come to expect flashy 3D graphics with bump mapping, DOF, ambient occlusion, etc. 

That complexity simply wasn't there in the 8/16bit days, because the hardware wasn't capable of handling it. 


09 February 2014 - 06:53 AM

To make a game of 'commercial' quality is much harder now.


Back in the 8bit days, you'd need to understand the machine down to the lowest level to make a game work, but then the complexity of the computers was much simpler (so it was something you could learn within a year or so). The 16bit era was a little bit more involved on the programming side, but still achievable. The only real problem was a lack of reliable information on the systems you were developing for (we are talking about a pre-internet time, so finding out information involved library searches, asking friends, buying specialist magazines/books etc).


These days getting your head around CPU registers, SIMD, & multi-threading will take a lot of time. Sure the dev tools are better, but back then we'd just worry about painting a few 32x32 sprites and a few parallax backgrounds in Deluxe-paint. These days you'll spend months doing modelling, you'll model super high res models to generate normal maps, then you'll be painting up any number of textures for your specular/diffuse passes. Whilst there are simpler languages than C++ available, you'll still need to understand how 3D mathematics work, and you'll be working with multiple languages (e.g. HLSL/GLSL). 


Certainly you could pick up a game engine off the shelf that allows you to get something working fairly quickly, but you'll still need to spend time learning and understanding what is a very complex piece of engineering. 


Developing for 8bit/16bit was actually very easy. The hard part was reading seriously unpleasant technical documentation to help you understand how  to write games (because there weren't that many tutorials, although there were plenty of code & hex examples you could pick apart).