Errors found so far in AOD, going from Prizm to g1m, copy-paste:

e -> Dsz
E -> e^
F -> F-Line
PV -> PxlOff
Prog -> PxlChg

Going to go through them, get them all ported and sent to the calculator, and see what else buggers up, once you can fix these issues. I just fixed the file as it should be on the calc, if you'd like me to send that back to you? Well, not going to wait for permission, I'll just do it anyways, if you need it.

I also went and uploaded the AODFIX program back through SC3, and it appears normal. I really don't know what's up.
As Kerm works on the picture format of the fx-9750gii, and was wondering on size, I decided to write up a little program to figure that out. I've found out a few things.

You cannot put a pixel on the very left column, or very top row, it gives an Error Argument.

Going up and down is values 1-63
Going left and right is values 1-127

Essentially:


Code:
ClrGraph
1->A
1->B
1->W
While W=1
PxlChg A,B
Getkey->K
If K>1
Then
PxlOff A,B
IfEnd
A-1((K=28 And A>1)-(K=37 And A<63))->A
B-1((K=38 And B>1)-(K=27 And B<127))->B
WhileEnd


Also updated the above list where I found 2 more broken tokens.
As a sanity check, I would like to modify the header of the AOD.g3m program to turn it into a g1m and see what happens. It is possible that the tokens do not in fact match up and that I was mistaken about that, although I really hope that is not the case.
Go ahead and shoot it my way Smile
tifreak8x wrote:
Go ahead and shoot it my way Smile
I will be viewing and giving presentations all day, so it may be later this evening before I am able to send it your way. I look forward to seeing what it reveals, and thank you for your continued patience.

Edit: I realized that was not necessary after inspecting the files that you sent to me at the end of your time on HCWP last night. I added a function to my preprocessor script that checks for duplicate tokens, and lo and behold:

Code:
Parsing ../xml/fx9860.xml...
Found 1 groups in ../xml/fx9860.xml
Warning: Token 'c' double-defined
Warning: Token 'F' double-defined
Warning: Token 'd' double-defined
Warning: Token 'i' double-defined
Warning: Token 'C' double-defined
Warning: Token 'E' double-defined
Warning: Token 'b' double-defined
Warning: Token 'e' double-defined
Warning: Token 'Next' double-defined
Warning: Token '|-' double-defined
Warning: Token 'Prog ' double-defined
fx9860: Max token length = 18
I will figure out what those are supposed to be ASAP. I simply need to make an artificial program that contains those characters and see what they show up as on a real Prizm.

Edit #2: I appear to have fixed these all. Please run your programs through SourceCoder 3 again and see if any other token gets replaced with the incorrect equivalent.
Well, it's a LOT better. An issue I've found, not sure wtf happened

What should be If J<3:Then turned into if J@:Then

This <3 seems tied to @ somehow, as I've found evidence in another program of it.. I'm correcting them as I find them, will edit if I find more issues.
Yes, the <3 is the heart symbol on the Prizm, and therefore also in the token set for the fx9860/fx9750. Try using <\3 to force it not to combine the two characters into one token.
Any chance, for simplicity's sake, to make that |<3 for the token set? I think it's a better idea to have | infront of all special characters like that, so it doesn't interfere with normal coding. IF not, that's okay. So far, I've fixed about half a dozen instances, I don't remember there being many more, so hopefully the game itself should start being bug free.
tifreak8x wrote:
Any chance, for simplicity's sake, to make that |<3 for the token set? I think it's a better idea to have | infront of all special characters like that, so it doesn't interfere with normal coding. IF not, that's okay. So far, I've fixed about half a dozen instances, I don't remember there being many more, so hopefully the game itself should start being bug free.
That's fair, I can certainly do that. I think that's similar to the ambiguities with the bold arrows on the TI-83 Plus/TI-84 Plus. Are there any other such character combinations that turn into a single token but in a less-confusing world would not that you've noticed so far?
At the moment, I have not noticed anything, but I don't really know what character combinations there are for the special characters. Do you have a list somewhere I could look at? Smile
tifreak8x wrote:
At the moment, I have not noticed anything, but I don't really know what character combinations there are for the special characters. Do you have a list somewhere I could look at? Smile
I could just send you the token definition file, but that would be rather tedious for you to browse. I'll do that myself for now and try to fix anything that seems illogical.

Edit: I have done so, and resolved a number of hard-to-type tokens. I didn't find any obvious annoying ambiguities.
I went through and re-exported them out, and so far, it seems to be happy Smile I'll play around with it for a bit more before I go releasing it, since we need that portion of the archives generated anyways.
tifreak8x wrote:
I went through and re-exported them out, and so far, it seems to be happy Smile I'll play around with it for a bit more before I go releasing it, since we need that portion of the archives generated anyways.
I'm glad to hear that it looks good, although I of course will be more than happy to address problems with SourceCoder's program export or with the Prizm/fx9860 tokens.
Oh yeah, one thing, are you able to set that drop down menu item to the g1m format when that's select from new file? It might cause confusion for people otherwise. Otherwise, all is good.
tifreak8x wrote:
Oh yeah, one thing, are you able to set that drop down menu item to the g1m format when that's select from new file? It might cause confusion for people otherwise. Otherwise, all is good.
Oh, did I still not resolve that? I thought that was working now.

Not-a-real-edit: I see that it still is not working. I'll try to get to the bottom of this.

Also-not-a-real-edit: This has now been repaired.
I am wondering if 3-bit g3p files have any kind of transparency support like 8xi files on the CSE?
DJ_O wrote:
I am wondering if 3-bit g3p files have any kind of transparency support like 8xi files on the CSE?


Do you mean "transparency support" as the whole image having the same level of transparency, some pixels being transparent (like GIF) or being able to specify a alpha level foelr each pixel (like PNG)?
I don't think the latter is possible (3 bpp doesn't leave enough space for this); it is possible that the g3p file format includes a field for a picture-wide transparency level, but in my opinion this is unlikely. GIF-like transparency, where a certain color index can be defined as the transparent color, or a certain index is transparent from the beginning, might be supported.
Actually, the 3-bit g3p file format has 4 bits for each pixel, but in my testing the high bit in each nibble is ignored, leaving only the 8 colors we already know about (white, black, red, green, blue, cyan, magenta, yellow) as renderable in images. I believe there's no way to specify a transparent pixel.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement