Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: waggyner on June 21, 2014, 05:43:45 pm

Title: Axe Parser Picture Issues
Post by: waggyner on June 21, 2014, 05:43:45 pm

I'm trying to make a game and I know I'm going to need more than the 10 pictures the calculator offers me so I thought if I convert the whole pic into hex and then display it, it would work.


Well its not working. The calculator is only graphic half the image and parts are messed up. I know my hex code is correct and I'm pretty sure the way I've set it up to display is correct so I don't know what the problem is.


I've include my source code and what the pic is suppose to look like if it was successful. Please help me out.
If you know a better way please give me an example and don't just say how to do it. Thanks
Title: Re: Axe Parser Picture Issues
Post by: ClrDraw on June 21, 2014, 06:04:17 pm
Have you tried http://www.cemetech.net/sc/ (http://www.cemetech.net/sc/)? You can upload a picture and then convert it into hex.


edit: look at this example program I've made for you.
Title: Re: Axe Parser Picture Issues
Post by: waggyner on June 21, 2014, 09:57:33 pm

Thanks for the help. I didn't know how to use the bitmap command.
It now draws the picture correctly but it has a lot of random shading at the top and a few pixels at the bottom that are not in the hex.
Is there a problem with Axe and outputting for DoorsCS?


I attached the new code as well.
Title: Re: Axe Parser Picture Issues
Post by: ClrDraw on June 21, 2014, 11:11:28 pm
Anytime :)

As for the shading, it works when I try. Maybe you forgot ClrDraw (my favorite command  :P )?
Title: Re: Axe Parser Picture Issues
Post by: Hayleia on June 22, 2014, 04:20:03 am
Axe is not Basic. Here's the source code, in spoiler, for those who wonder why I am saying that.

Spoiler For Spoiler:

.TEMPLE
Goto 1

Lbl 2

ClrDraw

Bitmap(0,0,Pic1)
Bitmap(0,0,Pic2)^^r

DispGraph
Repeat getKey(15)
DispGraph^^r
End

Goto 3

Lbl 1

.black
Data(96,64)->Pic1
[long hex]

.gray
Data(96,64)->Pic2
[long hex]
Goto 2

Lbl 3

For example, this Data(96,64)→Pic2 is NOT storing numbers into a variable. This is declaring to the PARSER that the pointer to those numbers who are somewhere in the program whill be called Pic2 until the end of the program.
This means that you don't need your Lbl 1, Goto 2 and caetera. Just put your pic declarations either at the beginning of your program or at the end (after the final Return) or in the middle, it doesn't change anything (putting it at the end helps you reaching the code when you open your program, putting it at the beginning helps you not forgetting what is what and putting it in the middle helps you know which data is used for which part of the code).
But wherever you put it in your source code, they will be put at the end of the compiled executable so your code will be compiled exactly like this one:


.TEMPLE
Goto 1

Lbl 2

ClrDraw

Bitmap(0,0,Pic1)
Bitmap(0,0,Pic2)^^r

DispGraph
Repeat getKey(15)
DispGraph^^r
End

Goto 3
Lbl 1
Goto 2
Lbl 3
Return

.black
Data(96,64)->Pic1
[long hex]

.gray
Data(96,64)->Pic2
[long hex]



Don't you think now that your Goto 1 then Goto 2 to go back at the beginning are useless ? Same for your Goto 3 ? And even with your original code, the Goto 3 was not so useful, you could have put a Return instead it would have worked too.

Now about your code. You are basically filling the two buffers, so why use Bitmap ? Copy your bytes directly in your buffers instead of wasting space for a routine you use for no big reason. Even worse. Why that DispGraph before the loop with the DispGraph^^r ?

And I would talk about basic optimizations, but this will come later ;)

So yeah, just do this:


.TEMPLE
.black
[]->Pic1
[long hex]

.gray
[]->Pic2
[long hex]

.once again, you can put those declarations elsewhere if you want

Copy(Pic1,L6,768)
Copy(Pic2,L3,768)

Repeat getKey(15)
   DispGraph^^r
End
Return
.the Return is not useful if at the end of the program but it's still good to be used to tell the program exactly what we want it to do and not suppose that it will work.


And since you are completely replacing all previous content in L6 and L3 by copying and not Bitmapping, you don't even need any ClrDraw.
Title: Re: Axe Parser Picture Issues
Post by: Streetwalrus on June 22, 2014, 07:06:00 am
By the way, avoid bitmap as much as possible.
Title: Re: Axe Parser Picture Issues
Post by: ClrDraw on June 22, 2014, 12:28:49 pm
Why?  ???
Title: Re: Axe Parser Picture Issues
Post by: Sorunome on June 22, 2014, 01:48:50 pm
IIRC it is slow and large
EDIT: I still used bitmap in reubenquest, though :P
Title: Re: Axe Parser Picture Issues
Post by: ben_g on June 22, 2014, 02:07:53 pm
Can't you do:
Code: [Select]
Copy(Pic1)

[long hex]->Pic1

instead of:
Code: [Select]
Bitmap(0,0,Pic1)

Data(96,64)->Pic1
[long hex]
iirc it's much more optimized.
Title: Re: Axe Parser Picture Issues
Post by: Hayleia on June 22, 2014, 02:08:51 pm
Where you like "tl;dr" when you saw my post ? Because I am exactly saying that Copy is better :P
Title: Re: Axe Parser Picture Issues
Post by: ben_g on June 22, 2014, 02:13:32 pm
Oh, apparently I did miss a huge part of your post. But you should be able to just use Copy(PTR_to_pic) and Copy(PTR_to_pic,L3) for the black and grey layers respectively.
But it probably compiles into the exact same binary as your code.
Title: Re: Axe Parser Picture Issues
Post by: Hayleia on June 22, 2014, 02:15:16 pm
Yeah, it's the same. I just like to know exactly where and how many bytes I am copying so I always give the three arguments ;)
Title: Re: Axe Parser Picture Issues
Post by: Runer112 on June 22, 2014, 04:43:52 pm
Yeah, it's the same. I just like to know exactly where and how many bytes I am copying so I always give the three arguments ;)

I like this syntax more as well. The copy command can copy any kind of data and doesn't seem like it has much business performing buffer-specific logic. The one-argument version is exactly the same as the much more appropriately named and categorized RecallPic, and the two-argument version could just be a two-argument RecallPic or StorePic. For those reasons, I've actually had ideas of simply removing them.
Title: Re: Axe Parser Picture Issues
Post by: waggyner on June 22, 2014, 07:50:54 pm
Thank you all for your help. I finally have the picture displaying correctly. ;D
Title: Re: Axe Parser Picture Issues
Post by: Streetwalrus on June 23, 2014, 04:04:54 am
Where you like "tl;dr" when you saw my post ? Because I am exactly saying that Copy is better :P
Hum. ::)