Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Camdenmil on October 03, 2011, 05:52:59 pm
-
Does anyone have a fast routine to display pictures bigger than the screen? I can't figure out how to draw them starting from any pixel coordinate of the picture.
-
meh that is actually kind of difficult because the picture and the screen memory is mapped differently........uhm let me try and make up a routine:
uhhhhhhhhhh
Copy(y*h+x,L6,12) will do the first row so..
For(e,0,63)
Copy(y+e*h+x,e*12+L6,12)
End
y*h->a
0->b
64
while -1->e
copy(a,b+L6,12)
a+h->a
b+12->b
e
end
Try that, I think it might be able to work
-
Couldn't you optimize that to a single copy statement?
Copy(Y*12+Pic1,L6,768)
Then again, this only works for pictures that scroll in the Y direction. The X direction is much harder D:
-
You can store your picture as a bunch of 8x8 sprites, then draw 13x9 of them to the buffer. Like a tilemapper, except without the tile lookup.
Edit:
This reminds me, why doesn't Axe support 8xN sprites yet?
-
Edit:
This reminds me, why doesn't Axe support 8xN sprites yet?
Because even though I've requested it at least twice it's deemed "too useless" for Axe. :P
-
I could imagine 4*4 (or 5*5) being used a lot...
As for the topic of this thread, idk to that as well, I'd go with what either calc84 or squidgetx said :P
-
You can store your picture as a bunch of 8x8 sprites, then draw 13x9 of them to the buffer. Like a tilemapper, except without the tile lookup.
Edit:
This reminds me, why doesn't Axe support 8xN sprites yet?
Why didn't I think of that :banghead: 8xN sprites would be nice for this though.
-
You can store your picture as a bunch of 8x8 sprites, then draw 13x9 of them to the buffer. Like a tilemapper, except without the tile lookup.
Edit:
This reminds me, why doesn't Axe support 8xN sprites yet?
For that matter, why doesn't Axe support m*n sprites yet?
-
You can store your picture as a bunch of 8x8 sprites, then draw 13x9 of them to the buffer. Like a tilemapper, except without the tile lookup.
Edit:
This reminds me, why doesn't Axe support 8xN sprites yet?
For that matter, why doesn't Axe support m*n sprites yet?
One step at a time :P
-
Yeah, I was thinking of changing the Bitmap() command's code to use a custom, fully clipped routine that would make it more useful. Currently its used very rarely because the OS's routine is slow, buggy, and just sucks. I don't mind having a big bulky routine as long as the ease of use makes up the difference.
If either you or Runer or anyone else wants to design a routine, I'd be happy to include it. It needs:
- Clipping in all directions
- Supports aligned and unaligned sprites
- Sprite dimensions built into data
- Data itself can be in any format (byte aligned not necessary)
- Usable on any buffer
- Extra argument to allow both "Or" or "Xor" drawing methods ("And" would be nice too)
Don't worry about the register/stack juggling for input, I can optimize that myself.
The complexity of this routine is the only thing holding me back right now :P The reason for the last condition is that I don't want separate routines for each method, this is a command that should be optimized for usefulness, not for size or speed. If you needed the later, you'd be using 8x8 or smaller anyway.
-
If you do that, you get >9000 respect. do it.