No questions today, but just wanted to pass huge congratulations your way.
Getting to release is no small feat even when leaning on existing engines, and knowing how little was available in CL makes this day all the sweeter.
TaleSpire dev here. jfabre is not a Bouncyrock employee and does not work on TaleSpire.
I'm sorry if you've run into people bashing our competitors. It sucks as there is plenty of room for different approaches in this space (see TTS and battlemapp for two ace alternative 3d vtts).
You setup sounds awesome. We've not got any plans for supporting the tv tables so far, but arkenforge and foundry both seem awesome at it.
I couldn't get anywhere with those last time I tried (2013). LispStick doesn't seem to have been updated since 2014 and LispBox has had no commits since 2010. Have you used either of these recently?
For those wanting to go this route I'd recommend Portacle which can run on off a usb and includes git
Main downside of Common Lisp is that Emacs or Vim are pretty much a requirement to get a nice development environment, without which you are pretty much in 'writing Java in notepad' territory.
[0] for some definition of fast that I don't want to belabor this comment with.
There are some other practical answers here so I'll take a different angle.
Fun! CL is a language to play in, after a day of wrangling Java & ObjC issues I love settling down to just play in an environment that lets blast some code out and play with ideas. Of course this applies to other languages too and this is dependent on your interests, so the case I want to put out there is:
Even if a language isn't suitable for your current business needs, see if it gives you joy. Languages have trades offs to meet their goals, evaluate languages for pleasure too.
Also come visit #lispgames on freenode sometime..most of us are procrastinating making engines but it's always nice to have new folks around.
It would be a very good idea. Be sure to make it talk to swank (the server side of the current editor tooling) so you can benefit from all the work that has been done there
Arcadia is very cool, having access to unity's content pipeline must be wonderful. What is your process for managing the gap between the running game state and the code. For example, you are tweaking the attack damage of some enemy-ship in the repl and you find a values that feels good, do you then jump to code and update the enemy-ship's data or do you have a system that handles 'committing' your changes from the live instance into the code?
It was on 13/03. It was on meetup.com & r/lisp but I wasn't sure of other places to shout about it without being spammy. I'd love to meet up with some other local lispers though.
I expect that's Alex Charltons work on glls, we've only chatted briefly but I naturally am excited by what he was oing. Or maybe davexunit it who doing some monadic gl work in guile. A few folks hang out on #lispgames on freenode. It's a small corner of a small scene, but it's fun.
If you are interested in this stuff also look at kovasb's gamma library for clojure or any number of cool project for haskell.
Yeah that was a shame, it was my first time playing with the cam/mic setup and I got something a bit wrong. It's worst at the start of the talk so if you can bear through it then ace. Otherwise I'm also looking talking to someone about subtitling it, so when those are available I'll add them to the video and make them available on my github.
The goodereader 13" is android, ReMarkable isn't. And the gooderader project has not turned to vapour yet althought I can understand linuxkerneldev's reason for being annoyed.
For a little historical context, this craft is 92m (301ft) long, the Graff zeppelin was 236.53m (776ft) and maxed out at 128km/h with 60 people on board.
Obviously these very different beasts with different goals, but the sheer scale of the old zeppelins never fails to make me happy.
- Even in it's older frp incarnation, elm didnt allow changing of the flow graph (sorry I cant remember the correct elm term for this) while the program ran [1], making it hard to say this would be an ideal way to go for true 'interactive coding' for games.
To clarify my opinion I would like to add that I am assuming an ideal of 'interactive game coding' where one would start a GL context & repl session at the start of the day and make the game whilst never closing the session or killing the context.
The OP limited himself to retrogames which is a wise move for exploring this topic, _one_ of the things that makes writing modern games hard is the extent to which you are pushing what the hardware can do. It is normal to be required to really be strict about what happens when in each frame and it's not possible to do this if, part-way through rendering you have to process events coming from some input thread that has no idea about the context your program is in.
Lastly I would add that your program itself is state. Interactive programming requires you to create and remove functions from your running program and bugs particular to doing this can occur (some object has a reference to a version of a function you have removed etc etc). Unless we move to a point where our code (compiled & text) live in a some persistant data-structure that allows rollback in some meaningful way I find it hard to imagine _real_ functional interactive programming.
This is a cool topic and ripe for discussion and progress, but just dropping in interactive programming does not in itself make game coding easier. However it is a pile of fun.
Hehe, what are curiously peeved sounding post. I was seeking to keep it short but as I've been unclear let's drill into some stuff.
> Not really; it will clash
Nope, named-readtables fixed the clashing reader-macro issue a good while back.
> You mean ... programming the programming language?
Yes, I do. I said it the way I did out of choice, as the 'programmable programming language' phrase has been bandied around so often that, for some, it has lost impact. Maybe that phrase doesn't inspire the same ahah moment in some as it does for other. Saying the same thing in a different way can be enough for someone to pick up something new. (It feels weird writing this down as it's kind of self evident)
> Do you plan to type "lambda" with args enough times to eventually that hour of your life back
I that hour was spent learning about reader macros, learning something new is of value to me, so there is no 'lost hour' to reclaim. Don't you just code for fun some days, without worrying if it is somehow ultimately useful?
> Note how if we take λ(* _ _) and then just move the parenthesis over the Greek symbol, we get (λ * _ _). This saves almost the same amount of typing
Ah ok, maybe this is where we parted mental ways. I'm not interesting in saving typing, that wasn't the goal. The point was to remove a little visual obstruction from what I was doing. For example (and yes it is a trivial example) (lambda (x) (* x x)) is 20 characters long, of which 8 are of interest (* x x) I liked that the shorthand reduced a little visual noise.
Yes there are many ways to skin this particular cat, but I liked the shorthand. I also like not having the lambda in the first position as it maintained a property of lisp code I generally enjoy, that I can run my eyes over the lefthand side of the forms and quickly get a rough feel of what is going on. Again, this is just a personal feeling, but some days I write code just for me, for fun, so why not make things pleasant for myself.
It's rather odd to get into a discussion about this, when the whole point is that we don't have to pick one golden way and enshrine it in the language. It's just a library, use it or don't, it doesn't matter.
I found them useful when I looked at clojure and saw their shorthand syntax for lambdas where #(* % %) is a lambda that takes one argument and squares it. You can get some tidy things that are similar with regular macros but to make it actually equivalent your need to hook into the reader..and that's what reader macros are for. So within the hour I had something that let me write λ(* _ _)
The best bit though, is that this isn't some nasty hack. This is supported by the spec, so I can package this up and let other people us it just like any other functionality we care to ship around.
That's my favorite thing really, being able to treat approaches to writing code in the same way we treat the functionality we make using code.
CEPL/Varjo creator here. Thanks for the shout-out but my compiler is very basic, it has potential though and I'm looking forward to people making higher level approaches/languages that use CEPL & Varjo under the hood.
Regarding the authors issues, the APIs are very ugly, especially in GL where you have two apis smashed together (pre v3.1 and post). I'm not qualified to comment of DirectX but I feel in the GL case there is a fairly nice API buried in the madness, and that with a suitably flexible language you can making working with it rather pleasant without resorting to tools that totally separate you from the lower levels.
Vulkan is no panacea (nor dx12) because with control comes the associated complexity. Vulkan is going to be awesome for folks making engines, languages or those who just want absolute control. But Khronos are very open that these Vulkan & SPIRV are not replacements for GL/GLSL. The increased variety of APIs that will be possible for people to make WILL be exciting though and that is worthy of celebration, as will be mixing and matching the above.
Re the "impoverished GPU-specific programming languages" comment. Limiting the scope of a language can give you valuable places to optimize and one of the primary concerns for this hardware is speed. As an exercise/strawman add pointers to an imaginary gpu language and work out how to keep the performance you currently have. This is going to become more evident as languages come out that compile to SPIRV and we get to see behind the curtain at just how hard it is to make code run fast against the various hardware approaches to render that exist in GPUs (for a case in point see 'tiled rendering').
Im unsure around the 'interface too flexible' issue as GPU resources are still valuable enough that being able to unload code is still useful, and at that point you have to rely that the pipeline you load follows the interface you expect it to, as you would with any shared library. Even when you take away all the api ugliness you are still left with the fact you are talking to a separate computer with separate concerns, I'd rather embrace this in a way that feels natural to your host language than hide this separation which makes certain issues (e.g synchronization) harder to deal with.
Regardless, this is still a valuable post and an issue worth getting fired up about, it's always exciting to see people making different ways of leveraging these awesome pieces of hardware