Author Topic: Axe Parser (Read 564944 times)

Quigibo · « **Reply #510 on:** April 25, 2010, 01:11:07 am »

All static pointers are distinct. Even Str1 and Str01 are not the same. GetCalc currently only works for appvars and programs so graph database files can not be read.

You can kind of get the Nth data pointer if all the data is the same size and declared consecutively. If you have:
:[C0FFEE]->Str0
:[DECAFF]->Str1
:[CAFE00]->Str2

You can get the Nth pointer here by doing "N*3+Str0"

There is another way to get the Nth arbitrary pointer (not consecutive not the same size) but its a little more complicated and involves pointers to pointers.

Eeems · « **Reply #511 on:** April 25, 2010, 01:15:21 am »

GDB0 and GDB10 are two separate pointers. It doesn't use the OS for this so it doesn't use the OS's silly rules about that.
EDIT: Ninja'd

Runer112 · « **Reply #512 on:** April 25, 2010, 01:19:01 am »

Quote from: Quigibo on April 25, 2010, 01:11:07 am

There is another way to get the Nth arbitrary pointer (not consecutive not the same size) but its a little more complicated and involves pointers to pointers.

Want to clarify for me? Because all my data sets are of different sizes

Quigibo · « **Reply #513 on:** April 25, 2010, 01:31:00 am »

Sure, lets say you have 10 blocks of data:

[Data Block 0]->Str0
[Data Block 1]
[Data Block 2]
...
[Data Block 9]

You then make an array with the cumulative sizes for each block like this:

dList(0,size of block 0,total size of blocks 0 to 1,total size of blocks 0 to 2, ... )->GDB1

These should all be 2 byte numbers so end them all with the "r" modifier.

Now, lets say you want the pointer to the Nth block of data, you can get it by doing:

Str0+{N*2+GDB1}^r

So if you want the 3rd byte of the 4th block of data, you could do:

{2+Str0+{6+GDB1}^r}

Runer112 · « **Reply #514 on:** April 25, 2010, 01:38:07 am »

Ok that looks pretty good. Just checking, though, this is a lot of data: 50 blocks totaling almost 10KB. Is it possible/safe to add all this data to just one reference?

EDIT: And while we're on the topic of large amounts of level data (this is data for 50 levels), storing all 50 levels in RAM is obviously not the best way to go. I'll probably end up putting this all into an archived AppVar (or program?), but then the question becomes: How do you extract only one level at a time?

meishe91 · « **Reply #515 on:** April 25, 2010, 01:43:13 am »

Quote from: Runer112 on April 25, 2010, 01:03:03 am

Yeah I'm used to forums where double-posting is just fine, so sometimes I don't think to check here. But once I look down at my post(s) and see two in a row I instantly realize

But anyways...

Quote from: meishe91 on April 25, 2010, 12:50:40 am
For the GDB# thing. I don't think there is a GDB10, only GDB0 to GDB9. Could be wrong though, please correct me if I'm wrong.

From the documentation:

Quote
Another thing is that Axe allows you to name everything with up to 2 numbers/letters instead of just a single number. The following are all valid names:
Str1
Pic0
GDB4 Str1A
Pic9Z
GDB45 Str66
Pic8C
GDB3X

Ah ok, I wasn't aware you could add a second character in Axe to those.

And at that point if it was in an AppVars then that is where GetCalc( comes in handy, I believe.

Quigibo · « **Reply #516 on:** April 25, 2010, 01:48:09 am »

It should be as long as all the data is one after the other, but be careful with the size counting! I think the limit to program sizes is 16k though or something just becasue of the way the RAM is works. What are you doing that uses that much memory? Is it picture files or something? And how is the parser working by the way, I haven't actually tried it with that much data before.

EDIT: As for individual levels at a time, there really isn't an easy way to do that. You could split the level data into more than one appvar maybe. Also, you can get more room in the ram if you have the program archive itself at the start (doesn't affect the copy of the program that is actually running).

Runer112 · « **Reply #517 on:** April 25, 2010, 01:58:11 am »

The parser seems to be handling the large amounts of data just fine. It takes a second or two to get through it all but it works.

And you were wondering what the data is?

Quote from: Runer112 on April 24, 2010, 06:37:25 pm

I was wondering Quigibo because I plan on making a project in which tiles will appear in groups of 16 at a time, with each tile being either white or black.

16 bits (2 bytes) * ~50-100 tile groups per level * 50 levels = ~5-10KB

DJ Omnimaga · « **Reply #518 on:** April 25, 2010, 02:02:34 am »

Just a head up: backup often before testing! If you're doing it already, fine, but else, you take big risks when testing your stuff (a crash occurs and all your stuff is gone).

I'm saying this often lately, especially to newer members or people starting a new project in a new language or new libs, because on the old Omnimaga forums I saw too many cases of projects dying due to data loss and the author giving up.

Quigibo · « **Reply #519 on:** April 25, 2010, 06:42:52 pm »

Hope everyone likes the new update!

I had a bad experience when I accidentally did drawing off-screen. I couldn't get the calculator to ram clear and removing the batteries wasn't helping either. I had to actually unscrew the case and remove the little button cell battery to unfreeze the calc. Anyway, I don't want that to happen to anybody else, so I added a little check when drawing pixels. Its only 6 more bytes total and any slowdown is negligible compared to the entire routine. It also allows you to clip lines off the right and bottom sides of the screen if they overextend.

Builderboy · « **Reply #520 on:** April 25, 2010, 07:34:47 pm »

its 6 bytes per program, not six bytes per call correct? Or else that would be very significant

yayyyy line routine! This is one i have been waiting for a while, glad its finally in

and signed division yaayyyyy! Haha now to go through and re-optimise some of the code i have

Quigibo · « **Reply #521 on:** April 25, 2010, 11:13:02 pm »

Quote from: Builderboy on April 25, 2010, 07:34:47 pm

its 6 bytes per program, not six bytes per call correct? Or else that would be very significant yayyyy line routine! This is one i have been waiting for a while, glad its finally in and signed division yaayyyyy! Haha now to go through and re-optimise some of the code i have

Yes, for the entire program. Glad you like the update

DJ Omnimaga · « **Reply #522 on:** April 25, 2010, 11:20:49 pm »

Wow awesome! I'm happy to finally see Line support! This will be very useful for drawing game menus, because I don't always want to have to draw borders using sprites.

Keep up the good work!

DJ Omnimaga · « **Reply #523 on:** April 30, 2010, 09:42:16 am »

wow ticalc stats epic failed again

Axe currently has 39 downloads and 11 in the past 7 days.

Wasn't it over 80 for both?

mapar007 · « **Reply #524 on:** April 30, 2010, 12:00:31 pm »

Ticalc must have magic-transferred some stats to me. I suddenly get 100 downloads/week...

Author Topic: Axe Parser (Read 564944 times)

Quigibo

Re: Axe Parser

Eeems

Re: Axe Parser

Runer112

Re: Axe Parser

Quigibo

Re: Axe Parser

Runer112

Re: Axe Parser

meishe91

Re: Axe Parser

Quigibo

Re: Axe Parser

Runer112

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser

Builderboy

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

mapar007

Re: Axe Parser