4 ms·
I actually force myself to do at least some of the development on (no cross-compilation) a raspberry pi for the reason of getting a snappy build-time. I had ev
by crazyloglad 10y ago
I actually force myself to do at least some of the development on (no cross-compilation) a raspberry pi for the reason of getting a snappy build-time.
I had even forgot there were instructions like that, outside the technical bits I'm probably the worst person to write helpful guides as the workflow etc. is just so strongly internalized that most of it 'feels' obvious.
Now don't look at the code for generating the FFT (or anything else in the _decode frameserver for that matter), the reason it doesn't update smoother is just how much I don't get along with "lib"vlc, but I added it more as a novelty (spoiler, FFT precision is murdered and packed into a texture and the rest is a shader, it doesn't even synch well).
- i336_ 10y agoAre you me? That's my ideal approach! Except I'm not so crazy to consider running the build on the slow box (:D), rather my approach would be to have 1Gbps+ between the two machines, build on the fast machine, and run (perhaps directly from NFS?) on the slow machine. I was thinking of editing on the slow machine too (so it's the machine you use) but I don't think going that far is actually necessary. Now, as to how exactly I would implement this idea under DOS for my 486 is another story entirely... I know what you mean by the obviousness thing. I however am sitting here with no idea how even to desktop with Arcan. I wouldn't mind finding out though. And I was wondering if it was updating the FFT so slowly because of... yeah, something like that. I see. I have to acknowledge and agree that it does indeed not sync well. Fixing this sounds like a large pile of boringness; I can see that the other display components update pretty quickly, at least. (But now I'm wondering, is the video of a VNC server? I thought it was SDL. How are you updating the screen so quickly?!)
- crazyloglad 10y agoIf you poke me on IRC (letoram, #arcan @freenode) I can probably help you out in using the thing. I think the hardest I've pushed the shared memory interface is basic computer vision (filtering, 9-segment display OCR, tracking an x-y plotter and some glowing devices) on 8-bit mono 2x1000fps 320x180-or-so cameras. Even then most time was spent waiting for synchronization bottlenecks because of OpenGL2.1 limitations. you thinking about https://youtu.be/bQlHnW2qCh0?t=1m28s https://youtu.be/bQlHnW2qCh0?t=1m28s ? so the round-trip time there is gpu-composite -> readback -> vnc-server -> vnc->client -> back to gpu.
- i336_ 10y agoThis is so annoying - I keep finding reasons to go on IRC, but am still stuck on what IRC client to use. ("No, my web browser feels weird." "irssi doesn't have a multiline text box." "weechat isn't configurable like irssi is." "I don't want to use GTK or Qt." Lost cause: check. Protip, don't drown yourself in chat client ideas for 4 years, you'll poison yourself to everything out there :X) - but the mention of IRC is duly noted. :D I had a major derp, however: I forgot durdan and arcan aren't, err, the same thing... let's just say I just installed durdan, and successfully played around for a bit. It's a bit slow on my frankensystem (GPU is older than motherboard+CPU... don't ask >.>) but still very cool. And wow, that's a pretty awesome usage of the SHMIF, cool. I wonder if porting Arcan to Vulkan would produce interesting results... And I meant https://youtu.be/3O40cPUqLbU?t=279 https://youtu.be/3O40cPUqLbU?t=279 - in particular the part I seeked to, where you play and record video and blit it onto a 3D surface so on and so forth - the VU is noticeably slower than everything else. I just thought it would be cool if the video was like "look: EVERYTHING is updating at 60fps!" - but it's cool. :P About the video you linked, that's pretty incredible too... wow.
- crazyloglad 10y agoI have high hopes for the shmif- port to vulkan, as far as I can tell, there's no good way to flag pinned memory as shared and build the shmif around that, but if it was possible it would be predictable synch, controlled colorspace conversion and ... oh well, QEmu integration first :-) You might be able to reduce the fillrate cost by trying config/system/simple displaymode.. it removes a lot of features but you save at least a full extra renderpass.
- i336_ 10y agoWow, shared pinned memory sounds absolutely awesome. Please tell me NVIDIA doesn't have to alter their binary driver to get this working... please. :P I'm not sure if you need to shout at NVIDIA, Linux or Vulkan to make this possible, but there are so many awesome things people could do if this were possible... I would totally recommend you shout at all the relevant mailing lists - even NVIDIA's, if it comes to that :P to get this supported. And how are you managing qemu integration? What do you mean by that? o.o I tried the simple displaymode, which seems to be a tad faster, but it's still glitchy - the issue specifically is that opening a fullscreen terminal (at 1600x1200) basically makes my mouse a slideshow, and there's noticeable typing lag too. Resizing the terminal down makes it go away: this is proportional to terminal size. And as an aside, -w 1600 -h 1200 makes the mouse cursor go halfsize, -w <= 1599 and -h <= 1199 makes the cursor normal size. Curious.