[9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

https://github.com/hajimehoshi/ebiten

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Ma2100d49fb233f6d22379b6e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 778 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

Yes.

Game dev could be pretty cool on plan9.

 I've been using love2d on Linux to write a frontend  GUI for bettercap and
metasploit and have been wanting to explore this concept more on plan9.

Plan9 seems like a good target for a game engine to be a application widget
tool kit and have a bunch of backend remote services.

It's not something I could port, but would be happy to test it and play
around.

On Thu, Nov 27, 2025, 9:42 AM ron minnich <rminnich@gmail.com> wrote:

> https://github.com/hajimehoshi/ebiten
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Ma2100d49fb233f6d22379b6e>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M809534db4922a64cd015daf6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1834 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

Another engine that looked like it could have potential on plan9 is raylib:
www.raylib.com.  It's in c89, the thing that stopped me was that I wasn't
sure I also wanted to port opengl, and I'm not sure how to do either of
those things on plan9.  I think there might be a tinygl port (or attempted)
somewhere but I've yet to find it and test it.

Maybe it's an ape or npe thing and I personally haven't gotten to the point
where I'm comfortable building with either of those toolkits.

I

On Thu, Nov 27, 2025, 11:43 AM Clout Tolstoy <tolstoyclout@gmail.com> wrote:

> Yes.
>
> Game dev could be pretty cool on plan9.
>
>  I've been using love2d on Linux to write a frontend  GUI for bettercap
> and metasploit and have been wanting to explore this concept more on plan9.
>
> Plan9 seems like a good target for a game engine to be a application
> widget tool kit and have a bunch of backend remote services.
>
> It's not something I could port, but would be happy to test it and play
> around.
>
> On Thu, Nov 27, 2025, 9:42 AM ron minnich <rminnich@gmail.com> wrote:
>
>> https://github.com/hajimehoshi/ebiten
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Ma2100d49fb233f6d22379b6e>
>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M17a8f3725d7a8a7d92adf17b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2899 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

Turns out raylib started using a few too many c99 features :(

On Thu, Nov 27, 2025, 12:51 PM Clout Tolstoy <tolstoyclout@gmail.com> wrote:

> Another engine that looked like it could have potential on plan9 is
> raylib: www.raylib.com.  It's in c89, the thing that stopped me was that
> I wasn't sure I also wanted to port opengl, and I'm not sure how to do
> either of those things on plan9.  I think there might be a tinygl port (or
> attempted) somewhere but I've yet to find it and test it.
>
> Maybe it's an ape or npe thing and I personally haven't gotten to the
> point where I'm comfortable building with either of those toolkits.
>
> I
>
> On Thu, Nov 27, 2025, 11:43 AM Clout Tolstoy <tolstoyclout@gmail.com>
> wrote:
>
>> Yes.
>>
>> Game dev could be pretty cool on plan9.
>>
>>  I've been using love2d on Linux to write a frontend  GUI for bettercap
>> and metasploit and have been wanting to explore this concept more on plan9.
>>
>> Plan9 seems like a good target for a game engine to be a application
>> widget tool kit and have a bunch of backend remote services.
>>
>> It's not something I could port, but would be happy to test it and play
>> around.
>>
>> On Thu, Nov 27, 2025, 9:42 AM ron minnich <rminnich@gmail.com> wrote:
>>
>>> https://github.com/hajimehoshi/ebiten
>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>>> <https://9fans.topicbox.com/groups/9fans> + participants
>>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>>> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Ma2100d49fb233f6d22379b6e>
>>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mcd9bbb0cc23ce7e25dd20256
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3462 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

I've found Go to be the post portable language if I need to span the space
of Plan 9, OSX, BSD, and Linux. Hence my interest in ebiten.

If somebody got this working it would be a great talk for IWP9

On Thu, Nov 27, 2025 at 7:38 PM Clout Tolstoy <tolstoyclout@gmail.com>
wrote:

> Turns out raylib started using a few too many c99 features :(
>
> On Thu, Nov 27, 2025, 12:51 PM Clout Tolstoy <tolstoyclout@gmail.com>
> wrote:
>
>> Another engine that looked like it could have potential on plan9 is
>> raylib: www.raylib.com.  It's in c89, the thing that stopped me was that
>> I wasn't sure I also wanted to port opengl, and I'm not sure how to do
>> either of those things on plan9.  I think there might be a tinygl port (or
>> attempted) somewhere but I've yet to find it and test it.
>>
>> Maybe it's an ape or npe thing and I personally haven't gotten to the
>> point where I'm comfortable building with either of those toolkits.
>>
>> I
>>
>> On Thu, Nov 27, 2025, 11:43 AM Clout Tolstoy <tolstoyclout@gmail.com>
>> wrote:
>>
>>> Yes.
>>>
>>> Game dev could be pretty cool on plan9.
>>>
>>>  I've been using love2d on Linux to write a frontend  GUI for bettercap
>>> and metasploit and have been wanting to explore this concept more on plan9.
>>>
>>> Plan9 seems like a good target for a game engine to be a application
>>> widget tool kit and have a bunch of backend remote services.
>>>
>>> It's not something I could port, but would be happy to test it and play
>>> around.
>>>
>>> On Thu, Nov 27, 2025, 9:42 AM ron minnich <rminnich@gmail.com> wrote:
>>>
>>>> https://github.com/hajimehoshi/ebiten
>>>>
>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mcd9bbb0cc23ce7e25dd20256>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Md3b65e8fc0ce42d505c3bd1c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4316 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

A very quick test
(base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
go build  .
package github.com/hajimehoshi/ebiten/v2/examples/snake
imports github.com/hajimehoshi/ebiten/v2
imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
imports github.com/hajimehoshi/ebiten/v2/internal/ui
imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build constraints
exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
(base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
/Users/rminnich/Documents/ebiten/examples/snake

So there's a glfw issue, whatever that is :-)


On Thu, Nov 27, 2025 at 8:24 PM ron minnich <rminnich@gmail.com> wrote:

> I've found Go to be the post portable language if I need to span the space
> of Plan 9, OSX, BSD, and Linux. Hence my interest in ebiten.
>
> If somebody got this working it would be a great talk for IWP9
>
> On Thu, Nov 27, 2025 at 7:38 PM Clout Tolstoy <tolstoyclout@gmail.com>
> wrote:
>
>> Turns out raylib started using a few too many c99 features :(
>>
>> On Thu, Nov 27, 2025, 12:51 PM Clout Tolstoy <tolstoyclout@gmail.com>
>> wrote:
>>
>>> Another engine that looked like it could have potential on plan9 is
>>> raylib: www.raylib.com.  It's in c89, the thing that stopped me was
>>> that I wasn't sure I also wanted to port opengl, and I'm not sure how to do
>>> either of those things on plan9.  I think there might be a tinygl port (or
>>> attempted) somewhere but I've yet to find it and test it.
>>>
>>> Maybe it's an ape or npe thing and I personally haven't gotten to the
>>> point where I'm comfortable building with either of those toolkits.
>>>
>>> I
>>>
>>> On Thu, Nov 27, 2025, 11:43 AM Clout Tolstoy <tolstoyclout@gmail.com>
>>> wrote:
>>>
>>>> Yes.
>>>>
>>>> Game dev could be pretty cool on plan9.
>>>>
>>>>  I've been using love2d on Linux to write a frontend  GUI for bettercap
>>>> and metasploit and have been wanting to explore this concept more on plan9.
>>>>
>>>> Plan9 seems like a good target for a game engine to be a application
>>>> widget tool kit and have a bunch of backend remote services.
>>>>
>>>> It's not something I could port, but would be happy to test it and play
>>>> around.
>>>>
>>>> On Thu, Nov 27, 2025, 9:42 AM ron minnich <rminnich@gmail.com> wrote:
>>>>
>>>>> https://github.com/hajimehoshi/ebiten
>>>>>
>>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mcd9bbb0cc23ce7e25dd20256>
>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M048a1a938abb560493d71ffe
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5787 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Noam Preil]

Which ones? We've been veeeeeery slowly adding more of them to 9front,
if there's a motivating use case (and _especially_ a patch ;), expanding
c99 support is hardly out of the question :)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M0fa384f9e7e0664f43f8c84e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Shawn Rutledge]

[-- Attachment #1: Type: text/plain, Size: 6809 bytes --]

> On Nov 28, 2025, at 13:50, noam@pixelhero.dev wrote:
> 
> Quoth ron minnich <rminnich@gmail.com <mailto:rminnich@gmail.com>>:
>> A very quick test
>> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
>> go build  .
>> package github.com/hajimehoshi/ebiten/v2/examples/snake
>> imports github.com/hajimehoshi/ebiten/v2
>> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
>> imports github.com/hajimehoshi/ebiten/v2/internal/ui
>> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build constraints
>> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
>> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
>> /Users/rminnich/Documents/ebiten/examples/snake
>> 
>> So there's a glfw issue, whatever that is :-)
> 
> GLFW is, IIRC, an OpenGL-based library.
> 
> a portable language doesn't help when all graphical toolkits
> rely on interfaces that are not available :)

GLFW is one of the lightest libraries for wrapping OpenGL rendering into a real window in a cross-platform way, and handling input.  https://www.glfw.org/

The Plan 9 community needs to start at the bottom IMO: get serious about supporting GPUs in some way.  So far the talk about GPUs has been hand-waving along the lines of using it as some sort of parallel computer for limited “compute” use cases, as opposed to the original application of rendering graphics.  But sure, if you can make it into a general parallel computer, and then still develop shader kernels (or whatever we call them in that kind of paradigm) that can render certain kinds of graphics, maybe it would be possible to accelerate some of the draw operations.  At least we have a chance to be original, ignore accepted wisdom about how to make graphics fast, and do it another way which might be more general.  Maybe.

There is also the idea that if GPUs turn out to be indispensable for general computing (especially AI), we won’t want to “waste” their power on basic graphics anymore.  Nearly every computer has a GPU by now, and if you run Plan 9 on it, you are letting the Ferrari sit there in the garage doing nothing for the rest of its life: that’s a shame.  But if you could use it for serious computing, but actually use it only for drawing 2D graphics, that’s like using the Ferrari only for short shopping trips: an improvement over total idleness, but also a bit of a shame.  If you find out that you can make money by racing the Ferrari, or something, maybe you don’t drive it to the store anymore.  We won’t mind wasting the CPU to draw rectangles and text if it turns out that the real work is all done on the fancy new parallel computer.  I’m not sure how that will turn out.  I’ve always wanted a GPU with a long-lived open architecture, optimized for 2D; but gaming was the main market selling GPUs until Bitcoin and LLMs came along, so we have that kind of architecture: more powerful than we need in the easy cases, but also less convenient.  Given that, I suppose finding the most-general API to program them would make some sense.

Probably someone could pick a relatively easy target to start with: a GPU that is sufficiently “open” to have a blob-free mainline Linux driver already, and try to get it somehow going on 9.  None of them are really open hardware, but for example there are enough docs for the videocore IV on raspberry pi’s, maybe other embedded ones like imagination tech, Radeon and Intel on PCs, etc.  (And I also don’t have any such low-level experience yet, I just read about it and think: if only I had more lives, maybe I could find time for that…)

You could use draw to render fancy graphics already (I guess that is what you are thinking), but it would be lots of CPU work, consequently slow, and without antialiasing (except for text).  Draw can render lines and polygons at any angle, and Bézier curves, but thou shalt not antialias them, because that would be a change and we don’t like change - that’s the vibe I’m getting from the community.  So someone could go ahead and port ebiten, but it might be a lot of work, and it won’t look as good even if you put up with the speed, I suspect, unless they already have a CPU renderer.  Do they, or is it OpenGL-only?  But you can maybe find such a rendering engine that can draw vector graphics with AA.  At that point, you just generate each frame (pixmap) using such an engine, and blit it afterwards.  Not really in the spirit of the mainstream accelerated graphics approach (OpenGL and Vulkan), nor how Plan 9 typically does things either.  I’d rather have full AA support with draw API, and get help from the GPU to do it, somehow.

With APIs like draw, you assume you can draw when you want.  For accelerated graphics, you wait for a callback to prepare a series of draw calls, which need to be minimized in number and maximized in data: don’t draw one primitive at a time, try to group them as much as possible.  (60FPS is 16 ms per frame: you don’t have time for too many draw calls; but the GPU is highly parallel and doesn’t mind if you throw in lots of data with each call.)   So the coding style has to change, unless the “turtle" API is used only to queue up the commands, and then batches are generated from the queue.  I.e. build a scene graph.  If you take for granted that there will be a scene graph, then IMO it works quite well to use a declarative style.  What you really wanted to say was “let there be rectangle, with these dimensions” (and other primitives: text, images, paths at least) rather than “go draw 4 lines right now".  Switch to retained mode.  Then it can go directly into the scene graph, optimization of the draw calls can be done algorithmically, and you don’t spend time redrawing anything that doesn’t need it.  But everybody seems to like immediate mode better.  They keep doing it on GPUs too, and those programs always seem to take a constant few percent of CPU just to maintain a static scene, because they keep redoing work that was already done.

I will keep working on my 9p scene graph approach, and then I can write renderers with any technology on any OS, as long as a 9p client is available (either integrated into the renderer, or by mounting the filesystem on the OS).  Maybe I or someone could try ebiten for that.  At least that way it can make good use of the GPU on platforms where it’s supported.  But I do fear that 9p may become a bottleneck at some point: I just want to see how far it’s possible to go that way.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M208d1db8610a887d62ba1f64
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 12626 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[noam]

Quoth ron minnich <rminnich@gmail.com>:
> A very quick test
> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
> go build  .
> package github.com/hajimehoshi/ebiten/v2/examples/snake
> imports github.com/hajimehoshi/ebiten/v2
> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
> imports github.com/hajimehoshi/ebiten/v2/internal/ui
> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build constraints
> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
> /Users/rminnich/Documents/ebiten/examples/snake
> 
> So there's a glfw issue, whatever that is :-)

GLFW is, IIRC, an OpenGL-based library.

a portable language doesn't help when all graphical toolkits
rely on interfaces that are not available :)


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M050f89d3dc9577d8baf93983
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

I'm not sure how to supply these Linux dependencies or it it would be easy
to use APE?

These alien deps are needed to build on alpine Linux:

   - alsa-lib-dev
   - libx11-dev
   - libxrandr-dev
   - libxcursor-dev
   - libxinerama-dev
   - libxi-dev
   - mesa-dev
   - pkgconf


On Fri, Nov 28, 2025, 12:40 AM <noam@pixelhero.dev> wrote:

> Quoth ron minnich <rminnich@gmail.com>:
> > A very quick test
> > (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
> > go build  .
> > package github.com/hajimehoshi/ebiten/v2/examples/snake
> > imports github.com/hajimehoshi/ebiten/v2
> > imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
> > imports github.com/hajimehoshi/ebiten/v2/internal/ui
> > imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build
> constraints
> > exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
> > (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
> > /Users/rminnich/Documents/ebiten/examples/snake
> >
> > So there's a glfw issue, whatever that is :-)
> 
> GLFW is, IIRC, an OpenGL-based library.
> 
> a portable language doesn't help when all graphical toolkits
> rely on interfaces that are not available :)
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Me73573d57589d5bbabc8171e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4666 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

here's the internal directory
affine beforemaintest builtinshader cocoa debug gamepad glfw
graphicscommand hook microsoftgdk packing processtest shaderir testing ui
vibrate
atlas buffered clock color file gamepaddb graphics graphicsdriver
inputstate mipmap png shader shaderlister thread vettools winver

There's several options there for graphics.

This is a case where you have to dig a bit.

On Fri, Nov 28, 2025 at 12:40 AM <noam@pixelhero.dev> wrote:

> Quoth ron minnich <rminnich@gmail.com>:
> > A very quick test
> > (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
> > go build  .
> > package github.com/hajimehoshi/ebiten/v2/examples/snake
> > imports github.com/hajimehoshi/ebiten/v2
> > imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
> > imports github.com/hajimehoshi/ebiten/v2/internal/ui
> > imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build
> constraints
> > exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
> > (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
> > /Users/rminnich/Documents/ebiten/examples/snake
> >
> > So there's a glfw issue, whatever that is :-)
> 
> GLFW is, IIRC, an OpenGL-based library.
> 
> a portable language doesn't help when all graphical toolkits
> rely on interfaces that are not available :)
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Ma64d4f27e170c2e3333f4144
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3627 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ori]

Quoth Shawn Rutledge <lists@ecloud.org>:
> The Plan 9 community needs to start at the bottom IMO: get serious about supporting GPUs in some way.  So far the talk about GPUs has been hand-waving along the lines of using it as some sort of parallel computer for limited “compute” use cases

So far, there haven't even been patches sent for modesetting; if
anyone cares about starting at the bottom, getting modesetting
working on, say, any recent AMD, Intel, or Nvidia card would be
a good place to start.

"the Plan 9 community" isn't big, and if you're waiting for
someone else to start working on it, you'll probably be waiting
a while.

Usually, things happen because someone gets enough working to
do a proof of concept, and then other people start contributing.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mb51af68b2edfd180a3cc4fdc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 8646 bytes --]

I'm going to be Debbie Downer here.

I worked on GPUs most of my career, from the early days of graphics
acceleration to the first 3D games consoles, to the start of shader
processing through to modern Nvidia architectures.

A GPU is *absurdly* more complex than is visible from its API surface,
which itself is maddenly complex.  Vulkan gives an inkling of what has to
be going on under the hood and what kinds of constraints exist to make a
performant graphics engine work.

The reason that plain compute looks more attractive is that the hardware
surface is so much smaller.  You don't have to worry about texture engines,
rasterizers, tiling, ROPs, in-order completion rules, and
myriad constraints on the memory subsystem to satisfy all these hardware
units.  Yes, compute leaves half the functionality that makes graphics
possible on the floor, but it also leaves all of its complexity there.

I like the 9p approach to 3D graphics - retained mode APIs have a long
history because of their usability.  I'd be happy to use such a thing on
Plan9.  But a driver for *any* modern GPU is not an achievable target for a
small band of independent developers.

Paul

On Fri, Nov 28, 2025 at 8:03 AM Shawn Rutledge <lists@ecloud.org> wrote:

>
> On Nov 28, 2025, at 13:50, noam@pixelhero.dev wrote:
>
> Quoth ron minnich <rminnich@gmail.com>:
>
> A very quick test
> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
> go build  .
> package github.com/hajimehoshi/ebiten/v2/examples/snake
> imports github.com/hajimehoshi/ebiten/v2
> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
> imports github.com/hajimehoshi/ebiten/v2/internal/ui
> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build constraints
> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
> /Users/rminnich/Documents/ebiten/examples/snake
>
> So there's a glfw issue, whatever that is :-)
>
>
> GLFW is, IIRC, an OpenGL-based library.
>
> a portable language doesn't help when all graphical toolkits
> rely on interfaces that are not available :)
>
>
> GLFW is one of the lightest libraries for wrapping OpenGL rendering into a
> real window in a cross-platform way, and handling input.
> https://www.glfw.org/
>
> The Plan 9 community needs to start at the bottom IMO: get serious about
> supporting GPUs in some way.  So far the talk about GPUs has been
> hand-waving along the lines of using it as some sort of parallel computer
> for limited “compute” use cases, as opposed to the original application of
> rendering graphics.  But sure, if you can make it into a general parallel
> computer, and then still develop shader kernels (or whatever we call them
> in that kind of paradigm) that can render certain kinds of graphics, maybe
> it would be possible to accelerate some of the draw operations.  At least
> we have a chance to be original, ignore accepted wisdom about how to make
> graphics fast, and do it another way which might be more general.  Maybe.
>
> There is also the idea that if GPUs turn out to be indispensable for
> general computing (especially AI), we won’t want to “waste” their power on
> basic graphics anymore.  Nearly every computer has a GPU by now, and if you
> run Plan 9 on it, you are letting the Ferrari sit there in the garage doing
> nothing for the rest of its life: that’s a shame.  But if you could use it
> for serious computing, but actually use it only for drawing 2D graphics,
> that’s like using the Ferrari only for short shopping trips: an improvement
> over total idleness, but also a bit of a shame.  If you find out that you
> can make money by racing the Ferrari, or something, maybe you don’t drive
> it to the store anymore.  We won’t mind wasting the CPU to draw rectangles
> and text if it turns out that the real work is all done on the fancy new
> parallel computer.  I’m not sure how that will turn out.  I’ve always
> wanted a GPU with a long-lived open architecture, optimized for 2D; but
> gaming was the main market selling GPUs until Bitcoin and LLMs came along,
> so we have that kind of architecture: more powerful than we need in the
> easy cases, but also less convenient.  Given that, I suppose finding the
> most-general API to program them would make some sense.
>
> Probably someone could pick a relatively easy target to start with: a GPU
> that is sufficiently “open” to have a blob-free mainline Linux driver
> already, and try to get it somehow going on 9.  None of them are really
> open hardware, but for example there are enough docs for the videocore IV
> on raspberry pi’s, maybe other embedded ones like imagination tech, Radeon
> and Intel on PCs, etc.  (And I also don’t have any such low-level
> experience yet, I just read about it and think: if only I had more lives,
> maybe I could find time for that…)
>
> You could use draw to render fancy graphics already (I guess that is what
> you are thinking), but it would be lots of CPU work, consequently slow, and
> without antialiasing (except for text).  Draw can render lines and polygons
> at any angle, and Bézier curves, but thou shalt not antialias them, because
> that would be a change and we don’t like change - that’s the vibe I’m
> getting from the community.  So someone could go ahead and port ebiten, but
> it might be a lot of work, and it won’t look as good even if you put up
> with the speed, I suspect, unless they already have a CPU renderer.  Do
> they, or is it OpenGL-only?  But you can maybe find such a rendering engine
> that can draw vector graphics with AA.  At that point, you just generate
> each frame (pixmap) using such an engine, and blit it afterwards.  Not
> really in the spirit of the mainstream accelerated graphics approach
> (OpenGL and Vulkan), nor how Plan 9 typically does things either.  I’d
> rather have full AA support with draw API, and get help from the GPU to do
> it, somehow.
>
> With APIs like draw, you assume you can draw when you want.  For
> accelerated graphics, you wait for a callback to prepare a series of draw
> calls, which need to be minimized in number and maximized in data: don’t
> draw one primitive at a time, try to group them as much as possible.
>  (60FPS is 16 ms per frame: you don’t have time for too many draw calls;
> but the GPU is highly parallel and doesn’t mind if you throw in lots of
> data with each call.)   So the coding style has to change, unless the
> “turtle" API is used only to queue up the commands, and then batches are
> generated from the queue.  I.e. build a scene graph.  If you take for
> granted that there will be a scene graph, then IMO it works quite well to
> use a declarative style.  What you really wanted to say was “let there be
> rectangle, with these dimensions” (and other primitives: text, images,
> paths at least) rather than “go draw 4 lines right now".  Switch to
> retained mode.  Then it can go directly into the scene graph, optimization
> of the draw calls can be done algorithmically, and you don’t spend time
> redrawing anything that doesn’t need it.  But everybody seems to like
> immediate mode better.  They keep doing it on GPUs too, and those programs
> always seem to take a constant few percent of CPU just to maintain a static
> scene, because they keep redoing work that was already done.
>
> I will keep working on my 9p scene graph approach, and then I can write
> renderers with any technology on any OS, as long as a 9p client is
> available (either integrated into the renderer, or by mounting the
> filesystem on the OS).  Maybe I or someone could try ebiten for that.  At
> least that way it can make good use of the GPU on platforms where it’s
> supported.  But I do fear that 9p may become a bottleneck at some point: I
> just want to see how far it’s possible to go that way.
>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M208d1db8610a887d62ba1f64>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1213743d46bd247dc794bece
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 13410 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[tlaronde]

On Fri, Nov 28, 2025 at 06:36:58AM -0800, Clout Tolstoy wrote:
> I'm not sure how to supply these Linux dependencies or it it would be easy
> to use APE?
> 
> These alien deps are needed to build on alpine Linux:
> 
>    - alsa-lib-dev
>    - libx11-dev
>    - libxrandr-dev
>    - libxcursor-dev
>    - libxinerama-dev
>    - libxi-dev

libx11, libxrandr, libxcursor, libxinerama and libxi are classical
X11 (Xorg) libes, so it is generally C with ifdef for various
platforms so should not be a problem by themselves---the compilation
is using autotools but is now changing to meson, imposing (since there
is no other complete implementation) Python.

The problem is a probable dependency on xcbproto that requires xmllint
to process the files.

>    - mesa-dev

This is another league entirely. This one will be more daunting...


Note: X11/Xorg is in fact almost dead. This is a legacy interface
almost orphaned and there are very few people still working on
these---and it seems that the few companies dedicating some people to
maintain these are planing to drop everything.

The problem is that X11 was just using a VGA and that today's GPU are
mostly something else. The massive work is done with the in-kernel GPU's
drivers, with already several interfaces orphaned and few things
"shared" between the drivers of distinct vendors.

Trying to fix numerous problems now arising in the Unices I use was
why Ron's Nix approach aroused my attention, because from the work I
tried to make in this area (just to have some understanding and to try
to fix things) it is clear to me that the GPUs are something new that
doesn't fit in the traditional Unix OS and that all the present
solutions (with already several "new" approaches already dropped) are
ad hoc solutions. For now, with huge corporations investing huge
resources (people and skills), it works, but for me it is not
maintainable and it is not the "shortest" path to the truth.

And the irony is that simple things that used to work (basic 2D
rendering---GUI---, watching a DVD) are now failing on Unices...

FWIW,
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M16f5abf823f7b214ac61d186
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 9051 bytes --]

This talks loops back to my hopes for the gpufs, but the drivers are in the
way.  Maybe matrox cards could be a good entry point for proper driver
support?

On Fri, Nov 28, 2025, 10:05 AM Paul Lalonde <paul.a.lalonde@gmail.com>
wrote:

> I'm going to be Debbie Downer here.
>
> I worked on GPUs most of my career, from the early days of graphics
> acceleration to the first 3D games consoles, to the start of shader
> processing through to modern Nvidia architectures.
>
> A GPU is *absurdly* more complex than is visible from its API surface,
> which itself is maddenly complex.  Vulkan gives an inkling of what has to
> be going on under the hood and what kinds of constraints exist to make a
> performant graphics engine work.
>
> The reason that plain compute looks more attractive is that the hardware
> surface is so much smaller.  You don't have to worry about texture engines,
> rasterizers, tiling, ROPs, in-order completion rules, and
> myriad constraints on the memory subsystem to satisfy all these hardware
> units.  Yes, compute leaves half the functionality that makes graphics
> possible on the floor, but it also leaves all of its complexity there.
>
> I like the 9p approach to 3D graphics - retained mode APIs have a long
> history because of their usability.  I'd be happy to use such a thing on
> Plan9.  But a driver for *any* modern GPU is not an achievable target for a
> small band of independent developers.
>
> Paul
>
> On Fri, Nov 28, 2025 at 8:03 AM Shawn Rutledge <lists@ecloud.org> wrote:
>
>>
>> On Nov 28, 2025, at 13:50, noam@pixelhero.dev wrote:
>>
>> Quoth ron minnich <rminnich@gmail.com>:
>>
>> A very quick test
>> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
>> go build  .
>> package github.com/hajimehoshi/ebiten/v2/examples/snake
>> imports github.com/hajimehoshi/ebiten/v2
>> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
>> imports github.com/hajimehoshi/ebiten/v2/internal/ui
>> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build constraints
>> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
>> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
>> /Users/rminnich/Documents/ebiten/examples/snake
>>
>> So there's a glfw issue, whatever that is :-)
>>
>>
>> GLFW is, IIRC, an OpenGL-based library.
>>
>> a portable language doesn't help when all graphical toolkits
>> rely on interfaces that are not available :)
>>
>>
>> GLFW is one of the lightest libraries for wrapping OpenGL rendering into
>> a real window in a cross-platform way, and handling input.
>> https://www.glfw.org/
>>
>> The Plan 9 community needs to start at the bottom IMO: get serious about
>> supporting GPUs in some way.  So far the talk about GPUs has been
>> hand-waving along the lines of using it as some sort of parallel computer
>> for limited “compute” use cases, as opposed to the original application of
>> rendering graphics.  But sure, if you can make it into a general parallel
>> computer, and then still develop shader kernels (or whatever we call them
>> in that kind of paradigm) that can render certain kinds of graphics, maybe
>> it would be possible to accelerate some of the draw operations.  At least
>> we have a chance to be original, ignore accepted wisdom about how to make
>> graphics fast, and do it another way which might be more general.  Maybe.
>>
>> There is also the idea that if GPUs turn out to be indispensable for
>> general computing (especially AI), we won’t want to “waste” their power on
>> basic graphics anymore.  Nearly every computer has a GPU by now, and if you
>> run Plan 9 on it, you are letting the Ferrari sit there in the garage doing
>> nothing for the rest of its life: that’s a shame.  But if you could use it
>> for serious computing, but actually use it only for drawing 2D graphics,
>> that’s like using the Ferrari only for short shopping trips: an improvement
>> over total idleness, but also a bit of a shame.  If you find out that you
>> can make money by racing the Ferrari, or something, maybe you don’t drive
>> it to the store anymore.  We won’t mind wasting the CPU to draw rectangles
>> and text if it turns out that the real work is all done on the fancy new
>> parallel computer.  I’m not sure how that will turn out.  I’ve always
>> wanted a GPU with a long-lived open architecture, optimized for 2D; but
>> gaming was the main market selling GPUs until Bitcoin and LLMs came along,
>> so we have that kind of architecture: more powerful than we need in the
>> easy cases, but also less convenient.  Given that, I suppose finding the
>> most-general API to program them would make some sense.
>>
>> Probably someone could pick a relatively easy target to start with: a GPU
>> that is sufficiently “open” to have a blob-free mainline Linux driver
>> already, and try to get it somehow going on 9.  None of them are really
>> open hardware, but for example there are enough docs for the videocore IV
>> on raspberry pi’s, maybe other embedded ones like imagination tech, Radeon
>> and Intel on PCs, etc.  (And I also don’t have any such low-level
>> experience yet, I just read about it and think: if only I had more lives,
>> maybe I could find time for that…)
>>
>> You could use draw to render fancy graphics already (I guess that is what
>> you are thinking), but it would be lots of CPU work, consequently slow, and
>> without antialiasing (except for text).  Draw can render lines and polygons
>> at any angle, and Bézier curves, but thou shalt not antialias them, because
>> that would be a change and we don’t like change - that’s the vibe I’m
>> getting from the community.  So someone could go ahead and port ebiten, but
>> it might be a lot of work, and it won’t look as good even if you put up
>> with the speed, I suspect, unless they already have a CPU renderer.  Do
>> they, or is it OpenGL-only?  But you can maybe find such a rendering engine
>> that can draw vector graphics with AA.  At that point, you just generate
>> each frame (pixmap) using such an engine, and blit it afterwards.  Not
>> really in the spirit of the mainstream accelerated graphics approach
>> (OpenGL and Vulkan), nor how Plan 9 typically does things either.  I’d
>> rather have full AA support with draw API, and get help from the GPU to do
>> it, somehow.
>>
>> With APIs like draw, you assume you can draw when you want.  For
>> accelerated graphics, you wait for a callback to prepare a series of draw
>> calls, which need to be minimized in number and maximized in data: don’t
>> draw one primitive at a time, try to group them as much as possible.
>>  (60FPS is 16 ms per frame: you don’t have time for too many draw calls;
>> but the GPU is highly parallel and doesn’t mind if you throw in lots of
>> data with each call.)   So the coding style has to change, unless the
>> “turtle" API is used only to queue up the commands, and then batches are
>> generated from the queue.  I.e. build a scene graph.  If you take for
>> granted that there will be a scene graph, then IMO it works quite well to
>> use a declarative style.  What you really wanted to say was “let there be
>> rectangle, with these dimensions” (and other primitives: text, images,
>> paths at least) rather than “go draw 4 lines right now".  Switch to
>> retained mode.  Then it can go directly into the scene graph, optimization
>> of the draw calls can be done algorithmically, and you don’t spend time
>> redrawing anything that doesn’t need it.  But everybody seems to like
>> immediate mode better.  They keep doing it on GPUs too, and those programs
>> always seem to take a constant few percent of CPU just to maintain a static
>> scene, because they keep redoing work that was already done.
>>
>> I will keep working on my 9p scene graph approach, and then I can write
>> renderers with any technology on any OS, as long as a 9p client is
>> available (either integrated into the renderer, or by mounting the
>> filesystem on the OS).  Maybe I or someone could try ebiten for that.  At
>> least that way it can make good use of the GPU on platforms where it’s
>> supported.  But I do fear that 9p may become a bottleneck at some point: I
>> just want to see how far it’s possible to go that way.
>>
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1213743d46bd247dc794bece>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M08d2b350f8d34c808c2ccf11
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 14107 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ori]

Quoth Clout Tolstoy <tolstoyclout@gmail.com>:
> This talks loops back to my hopes for the gpufs, but the drivers are in the
> way.  Maybe matrox cards could be a good entry point for proper driver
> support?

Intel cards seem to be the best documented, for example this
seems to have links to fairly complete manuals:

        https://cdrdv2-public.intel.com/772631/graphics-for-linux_developer-reference_1.0-772629-772631.pdf

including register references.

AMD is less well documented, but also has docs:

        https://gpuopen.com/amd-gpu-architecture-programming-documentation/

Their docs focus almost exclusively on the instruction set, and say
very little about the graphics pipeline and modesetting, however,
there is an open source driver, and there are old docs for old 2010
era cards that can serve as a starting point.

But in the the end, someone motivated needs to sit down and write
code; There is no simple, easily obtained, fast, and well documented
hardware out there. We get a couple of the checkboxes, and then some
motivated soul need to start working through the rest.

Even modesetting would be valuable.

But it's stil a lot of work, and it won't get done until someone
actually sits down and starts wiggling their fingers.
> On Fri, Nov 28, 2025, 10:05 AM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
> 
> > I'm going to be Debbie Downer here.
> >
> > I worked on GPUs most of my career, from the early days of graphics
> > acceleration to the first 3D games consoles, to the start of shader
> > processing through to modern Nvidia architectures.
> >
> > A GPU is *absurdly* more complex than is visible from its API surface,
> > which itself is maddenly complex.  Vulkan gives an inkling of what has to
> > be going on under the hood and what kinds of constraints exist to make a
> > performant graphics engine work.
> >
> > The reason that plain compute looks more attractive is that the hardware
> > surface is so much smaller.  You don't have to worry about texture engines,
> > rasterizers, tiling, ROPs, in-order completion rules, and
> > myriad constraints on the memory subsystem to satisfy all these hardware
> > units.  Yes, compute leaves half the functionality that makes graphics
> > possible on the floor, but it also leaves all of its complexity there.
> >
> > I like the 9p approach to 3D graphics - retained mode APIs have a long
> > history because of their usability.  I'd be happy to use such a thing on
> > Plan9.  But a driver for *any* modern GPU is not an achievable target for a
> > small band of independent developers.
> >
> > Paul
> >
> > On Fri, Nov 28, 2025 at 8:03 AM Shawn Rutledge <lists@ecloud.org> wrote:
> >
> >>
> >> On Nov 28, 2025, at 13:50, noam@pixelhero.dev wrote:
> >>
> >> Quoth ron minnich <rminnich@gmail.com>:
> >>
> >> A very quick test
> >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 GOARCH=amd64
> >> go build  .
> >> package github.com/hajimehoshi/ebiten/v2/examples/snake
> >> imports github.com/hajimehoshi/ebiten/v2
> >> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
> >> imports github.com/hajimehoshi/ebiten/v2/internal/ui
> >> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build constraints
> >> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
> >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
> >> /Users/rminnich/Documents/ebiten/examples/snake
> >>
> >> So there's a glfw issue, whatever that is :-)
> >>
> >>
> >> GLFW is, IIRC, an OpenGL-based library.
> >>
> >> a portable language doesn't help when all graphical toolkits
> >> rely on interfaces that are not available :)
> >>
> >>
> >> GLFW is one of the lightest libraries for wrapping OpenGL rendering into
> >> a real window in a cross-platform way, and handling input.
> >> https://www.glfw.org/
> >>
> >> The Plan 9 community needs to start at the bottom IMO: get serious about
> >> supporting GPUs in some way.  So far the talk about GPUs has been
> >> hand-waving along the lines of using it as some sort of parallel computer
> >> for limited “compute” use cases, as opposed to the original application of
> >> rendering graphics.  But sure, if you can make it into a general parallel
> >> computer, and then still develop shader kernels (or whatever we call them
> >> in that kind of paradigm) that can render certain kinds of graphics, maybe
> >> it would be possible to accelerate some of the draw operations.  At least
> >> we have a chance to be original, ignore accepted wisdom about how to make
> >> graphics fast, and do it another way which might be more general.  Maybe.
> >>
> >> There is also the idea that if GPUs turn out to be indispensable for
> >> general computing (especially AI), we won’t want to “waste” their power on
> >> basic graphics anymore.  Nearly every computer has a GPU by now, and if you
> >> run Plan 9 on it, you are letting the Ferrari sit there in the garage doing
> >> nothing for the rest of its life: that’s a shame.  But if you could use it
> >> for serious computing, but actually use it only for drawing 2D graphics,
> >> that’s like using the Ferrari only for short shopping trips: an improvement
> >> over total idleness, but also a bit of a shame.  If you find out that you
> >> can make money by racing the Ferrari, or something, maybe you don’t drive
> >> it to the store anymore.  We won’t mind wasting the CPU to draw rectangles
> >> and text if it turns out that the real work is all done on the fancy new
> >> parallel computer.  I’m not sure how that will turn out.  I’ve always
> >> wanted a GPU with a long-lived open architecture, optimized for 2D; but
> >> gaming was the main market selling GPUs until Bitcoin and LLMs came along,
> >> so we have that kind of architecture: more powerful than we need in the
> >> easy cases, but also less convenient.  Given that, I suppose finding the
> >> most-general API to program them would make some sense.
> >>
> >> Probably someone could pick a relatively easy target to start with: a GPU
> >> that is sufficiently “open” to have a blob-free mainline Linux driver
> >> already, and try to get it somehow going on 9.  None of them are really
> >> open hardware, but for example there are enough docs for the videocore IV
> >> on raspberry pi’s, maybe other embedded ones like imagination tech, Radeon
> >> and Intel on PCs, etc.  (And I also don’t have any such low-level
> >> experience yet, I just read about it and think: if only I had more lives,
> >> maybe I could find time for that…)
> >>
> >> You could use draw to render fancy graphics already (I guess that is what
> >> you are thinking), but it would be lots of CPU work, consequently slow, and
> >> without antialiasing (except for text).  Draw can render lines and polygons
> >> at any angle, and Bézier curves, but thou shalt not antialias them, because
> >> that would be a change and we don’t like change - that’s the vibe I’m
> >> getting from the community.  So someone could go ahead and port ebiten, but
> >> it might be a lot of work, and it won’t look as good even if you put up
> >> with the speed, I suspect, unless they already have a CPU renderer.  Do
> >> they, or is it OpenGL-only?  But you can maybe find such a rendering engine
> >> that can draw vector graphics with AA.  At that point, you just generate
> >> each frame (pixmap) using such an engine, and blit it afterwards.  Not
> >> really in the spirit of the mainstream accelerated graphics approach
> >> (OpenGL and Vulkan), nor how Plan 9 typically does things either.  I’d
> >> rather have full AA support with draw API, and get help from the GPU to do
> >> it, somehow.
> >>
> >> With APIs like draw, you assume you can draw when you want.  For
> >> accelerated graphics, you wait for a callback to prepare a series of draw
> >> calls, which need to be minimized in number and maximized in data: don’t
> >> draw one primitive at a time, try to group them as much as possible.
> >>  (60FPS is 16 ms per frame: you don’t have time for too many draw calls;
> >> but the GPU is highly parallel and doesn’t mind if you throw in lots of
> >> data with each call.)   So the coding style has to change, unless the
> >> “turtle" API is used only to queue up the commands, and then batches are
> >> generated from the queue.  I.e. build a scene graph.  If you take for
> >> granted that there will be a scene graph, then IMO it works quite well to
> >> use a declarative style.  What you really wanted to say was “let there be
> >> rectangle, with these dimensions” (and other primitives: text, images,
> >> paths at least) rather than “go draw 4 lines right now".  Switch to
> >> retained mode.  Then it can go directly into the scene graph, optimization
> >> of the draw calls can be done algorithmically, and you don’t spend time
> >> redrawing anything that doesn’t need it.  But everybody seems to like
> >> immediate mode better.  They keep doing it on GPUs too, and those programs
> >> always seem to take a constant few percent of CPU just to maintain a static
> >> scene, because they keep redoing work that was already done.
> >>
> >> I will keep working on my 9p scene graph approach, and then I can write
> >> renderers with any technology on any OS, as long as a 9p client is
> >> available (either integrated into the renderer, or by mounting the
> >> filesystem on the OS).  Maybe I or someone could try ebiten for that.  At
> >> least that way it can make good use of the GPU on platforms where it’s
> >> supported.  But I do fear that 9p may become a bottleneck at some point: I
> >> just want to see how far it’s possible to go that way.
> >>
> >> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> > <https://9fans.topicbox.com/groups/9fans> + participants
> > <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> > <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1213743d46bd247dc794bece>
> >

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M604519740dfb2b0d95fa42a8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 11412 bytes --]

So it seems we need something like kernel mode setting, but then for older
hardware that doesn't support KMS would still need something in user land.

Idk if this abstraction fully applies to plan9.

And then something for a direct rendering manager...

At least this is what I reflect from how Linux does it and that might not
be the best approach here.

On Fri, Nov 28, 2025, 12:24 PM <ori@eigenstate.org> wrote:

> Quoth Clout Tolstoy <tolstoyclout@gmail.com>:
> > This talks loops back to my hopes for the gpufs, but the drivers are in
> the
> > way.  Maybe matrox cards could be a good entry point for proper driver
> > support?
>
> Intel cards seem to be the best documented, for example this
> seems to have links to fairly complete manuals:
>
>
> https://cdrdv2-public.intel.com/772631/graphics-for-linux_developer-reference_1.0-772629-772631.pdf
>
> including register references.
>
> AMD is less well documented, but also has docs:
>
>
> https://gpuopen.com/amd-gpu-architecture-programming-documentation/
>
> Their docs focus almost exclusively on the instruction set, and say
> very little about the graphics pipeline and modesetting, however,
> there is an open source driver, and there are old docs for old 2010
> era cards that can serve as a starting point.
>
> But in the the end, someone motivated needs to sit down and write
> code; There is no simple, easily obtained, fast, and well documented
> hardware out there. We get a couple of the checkboxes, and then some
> motivated soul need to start working through the rest.
>
> Even modesetting would be valuable.
>
> But it's stil a lot of work, and it won't get done until someone
> actually sits down and starts wiggling their fingers.
> > On Fri, Nov 28, 2025, 10:05 AM Paul Lalonde <paul.a.lalonde@gmail.com>
> > wrote:
> >
> > > I'm going to be Debbie Downer here.
> > >
> > > I worked on GPUs most of my career, from the early days of graphics
> > > acceleration to the first 3D games consoles, to the start of shader
> > > processing through to modern Nvidia architectures.
> > >
> > > A GPU is *absurdly* more complex than is visible from its API surface,
> > > which itself is maddenly complex.  Vulkan gives an inkling of what has
> to
> > > be going on under the hood and what kinds of constraints exist to make
> a
> > > performant graphics engine work.
> > >
> > > The reason that plain compute looks more attractive is that the
> hardware
> > > surface is so much smaller.  You don't have to worry about texture
> engines,
> > > rasterizers, tiling, ROPs, in-order completion rules, and
> > > myriad constraints on the memory subsystem to satisfy all these
> hardware
> > > units.  Yes, compute leaves half the functionality that makes graphics
> > > possible on the floor, but it also leaves all of its complexity there.
> > >
> > > I like the 9p approach to 3D graphics - retained mode APIs have a long
> > > history because of their usability.  I'd be happy to use such a thing
> on
> > > Plan9.  But a driver for *any* modern GPU is not an achievable target
> for a
> > > small band of independent developers.
> > >
> > > Paul
> > >
> > > On Fri, Nov 28, 2025 at 8:03 AM Shawn Rutledge <lists@ecloud.org>
> wrote:
> > >>
> > >> On Nov 28, 2025, at 13:50, noam@pixelhero.dev wrote:
> > >>
> > >> Quoth ron minnich <rminnich@gmail.com>:
> > >>
> > >> A very quick test
> > >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9
> GOARCH=amd64
> > >> go build  .
> > >> package github.com/hajimehoshi/ebiten/v2/examples/snake
> > >> imports github.com/hajimehoshi/ebiten/v2
> > >> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
> > >> imports github.com/hajimehoshi/ebiten/v2/internal/ui
> > >> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build
> constraints
> > >> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
> > >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
> > >> /Users/rminnich/Documents/ebiten/examples/snake
> > >>
> > >> So there's a glfw issue, whatever that is :-)
> > >>
> > >>
> > >> GLFW is, IIRC, an OpenGL-based library.
> > >>
> > >> a portable language doesn't help when all graphical toolkits
> > >> rely on interfaces that are not available :)
> > >>
> > >>
> > >> GLFW is one of the lightest libraries for wrapping OpenGL rendering
> into
> > >> a real window in a cross-platform way, and handling input.
> > >> https://www.glfw.org/
> > >>
> > >> The Plan 9 community needs to start at the bottom IMO: get serious
> about
> > >> supporting GPUs in some way.  So far the talk about GPUs has been
> > >> hand-waving along the lines of using it as some sort of parallel
> computer
> > >> for limited “compute” use cases, as opposed to the original
> application of
> > >> rendering graphics.  But sure, if you can make it into a general
> parallel
> > >> computer, and then still develop shader kernels (or whatever we call
> them
> > >> in that kind of paradigm) that can render certain kinds of graphics,
> maybe
> > >> it would be possible to accelerate some of the draw operations.  At
> least
> > >> we have a chance to be original, ignore accepted wisdom about how to
> make
> > >> graphics fast, and do it another way which might be more general.
> Maybe.
> > >>
> > >> There is also the idea that if GPUs turn out to be indispensable for
> > >> general computing (especially AI), we won’t want to “waste” their
> power on
> > >> basic graphics anymore.  Nearly every computer has a GPU by now, and
> if you
> > >> run Plan 9 on it, you are letting the Ferrari sit there in the garage
> doing
> > >> nothing for the rest of its life: that’s a shame.  But if you could
> use it
> > >> for serious computing, but actually use it only for drawing 2D
> graphics,
> > >> that’s like using the Ferrari only for short shopping trips: an
> improvement
> > >> over total idleness, but also a bit of a shame.  If you find out that
> you
> > >> can make money by racing the Ferrari, or something, maybe you don’t
> drive
> > >> it to the store anymore.  We won’t mind wasting the CPU to draw
> rectangles
> > >> and text if it turns out that the real work is all done on the fancy
> new
> > >> parallel computer.  I’m not sure how that will turn out.  I’ve always
> > >> wanted a GPU with a long-lived open architecture, optimized for 2D;
> but
> > >> gaming was the main market selling GPUs until Bitcoin and LLMs came
> along,
> > >> so we have that kind of architecture: more powerful than we need in
> the
> > >> easy cases, but also less convenient.  Given that, I suppose finding
> the
> > >> most-general API to program them would make some sense.
> > >>
> > >> Probably someone could pick a relatively easy target to start with: a
> GPU
> > >> that is sufficiently “open” to have a blob-free mainline Linux driver
> > >> already, and try to get it somehow going on 9.  None of them are
> really
> > >> open hardware, but for example there are enough docs for the
> videocore IV
> > >> on raspberry pi’s, maybe other embedded ones like imagination tech,
> Radeon
> > >> and Intel on PCs, etc.  (And I also don’t have any such low-level
> > >> experience yet, I just read about it and think: if only I had more
> lives,
> > >> maybe I could find time for that…)
> > >>
> > >> You could use draw to render fancy graphics already (I guess that is
> what
> > >> you are thinking), but it would be lots of CPU work, consequently
> slow, and
> > >> without antialiasing (except for text).  Draw can render lines and
> polygons
> > >> at any angle, and Bézier curves, but thou shalt not antialias them,
> because
> > >> that would be a change and we don’t like change - that’s the vibe I’m
> > >> getting from the community.  So someone could go ahead and port
> ebiten, but
> > >> it might be a lot of work, and it won’t look as good even if you put
> up
> > >> with the speed, I suspect, unless they already have a CPU renderer.
> Do
> > >> they, or is it OpenGL-only?  But you can maybe find such a rendering
> engine
> > >> that can draw vector graphics with AA.  At that point, you just
> generate
> > >> each frame (pixmap) using such an engine, and blit it afterwards.  Not
> > >> really in the spirit of the mainstream accelerated graphics approach
> > >> (OpenGL and Vulkan), nor how Plan 9 typically does things either.  I’d
> > >> rather have full AA support with draw API, and get help from the GPU
> to do
> > >> it, somehow.
> > >>
> > >> With APIs like draw, you assume you can draw when you want.  For
> > >> accelerated graphics, you wait for a callback to prepare a series of
> draw
> > >> calls, which need to be minimized in number and maximized in data:
> don’t
> > >> draw one primitive at a time, try to group them as much as possible.
> > >>  (60FPS is 16 ms per frame: you don’t have time for too many draw
> calls;
> > >> but the GPU is highly parallel and doesn’t mind if you throw in lots
> of
> > >> data with each call.)   So the coding style has to change, unless the
> > >> “turtle" API is used only to queue up the commands, and then batches
> are
> > >> generated from the queue.  I.e. build a scene graph.  If you take for
> > >> granted that there will be a scene graph, then IMO it works quite
> well to
> > >> use a declarative style.  What you really wanted to say was “let
> there be
> > >> rectangle, with these dimensions” (and other primitives: text, images,
> > >> paths at least) rather than “go draw 4 lines right now".  Switch to
> > >> retained mode.  Then it can go directly into the scene graph,
> optimization
> > >> of the draw calls can be done algorithmically, and you don’t spend
> time
> > >> redrawing anything that doesn’t need it.  But everybody seems to like
> > >> immediate mode better.  They keep doing it on GPUs too, and those
> programs
> > >> always seem to take a constant few percent of CPU just to maintain a
> static
> > >> scene, because they keep redoing work that was already done.
> > >>
> > >> I will keep working on my 9p scene graph approach, and then I can
> write
> > >> renderers with any technology on any OS, as long as a 9p client is
> > >> available (either integrated into the renderer, or by mounting the
> > >> filesystem on the OS).  Maybe I or someone could try ebiten for
> that.  At
> > >> least that way it can make good use of the GPU on platforms where it’s
> > >> supported.  But I do fear that 9p may become a bottleneck at some
> point: I
> > >> just want to see how far it’s possible to go that way.
> > >>
> > >> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> > > <https://9fans.topicbox.com/groups/9fans> + participants
> > > <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> > > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> > > <
> https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1213743d46bd247dc794bece

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mc9914aba952fd0a65f996d0d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 16878 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ori]

The hardware doesn't care where the modesetting is done: it just
needs code to twiddle the registers. For example, this code twiddles
registers up to Haswell:

        https://git.9front.org/plan9front/9front/HEAD/sys/src/cmd/aux/vga/igfx.c/f.html

There's nothing, other than people spending time on it, preventing it from
working on newer hardware.

Quoth Clout Tolstoy <tolstoyclout@gmail.com>:
> So it seems we need something like kernel mode setting, but then for older
> hardware that doesn't support KMS would still need something in user land.
> 
> Idk if this abstraction fully applies to plan9.
> 
> And then something for a direct rendering manager...
> 
> At least this is what I reflect from how Linux does it and that might not
> be the best approach here.
> 
> On Fri, Nov 28, 2025, 12:24 PM <ori@eigenstate.org> wrote:
> 
> > Quoth Clout Tolstoy <tolstoyclout@gmail.com>:
> > > This talks loops back to my hopes for the gpufs, but the drivers are in
> > the
> > > way.  Maybe matrox cards could be a good entry point for proper driver
> > > support?
> >
> > Intel cards seem to be the best documented, for example this
> > seems to have links to fairly complete manuals:
> >
> >
> > https://cdrdv2-public.intel.com/772631/graphics-for-linux_developer-reference_1.0-772629-772631.pdf
> >
> > including register references.
> >
> > AMD is less well documented, but also has docs:
> >
> >
> > https://gpuopen.com/amd-gpu-architecture-programming-documentation/
> >
> > Their docs focus almost exclusively on the instruction set, and say
> > very little about the graphics pipeline and modesetting, however,
> > there is an open source driver, and there are old docs for old 2010
> > era cards that can serve as a starting point.
> >
> > But in the the end, someone motivated needs to sit down and write
> > code; There is no simple, easily obtained, fast, and well documented
> > hardware out there. We get a couple of the checkboxes, and then some
> > motivated soul need to start working through the rest.
> >
> > Even modesetting would be valuable.
> >
> > But it's stil a lot of work, and it won't get done until someone
> > actually sits down and starts wiggling their fingers.
> > > On Fri, Nov 28, 2025, 10:05 AM Paul Lalonde <paul.a.lalonde@gmail.com>
> > > wrote:
> > >
> > > > I'm going to be Debbie Downer here.
> > > >
> > > > I worked on GPUs most of my career, from the early days of graphics
> > > > acceleration to the first 3D games consoles, to the start of shader
> > > > processing through to modern Nvidia architectures.
> > > >
> > > > A GPU is *absurdly* more complex than is visible from its API surface,
> > > > which itself is maddenly complex.  Vulkan gives an inkling of what has
> > to
> > > > be going on under the hood and what kinds of constraints exist to make
> > a
> > > > performant graphics engine work.
> > > >
> > > > The reason that plain compute looks more attractive is that the
> > hardware
> > > > surface is so much smaller.  You don't have to worry about texture
> > engines,
> > > > rasterizers, tiling, ROPs, in-order completion rules, and
> > > > myriad constraints on the memory subsystem to satisfy all these
> > hardware
> > > > units.  Yes, compute leaves half the functionality that makes graphics
> > > > possible on the floor, but it also leaves all of its complexity there.
> > > >
> > > > I like the 9p approach to 3D graphics - retained mode APIs have a long
> > > > history because of their usability.  I'd be happy to use such a thing
> > on
> > > > Plan9.  But a driver for *any* modern GPU is not an achievable target
> > for a
> > > > small band of independent developers.
> > > >
> > > > Paul
> > > >
> > > > On Fri, Nov 28, 2025 at 8:03 AM Shawn Rutledge <lists@ecloud.org>
> > wrote:
> > > >>
> > > >> On Nov 28, 2025, at 13:50, noam@pixelhero.dev wrote:
> > > >>
> > > >> Quoth ron minnich <rminnich@gmail.com>:
> > > >>
> > > >> A very quick test
> > > >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9
> > GOARCH=amd64
> > > >> go build  .
> > > >> package github.com/hajimehoshi/ebiten/v2/examples/snake
> > > >> imports github.com/hajimehoshi/ebiten/v2
> > > >> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate
> > > >> imports github.com/hajimehoshi/ebiten/v2/internal/ui
> > > >> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build
> > constraints
> > > >> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw
> > > >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd
> > > >> /Users/rminnich/Documents/ebiten/examples/snake
> > > >>
> > > >> So there's a glfw issue, whatever that is :-)
> > > >>
> > > >>
> > > >> GLFW is, IIRC, an OpenGL-based library.
> > > >>
> > > >> a portable language doesn't help when all graphical toolkits
> > > >> rely on interfaces that are not available :)
> > > >>
> > > >>
> > > >> GLFW is one of the lightest libraries for wrapping OpenGL rendering
> > into
> > > >> a real window in a cross-platform way, and handling input.
> > > >> https://www.glfw.org/
> > > >>
> > > >> The Plan 9 community needs to start at the bottom IMO: get serious
> > about
> > > >> supporting GPUs in some way.  So far the talk about GPUs has been
> > > >> hand-waving along the lines of using it as some sort of parallel
> > computer
> > > >> for limited “compute” use cases, as opposed to the original
> > application of
> > > >> rendering graphics.  But sure, if you can make it into a general
> > parallel
> > > >> computer, and then still develop shader kernels (or whatever we call
> > them
> > > >> in that kind of paradigm) that can render certain kinds of graphics,
> > maybe
> > > >> it would be possible to accelerate some of the draw operations.  At
> > least
> > > >> we have a chance to be original, ignore accepted wisdom about how to
> > make
> > > >> graphics fast, and do it another way which might be more general.
> > Maybe.
> > > >>
> > > >> There is also the idea that if GPUs turn out to be indispensable for
> > > >> general computing (especially AI), we won’t want to “waste” their
> > power on
> > > >> basic graphics anymore.  Nearly every computer has a GPU by now, and
> > if you
> > > >> run Plan 9 on it, you are letting the Ferrari sit there in the garage
> > doing
> > > >> nothing for the rest of its life: that’s a shame.  But if you could
> > use it
> > > >> for serious computing, but actually use it only for drawing 2D
> > graphics,
> > > >> that’s like using the Ferrari only for short shopping trips: an
> > improvement
> > > >> over total idleness, but also a bit of a shame.  If you find out that
> > you
> > > >> can make money by racing the Ferrari, or something, maybe you don’t
> > drive
> > > >> it to the store anymore.  We won’t mind wasting the CPU to draw
> > rectangles
> > > >> and text if it turns out that the real work is all done on the fancy
> > new
> > > >> parallel computer.  I’m not sure how that will turn out.  I’ve always
> > > >> wanted a GPU with a long-lived open architecture, optimized for 2D;
> > but
> > > >> gaming was the main market selling GPUs until Bitcoin and LLMs came
> > along,
> > > >> so we have that kind of architecture: more powerful than we need in
> > the
> > > >> easy cases, but also less convenient.  Given that, I suppose finding
> > the
> > > >> most-general API to program them would make some sense.
> > > >>
> > > >> Probably someone could pick a relatively easy target to start with: a
> > GPU
> > > >> that is sufficiently “open” to have a blob-free mainline Linux driver
> > > >> already, and try to get it somehow going on 9.  None of them are
> > really
> > > >> open hardware, but for example there are enough docs for the
> > videocore IV
> > > >> on raspberry pi’s, maybe other embedded ones like imagination tech,
> > Radeon
> > > >> and Intel on PCs, etc.  (And I also don’t have any such low-level
> > > >> experience yet, I just read about it and think: if only I had more
> > lives,
> > > >> maybe I could find time for that…)
> > > >>
> > > >> You could use draw to render fancy graphics already (I guess that is
> > what
> > > >> you are thinking), but it would be lots of CPU work, consequently
> > slow, and
> > > >> without antialiasing (except for text).  Draw can render lines and
> > polygons
> > > >> at any angle, and Bézier curves, but thou shalt not antialias them,
> > because
> > > >> that would be a change and we don’t like change - that’s the vibe I’m
> > > >> getting from the community.  So someone could go ahead and port
> > ebiten, but
> > > >> it might be a lot of work, and it won’t look as good even if you put
> > up
> > > >> with the speed, I suspect, unless they already have a CPU renderer.
> > Do
> > > >> they, or is it OpenGL-only?  But you can maybe find such a rendering
> > engine
> > > >> that can draw vector graphics with AA.  At that point, you just
> > generate
> > > >> each frame (pixmap) using such an engine, and blit it afterwards.  Not
> > > >> really in the spirit of the mainstream accelerated graphics approach
> > > >> (OpenGL and Vulkan), nor how Plan 9 typically does things either.  I’d
> > > >> rather have full AA support with draw API, and get help from the GPU
> > to do
> > > >> it, somehow.
> > > >>
> > > >> With APIs like draw, you assume you can draw when you want.  For
> > > >> accelerated graphics, you wait for a callback to prepare a series of
> > draw
> > > >> calls, which need to be minimized in number and maximized in data:
> > don’t
> > > >> draw one primitive at a time, try to group them as much as possible.
> > > >>  (60FPS is 16 ms per frame: you don’t have time for too many draw
> > calls;
> > > >> but the GPU is highly parallel and doesn’t mind if you throw in lots
> > of
> > > >> data with each call.)   So the coding style has to change, unless the
> > > >> “turtle" API is used only to queue up the commands, and then batches
> > are
> > > >> generated from the queue.  I.e. build a scene graph.  If you take for
> > > >> granted that there will be a scene graph, then IMO it works quite
> > well to
> > > >> use a declarative style.  What you really wanted to say was “let
> > there be
> > > >> rectangle, with these dimensions” (and other primitives: text, images,
> > > >> paths at least) rather than “go draw 4 lines right now".  Switch to
> > > >> retained mode.  Then it can go directly into the scene graph,
> > optimization
> > > >> of the draw calls can be done algorithmically, and you don’t spend
> > time
> > > >> redrawing anything that doesn’t need it.  But everybody seems to like
> > > >> immediate mode better.  They keep doing it on GPUs too, and those
> > programs
> > > >> always seem to take a constant few percent of CPU just to maintain a
> > static
> > > >> scene, because they keep redoing work that was already done.
> > > >>
> > > >> I will keep working on my 9p scene graph approach, and then I can
> > write
> > > >> renderers with any technology on any OS, as long as a 9p client is
> > > >> available (either integrated into the renderer, or by mounting the
> > > >> filesystem on the OS).  Maybe I or someone could try ebiten for
> > that.  At
> > > >> least that way it can make good use of the GPU on platforms where it’s
> > > >> supported.  But I do fear that 9p may become a bottleneck at some
> > point: I
> > > >> just want to see how far it’s possible to go that way.
> > > >>
> > > >> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> > > > <https://9fans.topicbox.com/groups/9fans> + participants
> > > > <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> > > > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> > > > <
> > https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1213743d46bd247dc794bece

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M3931e96189019cd387505c4a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Noam Preil]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

I'm going to respectfully disagree without having ever done any non trivial graphics work: there's multiple examples of drivers that were done by a small group independently over a long period of time.

See e.g. asahi working against a hostile vendor.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M0bd29479fc0bc1e8e39760b7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1190 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ori]

Quoth Noam Preil <noam@pixelhero.dev>:
> 
> I'm going to respectfully disagree without having ever done any non trivial graphics work: there's multiple examples of drivers that were done by a small group independently over a long period of time.
> 
> See e.g. asahi working against a hostile vendor.

They're also building on a huge amount of work, often
commercially sponsored, around the whole linux graphics
stack.

It's possible to get there, but given that we've got a
fraction of the people hacking on things... it'll take
years of incremental work and some real simplifications
to the design.

If folks want graphics, it's time to start reading docs
and producing semicolons.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M6c7103f58293a7bb2150bf3c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[tlaronde]

On Sat, Nov 29, 2025 at 06:27:08PM -0500, ori@eigenstate.org wrote:
> Quoth Noam Preil <noam@pixelhero.dev>:
> > 
> > I'm going to respectfully disagree without having ever done any non trivial graphics work: there's multiple examples of drivers that were done by a small group independently over a long period of time.
> > 
> > See e.g. asahi working against a hostile vendor.
> 
> They're also building on a huge amount of work, often
> commercially sponsored, around the whole linux graphics
> stack.
> 
> It's possible to get there, but given that we've got a
> fraction of the people hacking on things... it'll take
> years of incremental work and some real simplifications
> to the design.

FWIW, I concur. On NetBSD, things started to go weird after they had
imported linux kernel related GPU support, the alien code weighting...
50%! of the previous existing code (kernel for all flavors + userland).
And once imported, it was already obsolete because it is a fast moving
target. And it is hugely memory related, and memory is at the core of an
OS, so importing an alien code with an alien memory interface was
doomed.

After fighting to find a way (starting at the KMS or DRM end; then
reverting to the user interface to try to reach the kernel articulation),
I personnally concluded that whether one has to stick to Linux for this
(not try to follow; it is hopeless), or find a totally different way to
do things (I mean the interface between the kernel and the GPUs; what
are the GPUs today can not be changed). And, IMHO, the design has
to start thinking about the kernel---after having found a thread
to what should be done, look at what is existing to sort the pieces
and implement the missing glue.

But, on the other hand, when it comes to 2D, it used to work without
much ado and with not full modern GPUs but in fact VGA (meaning Video
Graphics Array): an image, a clock to master when to send an image to
a display, and a circuitry to feed at the proper time these images to
a display (in fact, there were at some time "vectorial" displays, that
didn't take raster data but vectorial instructions: the
plotters, that took a pen and drew lines; since they were sequential,
they were not limited in the size and complexity of what had to be
drawn---I personnally loved watching the execution, step by step, of the
graphical program).

This is also why, in the mean time, I want to focus on rasterizing
capabilities (taken from METAFONT) and to see how far (and with what
efficiency) one can draw 2D images, including glyphes, with CPU like
cores---and I want to get rid of a PostScript interpreter and even
of other graphics libraries. So if I want to use Plan9 for programming,
TeX writing and rendering or even rendering GIS data (KerGIS), I will
depend on strictly nothing. I'm not doing 3D realtime motion stuff;
neither cryptocurrency mining nor A.I., so...

As usual (but as a French, it is a habit), I'm not trying to obtain
something claimed mandatory, I'm trying to do without.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mf555ed76295b66bdea37e1a1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 6516 bytes --]

I spend a few minutes looking at the code this morning.
This is on OSX, an m2 machine, so
CGO_ENABLED=0 GOOS=plan9 GOARCH=amd64 go build
Adding a few build tags for !plan9 gets me to the real errors.

I mainly got interested this because it seems to have broad portability,
and I  believe not all these run opengl?
* [Windows](https://ebitengine.org/en/documents/install.html?os=windows)
(No Cgo required!)
* [macOS](https://ebitengine.org/en/documents/install.html?os=darwin)
* [Linux](https://ebitengine.org/en/documents/install.html?os=linux)
* [FreeBSD](https://ebitengine.org/en/documents/install.html?os=freebsd)
* [Android](https://ebitengine.org/en/documents/mobile.html)
* [iOS](https://ebitengine.org/en/documents/mobile.html)
* [WebAssembly](https://ebitengine.org/en/documents/webassembly.html)
* Nintendo Switch
* Xbox (Xbox support is limited and not available to everyone. Negotiations
are currently underway to make it accessible to all.)

Here's the API:
https://pkg.go.dev/github.com/hajimehoshi/ebiten/v2#pkg-functions
not that complicated compared to some of these libraries.

I would not stress too much about implementing GPUs on Plan 9. From what I
can see, it's not a requirement for ebiten, it's just something ebiten can
use.

On OSX:
cd examples/cursor
CGO_ENABLED=0 go build
ofiles shows:
./cursor:
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version
1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility
version 1.0.0, current version 24.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
(compatibility version 1.2.0, current version 726.2.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version
228.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 4109.1.255)
/System/Library/Frameworks/Security.framework/Versions/A/Security
(compatibility version 1.0.0, current version 61901.40.77)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1356.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 2685.20.119)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
(compatibility version 64.0.0, current version 1965.1.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 1226.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 4109.1.255)

I have no idea if opengl is any part of these libraries, someone else might.


On Sun, Nov 30, 2025 at 7:13 AM <tlaronde@kergis.com> wrote:

> On Sat, Nov 29, 2025 at 06:27:08PM -0500, ori@eigenstate.org wrote:
> > Quoth Noam Preil <noam@pixelhero.dev>:
> > >
> > > I'm going to respectfully disagree without having ever done any non
> trivial graphics work: there's multiple examples of drivers that were done
> by a small group independently over a long period of time.
> > >
> > > See e.g. asahi working against a hostile vendor.
> >
> > They're also building on a huge amount of work, often
> > commercially sponsored, around the whole linux graphics
> > stack.
> >
> > It's possible to get there, but given that we've got a
> > fraction of the people hacking on things... it'll take
> > years of incremental work and some real simplifications
> > to the design.
> 
> FWIW, I concur. On NetBSD, things started to go weird after they had
> imported linux kernel related GPU support, the alien code weighting...
> 50%! of the previous existing code (kernel for all flavors + userland).
> And once imported, it was already obsolete because it is a fast moving
> target. And it is hugely memory related, and memory is at the core of an
> OS, so importing an alien code with an alien memory interface was
> doomed.
> 
> After fighting to find a way (starting at the KMS or DRM end; then
> reverting to the user interface to try to reach the kernel articulation),
> I personnally concluded that whether one has to stick to Linux for this
> (not try to follow; it is hopeless), or find a totally different way to
> do things (I mean the interface between the kernel and the GPUs; what
> are the GPUs today can not be changed). And, IMHO, the design has
> to start thinking about the kernel---after having found a thread
> to what should be done, look at what is existing to sort the pieces
> and implement the missing glue.
> 
> But, on the other hand, when it comes to 2D, it used to work without
> much ado and with not full modern GPUs but in fact VGA (meaning Video
> Graphics Array): an image, a clock to master when to send an image to
> a display, and a circuitry to feed at the proper time these images to
> a display (in fact, there were at some time "vectorial" displays, that
> didn't take raster data but vectorial instructions: the
> plotters, that took a pen and drew lines; since they were sequential,
> they were not limited in the size and complexity of what had to be
> drawn---I personnally loved watching the execution, step by step, of the
> graphical program).
> 
> This is also why, in the mean time, I want to focus on rasterizing
> capabilities (taken from METAFONT) and to see how far (and with what
> efficiency) one can draw 2D images, including glyphes, with CPU like
> cores---and I want to get rid of a PostScript interpreter and even
> of other graphics libraries. So if I want to use Plan9 for programming,
> TeX writing and rendering or even rendering GIS data (KerGIS), I will
> depend on strictly nothing. I'm not doing 3D realtime motion stuff;
> neither cryptocurrency mining nor A.I., so...
> 
> As usual (but as a French, it is a habit), I'm not trying to obtain
> something claimed mandatory, I'm trying to do without.
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M05c08b35ab56409ae6502d45
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 9456 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Bakul Shah via 9fans]

What I would love to see is a cross-platform 2D DisplayPDF engine,
incrementally optimized over time. All done on the CPU. May be we
can use it on BSDs (in place of X11) as well as Plan9.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M98b27dc4866b932ef9bf5b0a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[tlaronde]

On Sun, Nov 30, 2025 at 01:32:18PM -0800, Bakul Shah via 9fans wrote:
> What I would love to see is a cross-platform 2D DisplayPDF engine,
> incrementally optimized over time. All done on the CPU. May be we
> can use it on BSDs (in place of X11) as well as Plan9.

As far as I'm concerned, I will aim to a cross-platform 2D displayDVI
engine (DVI being extended to include some features that PDF provides, for
example the ability to append data without modifying the previous
pages series, this allowing for example signing, hence locking, a
portion of the file but applying clearly identified and not previously
signed modifications---DVI already have a postamble, so these
extensions fit in the general concept).

Contrary to PDF, DVI is not a text file, but a binary (bigEndian)
program for a virtual processor with defined opcodes (for the
moment, 0 to 249) [*]. The plan is simply to add in the not used
slots the few features necessary for *roff support (the quadratic
splines) and the ability to switch to another page of 256 other
opcodes, allowing extensions (and allowing a DVI renderer to pass
pages of opcodes it doesn't implement or that the user forbids to
execute---security feature).

And the "reference" implementation will use, when needed, the
rasterizing routines of METAFONT (extracted).

DVI is fully described in "TeX: The Program", part 31 (pages 235--243)
for the curious.

*: and if someone, one day, wants to build a core able to interpret
the file directly in hardware...---thinking about the instructions as
really an instructions set that could be fed to a real graphics processor
is perhaps not a bad Ariadne thread.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1cf47724da6d2783be6c1855
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[hiro via 9fans]

it's more likely that your government will have outlawed your GPU
based on humanity having run out of combustibles rather than ever
finishing a considerable fraction of the driver features that game
developers depend on.

On Mon, Dec 1, 2025 at 2:24 PM <tlaronde@kergis.com> wrote:
>
> On Sun, Nov 30, 2025 at 01:32:18PM -0800, Bakul Shah via 9fans wrote:
> > What I would love to see is a cross-platform 2D DisplayPDF engine,
> > incrementally optimized over time. All done on the CPU. May be we
> > can use it on BSDs (in place of X11) as well as Plan9.
> 
> As far as I'm concerned, I will aim to a cross-platform 2D displayDVI
> engine (DVI being extended to include some features that PDF provides, for
> example the ability to append data without modifying the previous
> pages series, this allowing for example signing, hence locking, a
> portion of the file but applying clearly identified and not previously
> signed modifications---DVI already have a postamble, so these
> extensions fit in the general concept).
> 
> Contrary to PDF, DVI is not a text file, but a binary (bigEndian)
> program for a virtual processor with defined opcodes (for the
> moment, 0 to 249) [*]. The plan is simply to add in the not used
> slots the few features necessary for *roff support (the quadratic
> splines) and the ability to switch to another page of 256 other
> opcodes, allowing extensions (and allowing a DVI renderer to pass
> pages of opcodes it doesn't implement or that the user forbids to
> execute---security feature).
> 
> And the "reference" implementation will use, when needed, the
> rasterizing routines of METAFONT (extracted).
> 
> DVI is fully described in "TeX: The Program", part 31 (pages 235--243)
> for the curious.
> 
> *: and if someone, one day, wants to build a core able to interpret
> the file directly in hardware...---thinking about the instructions as
> really an instructions set that could be fed to a real graphics processor
> is perhaps not a bad Ariadne thread.
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M12e89074824cd0053b524156
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Noam Preil]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Fwiw if the goal is something like this on 9, raylib is likely a much better choice. It can render entirely in software, to a framebuffer, iirc, and is entirely in C.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M69cf2ae6b1d290e9a4c3a05c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

My goal, for 9, was to look into a pure Go 2D game engine, to see if it
would work. This discussion spiraled off into thousands of other paths, as
things on this list are wont to do :-)

But I'm still wondering if the 2D game engine in Go could work. I think I'd
better go look.

On Thu, Dec 11, 2025 at 8:33 PM Noam Preil <noam@pixelhero.dev> wrote:

> Fwiw if the goal is something like this on 9, raylib is likely a much
> better choice. It can render entirely in software, to a framebuffer, iirc,
> and is entirely in C.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M69cf2ae6b1d290e9a4c3a05c>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M4fddef4421e1d5b958fb5634
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1651 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

npe looks like it has limited sdl2 support. That seems how you could get
along the fastest without having to refactor  image drawing, and IO to
plan9 abstractions.   Ebitengine requires a bit of C  libraries that are
unavailable on plan9/9front.

Mainly referring to this data structure
https://github.com/hajimehoshi/ebiten/blob/7d0692124a95528ee624ab641104e7a7bf1cb4b2/internal/graphicscommand/image.go#L31

I'm not sure which (raylib/ebiten) would feel more daunting to port because
of those dependencies.

If you have a source repo of your efforts, I can try  on a rpi0 or rpi4.

Best of luck and sorry for the slight derail.

Clout




On Thu, Dec 11, 2025, 8:37 PM ron minnich <rminnich@gmail.com> wrote:

> My goal, for 9, was to look into a pure Go 2D game engine, to see if it
> would work. This discussion spiraled off into thousands of other paths, as
> things on this list are wont to do :-)
>
> But I'm still wondering if the 2D game engine in Go could work. I think
> I'd better go look.
>
> On Thu, Dec 11, 2025 at 8:33 PM Noam Preil <noam@pixelhero.dev> wrote:
>
>> Fwiw if the goal is something like this on 9, raylib is likely a much
>> better choice. It can render entirely in software, to a framebuffer, iirc,
>> and is entirely in C.
>>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M4fddef4421e1d5b958fb5634>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mc197848348c7bc5e495db932
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3253 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

https://github.com/hajimehoshi/ebiten

I'm going to take a shot at turning off all linux dependencies, which
should remove GL dependencies, and see what's missing. But a look at the
graphics used on other platforms said to me that it doesn't demand too much.

On Fri, Dec 12, 2025 at 1:07 PM Clout Tolstoy <tolstoyclout@gmail.com>
wrote:

> npe looks like it has limited sdl2 support. That seems how you could get
> along the fastest without having to refactor  image drawing, and IO to
> plan9 abstractions.   Ebitengine requires a bit of C  libraries that are
> unavailable on plan9/9front.
>
> Mainly referring to this data structure
>
> https://github.com/hajimehoshi/ebiten/blob/7d0692124a95528ee624ab641104e7a7bf1cb4b2/internal/graphicscommand/image.go#L31
>
> I'm not sure which (raylib/ebiten) would feel more daunting to port
> because of those dependencies.
>
> If you have a source repo of your efforts, I can try  on a rpi0 or rpi4.
>
> Best of luck and sorry for the slight derail.
>
> Clout
>
>
>
>
> On Thu, Dec 11, 2025, 8:37 PM ron minnich <rminnich@gmail.com> wrote:
>
>> My goal, for 9, was to look into a pure Go 2D game engine, to see if it
>> would work. This discussion spiraled off into thousands of other paths, as
>> things on this list are wont to do :-)
>>
>> But I'm still wondering if the 2D game engine in Go could work. I think
>> I'd better go look.
>>
>> On Thu, Dec 11, 2025 at 8:33 PM Noam Preil <noam@pixelhero.dev> wrote:
>>
>>> Fwiw if the goal is something like this on 9, raylib is likely a much
>>> better choice. It can render entirely in software, to a framebuffer, iirc,
>>> and is entirely in C.
>>>
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mc197848348c7bc5e495db932>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1b21a64c8e2647a67c398add
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4141 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 7180 bytes --]

if you check out the plan9 branch of git@github.com:plan9foundation/ebiten.git,
and you cd to examples/cursor, you can
GOOS=plan9 GOARCH=amd64 go build
you'll get a plan 9 binary.

You can run it; it won't end well. All the functions you need to implement
(48 of them) are stubbed out to panic.

This is pretty much how I port unknown Go or C code to 9: stub out the
stuff I don't know how to do with panic (or for that matter, Plan 9  to a
new architecture, or
when we ported Plan 9 code to Akaros).

Here are the functions.

