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 ... 128 129 [130] 131 132 ... 135
1936
« on: February 19, 2010, 02:52:23 pm »
Well in the future, the source will be archived as it is being compiled. No RAM is used in Axe itself, so you have the entire free ram to create the executable.
By the way, that cave scroller game got reduced by about 50 bytes when I compiled it with the new automatic optimizations, plus I reduced it another 50 bytes from simple optimized source code tricks. An additional 50 bytes or so could be shaved off by using Ion routines. There is even more that can be done, but I'm just demonstrating that the file size you see now will in no way be the final size when I finish this project.
1937
« on: February 19, 2010, 02:31:02 pm »
The include statement will just be inserting "prgmNAME" into the code somewhere. I'm not sure how the Axioms will work, but they definitely won't be available on any time soon.
Just to give everyone a heads up, I am making a major change in the next version. I ran into a problem. When you display stuff, how does the compiler know in what format to display it? How does it know if you want to display a string, a number (and if so, in what base?), or a character? All three of those have a number as an argument, either as a pointer for strings, or a number for the ASCII value of the character and the plain old base 10 representation. Therefore, I must add some way to tell how you want to display that number.
So in the future, you can display a string by omitting any additinal notation, as you have already been doing, but to tell it that that number is not a pointer to a string, you have to use >Dec at the end to tell the Disp or Output command that you intend to display that number as a base 10 representation. Similarly, I might use >Frac to display the ASCII value of the number.
Sorry if this makes things a little inconvenient, but it will only reduce the size of the compiled program and add even more flexibility. Its a very simple thing to fix to make older programs compatible with the next version.
1938
« on: February 19, 2010, 02:12:15 pm »
The text shadow is not cleared when you do ClrHome. I was thinking of adding that to the routine, maybe I will next time.
I'll look into the problem with ^rand.
1939
« on: February 18, 2010, 10:11:01 pm »
It will be possible in a future version, so it I don't feel like adding something that will just be removed later.
A different idea though, is requiring all Axe programs to have a particular header in order to show up on the list. That would remove the clutter of BASIC programs, would that be more or less annoying than the clutter? What does everyone think about that?
Also, I am thinking in the far future to release a developer kit for asm programmers to add Axioms, which is a clever name for importable libraries to add new commands to extend the features even further.
1940
« on: February 18, 2010, 10:00:28 pm »
The reason for the down internet is that I just moved closer to the college and I haven't gotten the internet service yet.
Games will most likely not be comparable to the size of the source. There are several reasons for that. First of all, many of the routines can be smaller (like Dispgraph) if they use the built-in operating system calls, but that would really defeat the purpose of this project, so I am writing my own faster routines. Secondly, Axe source code can be made more compact than BASIC source code of the same program, so that kind of gives a bias to the file size numbers. Lastly, you have to re-learn how to optimize code. Similar to how there are so many tricks in basic to reduce size and/or increase speed, there are many many more shortcuts in Axe. For instance, A+1 results in smaller code and faster speed than 1+A.
Don't forget, I still have a lot more optimization to do. I've already made a lot of improvements for the next version, its already producing 15% smaller code and there are still many more optimizations to do. Another thing that will be added in the future will be shell support meaning that some routines will simply be calls to the shell functions, greatly reducing the file size. In the future, I would expect well optimized Axe Parser code to be approximately 1-2 times the size of its source, and only about 1.5 times the size of a pure assembly equivalent.
1941
« on: February 18, 2010, 04:25:43 pm »
That's awesome!  I can't wait to see everyone's projects! I'll open a new thread for posting programs after the next release! Just so everyone knows, I temporarily do not have internet right now, I'm basically checking everything once or twice a day at school or at the library. So I can't respond to things quickly. By the way, I already have sprites working in the next release, but I have to get pointers working before I can release it since the routines rely on pointers. Expect 0.0.5 sometime this weekend. At that point, games will be quite nice looking and can get relatively complex. I may or may not have lists working (variable pointers) but there will be other ways around that in the mean time. After that, I will focus a bit more on the Axe GUI, especially naming programs  , and safety features.
1942
« on: February 16, 2010, 01:31:45 pm »
Its pretty easy for me to make deadlines in Axe Parser. Since there really is no end to addable features, I can just keep adding things until I run out of time and then release what I have. Unlike games, an unfinished parser is still functional.
1943
« on: February 16, 2010, 01:23:22 pm »
randInt will come eventually. The best way to get random numbers between A and B inclusive is like this: A+rand^(B-A+1) and this will basically be what that function will do. So if you need a number 1-5, then simply do this: rand^5+1
Passing parameters is unnecessary complexity. Saving into variables in the main program and then recalling them from the subprogram is about as efficient as it can get and is much simpler to understand for the programmer. But like I said, I'm not sure if I will allow program modification tools. You can embed an external program inside the compiled program and call it from there, but you will most likely not be able to call an arbitrary external program from the compiled code. That would require error handling, something which I will add later, using the "Theta" variable. 0 means no error and all the other values represent different types of errors so you can check if some of the higher level commands executed properly.
1944
« on: February 16, 2010, 01:06:47 pm »
Oh I'm sorry, I forgot about the differences. I meant _VPutMap will be for Text().
I think there is a flag I can set to not auto-scroll the screen for the Output() command. I'll have to do more testing.
1945
« on: February 15, 2010, 09:19:20 pm »
My bad! The multiplication algorithm was incorrect, I had to change a z flag to an nz flag. Sorry! Until I update with the fix, you will not be able to multiply if either argument is larger than 255.
I am planning on optimizing the multiplication/division/modulo for constants as well as for equalities, bit operations, and other things. I was still a little busy today though so I just wanted to get the update released on time so I'll do that later.
_putMAP would work, but that's how Text( will operate, so there wouldn't be a purose to having two commands that do the same thing.
1946
« on: February 15, 2010, 04:21:30 pm »
Terminating means that the string will end. Literally, it means a null character is added to the end so that it knows when it gets to the end of the string. If you type:
"HELLO"[20]"WORLD"->Str1
Disp Str1
It will print "HELLO WORLD" since 20 is Hex for space. The hello part of the string will not terminate so it will continue to the rest of the data.
"HELLO"[]->Str1
" WORLD"[00]
Disp Str1
This also will print out "HELLO WORLD" since hello is NOT terminated in that first line so it continues to print the data until it reaches the null character.
EDIT: Oh about the pretest/posttest. Turns out it would be actually more code if I did that so I don't know if I will change that in the future.
1947
« on: February 15, 2010, 03:15:53 pm »
It works perfectly in 0.0.4 when I try that code.
Not sure if this might be the problem, but do realize that this:
X+(K=2)-(K=3)->X
Is not the same as this:
X+(K=2)-(K=3->X
The later will parse like this:
X+(K=2)-(K=3->X)
since store can be used inline.
1948
« on: February 15, 2010, 03:03:53 pm »
New version out. I bet you can't do THIS in basic:  Its a game of life simulator. It is horribly unoptimized since I haven't added pointers yet, but its fast enough to really see the speed difference with BASIC. By the way, please do not post in the updates thread. Whatever you would post there, post here instead, this is the discussion thread.
1949
« on: February 15, 2010, 03:01:07 pm »
Axe Parser
Alpha 0.0.4
New Features:- More string character support
- Adding and subtracting constants optimized
- Pixel routines
- For loops
- Compiling progress indication
- Hexadecimal data entry
Changed:- DispGraph is now the Ion Fast Copy instead of the slower OS routine.
New example program.
1950
« on: February 15, 2010, 02:47:50 am »
I wrote some custom fractal equations and coloring algorithms and then rendered them using Ultra Fractal.
Pages: 1 ... 128 129 [130] 131 132 ... 135
|
Show Posts