0 Members and 2 Guests are viewing this topic.
I think what he means is a replacement routine, where instead of calling the subroutine, the code is inserted inline. I'd like to see that implemented somehow (maybe parsing from the label until a Return is encountered).
In other news, Frey continues kicking unprecedented levels of ass.
Although a ++ command could definitely be useful to intense optimizers like myself, I don't think the command should be added due to confusion it may cause. These are the two major sources of confusion I would foresee:It's only an 8-bit math command, whereas every other math command is 16-bit. And unless the user knows the underlying machine code, I would imagine that they would think something as simple as addition of 1 could easily be performed on a 16-bit value.The result of the addition isn't returned in hl. {B+L1}+1 and {B+L1}++ would return an entirely different value, despite only having one slight difference in the mathematical operator that comes after what would appear to be a value fetch. In my mind, this is by far the stronger reason of the two as to why this operator could cause confusion.
Ability to change mem outside of the buffers, and have horizontal/vertical move those pixels in or out. I thin it was there before (listed as garbage pixels) but it should probably just be a fix/option, to avoid incompatibilities. Also, sprites overlapping the screen should draw to that area correctly.
Fix 3Fix 1Text(0,0,"HELLO WORLDFix 0Fix 2
Fix 3,1Text(0,0,"HELLO WORLDFix 0,2
That would be awesome!
It is if, like me, you tend to use a lot of Fix es.
Quote from: Freyaday on April 20, 2011, 09:43:39 amIt is if, like me, you tend to use a lot of Fix es.I don't think it's really worth it to add that, because it's only a small source-code convenience. It has no effect on the compiled program.