Author Topic: Making Axe Applications  (Read 5995 times)

0 Members and 1 Guest are viewing this topic.

Offline mrmprog

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 559
  • Rating: +35/-1
    • View Profile
Re: Making Axe Applications
« Reply #15 on: September 24, 2011, 12:06:42 pm »
On a semi related topic: I heard somewhere that axe makes "Trial" apps that can only run a certian number if times. Is that still true?

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Making Axe Applications
« Reply #16 on: September 25, 2011, 04:04:56 am »
How did we get on the topic of #Realloc()? That has to do with changing where in memory the A-θ variables reference, not strings or MemKit. I meant you should use a different pointer argument for Print() that will result in the string being copied to RAM, since Str1 is a part of your application and cannot be written to. For example: Print(L₁).

Regarding appvars, unless you want data to persist between runs (like settings or high scores), I would try to use scratch RAM to hold your data whenever possible. As far as I know, you don't need this string to persist between runs and it's pretty small, at most 9 bytes, so it's probably easiest to use scratch RAM to hold it.
Oh... I was under the assumption that #Realloc() would cause the variables to be located in L₁ for modification. :P
So wait, if I do use Print(L₁), will I still be able to use regular variables?

(Or maybe I just don't get where the variables are/how do variables work/etc. :P)

The variables are stored at the END of L1, not the beginning.  Using the first 714 bytes of L1 is perfectly fine and encouraged.  Its only the last 54 bytes that are freed during #Realloc() to expand the L1 buffer to the full 768 bytes so it can be used as a screen buffer.  Hope that clears up your confusion.

Also, no, there is no such command as ->nib{}r since you cannot write to ROM pages.  The nib{}r command is ONLY for reading data from the app itself (your strings, sprites, data, etc).  If you are reading nibbles from appvars, free ram, or other ram variables, you STILL use the regular nib{} command even in an app.

As of 1.0.4, all apps generated by Axe Parser are non-trial :)
« Last Edit: September 25, 2011, 04:07:39 am by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2898
  • Rating: +467/-17
    • View Profile
    • TI-Boy CE
Re: Making Axe Applications
« Reply #17 on: September 25, 2011, 12:30:39 pm »
Also, no, there is no such command as ->nib{}r since you cannot write to ROM pages.
Oh whoops, my bad :P
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline epic7

  • Chopin!
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2200
  • Rating: +135/-8
  • I like robots
    • View Profile
Re: Making Axe Applications
« Reply #18 on: October 26, 2011, 10:21:24 pm »
1100 bytes is a lot? My games are simple and they are all more than 1100 bytes.

Offline LincolnB

  • Check It Out Now
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1115
  • Rating: +125/-4
  • By Hackers For Hackers
    • View Profile
Re: Making Axe Applications
« Reply #19 on: October 26, 2011, 10:28:20 pm »
1100 bytes is a lot when it's just data.
Completed Projects:
   >> Spacky Emprise   >> Spacky 2 - Beta   >> Fantastic Sam
   >> An Exercise In Futility   >> GeoCore

My Current Projects:

Projects in Development:
In Medias Res - Contest Entry

Talk to me if you need help with Axe coding.


Spoiler For Bragging Rights:
Not much yet, hopefully this section will grow soon with time (and more contests)