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 - Runer112
Pages: 1 ... 64 65 [66] 67 68 ... 153
976
« on: November 13, 2011, 07:41:05 pm »
Here's what I came up with:
iPart(fPart(A/2^B/2)*2)
A is the number to examine, and the formula checks if 2^B is a binary component of A. B=0 would check if 1 is a component, B=1 would check if 2 is a component, B=2 would check if 4 is a component, etc.
977
« on: November 13, 2011, 02:20:49 pm »
:.TEST
:[FFFFFFFFFFFFFFFF]->Str1
:0->{L1}
:0->A
:Pt-on(8,8,8*{L1+A}+Str1
:DispGraph
This gives the "Wrong # of Args" err. Is this a bug, or am I just stupid?
Yes, this is a bug: {CONST} or {CONST + Var} produces a 'Wrong # of Args' error 
Thanks, I just caught that. A workaround for now is to just add the constant after the variable: Var + CONST, which is more optimized anyway.
978
« on: November 10, 2011, 08:13:36 pm »
They're variables like any other variables, except they were intended to be used to interface with Axioms. But you don't have to use them for that, as Freyaday is probably doing.
979
« on: November 10, 2011, 07:57:46 pm »
Found the bug! The peephole optimizer normally works by simply examining the compiled code, which is fine and dandy for 99.9% of code. But if a potential jump point exists inside of the code that the peephole optimizer is trying to optimize, the optimization should not be performed. I see that Quigibo remembered this and coded an abort to optimizing if an End of an if statement or a Lbl is inside the matching code, but no such abort exists if the previous line ends in an inline conditional. However, this is effectively like the End of an if statement, and should not be optimized. This lapse may exist because Quigibo forgot about this case, or perhaps just because it's probably more of a pain to detect.
980
« on: November 10, 2011, 04:55:12 pm »
Freyaday, can you give a concrete example of code that doesn't compile correctly? Because I lost you at "before and after an if statement makes the if statement not work when SHMPE." 
981
« on: November 02, 2011, 12:21:05 am »
That sounds awesome! I guess my only question about it is if there will be a way to draw the image with logic other than overwrite, as it might be nice to be able to draw large sprites that combine nicely with the background in games and such. And don't forget to browse the Axe issue tracker thingy if you ever want ideas for what to fix/optimize/add. I guess the first two are more important, but the third one is always good to have content added from as well. Especially if there are small, easy things to add that would still be awesome. EDIT: Oh, and are you completely getting rid of the old command? Because it might still be useful to some due to not requiring a large routine for things that don't really need amazing clipping logic or speed.
982
« on: October 31, 2011, 08:25:42 pm »
just read this:
hooray! sound is back 
Sound has been back for almost three months.  I think it just fixes crashes, but not the pitches.
Also, the pokemon games require 32 kb of ram.
Could this possibly be fixed?
Because 25 kb is available to user without like, hacking it. But I read somewhere that the chips have 48 kb of ram; is the other available ram used for other purposes that can't be disturbed or something?
I never understood this properly, so I'd appreciate it if someone could explain this to me.
Thanks.
The Pokemon cartridge contains 32KB of RAM. However, that is completely separate from the 32KB of RAM that is already inside the Gameboy itself. That brings the total RAM used by the game up to 64KB, which is already over the 48KB limit. And beyond that, the emulator needs RAM as well, bringing the real total RAM requirement closer to something like 72KB.
983
« on: October 27, 2011, 10:17:12 am »
1. I wouldn't call what he does immoral, but he is a jerk. Even his cameramen attest to this.
2. I don't think he's trying to prove a point, he just likes showing off his skills and being a jerk.
3. Having a soccer ball kicked at/into my car or work establishment is not really a big deal. It's a soccer ball, it really isn't going to cause catastrophic damage. I would probably be annoyed, but not to the point where I'd want to chase the guy down or call the police or anything. And I wouldn't really compare these situations to being "assaulted by a giant bottle of hair-remover," since that can actually inflict damage both on your body and your image for a long period of time.
984
« on: October 26, 2011, 02:51:14 pm »
Yeah, I saw your FP math Axiom and I figured that being able to enter token strings would make it about 100x simpler. People could then just enter standard homescreen/TI-BASIC code which could be executed simply with a bit of setup and calling the OS to handle parsing it from there.
985
« on: October 26, 2011, 01:24:49 pm »
Two feature requests: - The ability to include token strings as data. I thought about a possible syntax for this, and I came up with ["String goes here"]. Perhaps there's a better syntax, but that's just what I came up with.
- A peephole optimization to remove instances of inc hl \ dec hl. It is very common for operations that return a boolean to end in sbc hl,hl \ inc hl, but in many cases, the inc hl to normalize the result to 0 or 1 isn't really necessary and returning a value of -1 or 0 would work just as well (sometimes better, as is the case with a piece of code I was just working on). Being able to add a minus one after the boolean operation to save a byte could be very handy and could definitely add up.
986
« on: October 20, 2011, 10:20:29 pm »
Freyaday, that is most definitely valid code. Are you sure you've tested this with the latest version of Axe? Because I did and it worked just fine for me.
987
« on: October 20, 2011, 02:06:35 am »
I believe I have found a fairly obscure bug. It appears that comments do not work properly on Lbl or Goto lines. Not only does a period not start a comment, but it also makes the parser "forget" that the current line is a Lbl or Goto line and parses whatever follows the period like normal code.
EDIT: For that matter, it looks like Lbl and Goto are a little wonky with spaces as well. Spaces in label names are ignored by the parser, although they should probably end the label name.
988
« on: October 18, 2011, 11:01:50 pm »
Pick that post back up and take it right on over to the bug reports thread, because that's definitely Axe's fault, not yours. It's treating +F as adding the variable F instead of noticing the opening parenthesis immediately following it and treating it as adding the return value of a function.
989
« on: October 18, 2011, 04:00:32 pm »
You can already do that. Just do something like 1337→°Const, and now °Const is a constant that equals 1337 for the rest of your program.
990
« on: October 14, 2011, 09:18:06 am »
The variable creation routine hasn't been changed since Axe 1.0.2, so I'm pretty sure that your code should work exactly the same in 1.0.3 as in 1.0.5. I'm guessing the problem is that, upon running the program, you just barely no longer have sufficient free RAM to create the appvar. Something that you might call a bug does exist in the variable creation routine, in that it doesn't account for the size of the new VAT entry when checking to see if there is enough space for the new variable. So if you want to create a 7680-byte variable but have 7685 bytes free, Axe will think you have enough space and will try to create the variable. However you can't actually fit the variable and its VAT entry, so you will get an ERR:MEMORY.
Pages: 1 ... 64 65 [66] 67 68 ... 153
|
Show Posts