It was pretty nifty, although after I upped the size of the world to 200x200, Ruby could no longer process everything quickly enough to maintain the 1 FPS framerate I was working with - which I found pretty funny really, because there isn't that much processing going on. But whatever.
I decided to port the thing over to C because C is fast, and when it comes to SDL most of the calls are the same. It was now though that I really realized how much Ruby makes you lazy. Maybe not lazy, but it spoils you. For example, in Ruby you can do this:
pieces = File.read("my_file").split("\n").map { |l| l.split(//).map(&:to_i) }What this does (for those who don't know Ruby) is take the file, split it into an array of it's lines, and convert each line into an array containing the integer version of each character in the line. It's magical! Try doing this stuff in C:
FILE * f;It's so much longer in C! Why do I have to write so much?
char c;
int pieces[SIZE][SIZE];
int i;
f = fopen("my_file", "r");
while (!feof(f)){
c = fgetc(f);
pieces[i / size][i % size] = (int)(c - '0');
i++;
}
The answer is because it is faster. Like ridiculously faster. I put up the screen size to 800x800 (didn't make it higher because the window was only 800x800, but I could probably go higher) and it still maintained the same framerate.
This whole experience taught me something. While it is really nice to work with Ruby all the time (or languages like Ruby, say Python, Perl or dare I say it, PHP), these languages spoil you in ways that in time, you forget. However these nice things do come at a price, and when we need to do some work that is CPU-time-bound, I'm afraid that we may no longer have the skills to speed things up. It is important that when we're working with "productivity" languages like Ruby, we should still work with faster languages to keep us sharp.
2 comments:
For speed, shouldn't you be programming in ASM? ;)
Nope, I have faith that gcc is a better assembly coder than I am!
Post a Comment