Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Quigibo on May 15, 2010, 12:40:03 am
-
I'm planning to eventually write an all purpose sprite editor for 8x8 and 16x16 sprites supporting monochrome, 3 color, and 4 color grayscale on-calc. It will be written in Axe itself, but I need to wait on it because I have to add reading and writing to the Ans variable so that the sprites can be imported and exported.
If anyone has any other good tools, particularly for the computer since I imagine many sprites will be drawn there instead of on-calc, please post them here. I am currently looking for a good program that can output z80 hex code for a 4 color gray bitmap, but I can't seem to find anything. I'm about to write one in C++ if I don't see anything soon, but I really don't have the time for that right now.
-
Um...well I think someone posted a link to a good computer one when I asked about Hex Sprites. I'll find that real fast.
So ya, when I made a topic about asking for help with Hex Sprites (http://ourl.ca/4717) and tr1p1ea suggested Graphics Studio v1.2 (http://www.ticalc.org/archives/files/fileinfo/132/13274.html) (a.k.a. CalcGS) but I'm not sure if it does hex as an output option.
Also, good luck with the programming :)
-
that would rule, that and the ans support. So basically there will be an editor for the calc and one for the comp?
-
Isn't ans supported now?
-
Yeah it was added the week after my post. Keep in mind if the Ans value is something else than 0-65535, it will give an error, though.
-
Quigibo this is truely amazing
if i weren't straight, i would be gay for you
-
You could have it spit out the pics for the back-buffer and the buffer as text, and then have the person manually copy the text. Unless you can put it in an unarchived open program, in which case, that would be easer. Just have the program, after run, store the strings in str1 and str2. Would that work?
-
Also, no one has mentioned it since this topic is outdated, but there is also our dear friend's program here (http://www.ticalc.org/archives/files/fileinfo/429/42940.html). You can draw the sprites in Paint or something and then convert it to a calc picture file and use this program to convert the sprites.
-
I could not get that program to work.
-
Yeah that program is nice. Now if someone could port it to Mac for our dear mac users (which seems to increase in number lately)
-
The program worked for me... up until I tried to send the created program to my real calculator, which is odd cause it opened just fine in Wabbitemu.
-
Mhmm weird it works for me. Keep in mind you must absolutely select tiles by clicking the picture before exporting, though. Also do not merge them together because a bug in the program causes the last two HEX chars to miss from the program when saved
-
No, It wouldn't open at all. Of course, that could be my computer, though.
-
Oh that's worse x.x
I know it works under the 64 bit version of Windows 7. Could anyone else that got it to work post their Windows version?
-
I've actually been working on an Axe sprite editing program myself. As of now, it supports:
- 8x8 and 16x16
- Multiple realtime zoom views
- Realtime hex display
- Hex input
- Flipping horizontally/vertically
- Rotating
- Opening and saving as many sprites as memory allows
Help screen (with nice scrolling!) Had to scrap this to save 850 bytes, program was getting too large
The real trick will be fitting in features like grayscale with my program already over 7 KB.
-
interesting, it will be nice to have more tools for programming in Axe :)
-
Still working on my sprite editor. Pretty much every actual editing feature I plan on implementing is finished (including support for black and white and
both only 3-level grayscales! just kidding about 4-level, forgot I need to draw to both buffers for black so I need to accommodate for that now), although I still need to add/improve the sprite management commands such as adding new sprites or copying/pasting sprites.
-
cool :D keep us updated!
-
Yeah, I can make a monochrome sprite editor later today, and supporting GS won't be too much more of a challenge. I can probably have it done by the end of the day.
Mac users, all of my released PC programs are Mac and Linux compatible. Linux users, if you don't already have mono, go to the terminal and type sudo apt-get install mono. Mac users, I don't know how you can get Mono, but go online and look it up.
-
It would be nice to include some better sprite management features like copying, but with the compiled program pushing 8 KB as it is, it will be difficult to add this. But those are finishing touches sort of features, so until I even figure out how to fit those into the program... I present the awesome features!
-8x8 or 16x16
-Black and white, 3-scale grayscale, or 4-scale grayscale
-Multiple zoom views visible at once
-Realtime sprite hex display
-Hex input
-Flipping horizontally or veritcally
-Rotating clockwise or counterclockwise
-Create, edit, and save as many sprites as memory allows
-Delete sprites
Go ahead, try it out. I attached the source and compiled versions, as well as a readme to explain how the hell to use it. If you plan on compiling the source on your calculator and don't want to use the 14,082 byte commented and indented source file, download the attached uncommented and unindented version, weighing in at only 5,714 bytes!
** If you find any glitches, want to make any suggestions, or just want to tell me how great of a guy I am for making this, tell me about it! **
** Anyone who wants to, feel free to look at the source code and suggest optimizations. A good place to start may be areas that are easier to understand without knowing the intricate structures of the specific program, namely routines that perform math/graphics operations. Rotate and flip could be good candidates for this... It's really hard for me to add features with the current features already maxing out the program's size! **
-
nice, but it won't compile on Axe 0.2.6 ???
-
nice, but it won't compile on Axe 0.2.6 ???
It won't? That's what I'm compiling it on.
-
nice, but it won't compile on Axe 0.2.6 ???
It won't? That's what I'm compiling it on.
Well, it give a BAD Symbol Error. Is this a bug? Quigbo?
Error at 60% first pass.
-
Hit PRGM to scroll to the error, what is it citing as the error?
-
Hit PRGM to scroll to the error, what is it citing as the error?
E OF 8X8 PIXEL -tanh-1(
and yes the CAPS are correct.
-
works fine for me, at any rate.
-
Wierd...
I unarchived it but it gave me out of MEM at 51%
So I rearchived it and it threw a BAD SYMBOL Error at 0% ???
-
Yeah, I've noticed that Axe doesn't always read from the archive correctly. Either find a way to be able to compile it in RAM and have enough space for the compiled program or keep trying to compile the archived version until you don't get an error.
-
try freeing up RAM... when run in wabbit, with three things on it: Axe, the source, and the compiled program, I had only 2KB of memory left. Maybe Axe can't handle low mem well?
-
I RAM Cleared, stilled din't work, both ways.
I think I'll just send the excutable.
But I aready tried that and it didn't send... stupid TI-CONNECT.
-
Yeah, it's a really big program... If you want I can probably post a much smaller version of the source, with all comments and indentation removed
-
I was about to say "blame your linking software" earlier, but I didn't think TILP would do that. Now that you've made me certain you use TI-Connect, yes, blame your linking software.
-
Yeah, it's a really big program... If you want I can probably post a much smaller version of the source, with all comments and indentation removed
It's fine, I'll just try again with TI-Connect.
I was about to say "blame your linking software" earlier, but I didn't think TILP would do that. Now that you've made me certain you use TI-Connect, yes, blame your linking software.
Yeah, I really need TiLP, but my parents won't let me download 3rd party applications to my comp. just calc. so.. I'm stuck with TI-CONNECT
-
Wow, nice program! Excellent job! ;D
-
Yeah, I really need TiLP, but my parents won't let me download 3rd party applications to my comp. just calc. so.. I'm stuck with TI-CONNECT
So, obviously, Micro$oft Window$ is better than Linux... * calcdude sighs
Back on topic, yes, this program looks great. Probably will be the sprite editor on my calc for quite a while.
-
Wow! It looks really nice! Downloading them now :)
Great job on it!
-
If you want it, I attached a version of the source file with all comments and indentation removed. It dropped from 14082 to 5714 bytes.
-
That's a lotta comments... Of course, it's probably unreadable now.
-
That's a lotta comments... Of course, it's probably unreadable now.
Yeah, the program is so large I need the comments or I won't even know what my code is if I leave it alone for over an hour. Although I think most of the size bloating is from indenting 2 spaces per layer every line.
A reminder:
** If you find any glitches, want to make any suggestions, or just want to tell me how great of a guy I am for making this, tell me about it! **
-
i FINALLY GOT IT TO SEND, BUT YEAH, YOUR A GREAT GUY FOR MAKING THIS AND i THINK QUIGBO SHOULD PUT THIS IN THE TOOLS FOLDER OF axe AS A "aDVANCED hexeDITOR"
EDIT: oops, sorry, I had Caps Lock on
I finally... I'm too lazy to type.
It's only slightly annoying ;)
-
Runner, you're a great guy for making this! :D
I also think it should be in the tools folder. :)
-
Alright, I've got this really weird glitch going on. Whenever I run the program from my calc, I just get a jumbled mess of pixels dancing around, but when I open it on wabbitemu using the exact same rom, it works perfectly fine. I've tried using the no shell, compiling the big one, and compiling the small one and they all turn out the same.
btw, I'm using a TI 83plus SE with 1.15 if that means anything.
-
1.15?
Try upgrading to 1.19, it MIGHT solve the problem.
And lots of bugs can't be replicated with emulators.
-
Just upgraded. Same problem. I can't take any screenshots of it either, because TI-Connect doesn't read the calculator when an Axe program is running.
-
I got the same bug as Magic Banana. I'm using 84+ (BE) os 2.43 and I got the 'gray level' question the first time, then it displayed these random lines and what looks like cut-up zeros. On 0.2.6 it spat out a symbol error at 3% while compiling...
For the record, the ALCDFIX program (http://www.ticalc.org/archives/files/fileinfo/366/36608.html (http://www.ticalc.org/archives/files/fileinfo/366/36608.html)) didn't work.
Might Spr-2-Hex at http://www.ticalc.org/archives/files/fileinfo/397/39717.html (http://www.ticalc.org/archives/files/fileinfo/397/39717.html) work, by any chance?
-
Um... it's your calculator? It probably won't help, and a screenshot (even a picture) would provide more info,
but try ALCDFIX (http://www.ticalc.org/archives/files/fileinfo/366/36608.html)
Again, it shouldn't do anything... More information and maybe a picture?
Edit: Apparently ALCDFIX doesn't work... hm... Pictures?
-
Okay, so if you go into Memory Management, go to AppVars and delete the SPREDIT variable. It should be archived. This lets you go back to the gray level screen. Choosing 2 works perfectly. choosing 3 gets the jumping around. Choosing 4 gets the weird cutoff '0's. Its only a temp solution until this gets fixed for real, so I guess until then Darl181 and I are stuck in monochrome mode.
Also, I tried to go into the code and change it so that I can screenshot the thing, but just scrolling through that takes minutes.
EDIT: Okay, got it. SCREEN1 is when I choose 3 and SCREEN4 is when I choose 4.
-
Make sure there is no Full command in the program, as that can (seriously) screw up graphics if used when greyscale is being displayed.
-
Yep, just checked the source, and the program gets initialized with it.
-
That might be OK if when you choose a greyscale level of 3 or 4, then Normal is executed, but perhaps removing the Full would help.
-
I think I can modify the source a bit so that it checks whether you picked monochrome or grayscale and choose accordingly.
-
The screenies look really excellent for this. I'll give ti a try later and leave some feedback.
-
Hey, just got back. Is it the Full thing? It probably is >.< let me fix that now.
EDIT: Made a fix for the Full problem, assuming that was the problem. I can't test it myself because I don't have a 15MHz calculator. http://ourl.ca/4832/94254 (http://ourl.ca/4832/94254)
-
Ok, just tested it and the fix is working.
Here's the edited source and the Axe executable.
-
Ok, just tested it and the fix is working.
Here's the edited source and the Axe executable.
Beat you to it ;)
But sorry about that, I was testing it on a 6MHz and I forgot that I needed to turn off Full for the grayscale. And can you or somebody else with a 15MHz test my updated file just to make sure my fix works?
EDIT: Found another dumb error and fixed it.
EDIT AGAIN: Found another dumb error caused by my previous fix for a dumb error and fixed it.
-
Ok, just tested it and the fix is working.
Here's the edited source and the Axe executable.
Beat you to it ;)
But sorry about that, I was testing it on a 6MHz and I forgot that I needed to turn off Full for the grayscale. And can you or somebody else with a 15MHz test my updated file just to make sure my fix works?
EDIT: Found another dumb error and fixed it.
EDIT AGAIN: Found another dumb error caused by my previous fix for a dumb error and fixed it.
I can't check right now because I'm busy working with sprites.
I'm not sure what you did for a fix, but here's basically what I did to fix it:
(btw, this is in Lbl N:
While Gsub(65)
:If sub(GK)=26
:0→G
:End
:If K=18
:1→G
:End
:If K=35
:2→G
:End
:If G
:Normal
:Else
:Full
:End
: End
It doesn't conflict with anything so it works on 15Mhz calcs.
-
I actually did something else, I call Normal at the start of the sprite DispGraph routine and call Full at the end of it, which should give you the best of both worlds. It should run the grayscale display part of the program at normal speed on any calculator and run the rest of the program at full speed on calculators capable of it.
.DISPLAYGRAPH
Lbl DG
!If G
DispGraph
Else
Normal
If Gsub(1)
DispGraphʳ
Else
DispGraphʳʳ
End
Full
End
Return
-
Hey that is really cool! Definitely will consider adding this to the Axe Tools, with your permission of course.
-
Hey that is really cool! Definitely will consider adding this to the Axe Tools, with your permission of course.
Sure, although it's still a work in progress. Should I start a new thread for it? Or just keep updating my post on the second page?
-
Ah, I see what you did. Yeah, that looks to be much more efficient. Then again, it is pretty hard to fix code when you didn't write the thing and its over 5k.
-
Ah, I see what you did. Yeah, that looks to be much more efficient. Then again, it is pretty hard to fix code when you didn't write the thing and its over 5k.
If you're trying to figure out how it work, the best thing to do is look at the 14k source file on a computer, using something like SourceCoder. But good job figuring out how the whole thing works! Maybe you can tell me?
-
Well, first I just scrolled down to where Full was, removed that, then I just kept jumping labels (and also just random scrolling and a bit of luck) until I found what you stored the number checking for grayscale to (G). Then looked for anything that changed it and did trial and error from there. It actually took less time than I though because the labels kinda help to see what I'm looking at. I think a check to call sub(DG) was where I found it, which I assumed is draw grayscale.
-
If you look at the commented version it would probably make a lot more sense. Also, you would know that "DG" stands for DispGraph. Any time the screen needs to be updated while sprite editing, I call this, which will perform either DispGraph, DispGraphʳ, or DispGraphʳʳ according to the sprite's grayscale level.
** Anyone who wants to, feel free to look at the source code and suggest optimizations. A good place to start may be areas that are easier to understand without knowing the intricate structures of the specific program, namely routines that perform math/graphics operations. Rotate and flip could be good candidates for this... It's really hard for me to add features with the current features already maxing out the program's size! **
-
This is what I was refering to:
:If Gsub(N0)
:sub(DG)
:End
Eh, I was close enough.
Oh wow . Just opened up the commented version in SourceCoder. The amount of detail in these comments is ridiculous!
I'll take a pass or two through it and see if any revisions can be made. Although, I don't quite have everything down for optimizing in Axe so I probably won't find much.
-
One thing I'm doing is removing as much code I had previously planned on using, but never ended up finishing/getting to fit in the program. One such example is sprite moving/copying/pasting, which I just found a subroutine for that I forgot to comment out. Saved maybe 30 bytes, and at this size, every byte counts.
EDIT: Just chopped off about 150 more bytes. Realized that my sprite changing keypress handling was the complex version I needed back when I was trying to develop sprite copying/moving, so simplified that quite a bit.
-
I only read page 2 of this thread so far but what I saw is totally EPIC! I'm glad to see such sprite editor for Axe. It looks great too.
I will add it to the downloads section when finished. (Unless Axe includes it)
-
Hey that is really cool! Definitely will consider adding this to the Axe Tools, with your permission of course.
You might just want to put it in the downloads as well, in case somebody wants to use it, but doesn't use Axe or wants to download the entire zip just for it.
@runer112: Some optimizations that would be very helpful would be to require less free ram to use. I've had the thing throw an ERR:memory when I had around 8-9k free ram (after archiving it). Maybe Quigibo can give some tips on doing that.
-
You can start a new thread if you want. It doesn't have to be in the Axe subforum either.
By the way, I looked at the code and there are a lot of optimizations possible. I'll mention a few:
You should NEVER find yourself having to make big lists of non-data. I noticed this in the Help routine. I know its doted out, but if you want to do it efficiently, try this:
:.HELP
:If K=53
: Fix 0
: -1→A
: Repeat sub(15)
: sub(DT)
: sub(GK)
: If Ksub(1)→T and (A+1<number_you_will_need_to_determine)
: While {A+1→A+Str00}:End
: End
: If K=4 and (A≠-1)
: While {A-1→A+Str00}:End
: End
: End
: sub(L)
:End
:.Draw Text
:Lbl DT
: A→B
: ClrDraw
: For(J,0,9)
: While {B+1→B+Str00}
: Text(0,J*6+3,{B+Str00}►Frac)
: End
: End
: DispGraph
:Return
You can then get rid of all those extra text subroutines. I don't know if this routine works its untested, but you can probably see how it works. Also, add a det(1) before Str00.
: 3→K
: 3-Xsub(M4)→W
Can be:
: 3→K-Xsub(M4)→W
: 0→D
: 2→K
Can be:
: 0→D+2→K
I'll add more stuff later.
-
I'd love to add back a help system, but with only about 200 bytes of available space left in the program, there's no way I could add one. At least until you figure out a way to let us call outside programs. ;D
-
If you're trying to avoid the 8811 byte limit, remember that that's only for executable code. If you wanted, you could have 8811 bytes of executable code and 12000 bytes of data on the end of it. Since your help text would be data, I think you could fit it in 200 bytes of executable code. ;D
Good luck. :)
-
If you're trying to avoid the 8811 byte limit, remember that that's only for executable code. If you wanted, you could have 8811 bytes of executable code and 12000 bytes of data on the end of it. Since your help text would be data, I think you could fit it in 200 bytes of executable code. ;D
Good luck. :)
Wait, it's 8811? I thought it was 8192? Please say it is, that means I have 600 more bytes of free space than I thought I had!
EDIT: I just compiled and tried to run a 8,420-byte (no shell) program and it throws ERR:INVALID.
EDIT 2: However, when I run the program compiled for Ion, it successfully runs.
-
Quoted from Asm in 28 days:
"Assembly programs for the TI-83 Plus cannot be more than 8811 bytes in size. Well they can, but just keep them below that. "
Yay, almost 666 more bytes! :D
-
I just compiled and tried to run a 8,420-byte (no shell) program and it throws ERR:INVALID. However, when I run the program compiled for Ion, it successfully runs... I guess I could just make the program Ion-compatible only, I doubt many people even use no shell assembly programs.
-
I just compiled and tried to run a 8,420-byte (no shell) program and it throws ERR:INVALID. However, when I run the program compiled for Ion, it successfully runs... I guess I could just make the program Ion-compatible only, I doubt many people even use no shell assembly programs.
That's odd. Does it throw the error on smaller programs too? Besides that's not what would happen if you hit the executable code limit; the calc would maybe turn off and then RAM Clear. :)
Oh, and I like no stub Asm programs. ;D
-
I think I've successfully run an 8197-byte no shell program before, but much more than that and I get ERR:INVALID.
-
What does the error go to? Does it go to the program name on the homescreen, or somewhere else?
-
What does the error go to? Does it go to the program name on the homescreen, or somewhere else?
It goes to the Asm(prgmSPRTEDIT line on the homescreen.
-
Huh. I think it sounds like an Axe error. Would you mind reporting it in the Bug Reports topic with a copy of both the small and large program. Thanks. :)
Good luck. :D
-
Its a TI OS thingy, it restricts programs to around 8100 bytes, even though the maximum possible is around 8800 bytes. Thats why you get the extra 600 bytes in Mirage and Ion, because they aren't stupid like TI :P
-
Its a TI OS thingy, it restricts programs to around 8100 bytes, even though the maximum possible is around 8800 bytes. Thats why you get the extra 600 bytes in Mirage and Ion, because they aren't stupid like TI :P
Oh, okay. Thanks for this info! :D
-
I'd love to add back a help system, but with only about 200 bytes of available space left in the program, there's no way I could add one. At least until you figure out a way to let us call outside programs. ;D
IMHO I would keep most help in a readme file (altough then it can be a problem if you have no computer access for a while)
-
Is it possible to transfer the Hex value of the sprite to an Ans variable? I think with Axe you can't, because there's no writeback, right? But if it is possible, even if it means using hex code or asm lib, I think it would be really helpful. Because you don't need a paper to write down the hex code
-
As soon as a way to export data to ans, programs, strings, or any of the like becomes available, I will add support for it.
-
Ok, I got stuck on 1 bit.
Where are my sprites located? Is there any way to export them? Where does the editor itself store them? (So I can extract them)
Edit: I found the appvar, but I don't understand its structure.
How is the appvar structured so I can copy them out (to a picture file or sumthing)?
-
any chance you can add exporting the data?
-
Holy necropost :O
-
I'd love to add back a help system, but with only about 200 bytes of available space left in the program, there's no way I could add one.
If you compile your program to an App, you have much more memory to use.
This woud be cool
Why do you use Subroutines like them?
Lbl 16
=16
Return
Lbl 22
+22
Return
This isnt easy to read and takes memory.
-
HOLY NECROPOST BATMAN :o
protip: look at the date of the post you're replying on, because this post is 2 years old...
-
And using small routines can be useful when you use them several times since a call to that routine is smaller than the content of the routine.
-
Don't question Runer's programming. Ever. :P
-
Dammit, zombie threads. I almost thought quigibo was back D:
-
As soon as a way to export data to ans, programs, strings, or any of the like becomes available, I will add support for it.
Heh, forgot about that post... whoops?
But there are better tools available now, like tileIt! (http://www.ticalc.org/archives/files/fileinfo/448/44872.html), so I think people will be fine without that update. :P
-
with tileit you cant change the hexcode while editing the pic
-
Do people actually want me to revamp my sprite editor? I'll do it if there's demand (and if I can find the time).
-
Oh wow, I remember your sprite editor. I loved it but I didn't use it since back then, Doors CS7 wasn't out yet. I had to archive lots of stuff just to unarchive and use your sprite editor, which DCS solved a month afterward (by running programs from archive).
-
In my mind your sprite editor is better than Tileit because yours can edit 16x16 more level grayscale sprites. And if you want the hex of sprites which are bigger than 8x8 ...
EDIT:
Im trying to write an sprite edit program too, but with the sizes 95x63. later with variable sizes.
The reason I use the sprite editor is I want to see the more level grayscale picture and can edit it. To change the hex while editing the pic isnt so important if ther are any tools to color bigger areas than 1 pixel.
-
:) :D
Here is the first version of my sprite program!
Please give me feedback :D .
No screenshot because wabbitemu doesnt work :'( (http://ourl.ca/21012 (http://ourl.ca/21012)).
=====About=====
With this programm you can draw a 4 level grayscale picture and the it converts area, defined by you, to two hex and saves te hex into the programm HEX.
If you press [Enter] you can just draw an Inverted Outline Box. The outline and all what is inside will be converted.
-No filled circle implemented. Please help me with this.-
-Compile the program PICTOHEX not the other one.-
===Keys===
==Moving ==
[^] Up
[v] Down
[<] Left
[>] Right
==Drawing==
[prgm] draw menu
[2nd] Buffer 1
[Alpha] Buffer 2
[math] both Buffer (black/white)
[Clear] Clears the screen
[Enter] Change the area, which the program will convert to a Hex.
==Changing convert-to-Hex-area==
[2nd] start point of the convert-to-hex-area
[Enter] end point of the convert-to-hex-area / convert to hex
==Always==
[ON] Exit
=========