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 ... 4 5 [6] 7 8 ... 135
76
« on: January 10, 2012, 07:26:15 pm »
But you can always store the data to static pointers first and then put them in the Data() after. 
77
« on: January 10, 2012, 07:16:26 pm »
@Runer, that wasn't what I was referring to... the actual lookup table is easy enough to generate already: "Hello"[00]"World"[00]"GoodBye"[00] etc. I was referring to a command that takes the table and an index and the returns the pointer to that string.
EDIT: Also, I just realized you were talking about something entirely different. That type of command is difficult with Axe's limited memory because you can't determine where to put the static data until the size of the Data() command is known.
78
« on: January 10, 2012, 06:57:48 pm »
Since I've seen this asked several times, I decided to add a command for it to the next version But for now, you can do this using the fact that each string is zero terminated. All you have to do is start at the pointer and then increase it until you pass N zeros to get the Nth string.
79
« on: January 10, 2012, 03:24:22 am »
Very cool! I'd like to see that code, how you accomplished it. And I don't mind if you show off the code here, I'm always willing to share code. The only reason I haven't open-sourced Axe is simply because of standardization. If other people were to modify and release the parser you could start seeing programs that each need a special version to compile and it can get annoying, these versions wouldn't get official updates either without a very active developer. By keeping it closed, I can ensure reverse and forward-compatibility in a simple single version. If you want to know how any chuck of the code looks though, I can always share.
Some things I'm particularly curious about:
- How do you know if the program has just been opened using only the token hook? Would this process work during an instant scroll as well? Even in DCS?
- What do you do (or prefer me to do) when there are more replacements than can fit in the buffer? Especially with long names, it could only hold 80 or so max.
- Are you sure this doesn't slow down the scrolling too much with all these replacements?
- The token numbers are difficult for developers to type in manually, any ideas of how I could generate a list of equates?
Unrelated, but the other thing I realized a while ago is that its too difficult for Applications to use the framework. All the absolute labels are in the $4000 range, and since an app is running here, I would have to generate an entirely new copy of the pseudo-lookup-table in order to change these addresses to the $8000 range. And since space is a problem, I doubt I will be able to do that.
80
« on: January 08, 2012, 03:53:54 am »
I think the ldir is the best route. I mean you'd save less than 10 bytes if a bcall did exist, and plus its faster. The one you linked to is not the version Axe uses, it had the same bug as my previous attempts. The fixed version I posted on cemetech here.
81
« on: January 08, 2012, 03:34:17 am »
Blame TI for that. If you want to draw directly to the back-buffer, you'd have to make your own font routine, which is easy, but takes forever to get all those letter/number/symbol sprites as well as a lot of space in the program itself. But sometimes a kick-ass font can really improve a game's look! 
82
« on: January 08, 2012, 03:29:24 am »
Hmm interesting. I'll look into it, it might have something to do with the parsing of sub-programs.
83
« on: January 07, 2012, 05:57:02 pm »
If you want to use the nib{} command to avoid the unoptimized division and multiplications, you could do it like:
GetCalc(Str01)→V
For(A,0,175)
{L1+A}→nib{V*2+A}
End
And to decode, its as simple as reversing the store:
GetCalc(Str01)→V
For(A,0,175)
nib{V*2+A}→{L1+A}
End
84
« on: January 07, 2012, 12:22:05 pm »
Not all pixels are being mapped to because you only Pxl-On if there was a Pxl-Test. This restricts sprites to have the same number of pixels in the best case even though there could be a lot more when the sprite is rotated and I'm not even including the overlapped pixels. Instead what you have to do is get a bounding box of the destination zone (which could be the whole screen) and then run for loops over the region to see if each destination pixel belonged to the original image. So you need to find the inverse in your eqaution first of all:
XI = ([X - XOffset] * cos a) + ([Y - YOffset] * sin a)
YI = ([Y - YOffset] * cos a) - ([X - XOffset] * sin a)
Something like that... So you for loop over the X and Y bounding box, pixel test if (XI,YI) is shaded, and if it is, fill in (X,Y)
85
« on: January 06, 2012, 11:21:18 pm »
Yes, and also the extra space is required to be padded with 0s in the case of widths that are non-multiples of 8.
86
« on: January 06, 2012, 11:16:57 pm »
Both formats are correct but work with different commands. If drawn using the Pt-Logic() commands, it needs to be in the "tilemap" format, but if drawn with Bitmap() it needs to be in the bitmap format. So rather than changing your IDE, you should probably just add a radio button/checkbox to toggle which format the programmer is trying to use.
87
« on: January 06, 2012, 07:03:49 pm »
Okay I have it mostly working now with the exception of Midi playback which I think is due to another missing DLL, but the rest of the program works. Unfortunately, its too big for an attachment here so I will look for another place to host it. EDIT: Here, try this: Download 4.52MBs
88
« on: January 06, 2012, 05:20:43 am »
Apps only need to be signed to transfer to another calculator. Other than that, its just like all the other apps. Axe corrected the trial app issue a couple versions back when apps used to delete themselves after 15 runs.
89
« on: January 05, 2012, 11:29:32 pm »
Oh yeah, I'll try installing it again. I wish it weren't so complicated, but I have to build it from source in order for it to compile statically.  Maybe I can just find all the DLLs and include those, but I have no idea which ones I would need. Another option is that I could just rewrite it in Java using swing, that might be easiest, but it will take some time.
90
« on: January 05, 2012, 05:33:26 pm »
To clarify, this is simply another option in the shell menu. The ion header is, I feel, the best option for Axe programs because they are compatible with ALL shells and can still be run from the home screen with Asm(). There is not currently a way to use the external routines from an app, although I could add another option for that later. Runer, as much as I agree that that would be ideal for advanced users, its quite complicated to implement and would be confusing to new users. I would like to keep it as simple as possible for the user and have Axe determine these things automatically with common case defaults. I am actually almost out of space in the Axe app as of now. The first page (all executable code) is completely full and I have to optimize sections of code just to add more features. The 2nd page (all data) only has about 3kb of space which is not a lot for future expansion. I will have to consider paged calls to the 2nd page soon if I can't find more things to optimize. I have not tested this with Mirage or Doors yet. I assume they will work, but you might have to disable interrupts at the start of the program (or I might have to add that as part of the header). I highly doubt you have to worry about anyone not using your stuff Quigbo, especially if it reduces their programs by 3000 bytes. I was referring to asm programmers not wanting to use it because usually they have different IO preferences and don't like dependencies. But I guess people did use the ion routines so maybe it could still be useful to them. I guess I could change the name then. I was originally thinking of calling it "Axis" but that has the same issue. How about "Toolbox"? Its kinda related physically since it's a 'box' around an 'axe'. I dunno, does anyone have other ideas for one?
Pages: 1 ... 4 5 [6] 7 8 ... 135
|
Show Posts
