So, Kerm and I recently went through and did a huge bulk of work on the Prizm xml file, to get SC to handle Prizm and g1m file types (both seem to mostly use the same xml, Prizm has a few more characters than earlier calc models)
What would it take to get this integrated into Tokens?
I'd love to see it expand into the Casio formats a bit, if at all possible
Send me an XML file with token definitions.
I think Kerm has the absolute latest version of it, as I had missed a couple items in mine, plus he knows which characters need to be blocked from the g1m format. I'll see if I can get him to post it or send the information to you.
For a future update, when using the Block count function, could it add a soft grey - or some other indicator for how many spaces over it goes to the right for each Then, While, or Repeat it comes across? That'd be awesome if that's possible
Still need to get Kerm to post in here about the g1m and g3m formats.
I've rewritten the tokenizer. If you guys could give it a test for me to see if things are still working right, that'd be great:
http://merthsoft.com/Tokens.zip
Preliminary testing with the latest build available from your website suggests that all TokenIDE features work in Windows 10.
ordelore wrote:
Preliminary testing with the latest build available from your website suggests that all TokenIDE features work in Windows 10.
Thanks for testing that. I'm glad to hear that, as TokenIDE is an invaluable tool for me for creating xLIBC tilemaps and background images.
*bump* If you try to open a full-color PNG image without switching to "full565" first, TokenIDE throws an exception about indexed colors.
Edit: Also, it won't let me save a 565 image with 32 colors as a 32-color xLIBC background. Is that accurate?
KermMartian wrote:
*bump* If you try to open a full-color PNG image without switching to "full565" first, TokenIDE throws an exception about indexed colors.
Please make sure you're testing with the most recent version before submitting bug reports: http://merthsoft.com/Tokens.zip. Because the most recent version has a fully-rewritten tokenizer, I'm waiting for more testing before officially releasing it. Incidentally, I just uploaded a new version there which fixes a bug with 32-color images if they contain fewer than 32 colors. If your bug still happens, please send me the PNG, because it's working for PNGs that I have.
KermMartian wrote:
Edit: Also, it won't let me save a 565 image with 32 colors as a 32-color xLIBC background. Is that accurate?
Yes. 32-color images use the xLIB palette.
Feature request!
For Pokemon Purple, I was using large sheets of graph paper so I could put the characters in place for the maps and make sure things were lined up.
I was wondering if Tokens could offer something similar, where a user could change the amount of rows/columns are displayed, and tie in the pretty print (where theta becomes θ) so people could make maps, and then have it where it can be exported or copied out as a string, with blank cells being spaces. Being able to highlight the string to send back to the tool would also be handy.
tifreak: Very handy idea. I will think about it.
Meanwhile, update!
I've now completely rewritten the detokenization process to utilize the new efficiencies of the tokenization process I rewrote earlier. Both things are now much faster (proven with profiling!). Please test it out and let me know how it goes:
http://merthsoft.com/Tokens.zip
Also, for those of you who are doing dev with xlib, you'd probably do well to make these changes to you TokenIDE.ini file:
Code: 8xp=Tokens/DCS8.xml
8xv=Tokens/DCS8.xml
There is something very weird with TokenIDE. I opened the sprite editor, and make a basic sprite:
Then I saved it as a xLIB 32-Color Picture, and then closed the sprite editor.
When I re-opened it, I got this:
Am I wrong or...?
EDIT: thanks to Unicorn for using his spritesheet, I saved his spritesheet, and opened it with TokenIDE. That works properly, and it was not messed up. So saving is the problem I think.
I'm not entirely sure, but shouldn't you be saving spritemaps as an xlibc tile? I think thats what the save option is, its the first xlib option I think.
Unicorn wrote:
I'm not entirely sure, but shouldn't you be saving spritemaps as an xlibc tile? I think thats what the save option is, its the first xlib option I think.
That makes no difference, again the whole spritesheet is messed up.
What dimensions did you make your spritesheet? TokenIDE (and xLIBC) expect the spritesheet to be 64 pixels tall, and if it's not, when you re-open it, it will open as if it was 64 pixels tall anyway.
KermMartian wrote:
What dimensions did you make your spritesheet? TokenIDE (and xLIBC) expect the spritesheet to be 64 pixels tall, and if it's not, when you re-open it, it will open as if it was 64 pixels tall anyway.
Wow, that was indeed the problem. I thought TokenIDE did that automatically, but not . Many thanks!!
It warns you when you save it if it's not the right dimensions.
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
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