Author Topic: Axe Parser (Read 564824 times)

Quigibo · « **Reply #870 on:** June 22, 2010, 08:58:13 pm »

I was about to encourage you to learn it alongside BASIC, or as an alternative, but then I remembered I don't really have any comprehensive tutorials yet, just a simple one that already assumes you know BASIC. I really should update my tutorial one day and expand it to be actually complete, I just haven't had time unfortunately. The amount I'd have to write seems really overwhelming to me $:-\$

DJ Omnimaga · « **Reply #871 on:** June 23, 2010, 12:14:21 am »

One question: is it true that Getkey(0) and getkey doesn't work in WabbitEmu? I think I remember Player1537 having issues with it in his RPG entry, when he made the screenshot, and I recall having issues with my Tunnel game as well, where it just seemed to ignore those

Runer112 · « **Reply #872 on:** June 23, 2010, 12:18:15 am »

Both work just fine for me, DJ Omnimaga.

DJ Omnimaga · « **Reply #873 on:** June 23, 2010, 12:20:29 am »

Weird

Maybe it is specific to computer hardware and what version of wabbit you use. I think there is a regular version and a .NET one. I forgot which one is the best.

At least the positive thing is that it works well on calc. That's what matters

DJ Omnimaga · « **Reply #874 on:** June 24, 2010, 11:46:56 pm »

Question about L1/SaveSScreen:

If the data in this is modified, will the calc mess up on the next Auto Power Down/APD?

I am wondering because I just saw this: http://wikiti.brandonw.net/index.php?title=83Plus:RAM:86EC

Quote

Before using for data storage, ensure that the calculator will not APD™ by disabling it with B_CALL DisableApd.

calc84maniac · « **Reply #875 on:** June 25, 2010, 01:56:30 am »

Quote from: DJ Omnimaga on June 24, 2010, 11:46:56 pm

Question about L1/SaveSScreen:

If the data in this is modified, will the calc mess up on the next Auto Power Down/APD?

I am wondering because I just saw this: http://wikiti.brandonw.net/index.php?title=83Plus:RAM:86EC

Quote
Before using for data storage, ensure that the calculator will not APD™ by disabling it with B_CALL DisableApd.

Nope. What happens is that when it APDs, the current data on the LCD is put into savesscreen, and then when it powers up, savesscreen is copied back into the LCD. A side effect of this is that any of your own data that was in savesscreen will be overwritten.

DJ Omnimaga · « **Reply #876 on:** June 25, 2010, 02:16:59 am »

Aaah ok, thanks for the info. I should be safe, then.

cooliojazz · « **Reply #877 on:** June 25, 2010, 01:56:52 pm »

I have a question. I have a routine thats always drawing 13x8 sprites on the screen. It moves in half tiles, so its either drawing one whole tile off the screen, or drawing two half tiles. Now, whenever it draws the half tiles it slows down a LOT. Why would this be, cause when it draws the 13th normally, it doesnt take any time since its off screen, or cause its having issues drawing it half on the screen, or what? (And I checked my code, nothing but the drawing changes when it shifts)

Quigibo · « **Reply #878 on:** June 25, 2010, 02:13:39 pm »

That's just becasue the sprite has to be shifted before it can be drawn when it is not aligned with the grid on the LCD ram. The effect is most noticeable with Pt-Off() becasue that routine is particularly fast when its aligned and particularly slow when its not. There really isn't much you can do, other than add more pauses when the grid is aligned. This only applies to horizontal alignment by the way, not vertical so something along the lines of "!If X^8" would detect the alignment.

cooliojazz · « **Reply #879 on:** June 25, 2010, 02:15:54 pm »

Ahh, ok, makes sense, thanks for that. Grr, I'll just have to see how i can work around that...

DJ Omnimaga · « **Reply #880 on:** June 25, 2010, 06:17:23 pm »

Darn I didn't realize I would have to deal with this problem

. I hope the slowdowns aren't too drastic

EDIT: nvm. The program I have already sometimes does that. The slow down is not that bad, altough it is a bit noticeable.

It is kinda bad if you need to draw an entire tilemapper every frame, though.

DJ Omnimaga · « **Reply #881 on:** June 26, 2010, 12:50:03 am »

Question:

Is

{L1+44}+C->{L1+44}

faster than

F+C->F

?

I am wondering since the former uses 16 bit numbers while the later uses 8 bit

Deep Toaster · « **Reply #882 on:** June 26, 2010, 01:08:57 am »

I think you mean the latter is 16 bit and the former is 8.

And do I see a double-post by DJ

Or did someone delete a post?

I can't answer that question (sorry), but I have a related question that someone could answer along with his: Is there any way to get 16-bit signed numbers, like int(L₁)^r (which doesn't work, by the way)?

Quigibo · « **Reply #883 on:** June 26, 2010, 01:10:14 am »

No, its ever so slightly slower since it has to convert the 8 bit number into a 16 bit number (since C is a 16 bit number) in order to do the addition and then convert it back again to an 8 bit number. The fact that its 3 bytes larger I think? is the greater concern than the speed though. Its actually an optimization if you can store all your variables with constant addresses as 16-bit variables if you have enough ram. Variable addresses however ARE more optimized as 8 bit than as 16 bit.

DJ Omnimaga · « **Reply #884 on:** June 26, 2010, 01:17:30 am »

Quote from: Deep Thought on June 26, 2010, 01:08:57 am

I think you mean the latter is 16 bit and the former is 8.

And do I see a double-post by DJ Or did someone delete a post?

I can't answer that question (sorry), but I have a related question that someone could answer along with his: Is there any way to get 16-bit signed numbers, like int(L₁)^r (which doesn't work, by the way)?

oh right yeah, my mistake

. As for the double-post, there were 6 hours between both posts, so I am within the rules

Quote from: Quigibo on June 26, 2010, 01:10:14 am

No, its ever so slightly slower since it has to convert the 8 bit number into a 16 bit number (since C is a 16 bit number) in order to do the addition and then convert it back again to an 8 bit number. The fact that its 3 bytes larger I think? is the greater concern than the speed though. Its actually an optimization if you can store all your variables with constant addresses as 16-bit variables if you have enough ram. Variable addresses however ARE more optimized as 8 bit than as 16 bit.

Oh right I forgot about the fact variables remain 2 bytes and have to be converted when using inside addresses

. MY bad. I guess I'll need to be careful to what I choose depending of if speed is really a huge concern or not.

Author Topic: Axe Parser (Read 564824 times)

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Runer112

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

calc84maniac

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

cooliojazz

Re: Axe Parser

Quigibo

Re: Axe Parser

cooliojazz

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Deep Toaster

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser