Quote from: Runer112 on January 15, 2014, 09:03:21 pm

(A) While a full-screen update on the non-color calculators takes about 1/100th of a second and almost everything that uses it relies on it being fast, a full-screen update on the color calcs takes about 1/5th of a second

Yeah but we could cheat with some frameskip and with the double-pixel trick. Moreover, some coders (like matref and I, or Builderboy and others) still have the possibility to trigger the 15MHz mode to get more speed on the CSE without losing any compatibility this time, so our programs of course will have speed issues, but also some speed gains.
Also that depends on the program you are porting because I don't think AudaciTI will have too much issues with refreshing since nothing happens on the screen except menus

Unfortunately, these points are not really valid. The ~5Hz screen update rate I cited is with 15MHz mode enabled already. If you tried frameskip, considering most non-color games probably run at 20-60fps, you'd be skipping anywhere from 75% to 90% of frames, which is very poor. And finally, it doesn't really matter how few differences there are between frames, because DispGraph has always been a full-frame resend command and can't really be modified to (efficiently) perform incremental updates.

So with an 8 by 8 sprite you use Pt-Change() to draw it inverted. How do you do that with a 16 by 16?

Since Axe doesn't have any 16x16 sprite routines (at least as far as I could tell according to the official documentation), you have to do it by drawing four 8x8 sprites. So if Pic1 is the top-left corner of the 16x16 sprite, Pic1+8 is the top-right, +16 the bottom-left, and +24 the bottom-right, then you'd want to do something like this (assuming drawing to X,Y):
Pt-Change(X,Y,Pic1)
Pt-Change(X+8,Y,Pic1+8)
Pt-Change(X,Y+8,Pic1+16)
Pt-Change(X+8,Y+8,Pic1+24)

Choose a pointer to a safe RAM area with a length of two bytes or more, for example L1, then do L1→°Lolwat. Now Lolwat is a variable you can use. You can also do L1+2→°Wattouat or [0000]→°Meh. The last solution is not a good idea since it will trigger writeback and won't work in apps, but if you already use all safe RAM areas, you might want to do this.

there is two version of min/max :

one unsigned :

min(0,-1) .return 0 (0<65535)
max(-1,0) .return -1

and one signed (with the r modifier):

min(-1,5)r   .return -1
max(-8,9)r  .return 9


I'm writing an axiom and want to put the address of a function of the axiom in a variable. Currently what I do is : .db REP_ABS
 .org $-1
 ld hl, sub_axiom10
 ld (someVar), hlBut it doesn't seem to work : when in the Axe code I replace somevar by the axiom function itself it works. I have REP_ABS = $49. What am I doing wrong ?

EDIT : solved on IRC, I had to use REP_NEXT ($7F). I thought I tried it already.

Does using #ExprOn in a program affect axiom too ?
I mean, if an axiom use the axe multiplication and the program calling axiom command have #ExprOn, does the multiplication will be optimize for speed too ?

That's a good question... Honestly, I'm not sure. If I had to guess, I'd say that because of how Axioms are parsed, it would depend on the optimization state at the end of the main source program. Either that, or it simply ignores the optimization state (although if you use multiplication yourself in a speed-optimized block, that should force the Axiom to as well).

Isn't there a way to,simply call sub_mulFast instead of sub_mul ? Apparently axioms always compile in #ExprOff mode, no matter what the state of optimization is when they are parsed.

No, Axioms can't explicitly call the fast version of the command. And yes, a quick test seems to suggest that subroutines referenced by Axioms will default to the slow version. However, it also seems that my suspicion that using a native Axe command that calls the underlying subroutine in an #ExprOn section somewhere does result in the Axiom referencing the fast version, so I guess having a dummy call in the Axe source to a command that uses the underlying subroutine would be a workaround.

I'm not sure if this is a problem that is reasonably fixable, but I'll look into a more permanent solution.

I'm making a new game and need to make the attached picture into a giant bitmap for my Axe source. Is there any way to do this that won't take me an hour?