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

31–40 of 84 posts

Re: Porting SBCL to the Nintendo Switch

#31

Post by Arelius »

jsheard wrote: post #11
ducktective wrote: post #8

I wish the likes of Nintendo and Sony themselves finance such efforts. I mean it's one another way to create games (IP) for your console, what possibly could be the downside of starting something similar to Github Accelerator for your platform?

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.

Re: Porting SBCL to the Nintendo Switch

#32

Post by Shinmera »

cellularmitosis wrote: post #15
Shinmera wrote: post #12

Earlier quoted context omitted.

I'm not doing the SBCL parts, that's all Charles' work that I hired him for. My work is the portability bits that Trial relies on to do whatever and the general build architecture for this, along with the initial runtime stubbing. And, as mentioned, *her :)

Holy cow, Kandria looks amazing. Is it also developed using Trial? https://www.youtube.com/watch?v=usc0Znm-gbA

Yes, it's also open source: https://github.com/shirakumo/kandria

My current unannounced project is a lot more ambitious still, being a 3D hack & slash action game. I post updates about that on the Patreon if you're interested.

Re: Porting SBCL to the Nintendo Switch

#33

Post by Shinmera »

Retr0id wrote: post #29
Arelius wrote: post #27

Earlier quoted context omitted.

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

The OS can do it, and some Nintendo titles on the Switch do use this capability, but I have talked to Nintendo directly about using it, and it's a hard No. I can't even use the JIT feature purely for dev.

Re: Porting SBCL to the Nintendo Switch

#36

Post by koito17 »

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…

> 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 exclusively for REPL-usage.[1] However, at least SBCL and ECL will compile code, not interpret.

[1] https://github.com/Clozure/ccl/blob/v1.13/level-1/l1-readloo...

Re: Porting SBCL to the Nintendo Switch

#37

Post by Shinmera »

koito17 wrote: post #36
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…

> 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 specifically talk about the fast evaluator for SBCL. But even without that contrib, SBCL does have another evaluator as well that's used in very specific circumstances.

Re: Porting SBCL to the Nintendo Switch

#38

Post by f1shy »

anisoco wrote: post #20
f1shy wrote: post #7

Earlier quoted context omitted.

- Is it not her?

It is https://reader.tymoon.eu/article/436

Oh I did not know that she transitioned. I just remebered it was the author of portacle, that was a woman.

What a world of pain must be to have to go through it.

Kudos to her. Also what she does for lisp is amazing.

Re: Porting SBCL to the Nintendo Switch

#39

Post by arktos_ »

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 some libraries that make maps and the like usable with a cleaner syntax. You too could make some macros of your own for the same purpose, if syntax is the concern
Post reply on HN