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 ... 117 118 [119] 120 121 ... 135
1771
« on: March 30, 2010, 01:17:48 pm »
I can solve the Rubik's Cube! I'm not very fast though. My best times are usually about 60 seconds, I have a friend who can do it in half that! There's also a lot of cool patterns you can make. Its fairly easy to make the cube checkered with only 3 turns and you can make it have dots in only 4 turns from the solved position. You can also have multiple cubes in the same cube and bands of color in a spiral.
1772
« on: March 29, 2010, 02:25:38 pm »
Nah, I can always compress it. I haven't even optimized my regular code yet either. I have a feeling that the parser will be a one page app until maybe very close to the FINAL release. If I do need to expand it beyond a page, I will include a bunch of helper programs, manuals, and demos in the extra space. If not, the helper programs will be in a separate app.
1773
« on: March 29, 2010, 02:13:36 pm »
The space an app can have in one page starts at $4000 and ends at $8000. I am at $6075 right now. So I just passed the halfway point recently. That translates to 8309 bytes btw. A lot of that code I'm not even using right now. Its just sitting there until I write some code to use it.
1774
« on: March 29, 2010, 02:01:41 pm »
Right. It increments a variable (like a for loop) and then checks to see if it has reached a maximum. If the maximum is reached, the code gets executed and the variable resets back to zero so that the process can start over again. So if you put it in your loop like this:
0->A
While 1
<Render Frame>
IS>(A,20)
SinReg 150,5000
End
End
This would make a beep every 20th frame.
DS<(A,20) would do the same thing but counts downwards and reset to 20 when it gets to zero.
And the lowercase operations might actually be not too much overhaul since they can just use the low order bytes of the standard variables. However, they would be totally incompatible with regular variables. You couldn't mix the two very easily without using some weird conversions. Also, I would need to add some type of modifier so the parser knows if constants are 8 bit or 16 bit.
1775
« on: March 29, 2010, 01:13:26 am »
Probably those will come packaged with the parser when its completed either as a separate app or a submenu in the parser. But right now, if anyone authors a useful helper program to make axe programming easier, feel free to submit it to me and I'll include it in future versions. Its also a plus if you can write a short readme to go with the program. Include proper credits to yourself as well.
EDIT: This includes help manuals and tutorials too!
1776
« on: March 29, 2010, 01:01:22 am »
The user made routines I do not officially endorse because many of them will be added as built-in features in future versions.
1777
« on: March 28, 2010, 11:14:14 pm »
If you check the first post on this thread, I will be editing it constantly to give everyone an idea for the time frame in which I plan to add features. It also keeps track of ideas already suggested.
1778
« on: March 28, 2010, 10:42:57 pm »
Hello again everyone. I am officially back. I've finished my testing and I've finished moving into my new place which also means I have internet at home again  . I'm going to re-prioritize the upcoming features so that games will be able to be actual, directory quality, fully complete games. I have already been beyond impressed with what I have seen so far, but I still need to add some basic features like saving, loading, title screens, and shell support that are essential to what I would consider "complete" games. Its not that every game needs these features to be complete, some don't, but I need to at least support them in a simple way without needing asm() commands so that at least the programmer has those options. I am expecting this to take about 2 weeks. After that, I will release a beta to the public. I will also try to add some more safety features and parsing options. Glad to be back!
1779
« on: March 24, 2010, 02:13:38 pm »
I am going to have to dedicate this entire week/weekend to studying for a very important test; the Caltech Entrance Exam which is notoriously difficult. I am going to been staying at school from 8 in the morning to 10 at night as I have already been doing this week. I'm just letting everyone know, and this is why I am going to try to not return to this forum until Sunday evening because its a distraction. I haven't worked on Axe since Sunday and there is no way I am going to get anything done this week so the next update won't be until the following week.
1780
« on: March 24, 2010, 01:57:46 pm »
The ideal input routine should store the input into a buffer in ram. Then, the programmer has control of how to interpret the buffer; either as numerical, string, or something else. And yes, you can store numbers larger than 16 bits using part of RAM to store the larger number (kind of like how the 16 bit number is really just two 8 bit numbers). In fact, you can store as much precision as you want. You can have a 100 trillion digit number if you need it. It just complicates the math you have to do, but little subroutine can take care of that for you so you don't have to deal with it manually.
1781
« on: March 23, 2010, 10:20:32 pm »
I'm just going to mention that if you have over 8kb of executable code, you should probably consider assembly and flash apps. Even if I somehow got programs to compile to flash applications, you are still limited to 16kb of total data per page and anything above that involves page swapping which is an advanced procedure even for asm programmers. Not only that, but it would be impossibly difficult to automate this within the parser.
As much as I would like programmers to be able to use Axe without needing to know assembly, there is a real hardware limit and past that point requires assembly knowledge.
1782
« on: March 23, 2010, 09:57:52 pm »
I actually ran into this exact problem when I made Pyoro. That's the main reason I turned it into an app.
However! I am pretty sure that mirageOS and other shells CAN read files larger than 8kb, so you would just be forced to use a shell if you needed the extra room. Another alternative is to split the program into multiple subprograms and then read them all with GetCalc() which is a command not implemented yet.
EDIT: and yes, data is attached to the end of the program.
Currently, the structure is this:
Header - Program And Subs - Data
But in the future, there will probably be a third pass for extra efficiency and the new order will be:
Header - Program - Subroutines - Data
Right now, no checks are done, but I wouldn't recommend making an 8000+ byte program until the parser is finished anyway.
1783
« on: March 23, 2010, 09:53:02 pm »
Hey thanks! That will definitely come in handy! It does use multiplication in that routine though, but oh well. It just makes it difficult on the parsing side to have to call other subroutines that may or may not already have been added, but I guess I'll figure out a way to template it better to make this easier in the future anyway.
1784
« on: March 23, 2010, 09:46:37 pm »
Because in Axe, the ' token means that you are in Hex, and 0A in Hex = 10 in Dec  . Currently the only way to store data into Ram is by Hex, like this:
[010AFF]->Str1
which ends up looking like this in Ram
{1,10,255}
Hopefully in the future you will be able to input data like this as well But no matter how you put the data in, it is always extracted as Decimal.
You might have missed it in the new update. That was added already! Its the deltalist command.
1785
« on: March 23, 2010, 06:50:06 pm »
Don't forget, you can move 1 pixel at a time but update the screen every other time, so it appears you are still moving at 2 pixels per frame, but with the accuracy of 1 pixel per frame and nearly the same speed. That's what I did for starship.
Pages: 1 ... 117 118 [119] 120 121 ... 135
|
Show Posts