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 ... 59 60 [61] 62 63 ... 135
901
« on: August 18, 2010, 04:41:32 am »
I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.
By the way, that reminds me of a completely unrelated point. Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space? I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions. The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier. Would anyone be against changes like this? As always, it only affects Axe source code.
902
« on: August 18, 2010, 02:34:02 am »
Yet another alternative would be to create a value jump table which doesn't have to rely on ordered values, rather, on specific values. Like let's say you need to jump to one place when a is 20, another place when its 60 and another place when it's 250. You don't want to make a 250 valued jump table with lots of empty slots for only 3 labels. This is an optimization I use a lot in Axe Parser for deciding what to do with each token.
;I use these series of macros to make the code more readable and easier to type
#define JTABLE call JumpTable
#define JT(xx,xxxx) .db xx \ .dw xxxx
#define JTEND .db 0
;'a' holds a value and you want to jump to the label associated with the value.
JTABLE
JT(value1,label1)
JT(value2,label2)
JT(value3,label3)
;...
;...
JTEND
;This is the jump table routine
JumpTable:
ex (sp),hl
push bc
ld b,a
JumpTableLoop:
ld a,(hl)
inc hl
or a
jr z,hJumpTableEnd
cp b
jr z,JumpTableEnd
inc hl
inc hl
jr JumpTableLoop
JumpTableEnd:
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
hJumpTableEnd:
ld a,b
pop bc
ex (sp),hl
ret
I know the routine is much larger, but that's because it comes with a lot of other features and if you use it as often as I do, it really saves space in the program. The advantages are that it preserves all registers in all cases and if the value did not match any of the jump values in your table, then the routine comes back and continues executing after JTEND. By the way, you can't use 0 as a value for 'a' since that signifies the end of the table. It probably could use some optimization too.
903
« on: August 18, 2010, 01:58:57 am »
I forgot to address the break and continue idea. Those are both definitely possible, it could even be used in If and Switch statements which would be cool. Finding a token in a convenient menu might be a challenge though.
Sending multiple bytes is simple, I tested a program that sent the entire graph buffer from one calculator to the other and it took less than half a second. In fact, it is easier and more reliable to send a section of ram than to send individual values so I would recommend that you store all your sending values in consecutive ram addresses to make it easier.
Pixel swap might be nice, but I don't have a good token for that. Maybe I can put it in the same place as Pt-Mask.
904
« on: August 18, 2010, 01:39:43 am »
Hey that's cool! Porting a program an excellent way to learn Axe given a background in BASIC.
By the way, would a >Hex command be useful? I already have a >Dec, >Char, and >Tok so in a similar way I can add a >Hex. There is even a really cool optimization for it that uses the daa instruction which is something I've never used but always wanted to.
905
« on: August 17, 2010, 07:23:43 pm »
OMG this is hilarious!  View the page source near the bottom, make sure you have word-wrapping on. In firefox, you can go to veiw->page source and then view->wrap long lines. Offical website.
906
« on: August 17, 2010, 05:44:46 pm »
Yes, the bitmap command is not compatible if used with picture data stored in the app. It will work if the image is copied to saferam or an unarchived variable though.
907
« on: August 17, 2010, 04:35:21 pm »
Well, since its not for the contest anymore, it will certainly be easier to debug and you can post the source code directly. The problems you seem to be having are really not Axe related but usually programming in general, that is the same type of problems you would get had you been working on a BASIC program or Java or C. I'm not sure if Axe is the best language to start off with because it is a mid-level language that requires more experience with programming languages to be good at. That doesn't mean you shouldn't work on Axe projects, it just means that you're going to need a lot more guidance and assistance since you're learning the fundamentals of programming at the same time as the difficulties of Axe itself.
calcdude said the reverse when he was trying to explain what runer meant so that probably let to more confusion. What they were trying to say was that you first set the X variable to 0 then have a conditional "Is X zero?" in which case it will always be zero since you just set it to that. You have to set X to 0 outside of the main loop near the start of the program so that it doesn't keep resetting it back to zero after each iteration of the loop.
908
« on: August 17, 2010, 04:21:20 pm »
Actually, the limit is less than that. The calculator won't load the program in ram properly if it's above around 8150-ish, I'm surprised you were able to execute it fine all this time. I'm afraid I'm not sure exactly what the problem is either.
909
« on: August 17, 2010, 02:26:08 am »
That's interesting Qwerty.55 I heard that the new Math Print feature can cause some incompatibility with Basic programs, I hope that isn't the case, but no one else has reported the problem before... And lol, at first from reading your report I thought you actually converted the entire HEXPIC program to make it Axe compatible and got it to work, that would have been amazing. 
910
« on: August 17, 2010, 01:40:35 am »
Well the demo that I downloaded was a program. Its still available to download on his website I think.
I've been really busy this week so far and I'm leaving for school soon so I'll try to get a new version up soon, but not much new stuff will be added. The one thing I have had time for though is a complete example game which I'm about halfway though, it will be the final example program and downloadable individually as well. It's based on another game from Warioware that no one's heard of and its coming along very nicely.
Initially, I though I would have the final release nearly complete around this time, but I've decided instead to continue working on this a little more instead of compromising features. Updates will be more sparse though since college is starting again but I plan to finish around the time of the contest deadline or shortly after. There will still be updates after that, but I want a very stable, safe, and bug-free version out by then which will be 1.0.0
911
« on: August 16, 2010, 01:51:24 pm »
You don't need to check because I doubt your app signer will sign an app that's too large. But I use this:
#define VALIDATE(last) #if ($+0 > (last)) \ .echo "ERROR: MEMORY: " \ .echo ($+0 - (last)) \ .echo " bytes too large\n" \ ld q,q \ #endif
So then I just do VALIDATE($7FBD) at the end of the program. The lower size is to give enough room for the signature. Its great to use for any self modifying code that you copy to ram to make sure you don't overflow the buffer. Spasm has many of these macros built in as well. The ld q,q is just there to generate an error by the way.
912
« on: August 16, 2010, 01:39:42 am »
Not sure yet. Most likely 'yes' as a way to promote my updated Axiom engine (which isn't near finished yet). Calc84maniac's is great, but it relies on too much self modifying code and unrolled loops. Luckily I found a simpler source for a different mode 7 engine and after some major optimizations, you don't notice much speed difference between this and the F-zero engine. I found enough optimization to offset the SMC removal with even more extra speed and the Axe routines seem to suffice for the multiplication with very little speed loss. This will of course be a "15MHz recommended" command because I can't see it playable at a decent framerate without it.
@Builderboy its possible... I'll see what I can do.
913
« on: August 16, 2010, 01:25:45 am »
What you can do is "inflate" the value to get more accuracy. 256 is a great number since it's very optimized in both division and multiplication. Since Axe variables hold 16-bit numbers, you can use the lower byte as the decimal and the higher byte as the number. 9.8 can be represented by 9 + 205/256. You get your inflated number by multiplying by 256 so that's 9*256 + 205 = 2509 == 9.8 as an inflated decimal. You can treat this number like any other number. If you add 1 to it, you're really adding 1/256th and adding 256 is like adding 1, etc. When it comes time to display the point, just divide by 256 so that you recover the integer part for the pixel. So you're doing math with the precision of 1/256th and then just drawing it to the nearest pixel. EDIT: Damn! I knew I'd be ninja'd 
914
« on: August 15, 2010, 09:07:39 pm »
Are interrupts enabled and in "im 1"?
Pages: 1 ... 59 60 [61] 62 63 ... 135
|
Show Posts