EricBall's Tech Projects

I enjoy optimizing, but I hate having to optimize unexpectedly.

 

I feel your pain.

I enjoy optimizing, but I hate having to optimize unexpectedly.

 

I feel your pain.

Yeah. There's a difference between figuring out a better way to accomplish a small task (i.e. TJ's CMP #$80, ROR for a signed right shift). But realizing that you really need to find some way to squeeze a hundred bytes out of a K of code is kinda depressing.

I enjoy optimizing, but I hate having to optimize unexpectedly.

 

I feel your pain.

Yeah. There's a difference between figuring out a better way to accomplish a small task (i.e. TJ's CMP #$80, ROR for a signed right shift). But realizing that you really need to find some way to squeeze a hundred bytes out of a K of code is kinda depressing.

Speaking of squeezing >100 bytes out of 1k, take a look at the source for TJ's 1k minigames - chances are you'll learn something. Probably the most useful was the combined score digits trick. But there are lots of subtle things like a BRK subroutine trick, which further saves the byte after the BRK by doing DEC $FE, RTI to get back.

 

In my own minigames, other than doing some of TJ's tricks, I found that avoiding lookup tables in favor of pure calculation can save lots of space, though at the expense of cycles. And even when you've optimized the obvious, you can still find more savings. After a while your code does get heavily obfuscated, however.

After a while your code does get heavily obfuscated, however.

You can bet your life on that.

 

Still it is always somewhat rewarding when you find another byte in your already heavily optimized, obfuscated code.