I'm confused why that code is any different than the current code:

"A and B"
ld hl,(var_a)
ld de,(var_b)
ld a,l
and e
ld l,a

It returns 0 if its false and non-zero if its true as well, and its the same size.  Unless your optimization is a speed optimization?

And Ikkerens, that code has always worked.

That's not how "If" works.  X must have been 0 if it skipped the code.  This isn't something I've ever changed, its always been that true means non-zero and false means zero.

I just noticed that 'Sprites larger than 8x8' is still in this features list. Are the Bitmaps currently added not the thing you meant with this?

I just noticed that 'Sprites larger than 8x8' is still in this features list. Are the Bitmaps currently added not the thing you meant with this?

I believe they were added now. He probably just need to update the list. Keep in mind those bitmaps are slower than 8x8 sprites, though, since he uses a TI routine for them. If you need speed instead of size, I recommend using multiple 8x8 sprites instead

It's not incredibly slow. It's just a bit slower than regular ones. Bitmap uses a routine included in the TI OS, which means the code needed for it is not included in your Axe program, which is why your executable ends up slower. It's a BCall, I believe.

there's a fairly big chance that it is a ROM call I think, but I don't understand why it can't be used in BASIC then?

It's because there's no TI-Basic command for it. It's a routine intended for use in FlashApps and ASM programs.

I've got a feature request.

Would it be possible to make 'checkpoints' in the program editor and be able to jump between them using something like 2nd+Right/Left? Just wondering because my code is getting really long and it takes a while to scroll all the way to the bottom just to change 1 or 2 things before compiling again.

Also, for the Error scrolling, wouldn't it be better to scroll to 7 lines before the line with the error, so that it is at the bottom instead of the top? That's how the TIOS does it. I always have to scroll up to see what I wrote to cause the error.

Quote from: Ikkerens on June 22, 2010, 05:19:41 pm

1 more thing to the wishlist:
15Mhz GrayScale

Actually this isn't a  bad idea, as it *would* result in smaller compiled code and because we don't have the Full and Normals to make it slightly faster.   Can we please have this Quigibo?

The thing is, inside the display routines it would have to set 6MHz, run the code, and restore the previous clock speed. You really aren't saving space after all (especially if your code never sets Full in the first place).