<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) ***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>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>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.