RE: [pygame] people hating python for game dev.

[Chris Ashurst <CAshurst@xxxxxxxx>]

As I said, it's more or less just a copy and paste from the original authors
code with a few extra opcodes I put in. I think he possibly used switches,
because he could line them up nicely for readability. The original author
also intended for people to be able to run curses, which is why there's a
bit of a hack near the bottom to smoosh the output differently.

However, to get out of the whole elif thing, you could consider something
like the following:

getattr(self, "_" + opcode)(register, value)

So, say for example you had the instruction 031012, you'd write a function
that would intercept any incoming instruction and split out the relevant
parts (in this case, the opcode is 3, and we're putting the value 12 into
register 1).

so somewhere else in your class, you'd have a method defined as such:

def _3(register, value) {
	// Insert value into specified register
	r[register] = value
}

(Say r is a global tuple that represents your register addresses).

So your function that's splitting up the incoming instruction would then
call getattr with the freshly decoded instruction like so:

getattr(self, "_" + 3)(1, 12)

Basically the same as calling the function elsewhere in the code.

The above is an incredibly rough guide of what you *could* do. I worry about
arbitrary execution of code in any language as it is, and as such, tend to
steer well clear of it. You could do something with lambdas.

-----Original Message-----
From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx]On
Behalf Of Luke Paireepinart
Sent: Wednesday, May 17, 2006 13:15
To: pygame-users@xxxxxxxx
Subject: Re: [pygame] people hating python for game dev.


Chris Ashurst wrote:
> Sure thing.
>
> http://www.telestatic.net/python/cpu/
>
> It's a tad untidy, and I shoved some of my own stuff in there, but it's
got
> the comments from the original author liberally sprinkled throughout.
Ah, not to say anything negative about your code,
since the number of opcodes is small,
the whole "if -elif" branch (which in a C++ emu would probably be a switch)
is okay because it's concise.
However, in a larger subset of opcodes,
it starts too look ugly and hard to manage.
I know there's a more elegant approach to this,
and I've thought about it a lot.
You have any ideas on this?
the reason I ask is because I'm writing a
CPU emulator that has ~57 opcodes
and 13 addressing modes and
I really don't want a giant if-elif branch.
I don't care if there's a slight speed hit
by making them classes or functions or something.
My goal is to make the code understandable
and pretty, not fast.  I can make it fast later
if I need to.  I'm not going to try to write optimized code
off the bat.
So if you have any idea on how to implement the opcodes
in a less-switchy way, I'd appreciate the input.
Thanks.
-Luke




CONFIDENTIAL NOTICE: This email including any attachments, contains 
confidential information belonging to the sender. It may also be 
privileged or otherwise protected by work product immunity or other 
legal rules. This information is intended only for the use of the 
individual or entity named above.  If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, 
distribution or the taking of any action in reliance on the contents 
of this emailed information is strictly prohibited.  If you have 
received this email in error, please immediately notify us by 
reply email of the error and then delete this email immediately.