Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: nemo on June 15, 2010, 07:50:26 pm
-
"EXP→DispGraph Draws an arbitrary buffer at the pointed location onto the screen."
what exactly does this do?
i stored 0 to it, and got a nice plaster of RAM displayed on my screen, so i'm assuming you need to store something to L6 and it'll display that..?
-
I think that the 'EXP' you store to it is a pointer representing picture or sprite data.
-
My guess is that if for example you store a pic to Str1 pointer, if you do Str1->DispGraph it will automatically display that pic on the screen. My concern, though, is what about L1, L2 or any other pointers where the data is not exactly 768 bytes large?
-
This displays the 768 bytes pointed to. This is useful if you absorb a picture file into your program at the start of it, as you can easily display that picture to the screen. Whatever 768 bytes that are pointed to will be displayed, whether or not it's picture data you want.
-
Aaah ok so there would be no control on how much data we want to display. Thanks
-
By the way, you should be aware that it does not store it in L6, and you can't add sprites or text or anything on top of it. It's only real use is for a splash screen. If you want to change what is onscreen outside of the picture, you should use conj(Pic1, L6, 768. Change Pic1 to the pointer to your picture.
-
Mhmm I'm starting to get the use of this more now. So basically it can be useful if you want to display something on the screen without altering the main buffer, am I right?
-
Right. However, DispGraph will overwrite it. If you use Exp→DispGraph, you cannot modify what shows up onscreen unless you change the value at Exp.
DispGraph itself is essentially L6→DispGraph
-
Well, not yet. Maybe we could ask quigibo to add support for writing directly to the LCD? (and at any spot, most importantly)
-
Well, writing directly to the LCD means that you have to read from LCD RAM for things like Pxl-Test, and displaying sprites without overwrite logic would have to do the same thing, which means it would be much slower, and you would have to worry about the LCD delay, too.
-
Well, writing only, then. Yeah, the LCD is painfully slow...
-
So if you had a splash screen stored to, say, Pic1 and said Pic1->DispGraph, it would show Pic1? But I thought you could only store 8x8 sprites to pic pointers...? confused >.<
-
No, I could do "Hello World"->Pic1 and it'd be fine.
And yes, if Pic1 is a 768-byte picture, then Pic1->DispGraph will display it (on the screen only, not the buffer, as discussed)
-
So if you had a splash screen stored to, say, Pic1 and said Pic1->DispGraph, it would show Pic1? But I thought you could only store 8x8 sprites to pic pointers...? confused >.<
If you absorb a Pic into the source you can recall it in that manner. :)
-
I would like to be able to AND, OR, and XOR pictures to the LCD without having to use custom routines like I do now.
However, I don't think that directly reading/writing to/from the LCD would be a very good idea in Axe.
-
I would like to be able to AND, OR, and XOR pictures to the LCD without having to use custom routines like I do now.
However, I don't think that directly reading/writing to/from the LCD would be a very good idea in Axe.
I'm thinking the same things Sir. :)
-
[offtopic]It's so cool to have everyone refer to me as "Sir" even when they are pissed at me (not that ztrumpet is pissed at me) :P[/offtopic]
-
Right. However, DispGraph will overwrite it. If you use Exp→DispGraph, you cannot modify what shows up onscreen unless you change the value at Exp.
DispGraph itself is essentially L6→DispGraph
I'M a bit confused by what you mean here. So does Exp->DispGraph overwrite L6 or not?
-
No. Exp→DispGraph does not overwrite L6.
-
Aah ok thanks for clarifying. Also
[offtopic]It's so cool to have everyone refer to me as "Sir" even when they are pissed at me (not that ztrumpet is pissed at me) [/offtopic]
Could you quote the posts where people are pissed at you? O.o
-
Well, most of the time it was on IRC or the like...
Also, it might be worth mentioning that the LCD has its own internal RAM, which is where L6 is copied to when DispGraph is called, and where Exp is copied to when Exp→DispGraph is called. However, LCD RAM is horribly, horribly slow.
-
Oooh ok lol :P
And yeah I know how slow it is. Just to tell you, you know my pixelating routines, right? (see the Axe tribute vid and look for a pic that shows Link in manga style) Well, if I updated the screen pixel by pixel, it took several dozen of seconds to render. By storing to the buffer then updating the LCD only once, it took half a second!
-
Yeah, that would by why.
-
This is why BASIC programs using pixel and point commands are so slow. For example, I made a BASIC program to make the screen all-black and an Axe program to do the same (both doing it pixel-by-pixel). The BASIC program was, of course, slow, while the Axe program was nearly instantaneous. Changing the Axe program to update the LCD after every Pxl-On( made it as slow as the BASIC program. (Well, the Axe program was running at 6MHz, idk how much of a difference 15Mhz mode would make)
-
This is why BASIC programs using pixel and point commands are so slow. For example, I made a BASIC program to make the screen all-black and an Axe program to do the same (both doing it pixel-by-pixel). The BASIC program was, of course, slow, while the Axe program was nearly instantaneous. Changing the Axe program to update the LCD after every Pxl-On( made it as slow as the BASIC program. (Well, the Axe program was running at 6MHz, idk how much of a difference 15Mhz mode would make)
Mhmm I found the BASIC counterpart to run even slower if set at the same MHz speed as the Axe one. In my case, I got like 3x slower speed on the BASIC program when using pixel by pixel. Just the parsing makes things slower, but the LCD updating is even more enough to ruin everything.
Had BASIC not updated the LCD constantly and just did with DispGraph, certain things would have run much faster. I guess it shows TI-BASIC was not aimed directly at game developpement (altough you can still make awesome things in it, such as Exodus)
-
Expanding the awesome things list, I add Illusiat to it.
Also, I really wish that TI Basic could be run at 15 MHz
-
Lol ok ;D
And TI-BASIC already runs at 15, btw. If you test games on emulators, you'll notice how they run twice faster on 83+SE/84+/SE than on regular 83+
-
Really? I hadn't noticed.