Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Porting SBCL to the Nintendo Switch

reader.tymoon.eu

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Porting SBCL to the Nintendo Switch

#61

Post by pjmlp »

Arelius wrote: post #31
jsheard wrote: post #11

Earlier quoted context omitted.

Because it's well established that game developers can and will jump through whatever hoops the platform holder demands at their own expense, they don't have the leverage to be picky about the technical details when deciding which platforms to ship on. Nintendo doesn't need to create new incentives to release on the Switch when they already have the biggest incentive of all: 140+ million units sold, and a high attach…

Yeah, also whatever they would build, the other platform vendors won't choose the same thing, and it wont be the exact variant of lisp or w/e that even the few nice developers would want. I wish vendors would be just more supportive of different llvm tool chains. Rust isn't even well supported.

Rust isn't even available on Android NDK, even though is now used on Android.

Same applies to Rust on Windows, and whatever Microsoft is doing, windows-rs isn't that great, and after what the team did with C++/WinRT I don't have high expectations.

So consoles have even less reasons to support Rust.

Re: Porting SBCL to the Nintendo Switch

#62

Post by vindarel »

dasyatidprime wrote: post #58

How's CL's GC performance for games nowadays? I've been slightly eyeing the upcoming Autumn Lisp Game Jam myself, but last I checked all the major libre CL impls, including SBCL, still used a full stop-the-world collector, which feels like a recipe for latency spikes. I saw flashes of stuff on sbcl-devel about someone working on a lower-latency one, but I don't know whether it got anywhere.

see this detailed report: https://raw.githubusercontent.com/Shinmera/talks/master/els2...

> Overall we have needed to do surprisingly little actual performance analysis and optimisation work to make Kandria run well.

Re: Porting SBCL to the Nintendo Switch

#63

Post by Shinmera »

superdisk wrote: post #59

Great article. One question I had, not to diminish this hard work, is why not use a different implementation like ECL which is pretty portable already and can compile to static C code which can just be compiled traditionally for the target? I've been doing that for a Wasm + SDL2 game in Lisp and it's been (relatively) straightforward. I suppose performance might be a issue.

Because, as you guessed, no implementation other than SBCL comes close to the performance needed.

Re: Porting SBCL to the Nintendo Switch

#64

Post by tmtvl »

ArneBab wrote: post #54
hoten wrote: post #44

b/c it isn't described anywhere... SBCL - "Steel Bank Common Lisp" > Steel Bank Common Lisp (SBCL) is a high performance Common Lisp compiler. It is open source / free software, with a permissive license. In addition to the compiler and runtime system for ANSI Common Lisp, it provides an interactive environment including a debugger, a statistical profiler, a code coverage tool, and many other extensions. https://www.…

According to the Benchmarks Game, SBCL is roughly as fast as Node. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

See also https://github.com/attractivechaos/plb2 ...where I provided the SBCL solutions, so there's probably still a significant chunk of performance to be squeezed out.

Re: Porting SBCL to the Nintendo Switch

#65

Post by aktau »

Related: https://opengoal.dev.

Context: Naughty Dog used a custom Lisp-alike (GOAL) to build the Jak & Daxter series on PS2. They left enough debugging information in that it was possible to reverse engineer. The OpenGOAL project has done so, and these games can now be run on all platforms that their GOAL compiler gets ported to (x86 for now AFAIK). Would be cool to port this to the Switch.

Re: Porting SBCL to the Nintendo Switch

#66

Post by Shinmera »

trenchgun wrote: post #40

Does anybody know what is the status of Trial on Mac OS? Specifically Apple Silicon

I don't have a mac, let alone a silicon one, so I can't test on it (I also have no patience for Apple's BS). However, it should work. At least SBCL itself runs, and Trial is mostly portable code, so it should, too, modulo some regressions.

Re: Porting SBCL to the Nintendo Switch

#67

Post by igouy »

taeric wrote: post #45
koito17 wrote: post #36

Earlier quoted context omitted.

> The ability to evaluate code interactively without recompilation SBCL and other implementations compile code to machine code then execute it. That is to say, when a form is submitted to the REPL, the form is not interpreted, but first compiled then executed. The reason execution finishes quickly is because compilation finishes quickly. There are some implementations, like CCL, with a special interpreter mode exclus…

I think a lot of this is confusion between online versus batch compilation? Most of us have only ever seen/used batch compilation. To that end, many people assume that JIT in an interpreter is how online compilation is done. I probably am more guilty of that than I should be.

> online compilation

? incremental compilation

Re: Porting SBCL to the Nintendo Switch

#68

Post by phlakaton »

Jach wrote: post #47
sinker wrote: post #17

Earlier quoted context omitted.

Lisp languages seem well-suited for building games. The ability to evaluate code interactively without recompilation is a huge deal for feature building, incremental development, and bug-fixing. Retaining application state between code changes seems like it would be incredibly useful. Common Lisp also appears to be a much faster language than I would have blindly assumed. The main downside for me (in general, not jus…

If that's your main downside, that's pretty good, since clunkiness is in many ways fixable. Personally with standard CL I like to use property lists with keywords, so a "map literal" is just (list :a 3 :b 'other). It's fine when the map is small. The getter is just getf, setting is the usual setf around the getter. There's a cute way to loop by #'cddr for a key-and-value loop, though Alexandria (a very common utility…

The cost of a macro is not measured in lines of code. It's measured in things like adoption, clarity, and debuggability.

Re: Porting SBCL to the Nintendo Switch

#69

Post by codr7 »

coliveira wrote: post #52
pjmlp wrote: post #21

Earlier quoted context omitted.

There are 1980's papers about Lisp compilers competing with Fortran compilers, unfortunately with the AI Winter, and the high costs of such systems, people lost sight of it.

Well, I imagine at the time they had some LISP implementations that were very well tuned for specific high end machines, which essentially duplicated Fortran functionality. This is difficult to do for general purpose Lisps like SBCL. It was also probably very expensive.

As well as high end machines built for Lisp.

Re: Porting SBCL to the Nintendo Switch

#70

Post by Retr0id »

opan wrote: post #56
ArneBab wrote: post #53

Earlier quoted context omitted.

You don’t let your kids jailbreak their Switch. Because it’s a damn online system, so any leaked info and Nintendo can brick the Switch. And their game states are far too valuable for the kids for that.

Trey can ban the Switch, but offline games will continue to work. Also the account doesn't get banned, so you can buy a new one. (Speaking from experience, unfortunately) You can still play the new Zelda, just can't play Splatoon, Mario Kart, or Smash online then on the banned Switch. It's possible but arduous to rescue the saves off the banned Switch if you have access to a second modded Switch that is not banned (a…

> we're stuck with a "tethered jailbreak"

Modchipping makes things permanent, although the soldering isn't for the faint of heart.

Post reply on HN