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

21–30 of 84 posts

Re: Porting SBCL to the Nintendo Switch

#21

Post by pjmlp »

sinker wrote: post #17
colingw wrote: post #2

I have being using Trial[1] for the past few weeks to test out game development in Common Lisp, and have been having a great time. Being able to alter (almost) all aspects of your game while it's running is a blessing. I hope this port succeeds. [1]: https://github.com/Shirakumo/trial

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…

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.

Re: Porting SBCL to the Nintendo Switch

#23

Post by lispm »

sinker wrote: post #17
colingw wrote: post #2

I have being using Trial[1] for the past few weeks to test out game development in Common Lisp, and have been having a great time. Being able to alter (almost) all aspects of your game while it's running is a blessing. I hope this port succeeds. [1]: https://github.com/Shirakumo/trial

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…

One of the downsides is that implementations like SBCL have a deep integration and need things like a well performing GC implementation - to get this running on specialized game hardware is challenging. The article describes that. Getting over the hurdle of the low-level integration is difficult. The reward comes, when one gets to the point, where the rapid incremental development cycles of Common Lisp, even with connected devices, kicks in.

For the old historic Naughty Dog use case, it was a development system written in Common Lisp on an SGI and a C++ runtime with low-level Scheme code on the Playstation.

> Common Lisp also appears to be a much faster language than I would have blindly assumed.

There are two modes:

1) fast optimized code which allows for some low-level stuff to stay with Common Lisp

2) unoptimized, but natively compiled code, which enables safe (-> the runtime does not crash) interactive and incremental development -> this mode is where much of the software can run nowadays and which is still "fast enough" for many use cases

Re: Porting SBCL to the Nintendo Switch

#24

Post by laidoffamazon »

not_your_vase wrote: post #22

Somewhat offtopic, just flashed through my mind: you know what would be amazing and absolutely useless at the same time? Porting Yuzu to Nintendo Switch

This has been done, and it’s been possible to run Switch on Switch for several months [0] (about 39 minutes into the video).

[0] https://youtu.be/H1gveQUBIKk

Re: Porting SBCL to the Nintendo Switch

#26

Post by not_your_vase »

laidoffamazon wrote: post #24
not_your_vase wrote: post #22

Somewhat offtopic, just flashed through my mind: you know what would be amazing and absolutely useless at the same time? Porting Yuzu to Nintendo Switch

This has been done, and it’s been possible to run Switch on Switch for several months [0] (about 39 minutes into the video). [0] https://youtu.be/H1gveQUBIKk

Shoot, it was a suspiciously genius idea* for a Friday 13th.

*: Compared to my usual ideas

Re: Porting SBCL to the Nintendo Switch

#27

Post by Arelius »

Retr0id wrote: post #16
Shinmera wrote: post #13

Earlier quoted context omitted.

You cannot publish games with homebrew, it has to use the official SDK. Besides that, almost nobody has a jailbroken Switch, so it would make it extremely hard to play any games on anything but an emulator.

> You cannot publish games with homebrew, it has to use the official SDK This doesn't surprise me much, but does Nintendo state this explicitly anywhere public? If Nintendo chose to sign an application developed using a 3rd party toolchain, there's no technical reason why it couldn't run on retail consoles.

Yeah, maybe. But also the official SDKs are pretty good and you get support from Nintendo. It seems like a pretty big risk to use an unsupported SDK... for what benefit?

Re: Porting SBCL to the Nintendo Switch

#29

Post by Retr0id »

Arelius wrote: post #27
Retr0id wrote: post #16

Earlier quoted context omitted.

> You cannot publish games with homebrew, it has to use the official SDK This doesn't surprise me much, but does Nintendo state this explicitly anywhere public? If Nintendo chose to sign an application developed using a 3rd party toolchain, there's no technical reason why it couldn't run on retail consoles.

Yeah, maybe. But also the official SDKs are pretty good and you get support from Nintendo. It seems like a pretty big risk to use an unsupported SDK... for what benefit?

I don't have access to Nintendo's SDK so I can't compare directly, but the article cites an inability to map executable pages. libnx supports this (but of course, this is moot if Nintendo wouldn't let you ship it). But the main benefit is being able to talk about and share your work without worrying about violating an NDA.

https://switchbrew.github.io/libnx/jit_8h.html

https://switchbrew.org/wiki/JIT_services

Post reply on HN