Author Topic: More dynamic variables?  (Read 7678 times)

0 Members and 1 Guest are viewing this topic.

Offline johnbchron

  • LV2 Member (Next: 40)
  • **
  • Posts: 33
  • Rating: +1/-0
  • RiskALungForDiving
    • View Profile
More dynamic variables?
« on: March 13, 2018, 02:06:35 pm »
So I work in Axe, obviously (otherwise I would have put this in basic or some other topic), and I want to make large games. The main limitation I run into most of the time is that I don't seem to have enough non-final -- or for lack of a better word, dynamic -- variables. Does anybody have any ideas/solutions to this problem? I already know about A-Z, theta, and r1-r6, but are there any that I don't know of? Nobody else seems to have this problem.
Just a dude who is really bored in school... and a huge nerd.
Click here to give me an internet!
 <a href="http://www.freebiebitcoin.com">Earn free bitcoin</a>

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: More dynamic variables?
« Reply #1 on: March 13, 2018, 02:30:31 pm »
A lot of people use the areas pointed to by L1~L6 to store additional data. If even those don't suffice (that's a lot of RAM) you could make a buffer/array stored in your program and store the data there, or for a really complicated method, create a temporary OS variable of whatever size you need  and store the data there.

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: More dynamic variables?
« Reply #2 on: March 14, 2018, 06:03:37 am »
Xeda pretty much summed it up.
Note that I would not recommend creating buffers within your program, as most shells will write that data back to the actual program file and to archive when the program exits. That is in most cases not desirable: saving temporary data that you will erase later is wasteful, and you could end up with unpredictable initial state in your program because of that. In some cases you might want to use this for saving the game, but it's just better to make your own appvar for that.

Offline Sorunome

  • Fox Fox Fox Fox Fox Fox Fox!
  • Support Staff
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 7920
  • Rating: +374/-13
  • Derpy Hooves
    • View Profile
    • My website! (You might lose the game)
Re: More dynamic variables?
« Reply #3 on: March 14, 2018, 11:13:56 am »
[...]
That is in most cases not desirable: saving temporary data that you will erase later is wasteful, and you could end up with unpredictable initial state in your program because of that.
[...]
Hmmm couldn't you solve that in theory by clearing your temp. areas upon program start and upon program exit?

THE GAME
Also, check out my website
If OmnomIRC is screwed up, blame me!
Click here to give me an internet!

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: More dynamic variables?
« Reply #4 on: March 14, 2018, 11:44:28 am »
Yeah, that would actually work. It's still less efficient for the reason that it is taking up unnecessary memory, though.

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: More dynamic variables?
« Reply #5 on: March 14, 2018, 02:25:55 pm »
And that's extra effort. Though there is probably a performance advantage to accessing that data through statically computed pointers than from an unpredictable memory area. You shouldn't need to do anything at the start of the program either, just reset those arrays before exiting.

Offline c4ooo

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 252
  • Rating: +10/-1
  • The impossible chemical compound.
    • View Profile
Re: More dynamic variables?
« Reply #6 on: March 17, 2018, 03:17:01 pm »
I always use GetCalc(appvTEMP, size) for dynamic variables. (This creates an appvar called "TEMP" of the given size and returns a pointer to it.) Just remember to delete it later.
-German Kuznetsov
The impossible chemical compound.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: More dynamic variables?
« Reply #7 on: March 18, 2018, 07:03:43 pm »
There is a lot of free ram hanging around. Try using static locations if you can. (like L1-6 or special spots you can type in with the scientific E key) A large portion of 0x8000 - 0x9D93 is free to use. L1-6 are there but they only cover a small portion. If you need a lot of variables, use 0x966E. It is 128 bytes long. You will need to fill it with the space character when you are done or your homescreen will look wierd when you quit.
Also L5 is the only L1-6 variable that can't be used as 756 byte buffer.
L1 can be used whenever you want.
L2 is listed as 512 bytes long but it is closer to 800. Make sure to ClrDraw(L2) when you are done. I know that it says you can't use it with interrupts but that isn't true. I've written many programs with interrupts and used L2 in each one without any problems.
L3 is basically the same as L1. The only time you can't use it is when you are using greyscale.
L4 is listed as 256 bytes long but all L4-512 to L4+256 is free to use. Some values might change if you are are use Copy() with the Y0-9 archive variables.
L6 is the graph screen buffer. You probably know what that is used for.

If you really need more try:
https://www.omnimaga.org/index.php?page=ram

If you can't use any of that:

I would avoid using getCalc unless you need a very large amount of uninterrupted space. If you are trying to store a bunch of 2 byte variables there, it will be 2-4 times as slow as if you put those variables in L1-6. I'm not saying don't use getCalc for memory! I'm only saying that it will be a bit slower. (There are actually hacky advanced ways to get all the memory space of using getCalc and the speed of static locations...)

As for using Buff() for memory, that is up to you. Make a program that uses Buff(8000) and run it. If it takes a second to quit, don't use Buff. If not then feel free to use it as much as you want since your shell isn't writing it to archive.

If you know what you are doing, you can have a huge amount of memory at once. One of my programs had 25k of executable code and 28k of ram that I could write to at any time. (I didn't swap anything to archive)
I'm still around... kind of.

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: More dynamic variables?
« Reply #8 on: March 18, 2018, 07:21:55 pm »
I always use GetCalc(appvTEMP, size) for dynamic variables. (This creates an appvar called "TEMP" of the given size and returns a pointer to it.) Just remember to delete it later.
I'm pretty sure there's a type of variable that gets deleted automatically by the OS when you exit, it's called tmp and it replaces the w token (2nd+9).

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: More dynamic variables?
« Reply #9 on: March 18, 2018, 07:28:02 pm »
I always use GetCalc(appvTEMP, size) for dynamic variables. (This creates an appvar called "TEMP" of the given size and returns a pointer to it.) Just remember to delete it later.
I'm pretty sure there's a type of variable that gets deleted automatically by the OS when you exit, it's called tmp and it replaces the w token (2nd+9).
Yea... that's right. I think. Pretty sure. You might have to start its name with a non-alphabetical character like '*' though.
I'm still around... kind of.

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: More dynamic variables?
« Reply #10 on: March 18, 2018, 07:47:20 pm »
I don't think there is such a restriction. Just do GetCalc(tmpTEMP, size) and you're good.