Could SourceCoder support "large" images instead of assuming they won't fit ? I wanted to convert a 96x256 image into hex and make a program that scrolls through that image, but SourceCoder refused.

If I'm not mistaken the initial limitation to the size was not to make sure they fit but to mostly reduce load on our previous shared hosting provider as it's a smaller impact to the CPU than a larger image.

Now that we've been on our dedicated server for some time Kerm might feel comfortable to increase the size of supported pictures but that depends entirely on him. If he doesn't implement it you can always break it into parts and string the hex together after the fact right?

Just a feature request

Could SourceCoder save the language you set your project files to? Its not extremely important, just something I find slightly tedious to do when I need to change the language to Axe or something other than the default TI Basic for every file in a project.

In general it will already set the type of each file correctly when you load it. If you find an exception, please let me know, as that's a bug.

Here is a screenshot of when I open my Axe project up in SourceCoder 3:



It should be detected as Axe, unless I need to put in a special header?

I have a program that is named programCREDITS for a TI-84+CSE. I call this program from another program as such:

Code:


After having some trouble with TokenIDE changing prgmCREDITS to prgmCRedITS (due to the color command), I switched to Sourcecoder.
In Sourcecoder it reads it as the same. However when I transfer it to jsTIfied, it changes the name. In the program menu, the name is C(uparrow)BITS. When I try to run this from the homescreen it changes again to prgmC?BITS.

I have a feeling this is something like the PVPCRAFT bug.

Yes, it's extremely similar. Call it via "prgmCR\EDITS" in the code you've listed there.

I am sorry if I was misleading with the code I posted above. The problem is not with the actual code. Rather it is with the actual program name of prgmCREDITS.

I tried the above suggestion of adding the backslash and I still get the error message: ERROR UNDEFINED

You'll need to both change the name of the program to CR\EDITS in the name input box, and call it via prgmCRE\DITS (or CR\EDITS) in the parent program. I will soon get to implementing the more limited name tokenizer that will prevent this problem.

That fixed it. Thanks!

Source Coder 3 doesn't seem to want me to edit files. This is the same Google Chrome that has trouble with jsTIfied.

Can you tell me more about this bug? I assume the jsTIfied issue you refer to is the misaligned screen?

*bump* Did you ever find out more about this?

In other news, thanks to tifreak8x's work on his Age of Darkness Prizm Edition work, the support for ordinary and unusual Casio Prizm tokens in SourceCoder 3 is drastically improving. Please feel free to use SourceCoder 3 for your own Prizm programming work (you can import, edit, and export programs), and let me know if you run into any problems. I'm also strongly considering supporting older fx9860 (.g1m) programs.

I, for one, would be grateful for our g1m's overlordiness.. rule? That doesn't sound right..

Anyways, I'd be happy if .g1m would be supported 🙂 I'd like to figure out which calc uses the g2m format so I can get one of those and see what format that setup has in its header.

What would be cool is the ability to convert PNG/GIF/BMP files to FX-cg10/20 g3p files. I mean the low color ones that can be drawn directly on-calc that are like 84+CSE 8xi files, not the cg20-only files that are like 8ci files.

Some PRIZM BASIC programmers would probably like to have nice looking pictures in their games then have minimal movement during gameplay, but by using the 8 color files so that they can make their games run on the American models at the cost of having 8 colors instead of 65536.

Examples of pics that could probably be displayed on the calculator:

Can you either point me at format information about those files or send me a few samples along with PNGs of their contents? Thanks!

I do not have any info about the format and I think nobody ever bothered to look at it, but I got two samples below (copy URL in address bar):

http://www.omnimaga.org/pixel-art-and-drawing/mockups-'please-say-this-is-going-to-be-a-game'/?action=dlattach;attach=16815
http://www.omnimaga.org/pixel-art-and-drawing/mockups-'please-say-this-is-going-to-be-a-game'/?action=dlattach;attach=16816

I posted those for fb34ca9 months ago, because he wanted to look at the format, but he sadly vanished shortly afterward.

*bump* Based on those files and a few days of reverse-engineering, I succeeded in determining the obfuscation method used to hide the image data within the files. I have been able to parse the 3-bit-color g3p images, which for now allows SourceCoder to render them as images on a computer:



My next steps are as follows:
(1) Get SourceCoder to parse and display the contents of "full-color" picture files.
(2) Reverse-engineer the signatures and checksums used to verify that an image is valid.
(3) Check that a Prizm will accept these images, both for 3-bit and 16-bit images.
(4) Post a topic on Cemetech and discuss the moral and ethical implications of releasing this feature
(5) Release this SourceCoder feature, if the community decides that the ongoing lack of response from Casio as well as the ability of the TI-84+CSE to display full-color images and detailed non-full-color images means that no major detriment would come from making this tool available.

Looks awesome. I honestly don't think Casio is going to throw a huge fit over it, but I really wouldn't be one to say. They've obviously seen what we've done with creating an sdk trying to make our own C programs for the prizm. IF they had a real problem with us doing things for their calcs, I'd have thought they'd lock it down by now.

Good job so far Kerm. 🙂

Regarding the 16 bit images conversion, this might be controversial because this would circumvent Casio's protection against loading third-party images on American models. If possible, you should make 16-bit pictures cg20-only.


However, the 3-bit image format is not limited on any calc model. I can create/store/reload them perfectly fine on my cg10 with no modification in every OS, via the Sketch tools and the StorePict/RecallPict commands. It's just that creating the images directly on-calc takes an outrageously high amount of time (if I estimated correctly, the non-Zelda RPG style mockup I posted above would take approximately 2 hours to render via BASIC code). I don't see why 3-bit image conversion should be a problem, considering none of the calcs have limitations against that format.



For the time being, if I was you, I would only make 3-bit conversion public and perhaps cg20-only 16 bit conversion.



Suggestion: For 3 bit image viewing, try to add a SourceCoder feature allowing the user to view the images in true PRIZM colors if he checks a box. On the PRIZM, green is much darker than on the computer so maybe the user would like to see the result as it looks on calc.