internal/ui/input_plan9.go:func (u *UserInterface)
updateInputStateFromOutside(keyPressedTimes, keyReleasedTimes [KeyMax +
1]InputTime, runes []rune, touches []TouchForInput) {
internal/ui/input_plan9.go:func (u *UserInterface)
updateInputStateForFrame() error {
internal/ui/input_plan9.go:func (u *UserInterface) KeyName(key Key) string {
internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newAuto()
(graphicsdriver.Graphics, GraphicsLibrary, error) {
internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newOpenGL()
(graphicsdriver.Graphics, error) {
internal/ui/ui_plan9.go:func (*graphicsDriverCreatorImpl) newDirectX()
(graphicsdriver.Graphics, error) {
internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newMetal()
(graphicsdriver.Graphics, error) {
internal/ui/ui_plan9.go:func (*graphicsDriverCreatorImpl) newPlayStation5()
(graphicsdriver.Graphics, error) {
internal/ui/ui_plan9.go:func (u *UserInterface) SetUIView(uiview uintptr)
error {
internal/ui/ui_plan9.go:func (u *UserInterface) IsGL() (bool, error) {
internal/ui/ui_plan9.go:func dipToNativePixels(x float64, scale float64)
float64 {
internal/ui/ui_plan9.go:func dipFromNativePixels(x float64, scale float64)
float64 {
internal/ui/ui_plan9.go:func (u *UserInterface) displayInfo() (int, int,
float64, bool) {
internal/ui/ui_plan9.go:func (u *UserInterface) init() error {
internal/ui/ui_plan9.go:func (u *UserInterface) Update() error {
internal/ui/ui_plan9.go:func (u *UserInterface) SetForeground(foreground
bool) error {
internal/ui/ui_plan9.go:func (u *UserInterface) RunWithoutMainLoop(game
Game, options *RunOptions) {
internal/ui/ui_plan9.go:func (u *UserInterface) runMobile(game Game,
options *RunOptions) (err error) {
internal/ui/ui_plan9.go:func (u *UserInterface) outsideSize() (float64,
float64) {
internal/ui/ui_plan9.go:func (u *UserInterface) update() error {
internal/ui/ui_plan9.go:func (u *UserInterface)
SetOutsideSize(outsideWidth, outsideHeight float64) {
internal/ui/ui_plan9.go:func (u *UserInterface) CursorMode() CursorMode {
internal/ui/ui_plan9.go:func (u *UserInterface) SetCursorMode(mode
CursorMode) {
internal/ui/ui_plan9.go:func (u *UserInterface) CursorShape() CursorShape {
internal/ui/ui_plan9.go:func (u *UserInterface) SetCursorShape(shape
CursorShape) {
internal/ui/ui_plan9.go:func (u *UserInterface) IsFullscreen() bool {
internal/ui/ui_plan9.go:func (u *UserInterface) SetFullscreen(fullscreen
bool) {
internal/ui/ui_plan9.go:func (u *UserInterface) IsFocused() bool {
internal/ui/ui_plan9.go:func (u *UserInterface) IsRunnableOnUnfocused()
bool {
internal/ui/ui_plan9.go:func (u *UserInterface)
SetRunnableOnUnfocused(runnableOnUnfocused bool) {
internal/ui/ui_plan9.go:func (u *UserInterface) FPSMode() FPSModeType {
internal/ui/ui_plan9.go:func (u *UserInterface) SetFPSMode(mode
FPSModeType) {
internal/ui/ui_plan9.go:func (u *UserInterface)
updateExplicitRenderingModeIfNeeded(fpsMode FPSModeType) {
internal/ui/ui_plan9.go:func (u *UserInterface) readInputState(inputState
*InputState) {
internal/ui/ui_plan9.go:func (u *UserInterface) Window() Window {
internal/ui/ui_plan9.go:func (m *Monitor) Name() string {
internal/ui/ui_plan9.go:func (m *Monitor) ensureValues() monitor {
internal/ui/ui_plan9.go:func (m *Monitor) DeviceScaleFactor() float64 {
internal/ui/ui_plan9.go:func (m *Monitor) Size() (int, int) {
internal/ui/ui_plan9.go:func (u *UserInterface) AppendMonitors(mons
[]*Monitor) []*Monitor {
internal/ui/ui_plan9.go:func (u *UserInterface) Monitor() *Monitor {
internal/ui/ui_plan9.go:func (u *UserInterface)
UpdateInput(keyPressedTimes, keyReleasedTimes [KeyMax + 1]InputTime, runes
[]rune, touches []TouchForInput) {
internal/ui/ui_plan9.go:func (u *UserInterface) SetRenderer(renderer
Renderer) {
internal/ui/ui_plan9.go:func (u *UserInterface) ScheduleFrame() {
internal/ui/ui_plan9.go:func (u *UserInterface) updateIconIfNeeded() error {
internal/ui/ui_plan9.go:func IsScreenTransparentAvailable() bool {
internal/ui/ui_plan9.go:func (u *UserInterface) initOnMainThread(options
*RunOptions) error {
internal/ui/ui_plan9.go:func (u *UserInterface) loopGame() error {



On Sat, Dec 13, 2025 at 12:25 PM ron minnich <rminnich@gmail.com> wrote:

> https://github.com/hajimehoshi/ebiten
>
> I'm going to take a shot at turning off all linux dependencies, which
> should remove GL dependencies, and see what's missing. But a look at the
> graphics used on other platforms said to me that it doesn't demand too much.
>
> On Fri, Dec 12, 2025 at 1:07 PM Clout Tolstoy <tolstoyclout@gmail.com>
> wrote:
>
>> npe looks like it has limited sdl2 support. That seems how you could get
>> along the fastest without having to refactor  image drawing, and IO to
>> plan9 abstractions.   Ebitengine requires a bit of C  libraries that are
>> unavailable on plan9/9front.
>>
>> Mainly referring to this data structure
>>
>> https://github.com/hajimehoshi/ebiten/blob/7d0692124a95528ee624ab641104e7a7bf1cb4b2/internal/graphicscommand/image.go#L31
>>
>> I'm not sure which (raylib/ebiten) would feel more daunting to port
>> because of those dependencies.
>>
>> If you have a source repo of your efforts, I can try  on a rpi0 or rpi4.
>>
>> Best of luck and sorry for the slight derail.
>>
>> Clout
>>
>>
>>
>>
>> On Thu, Dec 11, 2025, 8:37 PM ron minnich <rminnich@gmail.com> wrote:
>>
>>> My goal, for 9, was to look into a pure Go 2D game engine, to see if it
>>> would work. This discussion spiraled off into thousands of other paths, as
>>> things on this list are wont to do :-)
>>>
>>> But I'm still wondering if the 2D game engine in Go could work. I think
>>> I'd better go look.
>>>
>>> On Thu, Dec 11, 2025 at 8:33 PM Noam Preil <noam@pixelhero.dev> wrote:
>>>
>>>> Fwiw if the goal is something like this on 9, raylib is likely a much
>>>> better choice. It can render entirely in software, to a framebuffer, iirc,
>>>> and is entirely in C.
>>>>
>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mc197848348c7bc5e495db932>
>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mf117e99d783bce7790fcfcd5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 9681 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 8277 bytes --]

and ... here we go:

term% git/clone git@github.com:plan9foundation/ebiten

fetching... \

indexing 77609 objects: 100%

checking out repository...

term% cd ebiten/

term% git/branch -n -b origin/plan9 plan9

term$ cd examples/cursor

term% go build

term% ./cursor

panic: init not implemented


goroutine 1 [running]:

github.com/hajimehoshi/ebiten/v2/internal/ui.(*UserInterface).init(...)

        /usr/glenda/ebiten/internal/ui/ui_plan9.go:101

github.com/hajimehoshi/ebiten/v2/internal/ui.newUserInterface()

        /usr/glenda/ebiten/internal/ui/ui.go:124 +0x245

github.com/hajimehoshi/ebiten/v2/internal/ui.init.0()

        /usr/glenda/ebiten/internal/ui/ui.go:99 +0x13


so it's a matter of filling in those blanks.

On Sat, Dec 13, 2025 at 8:04 PM ron minnich <rminnich@gmail.com> wrote:

> if you check out the plan9 branch of git@github.com:plan9foundation/ebiten.git,
> and you cd to examples/cursor, you can
> GOOS=plan9 GOARCH=amd64 go build
> you'll get a plan 9 binary.
>
> You can run it; it won't end well. All the functions you need to implement
> (48 of them) are stubbed out to panic.
>
> This is pretty much how I port unknown Go or C code to 9: stub out the
> stuff I don't know how to do with panic (or for that matter, Plan 9  to a
> new architecture, or
> when we ported Plan 9 code to Akaros).
>
> Here are the functions.
>
> internal/ui/input_plan9.go:func (u *UserInterface)
> updateInputStateFromOutside(keyPressedTimes, keyReleasedTimes [KeyMax +
> 1]InputTime, runes []rune, touches []TouchForInput) {
> internal/ui/input_plan9.go:func (u *UserInterface)
> updateInputStateForFrame() error {
> internal/ui/input_plan9.go:func (u *UserInterface) KeyName(key Key) string
> {
> internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newAuto()
> (graphicsdriver.Graphics, GraphicsLibrary, error) {
> internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newOpenGL()
> (graphicsdriver.Graphics, error) {
> internal/ui/ui_plan9.go:func (*graphicsDriverCreatorImpl) newDirectX()
> (graphicsdriver.Graphics, error) {
> internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newMetal()
> (graphicsdriver.Graphics, error) {
> internal/ui/ui_plan9.go:func (*graphicsDriverCreatorImpl)
> newPlayStation5() (graphicsdriver.Graphics, error) {
> internal/ui/ui_plan9.go:func (u *UserInterface) SetUIView(uiview uintptr)
> error {
> internal/ui/ui_plan9.go:func (u *UserInterface) IsGL() (bool, error) {
> internal/ui/ui_plan9.go:func dipToNativePixels(x float64, scale float64)
> float64 {
> internal/ui/ui_plan9.go:func dipFromNativePixels(x float64, scale float64)
> float64 {
> internal/ui/ui_plan9.go:func (u *UserInterface) displayInfo() (int, int,
> float64, bool) {
> internal/ui/ui_plan9.go:func (u *UserInterface) init() error {
> internal/ui/ui_plan9.go:func (u *UserInterface) Update() error {
> internal/ui/ui_plan9.go:func (u *UserInterface) SetForeground(foreground
> bool) error {
> internal/ui/ui_plan9.go:func (u *UserInterface) RunWithoutMainLoop(game
> Game, options *RunOptions) {
> internal/ui/ui_plan9.go:func (u *UserInterface) runMobile(game Game,
> options *RunOptions) (err error) {
> internal/ui/ui_plan9.go:func (u *UserInterface) outsideSize() (float64,
> float64) {
> internal/ui/ui_plan9.go:func (u *UserInterface) update() error {
> internal/ui/ui_plan9.go:func (u *UserInterface)
> SetOutsideSize(outsideWidth, outsideHeight float64) {
> internal/ui/ui_plan9.go:func (u *UserInterface) CursorMode() CursorMode {
> internal/ui/ui_plan9.go:func (u *UserInterface) SetCursorMode(mode
> CursorMode) {
> internal/ui/ui_plan9.go:func (u *UserInterface) CursorShape() CursorShape {
> internal/ui/ui_plan9.go:func (u *UserInterface) SetCursorShape(shape
> CursorShape) {
> internal/ui/ui_plan9.go:func (u *UserInterface) IsFullscreen() bool {
> internal/ui/ui_plan9.go:func (u *UserInterface) SetFullscreen(fullscreen
> bool) {
> internal/ui/ui_plan9.go:func (u *UserInterface) IsFocused() bool {
> internal/ui/ui_plan9.go:func (u *UserInterface) IsRunnableOnUnfocused()
> bool {
> internal/ui/ui_plan9.go:func (u *UserInterface)
> SetRunnableOnUnfocused(runnableOnUnfocused bool) {
> internal/ui/ui_plan9.go:func (u *UserInterface) FPSMode() FPSModeType {
> internal/ui/ui_plan9.go:func (u *UserInterface) SetFPSMode(mode
> FPSModeType) {
> internal/ui/ui_plan9.go:func (u *UserInterface)
> updateExplicitRenderingModeIfNeeded(fpsMode FPSModeType) {
> internal/ui/ui_plan9.go:func (u *UserInterface) readInputState(inputState
> *InputState) {
> internal/ui/ui_plan9.go:func (u *UserInterface) Window() Window {
> internal/ui/ui_plan9.go:func (m *Monitor) Name() string {
> internal/ui/ui_plan9.go:func (m *Monitor) ensureValues() monitor {
> internal/ui/ui_plan9.go:func (m *Monitor) DeviceScaleFactor() float64 {
> internal/ui/ui_plan9.go:func (m *Monitor) Size() (int, int) {
> internal/ui/ui_plan9.go:func (u *UserInterface) AppendMonitors(mons
> []*Monitor) []*Monitor {
> internal/ui/ui_plan9.go:func (u *UserInterface) Monitor() *Monitor {
> internal/ui/ui_plan9.go:func (u *UserInterface)
> UpdateInput(keyPressedTimes, keyReleasedTimes [KeyMax + 1]InputTime, runes
> []rune, touches []TouchForInput) {
> internal/ui/ui_plan9.go:func (u *UserInterface) SetRenderer(renderer
> Renderer) {
> internal/ui/ui_plan9.go:func (u *UserInterface) ScheduleFrame() {
> internal/ui/ui_plan9.go:func (u *UserInterface) updateIconIfNeeded() error
> {
> internal/ui/ui_plan9.go:func IsScreenTransparentAvailable() bool {
> internal/ui/ui_plan9.go:func (u *UserInterface) initOnMainThread(options
> *RunOptions) error {
> internal/ui/ui_plan9.go:func (u *UserInterface) loopGame() error {
>
>
>
> On Sat, Dec 13, 2025 at 12:25 PM ron minnich <rminnich@gmail.com> wrote:
>
>> https://github.com/hajimehoshi/ebiten
>>
>> I'm going to take a shot at turning off all linux dependencies, which
>> should remove GL dependencies, and see what's missing. But a look at the
>> graphics used on other platforms said to me that it doesn't demand too much.
>>
>> On Fri, Dec 12, 2025 at 1:07 PM Clout Tolstoy <tolstoyclout@gmail.com>
>> wrote:
>>
>>> npe looks like it has limited sdl2 support. That seems how you could get
>>> along the fastest without having to refactor  image drawing, and IO to
>>> plan9 abstractions.   Ebitengine requires a bit of C  libraries that are
>>> unavailable on plan9/9front.
>>>
>>> Mainly referring to this data structure
>>>
>>> https://github.com/hajimehoshi/ebiten/blob/7d0692124a95528ee624ab641104e7a7bf1cb4b2/internal/graphicscommand/image.go#L31
>>>
>>> I'm not sure which (raylib/ebiten) would feel more daunting to port
>>> because of those dependencies.
>>>
>>> If you have a source repo of your efforts, I can try  on a rpi0 or
>>> rpi4.
>>>
>>> Best of luck and sorry for the slight derail.
>>>
>>> Clout
>>>
>>>
>>>
>>>
>>> On Thu, Dec 11, 2025, 8:37 PM ron minnich <rminnich@gmail.com> wrote:
>>>
>>>> My goal, for 9, was to look into a pure Go 2D game engine, to see if it
>>>> would work. This discussion spiraled off into thousands of other paths, as
>>>> things on this list are wont to do :-)
>>>>
>>>> But I'm still wondering if the 2D game engine in Go could work. I think
>>>> I'd better go look.
>>>>
>>>> On Thu, Dec 11, 2025 at 8:33 PM Noam Preil <noam@pixelhero.dev> wrote:
>>>>
>>>>> Fwiw if the goal is something like this on 9, raylib is likely a much
>>>>> better choice. It can render entirely in software, to a framebuffer, iirc,
>>>>> and is entirely in C.
>>>>>
>>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>>> <https://9fans.topicbox.com/groups/9fans> + participants
>>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>>> <https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mc197848348c7bc5e495db932>
>>>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mb2961c44654ef0085570754d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 18189 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Ron Minnich]

I actually started looking at using 9fans.net/go/draw to support it,
but it turns out ... irony of ironies ... package drawfcall does not
build on plan 9. And, the 9fans/go code itself comes with a dependency
on C. I've not gotten an answer on whether they could include
GOOS=plan9 in their CI, so that it at least builds for Plan 9. It
would be nice to have this code working.

If getting 9fans/go to build or work on Plan 9 does not work out, I
guess I'll try to find some earlier rev of the code that does build
drawfcall on plan 9, OR just fork it to get to a working Plan 9
version.

This is purely I-need-a-break work, so will not go fast; the risc-v
port is higher priority.

On Tue, Dec 16, 2025 at 6:50 PM ron minnich <rminnich@gmail.com> wrote:
>
> and ... here we go:
>
> term% git/clone git@github.com:plan9foundation/ebiten
>
> fetching... \
>
> indexing 77609 objects: 100%
>
> checking out repository...
>
> term% cd ebiten/
>
> term% git/branch -n -b origin/plan9 plan9
>
> term$ cd examples/cursor
>
> term% go build
>
> term% ./cursor
>
> panic: init not implemented
>
>
> goroutine 1 [running]:
>
> github.com/hajimehoshi/ebiten/v2/internal/ui.(*UserInterface).init(...)
>
>         /usr/glenda/ebiten/internal/ui/ui_plan9.go:101
>
> github.com/hajimehoshi/ebiten/v2/internal/ui.newUserInterface()
>
>         /usr/glenda/ebiten/internal/ui/ui.go:124 +0x245
>
> github.com/hajimehoshi/ebiten/v2/internal/ui.init.0()
>
>         /usr/glenda/ebiten/internal/ui/ui.go:99 +0x13
>
>
> so it's a matter of filling in those blanks.
>
>
> On Sat, Dec 13, 2025 at 8:04 PM ron minnich <rminnich@gmail.com> wrote:
>>
>> if you check out the plan9 branch of git@github.com:plan9foundation/ebiten.git, and you cd to examples/cursor, you can
>> GOOS=plan9 GOARCH=amd64 go build
>> you'll get a plan 9 binary.
>>
>> You can run it; it won't end well. All the functions you need to implement (48 of them) are stubbed out to panic.
>>
>> This is pretty much how I port unknown Go or C code to 9: stub out the stuff I don't know how to do with panic (or for that matter, Plan 9  to a new architecture, or
>> when we ported Plan 9 code to Akaros).
>>
>> Here are the functions.
>>
>> internal/ui/input_plan9.go:func (u *UserInterface) updateInputStateFromOutside(keyPressedTimes, keyReleasedTimes [KeyMax + 1]InputTime, runes []rune, touches []TouchForInput) {
>> internal/ui/input_plan9.go:func (u *UserInterface) updateInputStateForFrame() error {
>> internal/ui/input_plan9.go:func (u *UserInterface) KeyName(key Key) string {
>> internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newAuto() (graphicsdriver.Graphics, GraphicsLibrary, error) {
>> internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newOpenGL() (graphicsdriver.Graphics, error) {
>> internal/ui/ui_plan9.go:func (*graphicsDriverCreatorImpl) newDirectX() (graphicsdriver.Graphics, error) {
>> internal/ui/ui_plan9.go:func (g *graphicsDriverCreatorImpl) newMetal() (graphicsdriver.Graphics, error) {
>> internal/ui/ui_plan9.go:func (*graphicsDriverCreatorImpl) newPlayStation5() (graphicsdriver.Graphics, error) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetUIView(uiview uintptr) error {
>> internal/ui/ui_plan9.go:func (u *UserInterface) IsGL() (bool, error) {
>> internal/ui/ui_plan9.go:func dipToNativePixels(x float64, scale float64) float64 {
>> internal/ui/ui_plan9.go:func dipFromNativePixels(x float64, scale float64) float64 {
>> internal/ui/ui_plan9.go:func (u *UserInterface) displayInfo() (int, int, float64, bool) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) init() error {
>> internal/ui/ui_plan9.go:func (u *UserInterface) Update() error {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetForeground(foreground bool) error {
>> internal/ui/ui_plan9.go:func (u *UserInterface) RunWithoutMainLoop(game Game, options *RunOptions) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) runMobile(game Game, options *RunOptions) (err error) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) outsideSize() (float64, float64) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) update() error {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetOutsideSize(outsideWidth, outsideHeight float64) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) CursorMode() CursorMode {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetCursorMode(mode CursorMode) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) CursorShape() CursorShape {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetCursorShape(shape CursorShape) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) IsFullscreen() bool {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetFullscreen(fullscreen bool) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) IsFocused() bool {
>> internal/ui/ui_plan9.go:func (u *UserInterface) IsRunnableOnUnfocused() bool {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetRunnableOnUnfocused(runnableOnUnfocused bool) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) FPSMode() FPSModeType {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetFPSMode(mode FPSModeType) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) updateExplicitRenderingModeIfNeeded(fpsMode FPSModeType) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) readInputState(inputState *InputState) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) Window() Window {
>> internal/ui/ui_plan9.go:func (m *Monitor) Name() string {
>> internal/ui/ui_plan9.go:func (m *Monitor) ensureValues() monitor {
>> internal/ui/ui_plan9.go:func (m *Monitor) DeviceScaleFactor() float64 {
>> internal/ui/ui_plan9.go:func (m *Monitor) Size() (int, int) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) AppendMonitors(mons []*Monitor) []*Monitor {
>> internal/ui/ui_plan9.go:func (u *UserInterface) Monitor() *Monitor {
>> internal/ui/ui_plan9.go:func (u *UserInterface) UpdateInput(keyPressedTimes, keyReleasedTimes [KeyMax + 1]InputTime, runes []rune, touches []TouchForInput) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) SetRenderer(renderer Renderer) {
>> internal/ui/ui_plan9.go:func (u *UserInterface) ScheduleFrame() {
>> internal/ui/ui_plan9.go:func (u *UserInterface) updateIconIfNeeded() error {
>> internal/ui/ui_plan9.go:func IsScreenTransparentAvailable() bool {
>> internal/ui/ui_plan9.go:func (u *UserInterface) initOnMainThread(options *RunOptions) error {
>> internal/ui/ui_plan9.go:func (u *UserInterface) loopGame() error {
>>
>>
>>
>> On Sat, Dec 13, 2025 at 12:25 PM ron minnich <rminnich@gmail.com> wrote:
>>>
>>> https://github.com/hajimehoshi/ebiten
>>>
>>> I'm going to take a shot at turning off all linux dependencies, which should remove GL dependencies, and see what's missing. But a look at the graphics used on other platforms said to me that it doesn't demand too much.
>>>
>>> On Fri, Dec 12, 2025 at 1:07 PM Clout Tolstoy <tolstoyclout@gmail.com> wrote:
>>>>
>>>> npe looks like it has limited sdl2 support. That seems how you could get along the fastest without having to refactor  image drawing, and IO to plan9 abstractions.   Ebitengine requires a bit of C  libraries that are unavailable on plan9/9front.
>>>>
>>>> Mainly referring to this data structure
>>>> https://github.com/hajimehoshi/ebiten/blob/7d0692124a95528ee624ab641104e7a7bf1cb4b2/internal/graphicscommand/image.go#L31
>>>>
>>>> I'm not sure which (raylib/ebiten) would feel more daunting to port because of those dependencies.
>>>>
>>>> If you have a source repo of your efforts, I can try  on a rpi0 or rpi4.
>>>>
>>>> Best of luck and sorry for the slight derail.
>>>>
>>>> Clout
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Dec 11, 2025, 8:37 PM ron minnich <rminnich@gmail.com> wrote:
>>>>>
>>>>> My goal, for 9, was to look into a pure Go 2D game engine, to see if it would work. This discussion spiraled off into thousands of other paths, as things on this list are wont to do :-)
>>>>>
>>>>> But I'm still wondering if the 2D game engine in Go could work. I think I'd better go look.
>>>>>
>>>>> On Thu, Dec 11, 2025 at 8:33 PM Noam Preil <noam@pixelhero.dev> wrote:
>>>>>>
>>>>>> Fwiw if the goal is something like this on 9, raylib is likely a much better choice. It can render entirely in software, to a framebuffer, iirc, and is entirely in C.
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mab999111e9a1d8cdc51bbded
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[Philip Silva via 9fans]

Actually there are forks of 9fans.net/go/draw that build on Plan 9

Not very recent but still: https://github.com/psilva261/go/

This is all based on this pull request: https://github.com/9fans/go/pull/17



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M237bd620d47bdf11bf5b7970
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Thanks! I'll give it a shot.

On Wed, Dec 24, 2025 at 6:47 AM Philip Silva via 9fans <9fans@9fans.net>
wrote:

> Actually there are forks of 9fans.net/go/draw that build on Plan 9
> 
> Not very recent but still: https://github.com/psilva261/go/
> 
> This is all based on this pull request:
> https://github.com/9fans/go/pull/17
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mb6876847bee80e6201d6e6df
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2093 bytes --]

Re: [9fans] 2d game engine, pure Go: anybody want to try it on Plan 9?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

bash-3.2$ (cd ~/Documents/9fansgo/ && git remote -v)
...
psilva git@github.com:psilva261/go.git (fetch)
psilva git@github.com:psilva261/go.git (push)
bash-3.2$ (cd ~/Documents/9fansgo/ && git branch)
* psilva # master

bash-3.2$bash-3.2$ pwd
/Users/rminnich/Documents/ebiten/examples/text
bash-3.2$ GOOS=plan9 GOARCH=amd64 go build .
bash-3.2$

Yep, it builds ...

thanks.


On Wed, Dec 24, 2025 at 9:57 AM ron minnich <rminnich@gmail.com> wrote:

> Thanks! I'll give it a shot.
>
> On Wed, Dec 24, 2025 at 6:47 AM Philip Silva via 9fans <9fans@9fans.net>
> wrote:
>
>> Actually there are forks of 9fans.net/go/draw that build on Plan 9
>> 
>> Not very recent but still: https://github.com/psilva261/go/
>> 
>> This is all based on this pull request:
>> https://github.com/9fans/go/pull/17
>> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mee9bb33b01b50be29951df15
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3031 bytes --]