Next version of xLIB - features?
Moderator: tr1p1ea
A recalled command, that lets you repeat any possible function, would be slower than the command originally was. However, a command to recall one particular function, like real(50 that calls real(30,aa,bb,cc,dd,ee,ff, would be muhc faster, if done properly (shouldn't be too hard to do). I'm not suggesting an entire recall command system, just a method for storing a few grayscale parameters so that the one grayscale command called every other line can be parsed as fast as is possible.
- JoostinOnline
- Regular Member
- Posts: 133
- Joined: Wed 11 Jul, 2007 10:42 pm
- Location: Behind You
No, I'm saying that I don't like the idea of an entire function-recalling system. It's overly complicated, it would slow down command execution, and you've pointed out a logic flaw that could lead to problems (though I think that the stack would overflow and a ram clear would occur before batteries died, and a check could be put in to prevent this problem). Instead, all I want is this:
At the beginning of the program, scene, whatever, you call:which stores the parameters to saferam. The parameters are only for the grayscale function. No other function can be mapped.
Then, every other line, instead of callingwhich is slow, and takes up space, you calland the function looks up the preparsed parameters from the saferam location. This idea is safe, it saves space, and it speeds up program execution, to improve grayscale quality and possibly make grayscale possible on the 83+ BE.
At the beginning of the program, scene, whatever, you call:
Code: Select all
real(40,param1,param2,param3,...
Then, every other line, instead of calling
Code: Select all
real(50,param1,param2,param3,...
Code: Select all
real(50
- tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
Im afraid that storing things in saferam isnt safe at all since people often use more than 1 asm lib and it cannot be garaunteed that the information will not be over-written. I dont think there is a problem with the way grayscale is currently done from BASIC, also i doubt there would be any real benefits to doing it this way.
- calc84maniac
- Regular Member
- Posts: 112
- Joined: Wed 18 Oct, 2006 7:34 pm
- Location: The ex-planet Pluto
- Contact:
- JoostinOnline
- Regular Member
- Posts: 133
- Joined: Wed 11 Jul, 2007 10:42 pm
- Location: Behind You
Appvar is not good, because searching for an appvar each time will slow things down and defeat the purpose. I know, because my app CalcUtil used to look up an appvar each time the parser hook fired, and it slowed execution speed to about 1/3 normal. But three or four bytes of ram, maybe at the beginning of the stack (according to Brandon Wilson, it's safe to assume it won't be popped off), should suffice.
- calc84maniac
- Regular Member
- Posts: 112
- Joined: Wed 18 Oct, 2006 7:34 pm
- Location: The ex-planet Pluto
- Contact:
Another idea if someone hasn't suggested it already is a way to store and recall what is currently on the homescreen.
Also, a home- and graphscreen cursor that returns the key pressed if anything other than the arrowkeys were hit would be nice.
Also, a home- and graphscreen cursor that returns the key pressed if anything other than the arrowkeys were hit would be nice.
"Python has dynamic typing, and dynamic binding, which means that not only does it make a great secretary, it is also pretty damn kinky." --Henry the Adequate
<My Artwork>
<My Artwork>
- JoostinOnline
- Regular Member
- Posts: 133
- Joined: Wed 11 Jul, 2007 10:42 pm
- Location: Behind You
It'll display a mouse on either the homescreen or the graphscreen that you can move around and when you hit any other key other than the arrowkeys to move it, it'll return the key pressed and the cursor location.
"Python has dynamic typing, and dynamic binding, which means that not only does it make a great secretary, it is also pretty damn kinky." --Henry the Adequate
<My Artwork>
<My Artwork>