3 ms·

Futurama reference ;) https://www.youtube.com/watch?v=VmCqn-DNSA0 https://www.youtube.com/watch?v=VmCqn-DNSA0 though apparently popular enough that some people

Futurama reference ;) https://www.youtube.com/watch?v=VmCqn-DNSA0 https://www.youtube.com/watch?v=VmCqn-DNSA0 though apparently popular enough that some people have made all-rush playlists ( https://www.youtube.com/watch?v=JsKBIBJj-4M&list=PL8BF75E7F0B3888C3 https://www.youtube.com/watch?v=JsKBIBJj-4M&list=PL8BF75E7F0... ) On-topic - definitely a cool project and one that I haven't heard about actually, added to my queue of weekly source-code readings. I'd also consider DirectFB similar, and another project that I just have in my vaguest of memories (think they used a project-name like Cairo that got google-CVed out of existence from the more recent one) from the 2001-02ish era. They tried to attack X back then, but fell victims to the driver situation (but they had arbitrarily rotated windows!). One of my stronger personal influences is BeOS though - Compare https://www.youtube.com/watch?v=BsVydyC8ZGQ https://www.youtube.com/watch?v=BsVydyC8ZGQ to https://www.youtube.com/watch?v=3O40cPUqLbU&feature=youtu.be&t=2m33s https://www.youtube.com/watch?v=3O40cPUqLbU&feature=youtu.be... :)

i336_ 10y ago
Ahh... I don't watch any^H^H^Henough TV. :P I've been meaning to poke around PicoGUI myself - I personally love stuff that's tiny and efficient, always looking out for things like that. (I just found a bunch of old versions of Contiki, the ones with the GUI stack; the non-broken ones were fun to play with: http://hitmen.c02.at/html/tools_contiki.html http://hitmen.c02.at/html/tools_contiki.html) Very cool to hear I recommended something relevant! ^^ I've heard of DirectFB, but my understanding is that it just tames framebuffers, as opposed to dealing with everything below the toolkit level. I don't recall anything called Cairo myself, but as for attacking X I do vaguely recall a company that made a closed-source alternate Linux display stack+desktop environment; it was very rudimentary and went nowhere because of that. I like BeOS too. I keep meaning to install it (and OS/2... and QNX... and...), just preferably on real hardware. I have a bunch of old stuff hanging around here that I hope to use once I have a little file server and I can free up my dozens of old HDDs :P And your video (I watched the other one in 2008 :D still remember it) was really awesome, and led to git cloning and compila--"wait it's done already?! Nice." Now my main request is, please update the documentation on GitHub (particularly the quickstart instructions) so we all aren't stuck with just welcome.lua (which I initially thought was a builtin options screen then double-checked to see if I'd specified the args wrong, lol). I (and probably everyone else) want(s) to play with the stuff you're demoing in your videos! Another tiny thing I'd mention about the video (it was the first thing I noticed actually) was that it would be a) awesome to watch and b) a great demo of your engine's graphics pipeline performance, if you have the media player update its graph at like 60fps. Or at least 24fps. Just a thought. For my favorite reference of what fast VU looks like, I recommend rezound (http://rezound.sf.net/ http://rezound.sf.net/) - run it once, then edit ~/.rezound/registry.dat and set meterUpdateTime (in Meters {}) to something like 4 (it's a delay in microseconds I think, 4 is nice and doesn't flood X with updates too fast on my machine). The weird knob thing to the right of the VU (very bottom-right) adjusts the frequency response. Another possible source of fast VU updates is the Linux port of Open Cubic Player (http://stian.cubic.org/project-ocp.php http://stian.cubic.org/project-ocp.php) - alt+c, set framerate to 60 or 120fps, set font to 4x4 (after loading music :D), and the result there looks nice, too - although it responds best (for me) with a non-fullscreen window. (This one's a bit of a project to learn all the shortcuts for, IMO.)
- 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 ago
    Are 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 ago
      If 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 ago

Ahh... I don't watch any^H^H^Henough TV. :P I've been meaning to poke around PicoGUI myself - I personally love stuff that's tiny and efficient, always looking out for things like that. (I just found a bunch of old versions of Contiki, the ones with the GUI stack; the non-broken ones were fun to play with: http://hitmen.c02.at/html/tools_contiki.html http://hitmen.c02.at/html/tools_contiki.html) Very cool to hear I recommended something relevant! ^^ I've heard of DirectFB, but my understanding is that it just tames framebuffers, as opposed to dealing with everything below the toolkit level. I don't recall anything called Cairo myself, but as for attacking X I do vaguely recall a company that made a closed-source alternate Linux display stack+desktop environment; it was very rudimentary and went nowhere because of that. I like BeOS too. I keep meaning to install it (and OS/2... and QNX... and...), just preferably on real hardware. I have a bunch of old stuff hanging around here that I hope to use once I have a little file server and I can free up my dozens of old HDDs :P And your video (I watched the other one in 2008 :D still remember it) was really awesome, and led to git cloning and compila--"wait it's done already?! Nice." Now my main request is, please update the documentation on GitHub (particularly the quickstart instructions) so we all aren't stuck with just welcome.lua (which I initially thought was a builtin options screen then double-checked to see if I'd specified the args wrong, lol). I (and probably everyone else) want(s) to play with the stuff you're demoing in your videos! Another tiny thing I'd mention about the video (it was the first thing I noticed actually) was that it would be a) awesome to watch and b) a great demo of your engine's graphics pipeline performance, if you have the media player update its graph at like 60fps. Or at least 24fps. Just a thought. For my favorite reference of what fast VU looks like, I recommend rezound (http://rezound.sf.net/ http://rezound.sf.net/) - run it once, then edit ~/.rezound/registry.dat and set meterUpdateTime (in Meters {}) to something like 4 (it's a delay in microseconds I think, 4 is nice and doesn't flood X with updates too fast on my machine). The weird knob thing to the right of the VU (very bottom-right) adjusts the frequency response. Another possible source of fast VU updates is the Linux port of Open Cubic Player (http://stian.cubic.org/project-ocp.php http://stian.cubic.org/project-ocp.php) - alt+c, set framerate to 60 or 120fps, set font to 4x4 (after loading music :D), and the result there looks nice, too - although it responds best (for me) with a non-fullscreen window. (This one's a bit of a project to learn all the shortcuts for, IMO.)

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 ago
  Are 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 ago
    If 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.