I was trying to convert a 208x44 monochrome image. Not even twice the size of the screen. And last time I was trying to convert an image that was just 4 times as large as the screen but still smaller than once the size of an Nspire screen, even forgetting the fact that my image was saved in 8 bit format to save space while an Nspire image would probably be saved in 16 bit format.

For the second image, I was able to split it in 4 times 96x64 but I still used at least as much processor power as if the image was converted in one pass, and this can not be done so easily with dimensions such as 208x44. Not impossible of course, but a lot more annoying (because I need to interlace the produced hex codes, not just copy paste one beneath the other).
Yes, I certainly see your point about that. How do you feel about me making the limit 320x240 for logged-in Cemetech members? Would that fit all of the images you need to convert in the foreseeable future?
Well I can't tell about the future Wink
However, while I agree that 320x240 would be a great improvement and probably enough for my z80 needs, I thought about something that could be done. Would it be possible to have the restriction be based on size in bytes or pixels instead of dimensions ? I mean that instead of limiting to 320x240, you could limit to 76800 pixels. This way, people can also make images wider than 320 (but less high) or higher than 240 (but less wide), without wasting excessive power. And for huge images, there is still the possibility to split them into smaller images that have the right width.
For an update to SC3, I'd like to recommend a text adjustment on the main menu:

Under Casio, it says: "Casio Prizm BASIC: .g3m and .g3p"

I'd like to recommend removal of Prizm, or adding of the other fx models, and adding of the g1m file type being listed, please Smile I'd do it myself, but I don't have that level of access.
I updated it to the following. Thank you for the suggestion, sir. Smile

Quote:
  • TI-BASIC: .8** (such as .8xp, .8xi, .8xg, .83p, .8xs, .8ca, .8ci, etc.)
  • Casio Prizm and fx-9860/fx-9750 BASIC: .g3m, .g3p, .g1m
  • Image Conversion: .bmp, .gif, or .png
  • Data Conversion: .csv
Thanks for modifying so quickly. Smile
tifreak8x wrote:
Thanks for modifying so quickly. Smile
My pleasure; I appreciate your ongoing help in getting SourceCoder 3 to be even more powerful and featureful. Speaking of which, does this decoded .g1m picture file that I rendered match the original, including the solid black line at the right edge, or are there errors?



Edit: Turned out the answer was "yes". The photographs from tifreak8x and his fx-9750gII below show that SourceCoder 3 is now able to both import .g1m monochrome picture files and export the same files for display on-calculator. Unfortunately, it appears that the last row of these images is ignored, as on the TI-83/+/SE and TI-84+/SE calculators. As with the .g3p format, I will be documenting the .g1m picture format when I get a chance.

Congrats on getting yet another format working in SC! Smile I look forward to a day when SC3 handles all calculator formats that jstified can emulate calculators of Smile
tifreak8x wrote:
Congrats on getting yet another format working in SC! Smile I look forward to a day when SC3 handles all calculator formats that jstified can emulate calculators of Smile
Thank you! One of the things I've noticed is still missing from SourceCoder 3 is the ability to import one calculator picture format and immediately export into another calculator picture format; I didn't realize that was missing. Other than that, which calculator formats do you find particularly lacking?
Well, there is more than just the .8xp format, the 83 format is nearly identical, is it not? I'd really just like to see SC be able to handle all the calc types, 73 through 68k, though I know that's tantamount to a mountain of work. Pretty sure we have fully working xmls for the 73 and 82, though, already in Tokens, so that'd take most of the work out of it, wouldn't it?
tifreak8x wrote:
Well, there is more than just the .8xp format, the 83 format is nearly identical, is it not? I'd really just like to see SC be able to handle all the calc types, 73 through 68k, though I know that's tantamount to a mountain of work.
It's a mountain of work whenever we need to create a new token file (or cut down an existing token file) for a particular model. The other half is building the file parsers and generators to understand and produce the tokenized files with their headers and footers
Quote:
Pretty sure we have fully working xmls for the 73 and 82, though, already in Tokens, so that'd take most of the work out of it, wouldn't it?
It would take most of the work out of it. Unfortunately, I don't seem to have those XML files.
KermMartian wrote:
Hayleia wrote:
Could you please add support for z80 monochrome Axe/Hybrid images that are larger than the screen ?
I don't think the "uses processor power" argument is valid since when I try to parse my image, processor power is wasted by giving me results for CSE and Nspire even though I want it for monochrome z80.
You're right that it would make sense to not produce all of the output formats at once, and instead only generate the specific format that the user might want. How big of images are we talking about? I might consider allowing logged-in users to have a larger maximum image size than guests, since I could keep track of who was issuing jobs with large sizes.


Pretty please Kerm? Smile Just had to split my large CSE image up into smaller chunks in order to convert them. It is very useful if you just want to display a single-color image depending on the order of bits. The z80 monochrome image converter is really useful for this. Smile
MateoConLechuga wrote:
KermMartian wrote:
You're right that it would make sense to not produce all of the output formats at once, and instead only generate the specific format that the user might want. How big of images are we talking about? I might consider allowing logged-in users to have a larger maximum image size than guests, since I could keep track of who was issuing jobs with large sizes.


Pretty please Kerm? Smile Just had to split my large CSE image up into smaller chunks in order to convert them. It is very useful if you just want to display a single-color image depending on the order of bits. The z80 monochrome image converter is really useful for this. Smile
What size images are you dealing with?
Oh, they weren't too big, only about 208x32 pixels. The only problem was that the width was way to big. Smile
Bug (I guess)
I'm not able to select text in SourceCoder on Android.
Browser: Chrome
The default browser works but I can't select by long press (I use keyboard shortcuts).
MateoConLechuga wrote:
Oh, they weren't too big, only about 208x32 pixels. The only problem was that the width was way to big. Smile
Wait, for CSE images? It should accept up to 320x240 for converting CSE images, unless I misunderstand you.

CKH4 wrote:
Bug (I guess)
I'm not able to select text in SourceCoder on Android.
Browser: Chrome
The default browser works but I can't select by long press (I use keyboard shortcuts).
Hmm, that's weird. Can you place the cursor and then drag the selector handles to select text, or does that not work either?
That doesn't work because I can't get the handles. There is only the middle cursor selector.
KermMartian wrote:
MateoConLechuga wrote:
Oh, they weren't too big, only about 208x32 pixels. The only problem was that the width was way to big. Smile
Wait, for CSE images? It should accept up to 320x240 for converting CSE images, unless I misunderstand you.


No, I have these images stored as 1 bit per pixel. So it's basically a one bit per pixel any size sprite routine for the CSE; so that way I can output 8 pixels (Pretty much any color, actually, as long as I set the high and low bytes separately) with just one byte. The converter is very useful for this, as it outputs the monochrome image, which is one bit per pixel. Hopefully that explains it somewhat... Smile
Oh look, I was the last one to post here as well. Razz
Anyhow, It would be usefull if SourceCoder could support images that need to be encoded in 4-bit BCD, such that numbers $0-F represent a palette index. That way many more colors are available in pallets, and you can get better compression for images. I know that this isn't really important, but it would be a nice feature. Smile
Sometimes, when changing back and forth between multiple programs in SC, one of the programs will be completely replaced with another. It happened a few times already and I lost a lot of changes because of it. Sad
  
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
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 4 of 7
» 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