Has anyone tried the new version yet except Technomonkey?

*semi-urgent bump*

I have found that storing a byte to (tempSwapArea) causes the calc to sometimes crash. Could someone please verify my hypothesis?

Edit: I've moved the enemy array from L3 to L1, so now I can make Falcon grayscale! Should I make grayscale sprites? A grayscale background?

I'm afraid that I haven't tried it yet; I shall do so soon. Can you give us the exact hex equate for (tempSwapArea)? My main concern with grayscale would be slowing it down too much, since you said it was already on the edge of being not the fastest?

Well, grayscale wouldn't slow it down too much, but I will probably have an option to turn grayscale on and off. Also, tempSwapArea is 82A5h.

Specifically:
Code:
Therefore it's 838D-82A5 = $E8 = 232 bytes. Are you using more than that?

I'm using only one byte. :/

Ah. Well, that seems to be used when the calculator is doing things with archive; can you clarify in what circumstances the calculator crashes? Or is there no discernible pattern?

There isn't any pattern, but once I got an ERR:Archived after quitting, and my calc turned off and wouldn't turn on again. Under a shell, it sometimes causes a RAM clear.

Hmmm, I'm not sure what to say. Surely for a single byte there are other safeRAM areas where you could put it?

What's the Axe equivalent of tempSwapArea (L1, L2, etc.)? edit: Ok, it's L4. Yeah, unless you're archiving/unarchiving within your program it shouldn't affect anything. Although I could see shells having issues with it. Maybe use L5 (textShadow) or $8000 (appData) instead if L1 (saveSScreen) and L2 (statVars) are already taken.

Also, grayscale actually will make your game faster by about 15000 T-states. It's something of an anomaly of Axe that DispGraph^r is faster than DispGraph. The extra cycles spent drawing the grayscale layers of the sprites might eat into that though

SquidgetX, graphscale drawing happens constantly from an interrupt, while normal drawing happens once inline; could that be the reason for the abnormality that you're quoting?

Axe's grayscale doesn't use interrupts; if you call it once a very slow loop, you will easily be able to see the checker-patterns.

Actually, I've found that a grayscale Falcon would be a PITA to program and play, so I've reverted to the older version and I am currently making a title screen.

Well, put a ClrDraw^r at the beginning of your program (that is, if you're not using L3 for data), and use DispGraph^r instead of DispGraph. Congratulations, you just saved 15000 cycles. (At the cost of around 10 bytes).

Also (I was looking through the source) always put constants last in expressions:
Code:
to
Code:
. Additionally, all single value equality checks can be optimized as follows:
Code:
to
Code:

Ah, I didn't know that, thanks for telling me. I suppose that's good for grayscale CALCnet 2.2 games in Axe.