If you PM me the latest assembly version I can decompile it manually. 
And yes, I should write a decompiler one day 
And yes, I should write a decompiler one day 
PT_ wrote:
If you PM me the latest assembly version I can decompile it manually. And yes, I should write a decompiler one day
The latest assembly version is in the archives below ICE Compiler if you have the time! And yes, I should write a decompiler one day
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_!
hmm, no idea who that was
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*
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
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?
The Future Is Now
PT_ wrote:
If you PM me the latest assembly version I can decompile it manually. And yes, I should write a decompiler one day
And yes, I should write a decompiler one day 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:
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.
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.
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.
Thanks PT_! I knew I was probably doing something wrong.
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.
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? 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.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!
Also, how is "decompiler" still recognized by Chrome as a misspelled word for me by this point?
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?
A pizza that has radius "z" and height "a" has volume Pi × z × z × a. 10!=The number of seconds in 42 days (coincidence? I think not)
Legoman314 wrote:
commandblockguy wrote:
Let's all nag PT_ to make an ICE decompiler!
Also, how is "decompiler" still recognized by Chrome as a misspelled word for me by this point?
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?
_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
Register to Join the Conversation
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
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