IRC channel logs


back to list of logs

<ArneBab>I created a small commandline->optargs parser, thought you might be interested: (apply hello (parsestrict args)) →
<ArneBab>It uses optargs to define commandline arguments
<ArneBab>There’s no help yet, but that’s something for another day (plan: use (program-arguments-alist hello)
<dustyweb>cool ArneBab :)
<ArneBab>thank you :-)
***apteryx_ is now known as apteryx
***karlosz_ is now known as karlosz
<iv-so>spk121: turns out I can just remove unwanted test files, lol, even reconfiguring unnecessary
<civodul>wingo: stumbled upon a case where our GMP custom allocation functions interfere:
<civodul>would be curious to hear your thoughts on how to address this!
<civodul>i can't really think of a short-term workaround and the longer-term solutions that come to mind aren't very nice either
<RhodiumToad>if A is a library that's intended to be embedded into other programs, and A references B, then it's A's responsibility not to do things to B that would mess up if the host application also uses B
***srandon111 is now known as suq_madiq
***suq_madiq is now known as genericname
<ruffni>leoprikler: thanks! i already managed to figure that part out (skimming the docs), but i don't know how to get a "writable surface" or whatever i need to keep a window open and drawable. right now i'm using (render-copy ren (surface->texture ren (load-bmp "hello.bmp"))) to get me starting..
<ruffni>(that's from the project page's "hello world")
<leoprikler>ruffni: that's bad
<leoprikler>You're allocating a new texture on each render call, which is not something you should do
<leoprikler>Or perhaps you haven't even abstracted to that level yet?
<leoprikler>It feels like you're in need of a game loop, that calls your render function at regular intervals first.
<leoprikler>Writable surfaces are perhaps a thing when doing software rendering; for hardware-accelerated stuff you should set your texture as render target.