The Optimization Compilation

[Runer112]

I'm a little confused... I'm not sure in what context you would be switching clock speeds. And by a compatibility mode, do you mean the fact that the DispGraph routine waits for the screen driver to say that it's ready? I'm a bit confused about that because calling it a compatibility "mode" would suggest that there's something you can just turn on to automatically activate the safety.

But disregarding things I'm confused about, I do know that the two commands are close to the same speed speed, but because DispGraph^r avoids driver readiness checking, it is in fact faster than DispGraph at 6MHz. And you can't really compare them at 15MHz, because DispGraph^r doesn't work properly at that clock speed due to the lack of driver checking. Also, you don't need to store to the back buffer every frame for DispGraph^r, you can still display black and white images by just keeping the back buffer clear.

[Freyaday]

'Twould be something like
Normal
DispGraph^r
Full
The 6MHz clock setting is a compatability mode. And Axe checkerboards the grey areas in DispGraph^r.

[Runer112]

Oh, well I haven't tested it but I think that still might be slightly faster than DispGraph at 15MHz, not 100% sure though. It would certainly be closer. And as long as you keep the back buffer blank, using DispGraph^r would result in the same image put on the screen as DispGraph.


EDIT: Actually let me test this right now...


EDIT 2: The results are in! Data first, analysis after.

• [Normal speed] DispGraph^r: ~94 fps
• [Normal speed] DispGraph: ~76 fps
• [Full speed]      DispGraph: ~114 fps

At normal speed (6MHz), DispGraph^r is about 25% faster than DispGraph. However, with an interesting turn of events, at full speed (~16MHz on my calculator) the results are pretty much reversed, with DispGraph being about 20% faster than DispGraph^r. Now that I think of it, this makes sense. The DispGraph^r routine runs about as fast as data can be outputted to the LCD driver. At 6MHz, the DispGraph routine is incapable of running this fast, because the driver readiness check slows things down a good amount for each failed check. However, at 15/16MHz, the check will be running very quickly and should continue execution much more swiftly after the driver becomes ready, resulting in only a little bit of overhead from the checking. After the check is exited, the remainder of the loop will then execute very quickly as well, making up most of the lost overhead from checking by performing the remainder of the loop in less than half the normal time. On top of this, the rest of the routine, including setup and the loop that the data sending loop is inside of, will run more than twice as fast, explaining the switch in the speed placings.

[Freyaday]

Ta-Da! Counterintuitivity strikes again! But this is officially a lesson: Always double check. And make sure it's been single-checked, too.

[Darl181]

Ok, I have no idea what's going wrong with this...
I've been optimizing dimansion shift.  Thing is, the inData() trick always returns as true
It worked in a little test program I made, but as soon as I put it into the shift source, it bugs.

In the screenie of the source, the unoptimized yet working line is shown just above the commented buggy line.
No matter wha the value of {P+D} is, it always returns true, be it any number that appears in the level (any num from 0 to 11)

btw, I tried storing {P+D} to a var and substituted {P+D} for the var in the code, still the same problem...

[aeTIos]

uh, data(2,3,0) O.o?

[squidgetx]

That is indeed very strange...(btw aeTIos, the Data(2,3,0) is correct)

Perhaps it may be because {P+D}=0? If it is equal to 0, then the inData() routine will return 3 (which will read as true). You'll have to deal with the zero case separately.

[Darl181]

No matter what the value of {P+D} is, it always returns true, be it any number that appears in the level (any num from 0 to 11)

Even when it equaled, say, 8, it would return as true (is that the right way to say it btw) and draw a door.
(what this if statement is part of is the level drawing code, if this line is true then draw a door)

Hm..might the nested For() loops it's inside of have anything to do with it?
EDIT: actually nvm that, it did the same thing in the repeat loop

EDIT2: info axe version 053, running on an 84pbe running os2.43.  Has extra ram if that makes a diff

[Runer112]

I tested that exact inData() situation and got the expected result of 0. All I can think of is either P+D is pointing to the wrong place or {P+D} equals zero, which will throw off the inData() command.

Anyway, if you want to test if the value equals 2 or 3, you can test much more efficiently with the following code:

Code: Select All | Copy To Clipboard

1 2 3 4

!If {P+D}/2-1   .{P+D}=2 or 3 End

[Darl181]

I have something in place that works atm, but it seems wherever I use inData it does the same thing (doesn't work).  Just in that one program..

[calc84maniac]

In Axe 1.0.0, new compiler optimizations allow you to further optimize If statements comparing to single-byte constants!
Whereas before you would do something like !If A-7, now you can save a byte and 10 clock cycles by doing !If A xor 7

[shmibs]

=D i'm amazed that axe can just continually get faster like it has been for months now.

[Happybobjr]

don't forget about just *2

[squidgetx]

^^Sorry, what? Explain a little more, please

This is getting out-dated but I haven't used 1.0.5 enough to figure out all the auto opts and new opts that can be (ab)used

[Happybobjr]

just like....
0->A+1->B
is more optimized than
0->A
1->B
....
4->A * 2->B
is more optimized than
4->A
8->B

||||||||||||||||||||||||

also, i think 'number less than 256' /256 might be more efficient than just 0