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 ... 58 59 [60] 61 62 ... 135
886
« on: August 31, 2010, 05:50:35 pm »
Mhhh.... Its actually a mistake in the documentation not the command. You *might* be able to read file pointers from ram as well as archive, I'll have to check. It only returns 0 if not found, it returns non-zero if it was found (although the number returned is not necessarily the pointer to the file. The real pointer to the file is stored in the structure of Y0-Y9)
887
« on: August 31, 2010, 05:39:40 pm »
It's possible, but you have to know how to transverse the symbol table which is a very low level thing to do. It can be done in pure Axe yes, but it requires a lot of knowledge of how TI organizes the file system. You'll have to look at the Developer's SDK (download from TI's website) to learn more about it but be warned that that guide is written for assembly programmers and what you're trying to do is a little tricky.
888
« on: August 31, 2010, 05:34:40 pm »
If you draw sprites from archive, you will need to follow a few steps. First have a small reserved place in ram for a very small and very temporary storage such as L5. Use the copy command to copy the sprite's data to that temporary buffer. Draw the sprite using that buffer as an argument instead of the file. You should turn this into a subroutine that does both of these things for you automatically so you only need a single call to draw the sprite. The exact same procedure should be used with apps as well. If you're drawing the same sprite multiple times, you can optimize by only copying once and then drawing every instance of that sprite before copying the next sprite to be drawn.
889
« on: August 31, 2010, 12:31:54 am »
Wow this really is amazing! Excellent use of double ascii sprites.
890
« on: August 31, 2010, 12:25:37 am »
By the way, I'm sure you're already doing this, but just in case this applies to someone else with this question, make sure you include at least a few default levels so that gameplay is possible without requiring the extra software. Don't expect players to have to build their own levels just to play it, that should only be an extra feature for added replayability.
891
« on: August 30, 2010, 02:54:49 am »
Yeah, it was done specifically for consistency so that you don't have to think to yourself "Did this command use (x,y) or (y,x)?"
That problem with the input function I can probably fix. I need to find where the buffer is that holds the input string so I can clear it.
892
« on: August 27, 2010, 03:00:45 pm »
That shouldn't be happening. Is anyone else getting that?
893
« on: August 23, 2010, 05:15:07 pm »
My activity with the Axe Parser project is already slowing down due to college related things and so I've decided I need to get 1.0.0 out as soon as possible. I will not be spending my time on new commands as much unless they are essential to most programs. This is because things like automated tile mapping, 3D graphics, automated multidimensional arrays/linked lists, compression/decompression etc. can all be done with Axiom expansions. Instead, what I will be focusing most on is expanding the block types like switch statements for instance, optimizations, and improving the Axioms themselves so that its very simple for even novice asm programmers to expand the functionality.
There is also the contest deadline approaching soon. I have noticed that there are many people who are still using older versions because they fear that syntax change, new bugs, or future changes will be too much effort to switch over to a newer version. Well, now is your chance because 0.4.4 is very stable and bug free as far as I know and I will not be having anymore updates until after the contest deadline unless its specifically to fix bugs. I doubt I will be active enough for weekly updates anymore but as some of you know, I was planning to do a feature freeze to give everyone a fair shot at the contest anyway.
I am in no way quitting this project or trying to end it early. I will continue progress even after 1.0.0. However I have to be realistic about the amount of time I'm going to have to actually work on it. Its possible I will make much of the source open after the final version so that others can collaborate to help me expand the features.
894
« on: August 22, 2010, 07:43:06 pm »
There is a difference between using a command while interrupts are on and using one in an interrupt routine. I think all commands will work fine with intterupts in the background but there are a few like DispGraphrr that don't work in the interrupt routine itself.
895
« on: August 22, 2010, 03:17:25 pm »
Thanks for those, I'll get them fixed. I have hardly been able to use the internet yet so I don't know how often I'll be able to post for the next few days.
896
« on: August 21, 2010, 02:58:39 am »
Axe Parser
Delta 0.4.4
New Features:- Convert integers to and from floating point numbers.
- String input just like BASIC!
- ElseIf and Else!If statements.
- Data search routine similar to BASIC's inString.
Changed:- Fixed bug with custom interrupt labels.
897
« on: August 20, 2010, 01:35:59 pm »
That code should work. Are you sure you recompiled it after making changes to the source?
The InsertMen and DeleteMem commands I was considering to add at one time, but then I realized that you can do basically the exact same thing by creating an appvar, string, program, etc. in ram and then delete it when you're done to get a quick temporary variable without any extra syntax.
By the way, I happened to stumble upon an undocumented bcall on brandonw's website that is nearly identical to BASIC's "Input" function, and so I've added that functionality now. The way it works is that it stores the input to a temporary string in ram and returns the pointer to it just like you would read any other external string. The only difficulty is that similar to strings, its token based instead of character based so anything that's not a number or uppercase letter has to be converted.
898
« on: August 19, 2010, 05:29:56 pm »
You can synthesize your own instruments you know without having to record anything. Its basically just like a regular solid square wave, but you have a list of pitch shifts like +1,0,-1,-2,-1,0,+1 or something and you can create some really cool effects at very high quality. I've never tried this, but its definitely possible.
899
« on: August 19, 2010, 03:46:22 am »
If you need a complete and current list of all Axe token conversions, the "commands.html" file on the left column shows all the tokens that change and what they change to. Its included in all zip files, but I can send you a better formatted list if you really need one or I can write the XML myself if you have an sdk for it.
900
« on: August 18, 2010, 02:40:14 pm »
Well I was thinking of instead of having just "Break" and "Continue", I also have "BreakIf" and "ContinueIf" as well as their conjugates since then they can be used in conditionals because I think that feature would be nice and this way the assembly is more optimized anyway than having a separate conditional. Also, I'm not even sure how I could make it break out of multiple levels of nested statements anyway with the way I currently handle nested blocks.
My switch command is going to be really different as well. I need it to be optimized enough where it is much more favorable to use so I think there will be no switch statement, only case statements. For instance:
:
:A*12+(B/8) .The last expression used becomes the switch statement automatically
:Case 0
: .Function1
:Case 83
: .Function2
:Case -1
: .Function3
:End
:
The look-ahead parsing to pregenerate a jump table would be messy and memory hungry so I'd have to see how feasible it is. So that means I am still unsure if automatic breaks would need to be implemented or not. I'm also unsure if I want to make this command a single byte only command since it could lead to a huge optimization
Pages: 1 ... 58 59 [60] 61 62 ... 135
|
Show Posts