This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Quigibo
Pages: 1 ... 35 36 [37] 38 39 ... 135
541
« on: February 03, 2011, 03:54:04 am »
If this remains a program, and not an app, then you can can continue to use self modifying code by adding an extra buffer. So lets say GDB1 is the unchangeable level and GDB0 is your level buffer (this is what you use in the game).
[...lots of level stuff...]->GDB1 .Your level data for level 1
[...lots of level stuff...]->GDB2 .Your level data for level 2
Zeros(1024)->GDB0 .Your buffer
Copy(GDB1,GDB0,1024) .Copy all of level 1 into the level buffer
...Feel free to modify this now...
Copy(GDB2,GDB0,1024) .Copy all of level 2 into the level buffer
...Feel free to modify this now...
Copy(GDB1,GDB0,1024) .Reloads level 1 again, restored to normal like it should
...etc...
542
« on: February 03, 2011, 03:47:29 am »
Using recursive subroutines with the r modifier only backs up the variables it uses so if you mess with the other r1-r6 that are not passed as arguments, there values will be changed as well. So calling:
:sub(A,50)
:
:Lbl A
:Disp r1>Dec
:sub(B,100)
:Disp r1>Dec
:Return
:
:Lbl B
:Disp r1>Dec
:Return
Prints: 50,100,100
:sub(A,50)
:
:Lbl A
:Disp r1>Dec
:sub(Br,100)
:Disp r1>Dec
:Return
:
:Lbl B
:Disp r1>Dec
:Return
Prints: 50,100,50 since r1, and only r1, is restored after the call.
543
« on: February 03, 2011, 03:38:15 am »
If you don't use any special characters, you could cut off the high bit of each letter, that would reduce the size 12.5%. If its all upper-case, you can do a direct mapping with only 6 bits which could compress it by 25%. Otherwise, huffman is really good at text compression (You might be able to get up to 50% compression) but the algorithm is so long and complicated that it might only be worth it if you had over 5k of text. Another suggestion is to use a special character that you never use as a "word replacer" for common words. Lets say that character [FB] is never used, you could have the sequence [FB01] replace the word "the" and [FB02] replace the word "only" etc. They can even be inserted into the middle of a sentence: [FB02]"re" would become "there".
544
« on: February 02, 2011, 10:18:43 pm »
Unfortunately I haven't really had time to add much more to Axe other than the Axioms, and I can't get my mode 7 engine working properly and I might have to rewrite it from scratch. So I think I will instead release more betas since there are so many more features that need to be worked on before 1.0.0. Instead I might just release a VAT based Axiom for reading from the VAT efficiently since that's both useful and quick to make.
545
« on: January 31, 2011, 02:55:31 am »
Well just to be fair, if you do ever find yourself with the need to reset the stack you are probably using bad coding practices or doing something too low level that should be taken care of with an Axiom. This is for the same reason that "Goto" is so frowned upon in languages like C++. The main reason I still have it in Axe is because it was really easy to add and should help those used to TI-BASIC, because with all the loops, control structures, and subroutines, you should pretty much never need a goto in your Axe code.
546
« on: January 30, 2011, 04:20:56 pm »
Yeah, I actually use it in my program " MISCPRGM" if you want to see it. It can do up to 999! I think as long as you have enough memory.
547
« on: January 30, 2011, 04:15:48 pm »
Yet another cool way to compute factorials, this way is for factorials of very very large numbers without multi-precision containers. No multiplication required  double sum=0;
for (int i=1; i<Max; i++) {
sum += log(i);
}
int exponent = floor(sum);
double coeff = Pow(10,sum-exponent);
print("Answer is: ",coeff,"x10^",exponent);
548
« on: January 30, 2011, 04:02:42 pm »
No I don't actually have one yet since I can't think of a good token for it, but maybe I'll add that feature in the future.
549
« on: January 30, 2011, 04:01:05 pm »
You should never rely on that wraparound in case the commands change in the future with different wrap around values for some reason. You should manually tell your drawer to not draw when the object is off-screen and then when the X or Y values pass a certain point, subtract the loop around values from them.
550
« on: January 30, 2011, 03:55:47 pm »
Yeah, its a nice idea. I use it in a lot of my programs, sometimes because I'm just too lazy to keep track of the stack, but the reason I don't have a single command for that in Axe is because its a 2 part command. You would need a "save stack" and "restore stack" command. Calling the restore stack without saving first though is pretty much a guaranteed ram clear.
551
« on: January 30, 2011, 01:25:51 pm »
I'm pretty sure those calls are not in little-endian. Switch the last hex pair with the middle hex pair for all the calls.
552
« on: January 29, 2011, 10:39:07 pm »
Oh yeah, I was planning on adding that functionality. I'll see if I can get it working.
553
« on: January 28, 2011, 07:41:22 pm »
Nothing I can really do about that unfortunately unless someone wants to looking into the disassembly of the bcall. It isn't documented.
554
« on: January 25, 2011, 05:08:47 pm »
I am pleased to announce that I have finished the Axioms finally. I will be distributing pre-release versions to a few people later today after I do more testing with them. They are extremely powerful right now. New features include: recursive axiom chain calling, distinct commands using identical tokens but based on different arguments, r modifiers, store arrows, and shells; native axe routine calling, relative and absolute referencing for any 2-byte immediate instruction, including calls, jumps, and loads; easily add data tables to aid your axioms, new tokens specifically for axioms, and a lot of other features I'm probably forgetting. Basically, you have nearly complete control with the new commands. I'm looking forward to some really great libraries  I'm also going to make a mode7 example program using the new library since I haven't done any example programs for a while. Quigibo, can you have the parser check Axioms first and then check the actual Axe code? This would allow redefinition of various Axe functions and allow different behavior. For instance, if you were writing some BrainFck in Axe and had an Axiom for it, you could use + in the way BrainFck requires it to be used in. 
I don't want to look through the axioms first or else the parsing will be slower since it will have to scan every single axiom before it starts looking at the regular commands. Also, I don't have axiom support for operators since they require a lot of special form stuff like auto-optimizations and operation on parenthesis.
555
« on: January 25, 2011, 04:51:57 pm »
Hopefully you still have the source code to those programs. As long as you do, you can just compile them with the new version and they will be fixed.
Pages: 1 ... 35 36 [37] 38 39 ... 135
|
Show Posts