If you PM me the latest assembly version I can decompile it manually. Razz And yes, I should write a decompiler one day Smile
PT_ wrote:
If you PM me the latest assembly version I can decompile it manually. Razz And yes, I should write a decompiler one day Smile
The latest assembly version is in the archives below ICE Compiler if you have the time!
After PT_ finishes decompiling the compiled ASM program— for which I am eternally grateful— I will immediately implement many features that are now available because of ICE 2.0, including:

    >Instant sprite importation and exportation to any OS string, contrary to the glacial speed of the current routine

    >Customizable palettes and multiple preset palettes including many grays which someone seemed rather salty about not having...

    >Bug fixes (Visual bugs and idiot-proofing)

    >Integrating the primary menu with the editor menu for a seamless experience

    >Anything else you guys want!
Hooray! Hurry up PT_! Razz

CalcMeister wrote:
>Customizable palettes and multiple preset palettes including many grays which someone seemed rather salty about not having...

hmm, no idea who that was Laughing

I can't wait to see this release! I'll start working again on something I should have been working on for the past month. *cough* FLY! *cough*
hehe, might use ICE for BonziBUDDY if things look well enough... The sprite editor will help a lot if I were to use ICE. **poke** PT_? any progress?
PT_ wrote:
If you PM me the latest assembly version I can decompile it manually. Razz And yes, I should write a decompiler one day Smile

This is totally infeasible. Writing a decompiler is 100x harder than writing a compiler. So even if you decide to decompile this huge file by hand; note that you will spend 2-3x the amount of time; if that; if he were to just rewrite it accept responsibility for not keeping adequate backups. That is something that everyone should learn about programming; even if it is harsh. Anywho. That's my 2 cents; I wish you the best on whatever you decide to do.
SM84CE wrote:
hehe, might use ICE for BonziBUDDY if things look well enough... The sprite editor will help a lot if I were to use ICE. **poke** PT_? any progress?
The file is already released in full, but the update will be monumental. The file is here.
MateoConLechuga wrote:
This is totally infeasible. Writing a decompiler is 100x harder than writing a compiler. So even if you decide to decompile this huge file by hand; note that you will spend 2-3x the amount of time; if that; if he were to just rewrite it accept responsibility for not keeping adequate backups. That is something that everyone should learn about programming; even if it is harsh. Anywho. That's my 2 cents; I wish you the best on whatever you decide to do.
If this is the case PT_, feel no compulsion to decompile the program. I am sure I can remake it in a day or two.
I've made significant progress on the refactoring of ICE Sprite Creator, if you ignore the fact that it crashes without ever drawing the main screen. The code below is what I have so far, heavily commented with things that have gone wrong and are going wrong. Please especially help me to understand why it crashes so near to the beginning, I am sure my syntax is right.

Code:
iSPRITES2
det(0
det(3
det(9,0
det(5,0
det(22,"1     //All pauses and det(17 instances were for bug seeking purposes
Pause
sum(1,"SPRITE","w+")->SLOT     //Opens a var location to store the current sprite. Didn't use Alloc( because it needs to be used more than once
det(17,"2
Pause
sum(11,64,SLOT
det(17,"3
Pause
sum(18,SLOT)->SLOT     //Changes SLOT into an address to the slot
det(17,"4
Pause
For(A,0,63     //This is where it crashes because the five below is never shown. What is wrong with this code?
255->*{SLOT+A}
End
det(17,"5     //The five that wasn't ever shown
Pause
8->SIZEX     //SIZE meaning current sprite dims, SPR meaning current sprite cursor location, PAL meaning the same for the palette, PALETTE meaning which of the four 8x8 palettes is currently in use, CURMODE being which cursor is in use.
8->SIZEY
0->SPRX
0->SPRY
0->PALX
0->PALY
0->PALETTE
0->CURMODE
Lbl EP
iD*aw Editpage     //All [r]s are replaced with [*] because I made this while the [r] bug was still there
0->A
Repeat max(SIZEX,SIZEY)*A>200     //This loop scales the sprite depending on its length and width to fit the screen properly. Scale (pixel width) is stored in SCALE.
A+1->A
End
A-1->SCALE
det(5,0     //Main screen drawing routines
det(2,84
det(36,240,0,80,240
det(2,83
det(36,0,231,320,9
det(20,1
det(21,255
det(18,"MODE to ente* File and Palette Menu",0,0
det(18,"D*aw Fill G*ab Cu*so* Palette",1,231
det(18,"Sp*ite",248,36
det(18,"Palette",248,106
For(A,0,7     //Draws the palette
For(B,0,7
det(2,32*A+8*PALETTE+B
det(36,248+8*B,159+8*A,8,8
End
End
det(2,255
det(35,18,18,SCALE*SIZEX+4,SCALE*SIZEY+4
For(A,1,SIZEY     //Draws the sprite
For(B,1,SIZEX
det(2,*{SLOT+(A-1)*SIZEY+B-1}
det(36,B*SCALE+20,A+SCALE+20,SCALE,SCALE
End
End
Pause
iEvent Loop
Repeat K=15
0->K
det(2,240+7*not(CURMODE     //Redraws anything that was likely changed after a keypress. Everything else is taken care of elsewhere.
det(35,SCALE*SPRX+21,SCALE*SPRY+21,SCALE-2,SCALE-2
det(2,240+7*CURMODE
det(35,PALX*8+249,PALY*8+160,6,6
PALY*32+PALX+8*PALETTE->PALCOL     //PALCOL meaning one byte value of selected color
det(2,PALCOL
det(36,248,74,64,32
SPRY*SIZEX+SPRX->SPRCOL     //SPRCOL meaning color of selected sprite pixel
det(2,SPRCOL
det(36,248,4,64,32
det(19,248,114
det(16,PALCOL,3
det(19,248,44
det(16,PALCOL,3
Repeat K
getKey->K
End
If K>0 and K<5     //If an arrow key was pressed, cover up current cursors
det(2,240+7*not(CURMODE
det(35,SCALE*SPRX+21,SCALE*SPRY+21,SCALE-2,SCALE-2
det(2,240+7*CURMODE
det(35,PALX*8+249,PALY*8+160,6,6
If K=1
iDown
If not(CURMODE
If SPRY+1<SIZEY
SPRY+1->SPRY
End
Else
If PALY<7
PALY+1->PALY
End
End
End
If K=2
iLeft
If not(CURMODE
If SPRX>0
SPRX-1->SPRX
End
Else
If PALX>0
PALX-1->PALX
End
End
End
If K=3
iRight
If not(CURMODE
If SPRX+1<SIZEX
SPRX+1->SPRX
End
Else
If PALX<7
PALX+1->PALX
End
End
End
If K=4
iUp
If not(CURMODE
If SPRY>0
SPRY-1->SPRY
End
Else
If PALY>0
PALY-1->PALY
End
End
End
End
If K=53
iD*aw     //Set PALCOL to current sprite location
ΣySLOT+SPRY*SIZEX+SPRX,°PALCOL+3,1
det(36,SPRX*SCALE+20,SPRY*SCALE+20,SCALE,SCALE
End
If K=52
iFill     //A bit of a convoluted fill routine. Suggestions greatly appreciated.
iFill all connected spaces with 256 until no change is made in an ite*ation, Then change eve*y 256 to PALCOL.
If SLOTB≠0 or SLOTBSIZE≠SIZEX*SIZEY
SIZEX*SIZEY->SLOTBSIZE
sum(1,"SPRITEB","w+")->SLOTB
sum(11,SLOTBSIZE,SLOTB
sum(18,SLOTB)->SLOTB
sum(1,"SPRITEC","w+")->SLOTC
sum(11,2*SLOTBSIZE,SLOTC
sum(18,SLOTC)->SLOTC
End
For(A,0,SIZEX*SIZEY-1
ΣySLOTB+2*A,SLOT+A,1
End
σySLOTB+2*SPRX*SPRY,2,256
Repeat FILLDONE
For(A,0,SLOTBSIZE-1
ΣySLOTC+2*A,SLOTB+2*A,2
End
For(A,0,SLOTBSIZE-1
If **{SLOTB+2*A}=256
If remainder(A,SIZEX)>0 and **{SLOTB-1+2*A}=PALCOL
σySLOTB-1+2*A,2,256
End
If remainder(A,SIZEX)<SIZEX-1 and **{SLOTB+1+2*A}=PALCOL
σySLOTB+1+2*A,2,256
End
If remainder(A,SIZEY)>0 and **{SLOTB-2*SIZEX}=PALCOL
σySLOTB-2*SIZEX,2,256
End
If remainder(A,SIZEY)<SIZEY-1 and **{SLOTB+2*SIZEX}=PALCOL
σySLOTB+2*SIZEX,2,256
End
End
End
1->FILLDONE
For(A,0,SLOTBSIZE-1
If **{SLOTB+2*A}≠**{SLOTC+2*A}
not(FILLDONE)->FILLDONE
End
End
End
For(A,0,SLOTBSIZE-1
If **{SLOTB+2*A}=256
ΣySLOT+A,°PALCOL,1
End
End
For(A,1,SIZEY
For(B,1,SIZEX
det(2,*{SLOT+(A-1)*SIZEY+B-1}
det(36,B*SCALE+20,A+SCALE+20,SCALE,SCALE
End
End
End
If K=51
iG*ab     //Sets SPRCOL to PALCOL and resets palette coordinates
SPRCOL->PALCOL
remainder(PALCOL,8)->PALX
PALCOL/32->PALY
remainder(PALCOL,32)/8->PALETTE
For(A,0,7
For(B,0,7
det(2,32*A+8*PALETTE+B
det(36,248+8*B,159+8*A,8,8
End
End
End
If K=50
iCu*so*      //Swaps current cursor (0=Sprite 1=Palette
not(CURMODE)->CURMODE
End
If K=49
iPalette
PALETTE+1->PALETTE
If PALETTE=4
0->PALETTE
End
End
If K=56
iD*op-down menu   //After all these bugs are fixed, this will be a hub for importing sprites, exporting sprites, creating custom palettes, editing a sprite queue, and other things.

End
End
You didn't close all the open slots before trying to open one; which means that the first sum(1 would fail, and thus GetSize() too. It's even said in the commands.html:
Closes all open slots. Call this before you use any variable functions!
Also, don't forget the det(1) at the end of your program. Razz
PT_ wrote:
You didn't close all the open slots before trying to open one; which means that the first sum(1 would fail, and thus GetSize() too. It's even said in the commands.html:
Closes all open slots. Call this before you use any variable functions!
Also, don't forget the det(1) at the end of your program. Razz
Thanks PT_! I knew I was probably doing something wrong.

Also, just because I don't want to trash my calc, whats the worst thing that could go wrong if I edit the wrong address?
I'm very close to done with the refactored version, except for a few things:
    Fill: My fill routine was created with the assumption that I would be using pointers, and not ICE lists. I'll need to redo that entire routine a second time.

    Drop Down Menu: I'm taking a new approach for importing and exporting this time, where there will be a drop down menu with a hub for all things file management and palette customization.

    ICE Lists Being Funky: ICE lists seem to be acting up, but like always it's probably my fault. At the beginning of the program, I run a For( to fill the first 64 elements of L1 with a 255. The result is, anytime I query those elements, it returns 16777216, which would be three whole bytes of 255. Why is this the case? Also, whenever I draw a color to the sprite (COLOR->L1(Y*XSIZE+X)) it instead draws the color to the selected pixel AND draws black to the two pixels immediately to the right. Can someone explain these issues?
CalcMeister wrote:
Fill: My fill routine was created with the assumption that I would be using pointers, and not ICE lists. I'll need to redo that entire routine a second time.
Why not using the FloodFill function?

CalcMeister wrote:
ICE Lists Being Funky: ICE lists seem to be acting up, but like always it's probably my fault. At the beginning of the program, I run a For( to fill the first 64 elements of L1 with a 255. The result is, anytime I query those elements, it returns 16777216, which would be three whole bytes of 255. Why is this the case? Also, whenever I draw a color to the sprite (COLOR->L1(Y*XSIZE+X)) it instead draws the color to the selected pixel AND draws black to the two pixels immediately to the right. Can someone explain these issues?
*sighs* I clearly said that when using L1(X) it ALWAYS gets/stores 3 bytes. The 16777215 is coming from the 3 255 bytes: 0xFFFFFF. It changes 3 pixels because you a value to 3 bytes (pixels), not 1.
PT_ wrote:
CalcMeister wrote:
Fill: My fill routine was created with the assumption that I would be using pointers, and not ICE lists. I'll need to redo that entire routine a second time.
Why not using the FloodFill function?
Even though it feels a bit like cheating, I completely removed my current Fill function and replaced it with FloodFill followed by GetPixel, and it works extremely fast now, regardless of the size of the sprite.
PT_ wrote:
CalcMeister wrote:
ICE Lists Being Funky: ICE lists seem to be acting up, but like always it's probably my fault. At the beginning of the program, I run a For( to fill the first 64 elements of L1 with a 255. The result is, anytime I query those elements, it returns 16777216, which would be three whole bytes of 255. Why is this the case? Also, whenever I draw a color to the sprite (COLOR->L1(Y*XSIZE+X)) it instead draws the color to the selected pixel AND draws black to the two pixels immediately to the right. Can someone explain these issues?
*sighs* I clearly said that when using L1(X) it ALWAYS gets/stores 3 bytes. The 16777215 is coming from the 3 255 bytes: 0xFFFFFF. It changes 3 pixels because you a value to 3 bytes (pixels), not 1.
Ok, I've implemented all of these changes, and I think I completely understand ICE lists now. The only thing left I need now is length( to work.

Also, a few updates on the UI architecture I've been designing. The main sprite editor is largely unchanged, except for a few visual optimizations. The sprite editor now automatically loads an empty 8x8 sprite, getting rid of the import/new sprite page, which was quite bland. MODE is now an undo button. FILL now works nearly instantly, even for a massive sprite. DEL now takes you to a completely different screen, with many options that have to do with importing, exporting, queuing, sprite previewing, options, and other palettes!

*New commented source code as soon as I get home!*
commandblockguy wrote:
Let's all nag PT_ to make an ICE decompiler! Razz
Also, how is "decompiler" still recognized by Chrome as a misspelled word for me by this point?

Just a question, would such a thing even be possible? Confused
Yes. PT_ has decompiled programs by hand in the past.
Legoman314 wrote:
commandblockguy wrote:
Let's all nag PT_ to make an ICE decompiler! Razz
Also, how is "decompiler" still recognized by Chrome as a misspelled word for me by this point?

Just a question, would such a thing even be possible? Confused

_iPhoenix_ wrote:
Yes. PT_ has decompiled programs by hand in the past.

Although possible, it is much harder than _iPhoenix_ makes it out to be. Decompiling a program by hand is relatively easy if you have the tables and the inc file in hand. PT_ is probably able to take a decompiled asm program and guess what the initial basic code was. However, making a program that decompiles into ti-basic is not very easy because ICE does a lot of fancy things to the program so that it ends up looking more like a proper asm program, which makes it so that even if you read through the final asm code, it isn't trivial to know what ti-basic code was inputted.
Besides, I think it would not be worth the effort, because compiling the program is much more important than decompiling it Wink
I love this, and it helps me a lot. I think an undo button would be appreciated, and a mode for making Cesium icons. I would also like an option to replace a certain color value with another, and a way to input a color value into the palette.
  
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
Page 2 of 2
» 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