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 ... 71 72 [73] 74 75 ... 135
1081
« on: July 11, 2010, 05:24:00 pm »
No, I mean it will only import 12 rows and 7 columns of tiles even if the pic is the full 96x64 pixels. All pics can be read from archive.
1082
« on: July 11, 2010, 04:52:47 pm »
The signed multiplication is performed using the high byte as the integer part and the low byte as the decimal part returning a number in the same format.
I don't do too much lower level programming, so from what I know this sounds like decimal-multiplication. Which would be extremely useful. My question is, which byte is the high byte? The first one?
You can't really think of it as "first" and "second" because they're stored in registers one way and in memory the opposite way. I don't know a better way of describing it, but the high byte is 2329 and the low byte is 23 29 where this is a hexadecimal representation of your favorite number. 2 => E200 = 512 1 => E100 = 256 .5 => E80 = 128 pi => E324 = 804 etc. Also, the reason there is no FP division is because you can multiply by decimal numbers. Keep in mind, if the answer is 20 it won't return 20, it will return a number in FP format which is 20*256 so if you want to immediately round and display an FP number X you have to do X//256. EDIT: I COMPLETELY forgot to mention another feature! When you absorb pics, they can now be in archive and pictures of larger sizes are now supported and will be imported to their original size. However it has no effect if imported as a tilemap.
1083
« on: July 11, 2010, 12:04:44 am »
Even as the creator I don't know the speed of the routines since they're different depending on a lot of factors like where they're drawn, how big they are, if there's clipping, etc. I can only give you a rough estimate without physically testing it. I could be totally off too.
1084
« on: July 10, 2010, 11:58:30 pm »
I don't know they sound about the same. You can test these you know with a loop. Either use an interrupt counter or a stopwatch.
EDIT: By the way, you also have size to consider. The rectangle routines are nearly the size of the sprite drawing routines and having 2 of them (Rect and RectI) when they don't need to be there is really a lot of extra bytes, probably 200 extra combined.
1085
« on: July 10, 2010, 11:34:34 pm »
Yeah so let me go through a few of the new features.
First of all, FP multiplication and high order multiplication are very advanced features. Odds are if you don't know what those mean you probably won't ever need them. The only time you do need them is for extremely low level math.
The rectangles are all filled. The way to make a rectangular border is by drawing 2 rectangles on top of each other or you can just use 4 lines or even 4 rectangles of heights and widths of 1. By using the back buffer you can actually get some really cool menu boxes with different shades of gray from the border inwards.
The freq() command is no longer totally compatible with my MidiToAxe converter because the lowest note C is now actually so low you can't hear it, however the rest of the notes are still the same. I'll be updating the converter for the new format later anyway, so you'll just have to wait for that.
I think that sums up most of the FAQs I anticipate.
EDIT: also, I should mention, there are less than 100 bytes left in the app. I had to do some major parser optimizations to be able to fit everything. So this is the last version that will fit on a single page. From now on, Axe will be 2 pages (never more) and the next version will be 0.4.0 because I want to make sure I add enough new features to justify the extra page.
1086
« on: July 10, 2010, 11:23:18 pm »
Axe Parser
Gamma 0.3.3
New Features:- Draw rectangles and boxes.
- Draw circles.
- Interrupts are now compatible with applications.
- 2 New advanced multiplication techniques: Fixed Point and High Order.
- "Return" at the end of the program is automatically optimized.
- Error scrolling is more accurate.
- Simple application signing included.
- Import Pictures from archive.
- Support for full screen pictures.
Changed:- Freq() can now play lower notes, and only the tone "0" has changed.
- Fixed some issues with negative numbers.
- Fixed the Data() command. All numbers should work with it now.
- Pixel drawing far off screen is safe now!
New Example program: Fractal Explorer! You will not find a faster one for the calculator!
1087
« on: July 10, 2010, 12:35:32 am »
You might not need a pause at all if the framerate is low enough. Personally I am liking the 45 degrees right now. Even with a pause, I find it difficult to press 2 buttons at once with the same finger unless you're dragging your finger around like a touch pad which is not how portal would use it. Especially if you design puzzles where the 22.5 degrees is a necessity to solve then it could get frustrating.
In addition, I think it would be cool to have another button like the decimal point also pick up crates so that way its more ergonomic and you can move, fire a portal, and release a box easily at the same time.
1088
« on: July 09, 2010, 04:35:59 pm »
Thanks! I thought about doing it that way, but I couldn't figure it out, its smart to use the negative. 
1089
« on: July 09, 2010, 04:21:04 pm »
Oh, is that what it is! I couldn't figure out why that was happening in wabbit, it happens with the Axe Parser app too but that's just a wabbitemu problem.
I've confirmed that the dummy signatures are in fact causing the apps to delete after 15 runs, but when signed on the computer, they behave just like regular apps. An app resigner will be included in the next release. I will try to make the dummy signature more convincing so that the apps stay. I'll have to talk to BrandonW about that because I feel like I'm missing another piece of information from that conversation.
1090
« on: July 09, 2010, 04:04:07 pm »
You're allowed to use OS variables and its even encouraged. How else are you going to save your games? Appvars are OS variables, but if you wanted, you can use pics, strings, or other things to save data but I don't know why you would want to.
But I have a feeling most people who voted did not vote because of the contest, but because they want to make some useful editors for sprites, tilemaps, music, and programs which are significantly more useful with more OS var support.
1091
« on: July 09, 2010, 03:53:14 pm »
Yeah, I fixed that too. I couldn't believe how dangerous it was before. It required the high byte of both arguments to be zero but it never bothered setting them to zero because it assumed the input was already valid. That really wasn't safe I completely forgot it was like that until I started the circle routine and noticed that. Sometimes my optimizations compromise too much hehe.
1092
« on: July 09, 2010, 02:45:30 pm »
Actually that problem has already resolved itself differently than I though. First of all the reason it was so strange was the way it handles pixels because it makes a call to the built in pixel drawing command to save space. That routine is modular with base 256 so pixels way off the screen in any direction loop back. So it wasn't a problem with the circle radii at all. You can just draw the circle far off the screen and get the same problem. So I decided I just wouldn't add any more checks and just keep it the way it is.
And no, a check in assembly is 2 or 3 bytes for the entire code since I can use flags and its only a single byte number whereas the min and max commands are probably more like 9 bytes EVERY time you call the routine. Huge difference.
1093
« on: July 09, 2010, 02:31:15 pm »
The algorithm is like this to display a number:
.Z is the number you're trying to display
!If Z
sub(D,0)
End
While Z
sub(D,Z^10)
Z/10->Z
End
Where the subroutine D does something with the digit 0-9 and moves a cursor. This displays the number from right to left and does not add extra zeros or spaces to the front of the number.
1094
« on: July 09, 2010, 03:45:58 am »
Not again ahhhh...  This is like the 5th time I've had to redo the negative numbers. Is probably one of the most complicated parts about the parser since I not only have to parse it correctly, but also automatically optimize things like making a subtraction of a negative number an addition or ignoring double negatives for example. Its extremely difficult for 2 reasons. First of all, they don't behave like normal functions because they have no end parenthesis. It would be a breeze to implement Neg() as a function or even X% where % is some kind of postscript symbol like the "squared" button. But NO! I have to figure out where to put the closing parenthesis and its a lot harder than it sounds. In builderboy's problem it was putting the parenthesis like this: -({R)} so making R negative instead of {R}. The second reason negatives are annoying and confusing is that when the parser reaches a negative sign, it has no idea if the expression is a constant or variable because the 2 are handled very differently. I have to use some look ahead parsing for that which just complicates things further. Anyway, I've fixed the problem. Hopefully I will find a better system for this soon.
1095
« on: July 09, 2010, 02:33:04 am »
Whoops! What was supposed to happen was if the source is in archive and you try to scroll to the error it quits instead and if the source file is not found on the calculator at all... then something is terribly wrong so it gives an unknown error. I accidentally switched these 2 conditions lol.
Pages: 1 ... 71 72 [73] 74 75 ... 135
|
Show Posts
