To rotate 3 bytes pointed to by hl one bit to the left, I think this is the fastest way it can be done:

13 bytes, 79 cycles
Axe: Asm(7E872323CB162BCB162BCE0077)
Source:
ld a,(hl)
add a,a
inc hl
inc hl
rl (hl)
dec hl
rl (hl)
dec hl
adc a,0
ld (hl),a

I assume you may want rotation to the right as well:

12 bytes, 80 cycles
Axe: Asm(7E1F23CB1E23CB1E2B2BCB1E)
Source:
ld a,(hl)
rra
inc hl
rr (hl)
inc hl
rr (hl)
dec hl
dec hl
rr (hl)


And for what it's worth, your code was already pretty close to mine in terms of speed; 102 cycles for yours versus 79/80 cycles for mine.

If you plan on using these code snippets a lot, it may be a good idea to put them in a subroutine and calling it each time you need it, which would save you 10/9 bytes, at the cost of 27 cycles, for each use.

A prefix version of ++ and -- that returns the in/decremented value instead of the previous one.

As of now, the ++ and -- operators don't actually have defined return values. Technically, any code that does currently use their return values is a hack, and would no longer work if ++ and -- were properly implemented. There are numerous programs that take advantage of the current implementation, and I don't want to break them, at least not for the moment.

I believe the main reason ++ and -- were never set up to properly return the new/old value exactly is for optimization reasons. If they were all fully implemented, VAR++ would be 1 byte larger, VAR^r++ and {EXPR}++ would be 4 bytes larger, and {EXPR}^r++ would be 3 bytes larger. And it's not uncommon that the return value isn't actually needed, so those would be wasted bytes. It was kept in mind that programmers could use the "undefined" return values to get the real return values if they wanted them. For the first two cases, which I believe are the most common, it actually costs the programmer nothing to do this; the assembly implementations would be the same as VAR++-1 for the first and {VAR^r++}-1 and {{EXPR}++}-1 for the second (pre-increment would be the same as well, just without the -1's). It does get a little hairy with the two-byte pointed increment/decrement, though.

Don't get me wrong, I do eventually want real ++ and -- implementation. However, I would like to save it for when Axe has a more powerful optimizer and can intelligently see if the return value is actually used, and then decide whether to use the smaller undefined return value code or the larger defined return value code.

Can the fill( function be auto opted when the byte it should fill with is a predetermined constant?
And can it be optimised even further if the size is less than 256?
I think it would look like this:
0<size<256:
bytesize: 7
ld b,*
ld(hl),*
inc hl
djnz -5

size>=256
bytesize: 15
xor a
ld bc,**
ld(hl),*
inc hl
djnz -5
ld b,255
dec c
cp c
jr z,-11

and I think the current code has a size of 18 bytes.
I don't know if the code I gave is as optimised as it can be (nor have I tested it yet), but it is smaller.

Fill is absolutely a command I'd like to optimize, and I like your ideas. But on a note related to my response to Freyaday above, Axe's optimizer is unfortunately too simple at the moment to allow for such optimizations. It doesn't provide for any way to supply optimized versions of multiple-input functions for which some set of the inputs are constants.

When Axe gets a more powerful optimization engine, I certainly would like to see things like this added.

---

I think I'm seeing a theme here...

I expect Cadan v2 to support the bullet patterns and quantities detailed in the attached gif.

Where are the individual files located (in relation to each other)? If each one is called noob, they would have to be in different folders and I imagine that it isn't easy for multi-file renaming tools to handle files scattered across different folders.

EDIT: I did a quick web search. This article and this one seem to be fairly promising for finding an easy solution to your problem (if there is one).

Out of curiosity, could you post the source of that plasma program? I'd be interested to look at it, I like Axe programs that do manual graphics rendering.
















I'm certainly not asking because I want to try to optimize it to hell >.>

I thought you had a scrolling tilemapper working? That should handle most of the general code and the movement. To place/remove tiles, just change the value of the tile byte in the tilemap that you want to replace. As for changing size (I assume you mean size of tiles), I wouldn't really even recommend doing so, at least until you fully understand how the tilemapping engine works and can write your own.

I believe the primary issue is that your phone produces mp4 files, not gif files. I'd save taking screenshots for when you have access to a computer and an emulator that is capable of gif recording.