I'd really like to understand how live reloading works a bit better, especially when editing variables that some running thread depends upon. Is there an overall strategy here? Do I implement locking around variables that I intend to play with at runtime?
With the threading model of most CL implementations, you really only need locking if you need to change two (or more) places and have the update appear atomic, or if you are doing a read/modify/write. But you would already need such infrastructure in place if you were going to modify them in you program as well.
>> One thing I do have to mention though is that the workflow in Lisp allows me to create these support libraries much faster than I can in other languages. I'm at that stage in my lisp journey (~18 months) where i know enough to be dangerous to others around me, i.e. i'm still a lisp n00b but have completed a few lisp & scheme books and written enough projects that i feel fairly productive. BUT i haven't reached, ne…
Could you expand on the REPL bit? Having worked with JS, Python and Elixir, they feel more or less the same. What’s Lisps have that these don’t?
I personally prefer SLIME over any IEX client I've ever seen, but that's not a limitation of Elixir. Since Erlang has a Smalltalk-esq image just like CL does, the Elixir REPL is in principle as powerful as a Lisp's. In practice CL has lots of additional little things which are nice, like the ability to update instances in place after changing a class or DEFVAR forms which don't clobber their contents on reloads, but for me most of the advantage comes from just how well designed SLIME is.
From the post: > The same doesn't apply to the player sprite, as Aseprite takes minutes to compile the atlas for the nearly 1000 frames we have. Why does compiling a sprite atlas for the player take 60ms/frame?
I'm sure Aseprite could be further optimised to press down the constant factor, but it is performing a rect packing algorithm among other things, which is an NP-hard problem.
The bin packing problem is NP-hard, but rectangle packing is "merely" NP.
However, most people just use a recursive biggest-fit-first ¹), a simple heuristic that is surprisingly hard to beat for most workloads.
I couldn't figure out what Aseprite is doing from their website or documentation, but if it's not that then it might be worth it writing your own sprite packer.
Heya, I'm the author of the article. I've been working on Kandria full time for close to two years now, and on-and-off for some years while I was doing my Master's at ETH. The engine it's running on, Trial, is a few years older still, and initially just started out of the good ole university boredom and curiosity. Games is how I got into programming when I was about 6, and that particular fever hasn't left me yet it…
This project looks awesome! I really like art, and it's exceptionally cool that you're using Common Lisp. As someone that often gets lost in the engineering (aka "fun") aspects of building things, my one piece of advice would be to make sure you put enough energy into marketing your game to ensure it reaches as wide an audience as possible and none of your efforts go to waste. Looking on reddit, I see a lot of posts in r/lisp, which is cool, but I'd work towards building as much buzz as you can in the indie gaming community (little teaser videos, etc). I'd also consider posting on the Tigsource forums, as that's a good way to build roots in the indie community. Anyway, looking great, and best of luck with your launch!
Heya, I'm the author of the article. I've been working on Kandria full time for close to two years now, and on-and-off for some years while I was doing my Master's at ETH. The engine it's running on, Trial, is a few years older still, and initially just started out of the good ole university boredom and curiosity. Games is how I got into programming when I was about 6, and that particular fever hasn't left me yet it…
This project looks awesome! I really like art, and it's exceptionally cool that you're using Common Lisp. As someone that often gets lost in the engineering (aka "fun") aspects of building things, my one piece of advice would be to make sure you put enough energy into marketing your game to ensure it reaches as wide an audience as possible and none of your efforts go to waste. Looking on reddit, I see a lot of posts…
Thanks! Yeah, marketing is definitely a weak point, in large part because it's just something that goes very much against my character. I've tried posting to reddit before, but most communities' strict posting rules about promotions make that a pain, or simply not worth bothering with due to low conversion rates.
I'm sure Aseprite could be further optimised to press down the constant factor, but it is performing a rect packing algorithm among other things, which is an NP-hard problem.
The bin packing problem is NP-hard, but rectangle packing is "merely" NP. However, most people just use a recursive biggest-fit-first ¹), a simple heuristic that is surprisingly hard to beat for most workloads. I couldn't figure out what Aseprite is doing from their website or documentation, but if it's not that then it might be worth it writing your own sprite packer. ¹) https://codeincomplete.com/articles/bin-packi…
Yeah I don't know what they use either, but so far repacking that atlas has not been frequent enough that writing my own packer would save time.