So last week, I was in Bongland visiting friends (and hung out with a Kiwi while I was out there).
I got back Monday, drank for a few days and I'm sorta now getting back to my routine. I really should get jobhunting again, so yesterday I talked to some borderline incomprehensible jeets. Including answering some terrible quizzicles about pointless technical nuances about web languages.
"uhh, what's the difference between a package and a module in golang?" "what's the difference between an array and a slice in golang"
(Frankly, as an established programmer with a decade+ of experience in professional development, I reserve the right to be uptight and crotchety about knowing every spergy little detail about your new pet webshit language's terminology. That being said, I think I got the package/module question wrong and I think I got the array v slice question right, which is probably the least petty and most job-relevant combo to fuck up. Slices and arrays will actually affect performance, your algorithms and your code equality. Package v module is a vocabulary quiz.)
Anyway, I also got back into
my game/opengl dev stuff. Was a little rusty yesterday and this morning, but I'm getting into it again.
The part that I'm at right now is probably the most "computer sciencey" part of a project like this. Everything else before this point was just a matter of code design, making stuff readable, and reading APIs and documentation and applying them properly.
I'm working on something to render 2d sprite graphics from spritesheets using OpenGL. For those who aren't familiar, OpenGL is a 3d rendering API, not a full fledged 3d engine. One aspect of OpenGL is that as you draw 3d elements, it draws it to the
framebuffer which ultimately will get shown on the screen. Naturally, you're going to want to have items closer to the screen (in the case of 2d, backgrounds vs characters) obscure things that are spatially behind them. In order to do this, OpenGL's approach is really just to draw things in reverse order and draw the later stuff over them. Sometimes for efficiency they'll use a
z-buffer, but that's just a specialization of the same concept.
So you need to sort your graphics and draw them in order, further ones first. (This is especially important if you've got any semi-transparent things, so like tinted windows need to shade the things behind it.)
So my little 2d tile manager library maintains an xy position for each tile, because it's 2d. But actually, internally, it has a full xyz coordinate, and the z is for depth for rendering. You can use the full
tile-position function to set/get it. But you'll probably want to use
tile-position/xy most of the time.
Most code will set the depth when the tile is first allocated and leave it as it is. But still, the rendering order for the objects in my OpenGL buffers will need to be kept sorted.
So I want to write an algorithm that maintain the sorted buffers. You give it your buffers and the index of the object that might've shifted, and it'll make sure the object to its left is nearer and the one to its right is further, if not, it should do some swaps (and as few swaps as possible, because any updates mean OpenGL calls) to reorder them.
Now this is the kind of thing that gets super in-the-weeds, and it's something I could see myself easily fucking up. So I'm implementing it as an extremely generic algorithm like this:
Code:
(define (vector-shift-sort-item! vect idx #!key
length
is-empty?
less-than-or-equal?
swap!
)
...
)
All the keyword arguments are functions the caller needs to pass in. Those will be simple, simple functions to move some bytes around in OpenGL buffers, but for my initial development and testing purposes, I can run it with ordinary Scheme vectors.
And I've got a bunch of tests like this:
Code:
(add-vect-shift-test!
name-suffix: 'left-min-equal-neighbor
idx: 0
in-vect:
(vector
(make-item value: 0.6 key: 'a)
#f
(make-item value: 0.6 key: 'b)
(make-item value: 0.7 key: 'c)
(make-item value: 0.8 key: 'd))
out-vect:
(vector
(make-item value: 0.6 key: 'a)
#f
(make-item value: 0.6 key: 'b)
(make-item value: 0.7 key: 'c)
(make-item value: 0.8 key: 'd)))
So because the function itself has a very functional (in the sense of lots of use of functions as an interface, not in the sense of not using side-effects) interface, I can make up these completely bogus test cases and make sure it's working.
The key, btw, is to make sure there aren't unnecessary swaps when the value is equal. That's what this is testing. Sorting for
a shouldn't require any changes, because the next item to its right,
b, has the same value. No reason to float it "above"
bif they're equal.
I just started this and I have some basic cases like the above working. The more complicated ones will take a bit. I'll need to have a bunch of tests by the time this is done.
I must be lucky then. After a few years at my current office I've seen way more competent female devs than I've seen trans employees working here. The few I have seen were either interning or on contract from another company.
Occasional I meet competent female devs. Often they're jeets though.
Or I meet smart women with interests in computer adjacent stuff, although they often do stuff like data science that requires them to fuck around with stuff like Python, but they're not necessarily particularly great Python programmers specifically.
