Live data from Hacker News

Viewing profile — makuto

makuto

HN member
Joined
Wed, Sep 30, 2020, 4:59 PM UTC
HN karma
184
Public activity
39 items

About makuto

Software engineer in the game industry.

Recent public activity

  1. comment
    Comment #36164268

    That's true. I was mainly trying to indicate there is no boxing or anything like some languages seem to have with their types.

  2. comment
    Comment #36164261

    There is a module in gamelib [0] which will automatically clone, build, and link raylib to your program. There are several other third party libs there as well, including SDL2 and …

  3. comment
    Comment #36164236

    Memory allocation matches C, i.e. malloc and free are used. If interoperating with C++, you can use new and delete.

  4. story
  5. story
  6. story
  7. comment
    Comment #32246198

    Author here! Isconnected is a hypothetical.

  8. story
  9. story
  10. story
  11. story
  12. comment
    Comment #26793209

    Chat profanity filtering is usually part of Xbox/PlayStation certification requirements, so their hands might be tied on that.

  13. story
  14. comment
    Comment #25568182

    I have a Surface Pro 2 running with the linux-surface kernel [0]. It feels like it has some rough edges - you have to decide between having pen support or having touch screen suppo…

  15. comment
    Comment #25558999

    I'm not sure why you say it's a "quite safe" assumption that most games are written in C#. Unity's beginner-friendliness gives it a disproportionate presence online, while the vast…

  16. comment
    Comment #25554387

    I did something similar with a Raspberry Pi and Waveshare e-ink display: https://github.com/makuto/home-life-display

  17. comment
    Comment #25498106

    Yes, there's nothing in the language which is specific to games. Once I get pure C output supported, it should be suitable even for embedded C environments.

  18. comment
    Comment #25496847

    That's correct. My goal wasn't to make a CL-compatible Lisp. I imagine the code will start to look less like C as more macros/generators get added.

  19. comment
    Comment #25496490

    Thanks! I have a list of similar projects, I will add these! https://github.com/makuto/cakelisp/blob/master/doc/VsOtherLa...

  20. comment
    Comment #25496376

    Yes, they are compiled just like the final exe, only they become dynamic libraries that I load with libdl. On subsequent builds, they are loaded again, unless the macro changed.

  21. comment
    Comment #25492761

    While I can't speak for any experimental new garbage collectors, I did analyze the SBCL generational GC's implementation. I encourage anyone interested in performance to look over …

  22. comment
    Comment #25492402

    It looks like Cakelisp for Rust! I'll have to look at it in more depth. Thanks for the link!

  23. comment
    Comment #25492394

    The big distinction to me is that there is a final executable that eventually gets created, whereas Lisp programs can continue to generate code and self-modify at runtime. Cakelisp…

  24. comment
    Comment #25492285

    I agree. Templates make some tasks easy (type specialization and generic containers) but become tangled messes with other tasks (function bindings, serialization). I used something…

  25. comment
    Comment #25492229

    Carp requires writing bindings to call C functions or use types. Additionally, code modification isn't possible in Carp. When I say seamless, I'm going for as close as possible, I.…