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
1
« on: May 27, 2012, 03:12:03 am »
It can already emulate a standard mouse, touchpad, and stylus. So everything in that respect is already reverse compatible. However, those devices all only have 2 degrees of freedom which is kind of a waste of another dimension entirely. The cool part comes in when you actually can use all 3 dimensions to physically manipulate objects in real 3D space, and 3D screens and headsets make the experience even more realistic.
2
« on: May 26, 2012, 02:45:04 pm »
Hi guys, I know I've been taking a break for a while from Axe development and the forums here, but I'm pleased to announce that starting tomorrow, I will be resuming  As some of you know, I have been spending a lot of time at work and school, but now that I've graduated, its going to be just working full time. What I did not say before is the company I am working for because previously we were in stealth mode meaning that most things had to remain secretive. But now that we did our public launch last Monday, I can talk more about it. The company is called Leap Motion and we create 3D input device that tracks precise motions of your fingers and hands in full 3D (sub-millimeter accuracy). It will eventually be integrated into monitors, phones, and laptops as a replacement for touch screens and mice, but for now the device is standalone. Pre-orders ship out around December and you should see it on store shelves shortly after that. If you have some cool ideas and a good coding background, you can get a free developer kit if you apply now, so encourage you to apply if you're interested. By the way, another community member is also interning here via a recommendation.
3
« on: April 19, 2012, 04:01:11 am »
Wow! This is quite an impressive accomplishment!  Are you planning on extending the functionality given that you have the resources of a computer or are you planning to continue improving emulation to make it more similar to the calculator language?
4
« on: April 17, 2012, 04:02:59 pm »
Hehe, just saw this. Thanks guys ^_^ As you've probably all noticed, I haven't been too active lately... Its mostly due to school and work loads. Normally I'd release what I have so far for the next Axe update, but unfortunately I'm rewriting the entire optimizer and parser once again. This time its to convert all parse tables to binary search trees, speeding up normal compiling faster than even the zoom feature! This required me to write my own assembler (finished) to do really complicated code restructuring automatically, like presorting lists and creating trees. But I still have quite a bit to go rewriting the optimizer on the assembly side... Thanks again for all the support 
5
« on: March 28, 2012, 08:50:49 pm »
Hmm... I'm not familiar with asm_data_ptr1 or asm_data_ptr2, I've never used them. Can you explain a bit more how they work? I can't find them on WikiTI.
6
« on: March 18, 2012, 11:52:27 pm »
Why can't custom constant names start with a lowercase letter? I feel like the reason for not allowing this was only to deal with binary numbers being represented as starting with b, but they aren't any more.
There isn't a syntax reason. Mostly, it allows me to use them for other purposes in the future if I ever decide on a use them (such as low level register access, low or high byte access for variables, tables, etc. To bring back another issue, I am basically going to have to write my own assembler or part of an assembler to build binary trees and hash tables because otherwise it would take forever to code it by hand and have to change every time I add new things to the lists. But it should be fun. I'll probably use python since it can do that kind of stuff with just a day or two of coding. Ignore this statement if you have no idea what I'm talking about, but the biggest part of the compiling time is searching through lists, and this should make that faster.
7
« on: March 18, 2012, 11:00:02 pm »
To answer the question of doing arbitrarily complicated "advanced" math in Axe (A system which does not support many math functions) is to approximate using more simple functions. This is in fact what Axe does natively for sin, cos, arctan, etc. I will demonstrate how I would approach this problem, the same way I did those other functions. Hopefully this will be helpful to everyone. Take a look at how arccos looks:  First things first, since we are using 8.8 and brads (binary radians) the same picture should range from -256 to 256 left to right, and 256 to 0 up to down. Next, does the shape look like anything simple that you're familiar with? What if we split it into 2 mirror images at the center? Yes! The left and right halves look like rotated and/or flipped square root functions, close enough!  So what are the functions for left and right? Lets do the right side first. By the shape, we know its going to take the form of sqrt(-x). But its shifted to the right by 256 so sqrt(256-x) and also we want it to go through point (0,128) and so when x=0, sqrt(256-x) should be 128, but its actually just 16. So multiply by 8 and finally you get y = 8*sqrt(256-x) for the right half. Follow a similar process for the left and you get: y = 256 - 8*sqrt(256+x) One cool thing to notice is that in fixed point, all math is modulo 256 and so 256.0 is actually the same as 0.0 so these equations strangely optimize to a case where it looks like we're taking the square root of a negative number all the time, but that's just modular arithmetic for you! This also forces us to add an extra special case. y = 8.0*sqrt(-x) when x>0
y = -8.0*sqrt(x) when x<0
y = 128.0 when x=0So now the code should be easy and straightforward. Here is an unoptimized version for readability: :Lbl acos
:If r1=0.0
: Return 128.0
:ElseIf r1<<0.0
: Return -√(r1)r*8.0
:Else
: Return √(-r1)r*8.0
:End
This is all untested, but I believe it should work
8
« on: March 18, 2012, 05:37:39 pm »
By the way, if you happen to be using 4-level grayscale instead of 3, make sure to add two r's to the DispGraph instead of one.
9
« on: March 18, 2012, 05:20:08 pm »
Hmm... I guess I did have it update twice as often to make it smoother, so I can reduce the updating a little more to be like how it was. However, I was actually thinking of optimizing the peephole opts into a lookup-table so that it performs significantly faster than the current linear search through all the opts. It might even be possible to compile at nearly the same speed as the zoom option, in which case I could remove that feature, but that's optimistic, we'll see.
And Darl, I see what you mean now. Since the size is now computeable during the first pass, I can show the message during the 2nd pass rather than after. That's a good idea, I'll add this in the next update.
10
« on: March 17, 2012, 06:27:42 pm »
As far as I know, if you use a custom named variable, it is impossible to modify the location it points to, as it is treated as a constant pointer. It is also impossible to have only a single byte custom variable as far as I know.
Actually, you can have a single byte variable with custom names just as you can do with the regular variables. Using the r modifier after the variable name treats it as a single byte value rather than a 2 byte value.
11
« on: March 17, 2012, 06:06:04 pm »
It should only display the warning after the 2nd pass has finished. Are you saying that its been showing on a different pass?
12
« on: March 16, 2012, 06:41:10 am »
This is an odd solution, but it might be fast enough to work. Consider the following situation: Your foreground layer is white everywhere there is no collision, and dark everywhere that you can collide, this is before the player is drawn of course otherwise there would always be a collision. Now, do a pt-get() on the location you plan on drawing the sprite. You can now scan this region R and the original sprite S and if ever the boolean operation "S and R" is true, you have a collision! Here is some sample code:
:.Example use
:CHECK(X,Y,Pic1)
:Lbl CHECK
:pt-Get(r1,r2)->R
:For(A,0,7)
: ReturnIf {R+A} and {r3+A}
:End
:Return 0
This can be optimized slightly, but this should make clear what is going on in the code. Keep in mind this code only works assuming my original condition. You might have to use another buffer for the sprite "collision masks" if you are already double buffering prior to spriting.
13
« on: March 14, 2012, 03:17:18 pm »
You can for-loop the rectangular boundary of the region you want to illuminate (could be the whole screen) and then for each pixel, calculate its angle to the light source. Only turn on the pixel if the angle is between the 2 angles of the light. You can calculate the angle from pixel (x,y) to light source (a,b) with tan-1(x-a,y-b)
14
« on: March 14, 2012, 04:36:21 am »
bit 5,a
bit 3,aThese will set the hidden flag in the F register in the same way as, and in addition to, the z flag. Obsucre? Yes. Useful? 
15
« on: March 14, 2012, 03:57:59 am »
Thanks guys! I know my activity here has been pretty low over the last few weeks, I've been really busy with interviews and job search related tasks for after graduation. But despite this, I've slowly added about 10 new bug fixes and features over the last month so I'm almost ready for another release. I'll be more active once I decide on a job offer in a few days Boy, this is such a difficult and important decision, more so than colleges.
|
Show Posts