Boring Friday night in? Looking for some hot, esoteric programming challenges? Give my "Low-Rez Shadertoy: The Game" a go!

Write shaders in some made up assembly language, match your target, win prizes*

This is an alpha version and I'm looking for feedback. Please boost/share, thanks!

http://lrst-alpha.s3-website.eu-north-1.amazonaws.com/

LRST

@evilpaul_atebit It'd be cool if it showed you which level you're on while you're in the level? Unless that is somewhere and I'm missing it.

I only did the first 8 levels but doing World 2 level 4 in three instructions was very satisfying.

@JoshGrams @evilpaul_atebit I went to bed thinking any fewer than 5 was obviously impossible and woke up and banged out the 3-instruction version in like 2 minutes. so satisfying, yes.
@JoshGrams @evilpaul_atebit
Was "fewer than 22 instructions" meant to be "fewer than 12 instructions"?
@jcreed @evilpaul_atebit Yeah, I wondered that too, because my first working try was 10 instructions.
@JoshGrams @evilpaul_atebit yeah, I was gonna say, I bet I could shave one more instruction off my solution

@jcreed @evilpaul_atebit Yeah, I'm still parsing yours. What I did was... for the stripes, since you need the 2 bit and the colors are 2 apart:

add r1,#1,r2
and r2,#2,r2
add r2,#5,r2 ; 5 or 7

Then center the x coordinate:

sub #31,r0,r0
sub.mi #-1,r0,r0

Triangularize the y coordinate:

sub #31,r1,r7
sub.mi #63,r1,r1

Stick them together and choose blue or stripes:

sub r0,r1,r0
mov.gt #1,r0
mov.le r2,r0

@JoshGrams @evilpaul_atebit nice! I feel like par could be lowered on several other puzzles as well, e.g.
@JoshGrams @evilpaul_atebit what a great little game, though. What I wouldn't do for some SIMD instructions...
@jcreed @JoshGrams Thanks for the feedback! Do you have suggestions for how SIMD might work here?
@evilpaul_atebit @JoshGrams good question, I haven't thought too deeply about it, but just to throw an idea up: what if you could say something like rL to mean all registers r0...r3 uniformly, and rH to mean all registers r4...r7 uniformly, so that
"add rL, rH, rH" would mean
add r0, r4, r4
add r1, r5, r5
add r2, r6, r6
add r3, r7, r7
?
@evilpaul_atebit @JoshGrams I'm thinking this would allow tightening up of identical preprocessing that I do to the x and y coordinates, (and maybe it'd be fun to only introduce the instructions later in the game so that people can go back and revise their earlier naive sol'ns) but surely there's bound to be other sneaky uses of it I haven't thought of
@evilpaul_atebit oh man and if you haven't already made plans to do it, giving access to some character/font/texture lookup data (presumably only in later levels) so that you can do the kind of "text mode" animations that are already in the background of the title screen would be super fun

@jcreed I was thinking about this again recently, but I deliberately steered away from addressing modes other than register and direct because memory access "doesn't make sense" in my mental model of the hardware.

I can see how I could have pre-defined lookup tables (font, etc.) and something like `fetch index,dst` without breaking the model. Hmmm.. that could work

Maybe even a way (on later levels..) for the user to create the lookup tables

@evilpaul_atebit interesting, makes sense! good game design --- especially for this genre, which benefits I think from the architecture being "cute" and "small" enough to kind of fit in your head --- does require a lot of very careful saying "no" to the endless stream of possible additions
@jcreed My challenge now is to make enough interesting levels while keeping things fresh. I expect I'll need to introduce new features to do this
@evilpaul_atebit yep, that sure is the challenge... but I really do think you've got a great start here, best of luck! happy to take a crack at any future betas :)
@jcreed Thanks. I'll go away and think about my next steps now. Maybe I'll have another iteration in another month or two

@evilpaul_atebit oh, one more little idea of an option for how "texture memory" might be handled: you could assign one of the registers to be the index into texture memory, and another be the "value", i.e. if r7 is the "index" and rtex is the "value", then maybe like

and #7, r0, r0
and #7, r1, r1
asl r1, #3, r1
add r0, r1, r7
add #3510, r7, r7 ; 3510 = 65 'A' * 64 pixels per character?
mov rtex, r0

would draw a screen full of 8x8 'A' characters?

@jcreed Oh damn it.. I want to go and try this now but I have more important stuff to do first :D
@jcreed ...and `and #7,rL,rL` would shave off an instruction..
@evilpaul_atebit actually although I proposed above having a single combined register for x and y, on second thought it seems much more in line with your existing design to just use (x=r0, y=r1) (or alternatively x=r4,y=r5? for simd?) for indexing into the "texture image". that way just
mov rtex, r0
would copy the input image to output, and maybe you could have puzzles about transforming various input images in various ways?
@jcreed Think I will go for `FETCH [Rn|#],[Rn|#],[Rn]` so that you can choose the x/y source registers. I really like the idea of puzzles about transforming input images.
@evilpaul_atebit cool, that certainly works. excited to see where this goes...