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 ... 68 69 [70] 71 72 ... 135
1036
« on: July 19, 2010, 01:23:30 am »
I'm pretty sure its just the DispGraph commands at the moment but please report if you find any more that do that!
1037
« on: July 19, 2010, 01:21:08 am »
Hmm... although it is technically possible, I was thinking I would just have a different way to add subs form external program data. But that would be cool to have an option to compile for Axioms. The only problem is that the current Axioms are too primitive to handle axe calls right now, but that is something I will definitely add later. I will play around with this idea and see if it's possible.
1038
« on: July 19, 2010, 01:12:31 am »
Nope, I still can't figure it out 
1039
« on: July 19, 2010, 12:59:24 am »
 Wow! And its so true too. The sad part is they've actually gotten even worse over time!
1040
« on: July 19, 2010, 12:53:09 am »
That looks nice, I love the car too! Someone should make robot unicorn for the calc! 
1041
« on: July 19, 2010, 12:42:40 am »
When I finish the Doc, I will mention which commands are safe to use with interrupts. I think only the 4 level grayscale is unsafe, but you NEVER want to have drawing as part of an interrupt because it can interfere with a lot of other things and is very uncontrollable. You can't really have the LCD routines interrupt driven otherwise you have to disable interrupts when drawing sprites so that the screen isn't drawn with incomplete sprites. But that's what usually takes up most of the processing and will completely ruin the timing aspect.
Instead, you want to make your interrupt just be a timer and that's it. That way you can have your main routine wait until its time to draw before actually drawing and only when its ready to draw.
1042
« on: July 19, 2010, 12:30:21 am »
Happybob, I would appreciate it if you could spend a little more time forming your sentences with correct punctuation and grammar because it becomes difficult to read and especially for a bug report, clarity is really important.
For your first point, the back buffer used to draw grayscale is the same back buffer used in the Recalpic and Storepic commands. If you want to back up a grayscale screen, you have to create 2 additional buffers with Zeros(768) and then back up both the front and back buffers to each one using the Copy() command.
Your second point, the OS getkey command does not work with interrupts. You will have to use direct keys instead like getkey(15) for instance.
Third, you mentioned to me in your PM that your AXEGUESS example program was not correctly returning random numbers and was the same number every time you played the game. Has anyone else had a problem with this, especially if you use the modified OS by BrandonW.
1043
« on: July 19, 2010, 12:20:36 am »
I think that would just be confusing especially since it used 2 sets of parenthesis. The reason I can't have custom names for the Axiom tokens is a lot more complicated than that. Probably what I will do is have a set of tokens (For instance, the 12 parametric tokens) be named really generic things like Draw1(), Draw2(), Swap(), In(), Out(), New(), Delete() etc. that are specifically reserved for axiom use.
1044
« on: July 18, 2010, 06:04:49 pm »
DJ, that just reminded me, I made a new player that automatically adjusts the timing based on the number of chords of each beat. However, quality begins to suffer when there are chords greater than 3 notes at once. However, its much more on beat and than the previous player. Also, I threw in a cool visualization 
1045
« on: July 18, 2010, 03:50:24 am »
Yeah, its the drawing itself since you're drawing twice as many sprites, each one to 2 buffers.
1046
« on: July 18, 2010, 03:25:02 am »
All the routines are almost exactly the same speed since they are limited by the LCD speed rather than the CPU speed. Even if I were to write an 8 level grayscale routine, odds are, it would be just as fast as the 4 level or the 3 level or the monochrome. The only speed you would be gaining from monochrome is that you don't have to update the LCD as often.
1047
« on: July 18, 2010, 02:52:57 am »
Nope, the LCD is so slow that if you try to write that data any faster than its slow speed, it causes weird graphical glitches. Its more efficient to have the routines in 6MHz because then I don't need to add as much extra pausing code. Even the 4 level grayscale that calc84maniac wrote was too fast for even 6MHz so I still need pauses, just not nearly as many as I would in 15MHz mode, so you end up with a routine that takes less memory.
1048
« on: July 18, 2010, 01:54:54 am »
In case you want a more technical explanation why you can't use bcalls that use data in the app, here it is. The entire readable memory is divided into 4 sectors each 16KB in size. There are many pages, but they have to swapped around and replace an existing page to be used in that sector. Apps execute in the sector which is from $4000 to $7FFF as I'm sure you are aware. It is write protected, but permits reading and executing. The 1st sector is OS stuff and the last 2 are ram, programs, and the sp stack in normal circumstances.
Now here is where it gets interesting. The operating system is much larger than just that one page, so when you make a call to something like _PutS or _DispImage the calculator has to swap in the page of the OS that has that routine in it. And guess which sector it uses? Its the one at $4000 where the app is. That means your page is swapped out so the OS can call it's routine. Now when it tries to read the data you passed to it, its just going to be some random junk on that page and not the actual data you intended since your page isn't at that location anymore! That's why you either copy the data to ram or write your own routines to use it.
1049
« on: July 17, 2010, 11:31:54 pm »
It is not possible to overload built-in commands because they're higher on the parsing hierarchy. However, You can overload other Axioms by declaring your axiom ahead of the others.
Unfortunately, this leaves the possibility of new Axe Parser commands overloading your existing Axioms as new versions come out which is why I don't think you will see many Axioms until the entire Axe language is completed and then the remaining gaps need to be filled.
1050
« on: July 17, 2010, 08:41:33 pm »
Its nowhere near done and it won't be released until after 0.4.0 comes out. Currently, the files are exactly 8 times smaller than the original wave file, but that is with no compression, I will add compression later. I'm still trying to figure out how to convert the 8 bit signal to a single bit one, this is the best I've got so far but I know I can do a lot better. If anyone knows the algorithm or where I can find it, that would be really helpful! Especially if you know how the RealSound algorithm works or similar player.
Here is a sample executable, it doesn't sound good, but at least you can hear it on wabbitemu. Its awful on a real calculator though, so test it on the emulator.
Pages: 1 ... 68 69 [70] 71 72 ... 135
|
Show Posts
