also I have an issue with C - SPC shortcut because it means "change keyboard language" in macbook shortcuts and it does not work in Emacs

Right, you can change switching the layout to something else, e.g. space+command

ok this issue with C - SPC solved. How is about other keys? What bindings do you use?

Since you're a native Russian speaker, I can share that link: https://grishaev.me/key-remap/

thank you man, will check it up

tl-dr: https://grishaev.me/assets/static/aws/remapping/kb-layout.jpg

Both M- and C- use thumb fingers, which is great for hands

so you press shift with pinky and alt/ctrl with your big finger?

ah both

yep, and sometimes I press caps instead of shift, that's why both shift and caps act the same

can you please rephrase your last sentence please? Dont understand. As I see your caps is Shift , right?

yeah I mean, caps works as shift. Pinky is a weak finger and something I miss shift and press caps; thus, I remapped caps to shift

ah got it

I read your post, its awesome. Do you use left Cmd as Emacs Control key, right?

Yes, left Cmd is C- in emacs, and the right Cmd is M-

how is about "Delete"? Do you use it in Emacs? how?

for Delete, I just use backspace. None of Mac keyboards have a Delete key as I know.

backspace is far from default hands position

In general, Backspace is not Delete, but with Cmd it works like Delete (e.g. for files and directories in Finder)

In Emacs, there are plenty of commands to delete something without touching Backspace/Delete

you need to rotate your right hand to right on ~25degrees to push backspace

Cmd-K -- kill the current line of a Clojure form is you use paredit

Meta-d -- kill the word or something like that

In general, I almost never press Backspace or Enter in Emacs due to other commands

You can push that further with ctrl-j (ret) ctrl-h (delete char), ctrl-i (tab) etc. They work pretty much everywhere but windows. Back when I was using regular keyboards I would avoid anything involving pinkies like the plague.

ctrl-m works also for ret

I personally gave up and bring an atreus everywhere I bring my laptop. It’s small/light enough not to be an issue

@U050SC7SV thanks dude, yes, hotkeys for ret/del/tab is very usefull so to not move hands

When I am doing my heaviest typing, I have found a Kinesis keyboard nice (after the 1-2 weeks of practice to get familiar enough to be at full typing speed again) in that it puts keys like shift/ctrl/alt/return under your thumbs.

https://kinesis-ergo.com/

Not cheap, but way cheaper than wrist surgery

@U04BRV8JQKE on a macbook, the Fn key is the layout switcher by default, no? u should definitely disable or change the default Cltr-Space binding to Select the previous input source, because other editors might also assign more useful features to it by default. i'm also re-mapping Cmd-Opt-Space to Show Spotlight search (in System Settings / Keyboard / Keyboard shortcuts... / Spotlight) for many years by now, because the default binding to Show Finder search window is not very useful, especially by default, when it only searches in some single directory... it opens up the possibility to use Cmd as Meta in Emacs, using the mac-command-key-is-meta variable (https://ftp.gnu.org/old-gnu/Manuals/emacs/html_chapter/emacs_36.html#:~:text=On%20the%20Mac%2C%20Emacs%20can,key%20as%20the%20META%20key.) i wasn't very satisfied with that option though, since it interferes with the Cmd-X/C/V shortcuts, so maybe you can assign Cmd-Space to the Select the previous input source action (in System Settings / Keyboard / Keyboard shortcuts... / Input Sources).

maybe via wrapper (e.g. for unity) https://old.reddit.com/r/Clojure/comments/11z109z/anybody_working_on_games_here/

I haven't tried any of this, but looks like you should be able to display graphics directly with lwjgl + openVR. Or you can add one more layer and use libgdx (that I think uses those at the bottom) as described here https://libgdx.com/wiki/jvm-langs/using-libgdx-with-clojure, or add one more layer and try https://github.com/damn/engine which was announced recently on reddit and looks like it wraps libgdx for Clojure

You could also try Arcadia and Unity

https://github.com/arcadia-unity/Arcadia looks kinda dead

or maybe WebXR and ClojureScript?

I would also try WebXR (through three.js)

Using clojure for vr is achievable but be aware that the biggest limiting factor on the comfort-ability of vr is how fast you can render. This means that it may be advisable to have your rendering pipeline decoupled from your simulation, and to have it written in the most performant language available to you on the runtime you are using. The simulation hitching usually won't be a concern in VR unless it makes player motion choppy, which means that Clojure can be a perfectly good language for running the simulation. If you're on JVM clojure it can also be just fine for the rendering too as you can get JVM clojure to be very performant when needed. I can't comment either way on if cljs is fast enough for webxr to keep things smooth.

I concur with Joshua. Surely the choice of a GC is key here. Some of the more recent GCs the JVM has to offer are optimized for very short pauses, which might fit into the performance budget for VR?

ZGC would be optimial from that regard. You have about 6 ms frame budget, ZGC is optimized to have sub-ms pauses regardless of heap size.

