Suggestion: Can you make it so pictures can be converted even if larger than the screen?
and also up the max file size plz.
Before I answer, I must say that I'm greatly amused by this late-October 2011 quote:
KermMartian wrote:
An option that would sort of work would be a javascript TI-83+/84+ emulator, with a ROM in client-side DOM Storage, so that ROMs would never touch the server. It's of questionable but slightly less definitely bad legality, as far as I know, but I unfortunately haven't had the time to put it together in the two years since I had the idea.
Anyway, your request:
happybobjr wrote:
Suggestion: Can you make it so pictures can be converted even if larger than the screen?
and also up the max file size plz.
Can you explain your logic behind each?
With axe's bitmap( command, you can have any size image displayed, and have it displayed at negative locations.
This would allow a Gamemaker style game where the whole map is displayed at once. Then you have the location around the character be moved.
And the upping the size limit would be because of the above, and
"All files are removed from the server immediately after processing. "
so it really wouldn't matter would it?
Hey! I got an idea: Make 16 colors sprites for Prizm:
Using some nibbling (0xXX), we can use 16 coors per nibbles, and per Pixel.
I usually use this, and I think that would be awesome for SOurce Coder!
It would take the palette from the picture, and add it with the sprite code
Request: The ability to take .8xv's and display their hex values. I won't be using it as much as other stuff, but it would be very handy for axe programmers, storing the hex data inside the source, etc.
parserp wrote:
Request: The ability to take .8xv's and display their hex values. I won't be using it as much as other stuff, but it would be very handy for axe programmers, storing the hex data inside the source, etc.
That's easy enough to add; I see no reason not to do so. I'm very busy and might forget, though, so would you mind poking me to remind me about it if I haven't implemented this in about a week's time?
KermMartian wrote:
parserp wrote:
Request: The ability to take .8xv's and display their hex values. I won't be using it as much as other stuff, but it would be very handy for axe programmers, storing the hex data inside the source, etc.
That's easy enough to add; I see no reason not to do so. I'm very busy and might forget, though, so would you mind poking me to remind me about it if I haven't implemented this in about a week's time?
Sounds good, I definitely will remember to poke you.
Suggestion: Show arrays for TI-68k calcs (monochrome & grayscale). Use multiple arrays if width>32.
blue_bear_94 wrote:
Suggestion: Show arrays for TI-68k calcs (monochrome & grayscale). Use multiple arrays if width>32.
I have a lot of 68k stuff that I wanted to add to SourceCoder, and I even have most of the code for reading and writing TI-89/92/V200 BASIC programs already in there, but realistically, I'll probably never finish/release those features.
Parserp: You'd better get that poking stick ready; looks like it has been a week!
...and nearly a week more.
POKE POKE POKE POKE POKE POKE
parserp wrote:
...and nearly a week more.
POKE POKE POKE POKE POKE POKE
Done, I implemented better AppVar decoding in SourceCoder. Give it a try, and tell me how it works for you.
happybobjr wrote:
Suggestion: Can you make it so pictures can be converted even if larger than the screen?
and also up the max file size plz.
happybobjr wrote:
With axe's bitmap( command, you can have any size image displayed, and have it displayed at negative locations.
This would allow a Gamemaker style game where the whole map is displayed at once. Then you have the location around the character be moved.
I second that request. That would also be useful when I need to translate a bunch of sprites. I'd just have to draw them each one below each other (on a picture that could have a height higher than 64 if there are more than 8 sprites to convert) and convert the pic, which would give the sequel of hex codes.
The size limit was intended to avoid people hogging bandwidth and temporary disk space with massive images, but I can raise it a bit. What would be a reasonable maximum for the TI-83+/84+? 256x256?
I think we should keep the file restrictions in place until we decide to stay on our current server or go back to Surpass. It wouldn't be fun to up the limit, go back to surpass and lower the limit. Would projects already saved (and larger than allowed) be able to be opened? Re-saved?
KermMartian wrote:
The size limit was intended to avoid people hogging bandwidth and temporary disk space with massive images, but I can raise it a bit. What would be a reasonable maximum for the TI-83+/84+? 256x256?
Well for the purpose I'd have, images would not be massive since they would only be high, not wide (the width would always be 8 or 16).
With 256x256, I would be able to convert 32 sprites, I guess it is enough for me, hopefully that should be enough for happybobjr too
Speaking of Axe and Grammer files, can someone please guide me on a good way to detect probable Axe and Grammer source code? I believe Axe always start .<letters and numbers><enter>, right? What about Grammer?
Edit: Thanks to Runer112, I know that the answers are:
Axe: /^\.(\.|[A-Ztheta][A-Za-z0-9theta]*( |\n))/
Grammer: ^\.0:
Select more than one program to delete or open.
While editing a program have the option to hide the content between if and end. (kind of like on Notepad++ where you can hide the stuff between tags.)
PizzaisDavid wrote:
Select more than one program to delete or open.
While editing a program have the option to hide the content between if and end. (kind of like on Notepad++ where you can hide the stuff between tags.)
Collapsing tags would be a cool feature; I might try to do that with the SourceCoder 3 editor. Speaking of SourceCoder 3, you should try out the early alpha and see what's in store.
For the converter of sprite data to text data, could you have the text displayed in exactly how the sprite shows up? Like, if it is 32 pixels wide, it displays 32 characters, and drops down to the next line to display the next? This will be critical in making sprites small enough to display via the 'G' character trick. :<
tifreak8x wrote:
For the converter of sprite data to text data, could you have the text displayed in exactly how the sprite shows up? Like, if it is 32 pixels wide, it displays 32 characters, and drops down to the next line to display the next? This will be critical in making sprites small enough to display via the 'G' character trick. :<
Well, the reason I don't do that is so that people who are not using that trick don't have to go through line-by-line and remove all the line returns. I'm trying to think of a way out that doesn't require having two separate boxes.