PicoSnake - 2.0.0

replace
v=e.key-272
by
v=e.key&7

replace
[f(99,(o%T*T,o/32*T,T,T))for o in l+[a]]
by
[f(-1,(o%T*T,o/32*T,T,T))for o in l+[a]]
for better visibility

I don't think the D variable can be completely eliminated -- the reason it is there is because if you press two directional keys at the same time (one back on yourself, one a valid turn), and the valid turn gets processed first, then you can hit yourself. I could accept removing it if the bug were fairly infrequent, as this program does have a history of bug tolerance unlike mine (event.get(), anyone?)

As a side note, geometrian, can you tell what the line while not x&528 does? It's magic, isn't it? :)

at the end of line 4 ";D=d" can be deleted (you don't use it anywhere else than on line 7 so I did "if n+d:d=n" (added tgfcoder's thing) for 297 (the game still runs the same + you can't go back on your-self).

but you could do "if-n-d&0<5:d=n" on line 7 like you have for 302

About time someone beat me and PicoSnake lived up to its name :)
Go go!

You can also change line 2 to

while x&528==0:

to bring it to 299. :)

Yes actually that line of code is broken. It's supposed to stop you going back onto yourself, but it should be:

if n+D:d=n

which will make sure your direction isn't the opposite of the last frame's direction. :) This gets you to exactly 300 bytes.

292 bytes, and its exactly the same from what I can tell. :D

but its not game-breaking really.

Also, as far as I can see, "if-n-D&0<5" is always true (correct me if I'm wrong) so chuck the d=n after v=e.key-272;n=((v&2)-1)*[1,32][v<3];

this saves you 12 bytes O:

Ooh, this results in wonky snake.. hehe.

How about changing o*32/T to o/2.

Unfortunately, I don't think so. a = (a*9)%512 isn't the same as a = a*(9%512)

on gagne 1 caractere en remplaçant
a=a*9%512
par
a*=9%512

304B--will we break 300???

If you want syntax highlighting, I believe you can change the pre tag to:

<pre class="python">(code here)</pre>

Nice job, btw. :)

320 bytes...

oh well

<i>test</i>

Yes, I was wondering about that. Obviously, key inputs will get processed. Nothing else will. I'm thinking this wouldn't be a problem, unless you repeatedly bump the mouse or something. All the <i>relevant<i> data is processed.

Am trying experimental italics here, we'll see how it works out.

Uhoh. You are right, sorry 'bout that. Ian... ;)

Look at his event.get() calling code:

for e in p.event.get(2):

He kept the 2, but didn't clear the event queue afterwards.

But he is not just grabbing specific events ;) He is grabbing *all* events. Your code grabs only specific events, note the (2) arguments you have ;)

In the end also, you are clearing the event queue the same way he is, just doing it once for the specific events you want (allowing you to use them) and once for the rest.

About the incomprehensibility, it's because I posted that when the code had those ugly &nbsb; all over it.

About the fairness, well, I guess it's OK.

And about the event queue, check the pygame docs: "If you are only taking specific events from the queue, be aware that the queue could eventually fill up with the events you are not interested." Move the mouse while you play if you don't believe me, the game is going to lock down pretty quickly (the queue will fill with MOUSEMOTION events).

regular event.get clears all events, so they are being cleared every frame, the difference is that ffao is only catching *some* of the events in his code, then destroying the rest...

That and the minus thing are all I really did to it. I also gave you nearly complete credit (plus a link) and didn't say your code was mine at all.

As for incomprehensibility, smaller code expects to be less readable.

Incidentally, I've never had trouble with the event queue; perhaps it's a pygame version thing? I almost always do event checking this way and no one has ever mentioned it...

I don't think it's really fair that you make minor changes to my code and upload it as a second version of your own -- NanoSnake is open to suggestions, after all (4 people have contributed, if I counted right). But please fix the code, it is incomprehensible right now. Also, you only call p.event.get(2) once -- you need to clear the event queue later, or else it will be eventually (no pun intended) filled with other events.

Version 2.0.0 released!

Very small indeed but before we can declare you the winner you must fix the thing with the controls, when you go right, you shouldn't be able to go left (and vise versa, the same thing with up/down).

Version 1.0.0 released!