which means you can account for about 5 ms of draw time on your render thread.

Which should include updating player position if you ever move it smoothly, as well as updating player camera position, and all rendering logic.

Getting that done in 5 ms is possible but doing so from a language besides Clojure is advisable if you plan to have complex rendering. In this case the primary thing you want to do is remove CPU overhead, which also means that you'll likely want to consider using Vulkan for your rendering library.

I'd be happy to talk through the kinds of architecture decisions that need to go into giving a nausea-free experience doing VR, since game engine development is what I went to school for and I've built about half a dozen game engines.

I guess if you go the opengl route the only graphics things you mostly end up dealing with (at least for the basics) apart from pushing your vertices and textures is pushing to the gpu a few matrices for the camera, and translation/rotation ones for the entities. But I'm not sure how fast Clojure can run a simulation, like 60fps or whatever, if everything is model with immutable data structures without fighting the GC. All this from theory since I've never tried any of this

@U5NCUG8NR given that you have experience with game engines, do you this is feasible to implement game loops in Clojure using it's immutable data structures (without doing Java in Clojure) when you need to simulate many entities, particles systems, etc?

Yes. Reducers are your friend, as is interpolation. Particle systems should nearly always be done entirely GPU-side and as such don't rely on garbage collection or linear speed of your CPU. If you want to stick entirely in Clojure you could look into cljsl or another tool to allow you to use clojure syntax to write shaders.

As for how fast clojure can run a simulation, quite fast! The big limiting factor is how big a simulation you want to run, and how detailed you want that simulation to be.

While you do have a 5ms deadline for rendering, simulation is usually much more forgiving.

You can choose to have simulation run at a different framerate and rely on interpolation to allow smooth visuals with lower framerates.

Also you can use tools like ODE4J or others to allow you to have physics code run in java land without you writing it yourself, and physics code is usually the most expensive thing that is done in a video game which requires you to hit the frame deadline.

Things like pathfinding are also expensive but they have no requirements to run within a frame budget.

interesting

From my own small tests on random mid-level gaming laptops from 3-5 years ago you can get a pure-clojure game engine to easily run thousands of dynamic objects in a simulation doing simple things within a 60 fps frame budget. You can run fewer objects doing more complex things, or you can work to eliminate some of the things that I was doing which are inefficient but that I did for flexibility.

So while you won't be writing total war or other games with hundreds to thousands of complex ai actors on screen all at once in linear clojure code, most games don't demand that.

do you know of any github repo that implements this kind of stuff? I'm particularly interested in techniques for reducing the amount of garbage generated by Clojure data structures

I have a clojure game engine called s-expresso that I've got published on sourcehut. I haven't had time to work on it in a while because of work, but it's up there, partially documented, and I'd be happy to talk about it.

Although I'd say don't worry about generating that much garbage.

Collecting ephemeral garbage is one of the things the JVM is best at

https://git.sr.ht/~srasu/s-expresso/tree/sample/brick-breaker/

nice, thanks! I'll take a look

I haven't finished writing any games in this engine, most of my effort has been in making it so that the rendering engine and simulation engine are fully decoupled and can result in buttery-smooth gameplay even through hiccups.

yeah that is very interesting

It uses an entity component system architecture, but that's for the API, I don't worry about data layout like most ECS people do in other languages.

that frame-timings.svg file as well is potentially useful to look at

it's a visual representation of approximately what the architecture is doing frame to frame

https://git.sr.ht/~srasu/s-expresso/blob/sample/brick-breaker/frame%20timings.svg

@U5NCUG8NR I was about to play a little bit with your code, but after running it I see the assets aren't on the repo, do you happen to have them around?

if you want a Clojure-like experience that isn't constrained by the JVM or JS runtimes, it may be worth looking into other Lisp implementations that can more directly interface with C and/or C++, which is probably where a lot of the heavy lifting is going to be and there are likely performance-oriented libraries available to use that simply don't exist on the JVM. • https://fennel-lang.org/ - a Clojure-like Lisp on top of Lua • https://janet-lang.org/ - another Clojure-like Lisp designed for fluid interop with C • https://ferret-lang.org/ - similar to above, but with C++ in mind Full disclosure: I haven't used any of these languages, so I can't speak to their suitability to any particular problem. I do think it's worth considering whether the tradeoffs of the JVM are worth it for such a performance and latency-sensitive domain, though.

Hey @U0739PUFQ, I can help out with that for sure. The assets deliberately aren't on there to prevent bloating the git repo and to avoid licensing issues. I'll contact you via DM to get it worked out.

oh, great!

Also for doing gamedev, lwjgl is more than enough for most purposes. In cases where it isn't, #C02EEAUHSJJ or dtype-next can be used to access C-abi libraries from Clojure directly.

I'm hoping #C03SRH97FDK will have a good story for VR dev.