Lisp is and was the best programming language. I moved to Java many years ago and still regret :)
Technical Breakdown of a new NES game written in Lisp
51–60 of 71 posts
Re: Technical Breakdown of a new NES game written in Lisp
#52I'm struggling with the same problem: I'm a Lisp programmer who's writing a commercial game, in my case a Unity engine game, which requires C#. I've opted for a less elegant, but technically simple strategy: I'm writing all the build tools/content tools in Clojurescript, and then writing only the core game engine in raw C#. Next, I'm using http://bridge.net to cross-compile the game engine into javascript, which I ca…
Have you explored Arcadia at all? It uses the Clojure CLR port to hook into Unity with some sweet repl goodness.
https://github.com/arcadia-unity/arcadia
There seems to be some active development and I hope it works out great.
Re: Technical Breakdown of a new NES game written in Lisp
#53I'm struggling with the same problem: I'm a Lisp programmer who's writing a commercial game, in my case a Unity engine game, which requires C#. I've opted for a less elegant, but technically simple strategy: I'm writing all the build tools/content tools in Clojurescript, and then writing only the core game engine in raw C#. Next, I'm using http://bridge.net to cross-compile the game engine into javascript, which I ca…
Have you explored Arcadia at all? It uses the Clojure CLR port to hook into Unity with some sweet repl goodness. https://github.com/arcadia-unity/arcadia There seems to be some active development and I hope it works out great.
It's a cool project, but I mad the judgement that it was too risky as a dependency for my game.
Re: Technical Breakdown of a new NES game written in Lisp
#54This was an incredibly enjoyable read. A lesson to take away is that many of the ideas of Lisp can be taken advantage of without reeling in the entirety of an existing stack. Writing a Lisp parser is easy. Walking Lisp code is easy. Serializing Lisp code is easy. Adding a new primitive is easy. Adding very basic syntax transforming macros is easy. All of these are virtually trivial if your host language is a Lisp, as…
I think this is very true. It also wouldn't be hard to implement basic function pointers, lambdas that don't capture anything.
Re: Technical Breakdown of a new NES game written in Lisp
#55If you like this, you should also check out the work around Retro City Rampage. RCR is a GTA1 clone for multiple platforms from a few years back, but the developer also made a real NES ROM of it. Here's a great talk about that process: https://www.youtube.com/watch?v=Hvx4xXhZMrU (I'm not related to the project, but it's one of the few games I've 100% completed because it was just so good)
I don't think they finished the NES version?
Sort of, it's in the game as an emulated ROM: https://www.youtube.com/watch?v=ZffFxLyD4Ig
Re: Technical Breakdown of a new NES game written in Lisp
#56Earlier quoted context omitted.
They used Lisp to generate machine code. They didn't parse lisp at all. Imagine writing a library in your favorite language to do what they've done.
They did parse it, albeit indirectly, by Racket’s reader. Co2 is a language, not a bunch of function calls, so it’s not quite the same as building a library in your favorite language. The article even gives examples of new syntax they produced. Parsing Lisp in Lisp is so easy because it’s free.
> Parsing Lisp in Lisp is so easy because it’s free.
Are there any other languages that have this feature? I.E. where the data and the code are the same syntax?
Re: Technical Breakdown of a new NES game written in Lisp
#57Earlier quoted context omitted.
They did parse it, albeit indirectly, by Racket’s reader. Co2 is a language, not a bunch of function calls, so it’s not quite the same as building a library in your favorite language. The article even gives examples of new syntax they produced. Parsing Lisp in Lisp is so easy because it’s free.
https://github.com/dustmop/co2/blob/master/compile.scm#L3689 Indeed, it's almost trivial.
you just need to implement read-syntax ...
Re: Technical Breakdown of a new NES game written in Lisp
#58Earlier quoted context omitted.
They used Lisp to generate machine code. They didn't parse lisp at all. Imagine writing a library in your favorite language to do what they've done.
They did parse it, albeit indirectly, by Racket’s reader. Co2 is a language, not a bunch of function calls, so it’s not quite the same as building a library in your favorite language. The article even gives examples of new syntax they produced. Parsing Lisp in Lisp is so easy because it’s free.
> Parsing Lisp in Lisp is so easy because it’s free.
You just have to implement an s-expression reader.
Plus an interpreter, compiler or a code walker, which can actually parse the Lisp code.
Re: Technical Breakdown of a new NES game written in Lisp
#59I’d like to hear more about the compiled stack. In extremely latency sensitive applications, the mix of stack and instruction cacheline faults can cause significant overhead.
I've only heard this term used with PIC development tools.
It makes all local variables have a fixed place in RAM. This obviously removes support for recursion. A naive implementation would cause this to explode memory usage.
However, you can analyze your entire program and any variables (including across function boundaries) that are never live at the same time are now allowed to share storage. Now you never push or pop variables to your stack, and your dynamic stack size is only the maximum call depth (no frame pointer needed because you don't have any on-stack variables, so you only save the return pointer to the stack).
Re: Technical Breakdown of a new NES game written in Lisp
#60Earlier quoted context omitted.
With only looking through the article and being a 6502/NES programmer myself, you can't escape having to know 6502 and the NES hardware to write a NES game. This Lisp is cool and it will certainly smooth the process and is a good fit for an Adventure game and other parts of NES game development where you aren't counting cycles (like UI).
Good to know. Assuming it's true that 6502 asm is not too difficult to learn, co2 looks like it would be fun to work with on a simple game. Really neat project.
6502 is easy to learn. Have some fun here https://skilldrick.github.io/easy6502/
For me the challenge with the NES itself was getting a good tutorial and then with making a game, getting your art from your mind into the tiles and sprites and in your project. Your art 'pipeline'. Once that's established it becomes easier.