Random "work in progress" shots
category: general [glöplog]
Since everyone is posing with their music tool. Ahem, let me introduce you to this beauty, straight outta 1994 or so. (actually 2004, but who is counting =)
is it trackers thread?oO
@p01 please don't tell me that's going to be 1k! :o
Quote:
@p01 please don't tell me that's going to be 1k! :o
...doesn't sound like bin ;)
dat midi sequencer ♥ i'm always thinking about doing one in DOS (as sizetro ofc), yet never find motivation to do so...
p01: that looks nice, and totally doable in JS1k ... right? ;)
p01: that looks nice, and totally doable in JS1k ... right? ;)
HellMood: Thanks. The reasoning was that I wanted to have a simple sketching tool that works like a horizontal piano roll (not a vertical one) + the usual linear pattern sequence of older trackers. It's kinda cute and still works. Should work with external synths too of course, but could never try it as I never had any actual MIDI gear. :)
Thanks!
Of course this fits in 1kb. Don't you worry about that.
Really I wasn't sure if this little thing was worth digging further, or good for the bin :\
Of course this fits in 1kb. Don't you worry about that.
Really I wasn't sure if this little thing was worth digging further, or good for the bin :\
p01: dig further, it looks really good already!
currently stuck with:
currently stuck with:
weeel...fuck
Did you try glRotated(180.0, 0.0, 1.0, 0.0);? ^^
Looking good so far
Looking good so far
The black pentagon is a child node of checkered one, placed at (0,0,0.81) and rotated 180 at Y(to turn it around).
Trying to rotate the root should displace children its properly.
I thought I'd fixed the Combinatoral matrix...
Or maybe its a simple orientation problem due to the initial rotation(can't check it atm)
I'm embarrased how I haven't mastared this yet.
Trying to rotate the root should displace children its properly.
I thought I'd fixed the Combinatoral matrix...
Or maybe its a simple orientation problem due to the initial rotation(can't check it atm)
I'm embarrased how I haven't mastared this yet.
continued adventures in software rendering
greetings to chaos/fr: the rev2011 work-stealing talk & demo inspired this
cyan: translation, clipping, binning
orange: tile rendering
pink: Kawase blur, 3 passes
green: post processing & truecolor conversion
anix: cool stuff, respect!
anix: Nice! Uses a homogeneous based approach I guess... Why not 8x8 or 16x16 tiles?
...homogeneous coordinates...
Experimenting with 1k and Win10 (on a crappy APU netbook with a 1366x768 screen). Compiles to about 570 bytes with the empty shader (SIZEBENCH=1). The above is just a random shader from glslsandbox for testing (not mine). Here's a quick recording of it running: http://webm.land/w/9DGX/. Compiles to 854 bytes, though there is some further minification potential in the shader code.
Obviously no sound output whatsoever for now.
SkilledButter: Looks promising!
noby: Thanks. It compiles at least 100 bytes smaller than eg. iq's OGL framework with the shaders I tested (iq's original tunnel demo shrinks from 873 to 695). Downside: It only works with a max. of 1 enabled displays (works on external, but only if it is the only one enabled).
Still haven't decided what to do with the sound. (Procedural) MIDI is prone to fail on some systems. On the other hand I could use the free'd bytes for a tiny synth.
Still haven't decided what to do with the sound. (Procedural) MIDI is prone to fail on some systems. On the other hand I could use the free'd bytes for a tiny synth.
raer: i always thought that the tile-size should be small, so that the depth buffer fits in L1 (sort of like PowerVR), but that doesn't seem to work in practice -- i believe because the binning time & ram are too expensive. It can probe for the most effective tile-size, and it seems to always pick something that appears related to L2 size.
the blur and pp jobs process horizontal lines.
http://home.rqdq.com/cuber.zip if you want to play with it. needs msvcrt 2015.
the blur and pp jobs process horizontal lines.
http://home.rqdq.com/cuber.zip if you want to play with it. needs msvcrt 2015.
anix & SkilledButter : both these look very impressive =) While i'm still in the "do-everything-yourself-in-asm" domain mostly, these kind of motivate me ;)
hellmood: _mm_mul_ps() is close enough for me. optimizing memory/cache usage seems to be what matters (on this platform) and you shouldn't need *.asm to make big improvements in that regard.
that said, hoping-the-compiler-does-what-you-think-it-will kind of sucks, and I don't examine the assembly output as closely or often as I probably should.
that said, hoping-the-compiler-does-what-you-think-it-will kind of sucks, and I don't examine the assembly output as closely or often as I probably should.
HelloMood: Well, I'm not using any std libraries. The 800B include is my framework (which also doesn't include anything else). This way I can force the "wrong" data types down the WinAPI's throat and save a considerable amount of bytes without falling back to pure ASM. Even with recent improvements (+ 8 bytes or so for timer scaling and graceful exit) the MSVC *.asm is still just under 180 lines (with comments). Inspecting the asm is a must though.
DirectX12 will not enhance MSDOS programs, trust me.
Hopefully Vulkan support arrives soon to MS-DOS.
our new 64k is coming along really well!