pyNES: writing NES games in Python

[slobu]

I appreciate the effort darkhog. I hope gutomaia realizes he has eager eyes on his project!

[darkhog]

Thanks, I hope too!

[darkhog]

A question in case Gutomaia decide to respond to this thread:

How nametables are handled here and how can I import nametable made in NES screen tool to my game? I need it for title screen, instructions and such.

[gutomaia]

Hi guys,


Sorry for the huge delay. I got some problems. But now I'm putting this project back on it's track.

The project it self lacks not only documentation. But that are several features that are broken. And has some architectural problems.

Also I need a way to help people download and use pyNES.

So, tomorow I you find a very suitable windows executable.

I will keep this thread updated.

Thanks darkhog for document the project. I want to use that as the first oficial documentation. I will take a good look, and add it to github. Darkhog? do you have an github account?

thanks

[darkhog]

Yup, name same as here.

[darkhog]

As for what I want to achieve with pyNES, my ultimate goal is to port platformer I've made using Stencyl a while ago to actual NES rom (I already have chr with all sprites used there tucked away). It is already made with NES' limits (music was done in FamiTracker so I have ftm files) in mind so it probably will be easy to port once I'll know what I'm doing (and will take off every zig ). But before that I'll need to learn many things and pynes will need to be developed further.

[darkhog]

Any news on the project?

[qbradq]

PyNES isn't going to be able to allow you to port an existing PyGame project to the NES. PyNES is a set of Python functions like read_controller() and move_sprite() that generate NES code to implement the named function. Think of it as a templating language for a NES game.

[darkhog]

I know that. And pyGame is bonkers on API side anyway.

I don't think anyone in the right mind would try to get straight pyGame port to nes with pyNES. I'm going to make original projects with it.

//edit: And if you are referring to my earlier post, by "port" I meant "rewrite whole thing from scratch for NES" using already made graphics.

[gutomaia]

Yes!

We have news!

1) First, now I have windows and mac binaries. I mean, that would be easier for other platforms to install and test pyNES.

2) I've started to deattach the innerfunciton module. That way would be easier to write plugabble functions. Also would be easier to rewrite the whole logic part. I mean "ifs, loops"

Project is not dead!

[qbradq]

That's great news! Python is my favorite language, and the NES my favorite retro platform, so this project has always had a special place in my heart. And it seems to have been effective in at least a few instances of bringing folks into the NES Dev scene.

[darkhog]

That's great news! Python is my favorite language, and the NES my favorite retro platform, so this project has always had a special place in my heart. And it seems to have been effective in at least a few instances of bringing folks into the NES Dev scene.

Yes, pretty much. Since I got interested into making NES games, I've looked into easy ways to make NES games and cc65 wasn't easy enough as I just plain hate C/C++ (not languages with C-like syntax as I love Java, C# and D, just C/C++) because you can shoot yourself in the foot so easily with it that you wouldn't even know that until some user, months after "tested" release (not RC, beta or anything, final one) reports segfault because he looked on app funny and it turns out some pointer went null when it shouldn't do that yet.

[tepples]

some user, months after "tested" release (not RC, beta or anything, final one) reports segfault because he looked on app funny and it turns out some pointer went null when it shouldn't do that yet.

There'd be one quick way to solve this particular problem: separate pointer types into a non-null pointer type, whose variables cannot be assigned null, and a nullable pointer type, which can't be dereferenced without an explicit "if null" block. This way the compiler can verify at compile time that a null pointer dereference will never happen. The Rust language has this, called an option type. Even SQL has NOT NULL column types. (SQL has pointers but calls them foreign keys.)

[darkhog]

Tell that to poor Turbo C I had to learn C on. Or cc65 for that matter.