Game developers...

[Bonknuts]

 I get what TheOldMan is saying and completely agree. Logic and problem solving are more important than knowing anything above algebra (or intro to algebra 7th grade, IIRC). But when you work with any level of math algebra or higher, you're problem solving. This direction works out and builds up that part of your brain. I highly doubt you're gonna get a quadratic equation, and need to solve the vertex and line intercepts in most programming projects. But, IMO, knowing how to reduce a more complex equation into something simpler, or expand it into simpler steps (it goes both ways). Or just looking at what's need for the equation, and set limitations so that you can further reduce steps (replacing variables with coefficients and/or putting limits on variable's value range), etc. On these old systems, there's no multiplication or division. Binary shifting is the closest you'll get. If you need (i*c)+j. And 'c' is a constant and a value of the power of 2, then you can simply shift i and add j. Like wise, if you're in a loop where i increments by a constant value, then you can reduce it down to just an add and no shift. I.e. problem solving by removing redundant operations. A lot of times, you need to come up with the limitations yourself on the higher level end, so that you can optimize for it on the lower level end.

 But that's not to say just because you're not good a higher level math, that you don't possess an intuitive ability for problem solving. The mind works in mysterious ways like that. They're not mutually exclusive. But practicing/learning one (math), does helps out the other IMO. How much, depends on the person.

11*11   = 121 sprite vs sprite collisions  (You or robots colliding with one another)
1*10    = your shot vs. 10 other shot collisions
1*10    = your shot vs 10 robots
10*1    = 10 robot shot vs. your hero collisions
10*9    = 10 robot shots vs 9 other robots (cant shoot themselves)
1*11    = Otto colliding with any other sprite
1*11    = Otto absorbing shots
1*22    = wall checks for all 22 sprites

 That's a lot of collisions per frame.


 Also, writing in assembly necessarily guarantee automatic improvement in speed (relative improvement) over some higher level language compiler. It's highly depended on the processor and it's highly dependent on how you optimize your code. But I can say this, 9 times out 10 your real optimizations are going to come from the higher level logic first, then lower level logic (cpu instructions). Optimizing the hell out of something that's poorly designed to begin with, usually doesn't net much result for the amount of work put in. The best optimizations come from thinking in both levels at once.

[TheOldMan]

But when you work with any level of math algebra or higher, you're problem solving. This direction works out and builds up that part of your brain.

But note that this is -not- the only way to work out that part of your brain. Do some serious programming and planning, and you'll get better at it. Anything you practice you get better at (usually).

........................................................................................

But I can say this, 9 times out 10 your real optimizations are going to come from the higher level logic first, then lower level logic (cpu instructions). Optimizing the hell out of something that's poorly designed to begin with, usually doesn't net much result for the amount of work put in

I agree with this, sorta. If something is poorly designed, it's going to be hard to optimize it; hence, trying to optimize it will probably result in a cleaner design, which -can- be optimized better. I was taught a long time ago that programming means writing, and then re-writing, and then .... You get the idea. The second try is almost guaranteed to be better than the first.

As for 'real' optimizations, yeah. Major improvements are only going to come from changing the algorithm used; You're not going to get a 10-fold improvement just by moving to assembly. That's just part of optimizing.
But there are a -lot- of things that can only really be done one basic way; Take strcpy() as just a basic example. Knuth shows about 3-4 different ways of writing it when he explains pointers. But he takes the time to point out that each version will run at different speeds on different machines; those that have multiple index registers (ie, used as an array index) will run that version as fast as cpus with a single indirect register will run the pointer version; it all comes down to what the cpu can do as to which version is 'best'.

But that's not why we optimize some sections of the code. Quite simply, HuC sucks at generating anywhere -near- optimal code. And if you think that's not a problem, try writing a pc program with and without optimization using gcc. You'll quickly discover there are a -lot- of optimizations that can be performed automatically (like all of those you mentioned), that -aren't- in Huc. (And don't get me started on simple things, like function calls and parameters. Much less pointers.) A lot of the optimizing we do involves working out a relatively speedy algorithm in HuC, and then fixing the crap assembler it generates. Makes a world of difference in speed. [And don't think it's just HuC. I used to do the same thing with the earlier versions of Microsoft c.]

That's a lot of collisions per frame.

[ But I think 1 frame = 1/30 sec. If Arkhan hadn't insisted on using bounding boxes (ie, not the actual sprite sizes; it varies depending on which way you face) we could have done it in 1/60 sec. All those adds added up. No pun intended. It's one of the things I want to fix for the multi-player version But to be fair, is -was- his decision to make.]

[Arkhan]

Yeah, Insanity has alot of collisions per frame.  The fact that it has no slowdown is a testament to the bamfness at Aetherbyte. 

But I think 1 frame = 1/30 sec. If Arkhan hadn't insisted on using bounding boxes (ie, not the actual sprite sizes; it varies depending on which way you face) we could have done it in 1/60 sec. All those adds added up. No pun intended. It's one of the things I want to fix for the multi-player version But to be fair, is -was- his decision to make.]

If you used 16x16 boxes the game would be more shitty than it already is!

You'd collide before you get visual confirmation!

and Spenoza, you didn't insult anything lol.  I'm sorry if I'm coming off defensive.  I'm not!  I'm just giving the behind the scenes stuff that most people are unaware of.  Things that seem kind of plain/easy on the surface can pandoras box into a nightmare.

... like Insanity did!

More collisions than a commercial shooter! Whoops.



Also, an understanding of math only gets you so far.
See, there are programmers who program, and then there are engineers who program.

I have a buddy that has a masters in controls systems engineering.  He is a mathematical god.  Tons of physics, calculus, and other odd maths.  You give him a math problem, he will solve it.  He's reverse engineered Ultima Online to the point where hes got more money than the rest of his server combined.  You will probably lose most table top games with him.  He crunches numbers in his head and figures out how to pummel everybody before they even finish their turns usually.

He can't program.   He openly admits it.  He can f*ck with something until it does what he wants, but it will be inefficient and have "what the hell were you thinking" written all over it because he doesn't have a grasp on key good-programming concepts.  He will get a problem, figure out how to solve it, get it working, and be done with it.  He's not expected to be an ace at efficient programming.  Hes an engineer!

Being able to think abstractly, planning for things to be modular (collision checks!), having tightly-knit logical processes.... that stuff is far more important.  If your mathematical algorithms are the most amazing things ever, but the logic to implement them is full-retard, it won't matter.  You'll bottleneck all over the place and produce tons of overhead just by being sloppy with your planning.



and, lol, pointers in HuC.  Yeah right.  We don't even get structs.