Author Topic: Axe Parser (Read 495020 times)

Builderboy · « **Reply #450 on:** April 17, 2010, 01:16:13 am »

Hey I was wondering, if you are usig memory locations as variables, is it any faster to say A than {L1+12}? Because I have already run out of variables in Portal and I have had to seep into memory locations.

Quigibo · « **Reply #451 on:** April 17, 2010, 03:08:04 am »

No. In fact the variables A-Z really are memory locations located between {L1-52} and {L1-2} or something like that I think. It just does all the behind the scenes work for you when you use the letters.

However, even though they should be as fast, they won't be just becasue I haven't done the hardcore precompile optimizations yet and probably won't for a long time. I doubt you'll notice the difference though, it just means that when you do {L1+12} like you say, it adds the 12 during execution. Arithmetic is super fast though, so don't worry about it.

By the way, I'm thinking of adding a new unsigned division routine for division of constants less than 256. It would be almost twice as fast and twice as small as regular division. The drawback is that now you'll be calling 2 separate subroutines for long division (division by variables and constants greater than 256) and short division (by constants less than 256). If you have to use both in the same program, we're only talking about 15 extra bytes total so its worth it in my opinion.

Raylin · « **Reply #452 on:** April 17, 2010, 08:10:34 am »

^++
Agreed and seconded.

Also, are you going to fix the DispGraph(r) command in this update?
I'd like to use it.

DJ Omnimaga · « **Reply #453 on:** April 17, 2010, 12:16:47 pm »

That would be nice Quigibo. ^^

Quigibo · « **Reply #454 on:** April 17, 2010, 12:28:05 pm »

I've already fixed the DispGraph command. But I might have to fix it more. It looks fine in 6MHz mode, but its pretty grainy in 15MHz mode. If I change the pause times, the opposite happens... I might have to make it adjust dynamically so both cases look good.

DJ Omnimaga · « **Reply #455 on:** April 17, 2010, 01:03:51 pm »

i think it might be best to have it so it is based on the calc model the game runs on. In future versions of Axe, Maybe also allow a command for use in Axe programs option menus so the user can manually alter the delays between grayscale updates, since not all calcs have the same grayscale quality at the same levels. Even two 83+ calcs could have different quality between each others.

jsj795 · « **Reply #456 on:** April 17, 2010, 01:53:57 pm »

Quote from: DJ Omnimaga on April 17, 2010, 01:03:51 pm

Even two 83+ calcs could have different quality between each others.

Is it because of difference in hardware? Did TI change the hardware during the production of TI83+ just like what they did with the extra ram page in TI84+SE? Anyways, good luck on fixing the greyscale, Quigibo!

DJ Omnimaga · « **Reply #457 on:** April 17, 2010, 02:03:55 pm »

I think it's more the LCD. Sometimes, a LCD may not exactly be the same speed as another, for productions reason. Same for the calc processor. Some 84 calcs reports speed of 15.1 MHz instead of 15, for instance. It's like when you buy two identical watches. One may go at a slightly different speed

Quigibo · « **Reply #458 on:** April 17, 2010, 02:26:44 pm »

I think the hardware is pretty reliable for the most part. It's mainly the delay routine I'm using should delay a different amount of time if the calc is in each speed setting. Currently it does an empty loop until the LCD driver is ready and then it writes the pixel. I'll figure it out though.

DJ Omnimaga · « **Reply #459 on:** April 17, 2010, 02:28:55 pm »

Aaah ok. I wonder if automatic grayscale commands will slow down program execution a lot? I don't think grayscale quality needs to be perfect, though. As long as it wont flickers horribly.

Quigibo · « **Reply #460 on:** April 17, 2010, 02:38:20 pm »

You're talking to a perfectionist here

But not necessarily next release, I can always tweak it more later, as long as the final version is perfect gray.

Also, I forgot to mention, the only routines I was able to outsource to the shells so far were all the pixel routines. They certainly cut down on the program size! But unfortunately, the shell calls are slower becasue they are not as optimized as the routines I'm using. Its a small difference, but definitely noticeable in the Game of Life program. There's nothing I can do about that though...

DJ Omnimaga · « **Reply #461 on:** April 17, 2010, 02:42:52 pm »

Will there be the option to not outsource to specific shell routines in later versions? Or will creating a program for Mirage for example automatically make it use that shell's routines?

Quigibo · « **Reply #462 on:** April 18, 2010, 02:41:50 am »

Hmm... I don't know. Is that an option you would like? I think generally, you won't notice the slowdowns unless you use the same routine over and over for practically the entire program (Like my Game Of Life example).

DJ Omnimaga · « **Reply #463 on:** April 18, 2010, 04:18:28 am »

Well I guess if the speed difference is not that big, then disregard my comment. I was just worried about if somebody needed every single clock cycles he can get in some sort of complex game that it could cause issues.

I want to make World of Warcraft in Axe Parser!

j/k I don't even play WoW.

Quigibo · « **Reply #464 on:** April 19, 2010, 02:23:48 am »

*Update*

Finally! I have moved from alpha to beta release. If you don't upgrade regularly, I would definitely recommend upgrading now since I really improved the user friendliness of it instead of just adding commands this time. Enjoy!

Author Topic: Axe Parser (Read 495020 times)

Builderboy

Re: Axe Parser

Quigibo

Re: Axe Parser

Raylin

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

jsj795

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser