Just under a month until the deadline. Please send your submissions to sebastian DOT redl AT getdesigned DOT at. It should be a single archive (zip, tgz, tbz, rar, 7z, I don't really care which).
Just under a month until the deadline. Please send your submissions to sebastian DOT redl AT getdesigned DOT at. It should be a single archive (zip, tgz, tbz, rar, 7z, I don't really care which).
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Yep, brewbuck, I'm working on it too. I have a working version but I'm trying to improve on it before I submit it.
abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "
My intention is to write it in Visual Studio, so I guess Im out.
Ok well I had a go at knocking up a quick version. Me being me I ignored the rules and made something with a graphical representation; the thought of staring at a list of co-ordinates trying to figure out what was going on would stretch my attention span a little too far. I couldent be bothered with lists either so its all done on, and limited to, a 2d array. Its very slow; O to the something horrible.
If anyone else finishes this youre guaranteed to beat me
I attached the source; it requires SDL. I'm not completely sure If I got it right. My little automatons dont seem to behave very interestingly off a random generated grid. Oh well.
I still fail to see how you can get an inline assembly version working reliably in both 32-bit and 64-bit environment (a requirement). In fact, Visual Studio does not allow inline assembly for 64-bit targets.
Thanks, mike. I'll try to give you some feedback over the weekend.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Not wrong, but just because the instructions are available, doesn't mean you can use all code without changes.
For example, to completely dereference a double pointer, in 32 bits you do this:
In 64 bits you do this (guessing a bit here - do the 64-bit GPRs have a g or an r prefix?):Code:MOV eax, DWORD PTR[somevar] ; Load variable MOV eax, DWORD PTR[eax] ; Dereference once MOV eax, DWORD PTR[eax] ; Dereference twice
In AT&T syntax, it's yet more complicated, because the operand size is in the instruction mnemonic. So instead of movl you have to write movq.Code:MOV gax, QWORD PTR[somevar] ; Load variable MOV gax, QWORD PTR[gax] ; Dereference once MOV eax, DWORD PTR[gax] ; Dereference twice (get at a 32-bit int)
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
You can use inline assembly under VS 2005 and 2008 and it will compile for an x86 target, btu if you try to compile it for an x64 target , then it throws errors. Yeah lots of developers are ........ed at MS for that one, it basically makes it 10 times harder to write drivers, since now all the hardware companies have to buy additional products and convert all their existing code.
Sorry , didn't mean to derail your thread, lets get back on topic now.
I think you're getting uninteresting results because you're not using the right rules:
You're only looking at the four neighbors above, below, left and right. The actual rules require you to examine the four diagonal neighbors as well. Add that, and I bet things get a lot more interesting.Code:Uint8 u = (y > 0)? cells[flip][x][y-1]: 0; Uint8 d = (y < Y_CELL-1)? cells[flip][x][y+1]: 0; Uint8 l = (x > 0)? cells[flip][x-1][y]: 0; Uint8 r = (x < X_CELL-1)? cells[flip][x+1][y]: 0; switch(u+d+r+l)
Will you be analyzing memory usage of the submissions? It might be interesting data.
As long as there are no penalties for horrible abuse of memory... You did say you have 8GB of Ram, right?
abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "
I have one Gig on both test machines
I can analyze the usage, but I won't count it. My experience with our own program is that memory usage is its own speed penalty in CPU-bound applications. Basically, our performance went down drastically when the data got too large to fit into the L2 cache. And God help you if you start swapping.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law