Here's a little quiz for you. Both of these issues have come up in conversation over the past week or so, and I thought it would be interesting to pose them, and give you the chance to prove your smarter that most games developers...
Question 1
Whats the main thing to tackle inside a program, that's virtually guaranteed to speed it up?
Question 2
When writing a game, whats the 2 most important things to make sure you do? (In order please)
The answer to both these questions should be obvious, but lets see how you do. I'll answer them in a couple of days...
Now... if you cast your mind back a few years, you'll remember me doing a fancy little routine for XeO3's bullet allocation. This was a simple "stack allocator" that sped up my code by quite a bit. Well, you can now find this article in the new Games Programming Gems 8 book. Yes, about a year ago I got the article accepted, and it's now in print and out. This is the 1st time I've decided to try and get an article published, but I thought it was about time. It takes the general concept a little further and uses it in standard programming (rather than 6502), and comes with a few little examples.
The only reason I mention this (aside from being chuffed that I finally got something published), is that this is one of the main reasons I still code old machines. Without writing XeO3, this would never have occurred to me. Old machine place unique limits on what you can do, limits that simple don't appear to be around anymore, and as such require you to think outside the box. They are still a valuable learning tool, and can lead to better code on a day-to-day basis. I've now used the Stack Allocator in several applications I've since written, and found it much simpler/quicker to implement than linked lists, not to mention easier to follow. I love how retro coding really can teach an old dog new tricks....
4 comments:
Answer 1
Precalc as much as memory allows...
Answer 2
1. Make as much coffe as you can.
2. Tell your better half to go to her mothers for few hours, days, months...
Sorry I didn't come up with more serious answer but I couldn't find anything special enough to distinguish...
1) Hmm... that's a tough one really - well for me it is anyway. I know my Java assignment built up the picture faster [than my fellow student's work] because I didn't use a load of FOR/NEXT loops to draw up the screen; I simply read the relevant variables from a data array and drew everything in a single pass. That seemed to me to be the most efficient way to do things, whether it is or not is a completely different matter, and not something that anyone has answered yet. On this basis, does it have anything to do with global variables? ie, the program has all of the variables in one place, rather than all over the program?
As for question 2, I *really* don't have a clue there. I suppose I'd have to buy the book.
Indeed, hard to answer these questions as they are too open-ended. Here's my best guess:
Answer 1:
Depends on the era of the hardware you are targeting, as the problems one tries to solve are generally different. However, I'd say to have a clear objective of the goal, and a narrowly-focussed range of target hardware, so you can take advantage of what you've got. And don't use a language which is more wasteful than absolutely necessary (*cough* JAVA *cough* Ruby *cough*).
Answer 2:
Again, pretty vague. How about make sure that you are going to get paid ?
I'll assume that you mean "as a developer".
1) Scope control - don't let feature-creep kill the project.
2) Since you're talking about performance, I'll say: constant and repeated critical-path analysis. I mean, like in the old days when we would flip overscan colors when performing a certain function, so we could see both the individual compute time of a function and the net per-frame compute time. Or maybe that's the answer to your first question...
Nice blog thannks for posting
Post a Comment