Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: Raylin on June 06, 2010, 11:43:58 am

Title: Enlarging sprites?
Post by: Raylin on June 06, 2010, 11:43:58 am
Is there a way to do it in Axe without losing resolution?
Title: Re: Enlarging sprites?
Post by: calcdude84se on June 06, 2010, 12:25:50 pm
What do you mean by enlarge? Draw a normally 8*8 sprite 16*16? You can't enlarge any image w/o losing resolution, though if you mean anti-aliasing it somewhat, you could write a program or do it by hand.
Sorry if that made no sense, I did the best I could considering I didn't completely understand you're question.
Title: Re: Enlarging sprites?
Post by: Raylin on June 06, 2010, 12:33:27 pm
Basically.
Make an 8*8 sprite 16*16.

Or vice versa.
Title: Re: Enlarging sprites?
Post by: calcdude84se on June 06, 2010, 12:38:02 pm
I don't think there's an efficient, good-looking way to do it automatically. (Someone correct me if I'm wrong). If you just want to double the size of a sprite with no regard to de-pixelizing it, well, I can't think of an efficient way to do it. I'll think about it...
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 06, 2010, 03:51:01 pm
the only way I can think about would be drawing the sprite on the buffer somewhere, and using pixel test to display it scaled up.

I think it would be very slow, though, especially if you want to draw an entire map or masked sprites
Title: Re: Enlarging sprites?
Post by: meishe91 on June 06, 2010, 03:51:42 pm
Well the only way I can think of doing this is making a program that checks for a position of a pixel on one buffer and for ever pixel make a block of four pixels on the other buffer.

Example:

Code: [Select]
██
██

would be:
████
████
████
████

That's the only way I can think about. I don't have time to try and make a program in Axe for this right now but I can try later if no one else does. No idea if this helps though.
Title: Re: Enlarging sprites?
Post by: calcdude84se on June 06, 2010, 04:14:41 pm
So we can't think of anything efficient. Does anyone know something that does it efficiently? (I'm asking our ASM experts here)
Title: Re: Enlarging sprites?
Post by: Builderboy on June 06, 2010, 04:24:32 pm
Is it enlarging by 2 only? Then i can think of a way, let me pull something together...
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 06, 2010, 04:49:59 pm
I would have given this a try, but given my recent Axe experiments, I seriously doubt I'll have any success getting anything to run at all
Title: Re: Enlarging sprites?
Post by: meishe91 on June 06, 2010, 05:14:26 pm
I'm close to getting it to work. The result is just turning out skewed. I'll post the code to see if someone else can get it to work before me.

Got it to work!

Code: (x2 Magnification) [Select]
.TEST
ClrDraw
ClrDraw^r
[3C42A59999A5423C]→Pic1
[C0C0000000000000]→Pic2
Pt-On(0,0,Pic1)
DispGraph
0→C→D
For(A,0,7)
For(B,0,7)
If pxl-Test(B,A)
Pt-On(B+C+10,A+D,Pic2)
End
C+1→C
End
0→C+D+1→D
End
DispGraph^r

I realize some may not be optimized.

Note: Technically you don't have to use both buffers. I just did because it avoids colliding of pictures. It just depends where you want the end to display.

P.S. I would like to point out out the time when I made my first successful Axe program/routine ;D

Edit: If you want x8 magnification (like graphmastur did) you only have to make a few tweaks to my code. Once I figure it out you will be able to make any sized magnification with simple tweaks of mine, I just have to make sure I'm right.

Anywho, the tweak for x8.

-Change [C0C0000000000000]→Pic2 to [FFFFFFFFFFFFFFFF]→Pic2.
-Change Pt-On(B+C+10,A+D,Pic2) to Pt-On(B+C+17,A+D,Pic2).
-Change C+1→C to C+7→C.
-Change 0→C+D+1→D to 0→C+D+7→D.

Edit: Ok, so ya. This method does work with any level of magnification. (Well up to x8 since I use sprites to display the magnified version. You could do more if you started displaying multiple sprites for one magnified block.)

Here is what you do:

-You change the hex code into a block of either 1*1, 2*2, 3*3, 4*4, 5*5, 6*6, 7*7, or 8*8 (which ever level of magnification you want).
--x1: [8000000000000000]→Pic2
--x2: [C0C0000000000000]→Pic2
--x3: [E0E0E00000000000]→Pic2
--x4: [F0F0F0F000000000]→Pic2
--x5: [F8F8F8F8F8000000]→Pic2
--x6: [FCFCFCFCFCFC0000]→Pic2
--x7: [FEFEFEFEFEFEFE00]→Pic2
--x8: [FFFFFFFFFFFFFFFF]→Pic2
-Change the constant in the first part of the Pt-On( (that is in the For( loop) to 8+Level of Magnification+1.
--x1: Pt-On(B+C+10,A+D,Pic2)
--x2: Pt-On(B+C+11,A+D,Pic2)
--x3: Pt-On(B+C+12,A+D,Pic2)
--x4: Pt-On(B+C+13,A+D,Pic2)
--x5: Pt-On(B+C+14,A+D,Pic2)
--x6: Pt-On(B+C+15,A+D,Pic2)
--x7: Pt-On(B+C+16,A+D,Pic2)
--x8: Pt-On(B+C+17,A+D,Pic2)
-Change the constant that is added to the variable C to Level of Magnification-1.
--x1: C+0→C (Could technically take out at this point.)
--x2: C+1→C
--x3: C+2→C
--x4: C+3→C
--x5: C+4→C
--x6: C+5→C
--x7: C+6→C
--x8: C+7→C
-Change the constant that is added to the variable D to Level of Magnification-1.
--x1: 0→C+D+0→D (Can simplify to 0→C+D→D.)
--x2: 0→C+D+1→D
--x3: 0→C+D+2→D
--x4: 0→C+D+3→D
--x5: 0→C+D+4→D
--x6: 0→C+D+5→D
--x7: 0→C+D+6→D
--x8: 0→C+D+7→D

Example:

Code: (x6 Magnification) [Select]
.MAGX6
ClrDraw
ClrDraw^r
[3C42A59999A5423C]→Pic1
[FCFCFCFCFCFC0000]→Pic2
Pt-On(0,0,Pic1)
DispGraph
0→C→D
For(A,0,7)
For(B,0,7)
If pxl-Test(B,A)
Pt-On(B+C+15,A+D,Pic2)
End
C+5→C
End
0→C+D+5→D
End
DispGraph^r

I just realized that DispGraphr isn't technically used for displaying the back buffer (it works in this case though). Is there a command that does just display the back buffer? Or is DispGraphr used for this as long as it isn't in a loop?
Title: Re: Enlarging sprites?
Post by: BuckeyeDude on June 06, 2010, 05:19:34 pm
Even if you could do this, it probably wouldnt be a smart idea. Drawing anything takes a lot of time normally, and you will want to optimize it as much as possible. This is made even harder by the fact that it is stored as bits and not bytes. Much better to use the extra space and store the sprite blown up if you need that. This also lets you store extra detail instead of a blown up 8x8
Title: Re: Enlarging sprites?
Post by: jnesselr on June 06, 2010, 05:38:07 pm
How about this for enlarging it 8 times.  Useful for editing I guess.  I did not use the back buffer at all.
Code: [Select]
ClrDraw
[C3A5555A242445AA5C3]->Pic1  // Your sprite
[0000000000000000]->Pic2
[FFFFFFFFFFFFFFFF]
For(A,0,7
{Pic1+A}->I
For(B,0,7
I^2->L
I/2->I
Pt-Off(8*(7-B),8*A,8*L+Pic2
End
End
Title: Re: Enlarging sprites?
Post by: Quigibo on June 06, 2010, 05:41:21 pm
Pt-Off(8*(7-B),8*A,8*L+Pic2

To

Pt-Off(7-B*8,A*8,L*8+Pic2

For much faster/smaller optimization.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 06, 2010, 05:45:01 pm
The trick when you just need 2x, 3x, 4x, 5x, up to 8x8, is to just use 8x8 sprites that contains square of those sizes (filled black) and use them instead of pixels. It's much faster than recalling each pixels one by one. It's much larger, though...
Title: Re: Enlarging sprites?
Post by: jnesselr on June 06, 2010, 05:46:34 pm
True.  And this is for 8x8 to 16x16. with x,y location.
Code: [Select]
ClrDraw
[C3A5555A242445AA5C3]->Pic1  // Your sprite
[0000000000000000]->Pic2
[FFFFFFFFFFFFFFFF]
For(A,0,7
{Pic1+A}->I
For(B,0,7
I^2->L
I/2->I
For(C,0,1):For(D,0,1)
if L
Pxl-On(7-B*2+D+Y,2*A+C+x
else
Pxl-Off(7-B*2+D+y,2*A+C+x
End
End:End
End
End

How's that?
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 06, 2010, 07:18:22 pm
I'll try this later, I am too lazy to convert it to SourceCoder format or typing it on my calc by hand ATM :P
Title: Re: Enlarging sprites?
Post by: Deep Toaster on June 06, 2010, 08:04:20 pm
I tried it out on my calculator, but Axe didn't gave me an ERR: HEXADECIMAL. Is the 9.5-byte sprite [C3A5555A242445AA5C3] a typo?
Title: Re: Enlarging sprites?
Post by: meishe91 on June 06, 2010, 08:18:40 pm
I don't know but it isn't a correct sprite hex. I think he just typed a bunch but I'm not sure. Just take away the 5C3 at the end and it'll work.

I updated my post to show how to get all the different levels of magnification using my routine for anyone who wants to check that one out.
Title: Re: Enlarging sprites?
Post by: FinaleTI on June 06, 2010, 08:29:17 pm
I tested it with [FF818181818181FF] as Pic1 and it worked great!
Please excuse any typing errors. (Stupid iTouch!)
Title: Re: Enlarging sprites?
Post by: Deep Toaster on June 06, 2010, 08:34:18 pm
It works perfectly now. Nice routine.
On a related topic, is there a command to display a 16x16 sprite in Axe?
Title: Re: Enlarging sprites?
Post by: meishe91 on June 06, 2010, 08:40:25 pm
Not a built in command. But there are routines in the Axe board somewhere. There are a couple. I don't know if they would work the same now though since they were made for previous versions.
Title: Re: Enlarging sprites?
Post by: jnesselr on June 06, 2010, 09:35:01 pm
Sorry, the sprite is C3A55A24245AA5C3.  I just typed too many chars in some places. (Extra 5, extra 4...)
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 06, 2010, 10:02:46 pm
It works perfectly now. Nice routine.
On a related topic, is there a command to display a 16x16 sprite in Axe?
You need to display 4 8x8 sprites that forms a 16x16 one. It's best if done in a sub(LBL) routine, though, if you have to use 16x16 several times in the program.
Title: Re: Enlarging sprites?
Post by: meishe91 on June 06, 2010, 10:26:44 pm
Could someone take a look at my routine/s and tell me what they think and all? Just haven't heard anything about it and I'm a bit curious, not trying to sound rude or anything.

Edit: By the way, here is a basic and not efficient way for displaying a 16*16 sprite.

Code: [Select]
.SPT16X16
ClrDraw
[FFFFC0C0C0C0C0C0
FFFF030303030303
C0C0C0C0C0C0FFFF
030303030303FFFF]→Pic1
Pt-On(0,0,Pic1
Pt-On(8,0,Pic1+8
Pt-On(0,8,Pic1+16
Pt-On(8,8,Pic1+24
DispGraph

Like I said this is probably really inefficient. There are better methods of doing this. This just shows the displaying four sprites to make one large one thing DJ said.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 06, 2010, 10:52:26 pm
Do you think you could post a 8xp version of it? Because it errors in SourceCoder
Title: Re: Enlarging sprites?
Post by: meishe91 on June 06, 2010, 10:54:27 pm
A version of what? Of one of the magnifiers?
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 06, 2010, 11:02:23 pm
yeah (or both)
Title: Re: Enlarging sprites?
Post by: meishe91 on June 06, 2010, 11:03:58 pm
Well there are technically eight :P But ya, I'll to that in a minute.

Edit: Here are all 16 programs. X?.8xp is the source code and MAGX?.8xp is the executable.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 07, 2010, 12:01:49 am
cool thanks


And they are epic!
Title: Re: Enlarging sprites?
Post by: meishe91 on June 07, 2010, 12:02:18 am
Why thank ya. :)
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 07, 2010, 12:58:32 am
Well I was a little bored and modified the last one. This is not very practical for stuff such as a tilemapper (I get 10 fps on one sprite) but for other stuff it can be useful maybe. In its current form it just animates through smallest zoom to the largest.

Code: [Select]
:.MAGX8
:ClrDraw
:ClrDrawr
:[3C42A59999A5423C]→Pic1
:[0000000000000000FFFFFFFFFFFFFFFF]→Pic2
:For(Z,10,80
:ClrDraw
:Pt-On(0,0,Pic1)
:For(C,0,8)
:C*Z/10→A
:For(D,0,8)
:D*Z/10→B
:Pt-Off(B+17,A,((pxl-Test(D,C)) and (C<8) and (D<8))*8+Pic2)
:End
:End
:DispGraph
:End

I am sure someone could poke this code with Quigibo's Axe of Optimization (sorry, stolen from Weregoose TI-BASIC stick of optimization... couldn't resist :P)
Title: Re: Enlarging sprites?
Post by: Quigibo on June 07, 2010, 01:54:14 am
 ;D Wow!  That's really cool!

On the topic of optimizations, why is there D<8 and C<8?  Can't the loop just go from 0 to 7 instead?  Other than that its pretty optimized.  But if you really want speed, you can actually read from the sprite data directly instead of using the getpixel command and then the sprite doesn't have to be drawn first either, but it is a little harder.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 07, 2010, 02:27:59 am
Oh I did that since I was only drawing one single sprite. If I stop at 7, the last row and column will always be 8 pixels wide.

Could you explain how to draw from sprite data directly? Axe lacks a command to read individual bits from data, which I assume I would need to do that...
Title: Re: Enlarging sprites?
Post by: Quigibo on June 07, 2010, 02:30:58 am
You wouldn't use a bit command anyway since it would be a slower.
Code: [Select]
:.MAGX8
:[3C42A59999A5423C]→Pic1
:[0000000000000000FFFFFFFFFFFFFFFF]→Pic2
:For(Z,10,80
:ClrDraw
:For(C,0,8)
:C*Z/10→A
:{Pic1+C}→E
:For(D,0,8)
:D*Z/10→B
:Pt-Off(B+17,A,E^2 and (C<8) and (D<8)*8+Pic2)
:E/2→E
:End
:End
:DispGraph
:End
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 07, 2010, 03:51:30 am
Oh ok I thought you meant a way to also draw each individual columns of pixels one by one too, not just rows. I guess just rows are not too hard then (well I don,t really understand the code that much but it seems to make a bit more sense than what I thought).

Sadly I did not notice that much of a speed increase, though. I used a stopwatch and the increase total was only like half a second. Still better than nothing I guess, though.

Size-wise, there's a huge difference, though. Even after deleting the two unnecessary ClrDraw commands at the top of my original code to drop my original program to 623 bytes, your optimizations made it drop to 457 bytes!

Thanks a lot
Title: Re: Enlarging sprites?
Post by: meishe91 on June 14, 2010, 01:34:02 am
@Raylin
Any of this stuff help?
Title: Re: Enlarging sprites?
Post by: Raylin on June 14, 2010, 08:21:27 am
Yes! It helps quite a bit.

I think that I underestimate the speed of which Axe can produce sprites. This would explain a lot of things.
Title: Re: Enlarging sprites?
Post by: Galandros on June 14, 2010, 09:54:54 am
Looks really cool and fast. :o
I have to learn how to enlarge sprites like that. Enlarging by 2x is easy, though...
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 14, 2010, 01:07:15 pm
Note: I would not recommend using zooming tilemappers, though. As you can notice in the screenshot, I get about 9 fps. After Quigibo optimization, I got 10. If I get 10 with only one sprite, imagine what it would be with 10+
Title: Re: Enlarging sprites?
Post by: Raylin on June 14, 2010, 01:12:35 pm
I only needed one sprite to be enlarged. :P
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 14, 2010, 01:14:55 pm
Aaah ok, should be good, then ^^
Title: Re: Enlarging sprites?
Post by: calc84maniac on June 15, 2010, 02:34:14 pm
Here's the code I just modified for 16x24 sprites:
Code: [Select]
:.MAGX8
:.I'm too lazy to put in my own 16x24 sprite
:[sprite data here]→Pic1
:[0000000000000000FFFFFFFFFFFFFFFF]→Pic2
:For(Z,10,80
:ClrDraw
:For(C,0,24)
:C*Z/10→A
:{C*2+Pic1}r→E
:For(D,0,16)
:D*Z/10→B
:Pt-Off(B+17,A,E^2 and (C<8) and (D<8)*8+Pic2)
:E/2→E
:End
:End
:DispGraph
:End

Should work, I hope.

Edit: typo
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 02:35:02 pm
cool I'll try it when I get some time ^^
Title: Re: Enlarging sprites?
Post by: Raylin on June 15, 2010, 02:39:09 pm
I see that the community wants me to make this thing psuedo-3D.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 02:42:49 pm
XD

Try to not make something too large, though, if you do that. If you use pre-rendered map pics your game will get massive very fast and collision detection will quickly reach the 8 KB code limit x.x
Title: Re: Enlarging sprites?
Post by: Raylin on June 15, 2010, 02:49:02 pm
Wait. Speaking of collision detection...

Oi. That thing is going to be a monster if I do this...
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 04:05:30 pm
Calc84maniac your routine seems buggy or use different sprite format. Here's what I got :S
Title: Re: Enlarging sprites?
Post by: Raylin on June 15, 2010, 04:41:58 pm
It looked like that was updating PREETTTY slow. :c
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 04:48:34 pm
yeah. I think scaled sprites are definitively not really suitable for real-time movement D:
Title: Re: Enlarging sprites?
Post by: Raylin on June 15, 2010, 04:50:43 pm
Agreed.
Perhaps a type of enemy?
Big Boss!?

:D

Yes, that was a Metal Gear Solid reference.
Title: Re: Enlarging sprites?
Post by: calc84maniac on June 15, 2010, 05:01:22 pm
Ooh, I think the C<8 and D<8 need to be changed.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 05:08:51 pm
Agreed.
Perhaps a type of enemy?
Big Boss!?

:D

Yes, that was a Metal Gear Solid reference.
what I thought is that it might be more suitable for animations or maybe some transitions that doesn't require much speed

Ooh, I think the C<8 and D<8 need to be changed.
do you mean to C>8 and D>8?
Title: Re: Enlarging sprites?
Post by: calc84maniac on June 15, 2010, 05:10:07 pm
Agreed.
Perhaps a type of enemy?
Big Boss!?

:D

Yes, that was a Metal Gear Solid reference.
what I thought is that it might be more suitable for animations or maybe some transitions that doesn't require much speed

Ooh, I think the C<8 and D<8 need to be changed.
do you mean to C>8 and D>8?
No, I think it should be C<24 and D<16
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 05:13:31 pm
aaah ok thanks for clarifying :P

It still kinda fails, though :(
Title: Re: Enlarging sprites?
Post by: Quigibo on June 15, 2010, 05:16:42 pm
I think you might just have your data in the wrong format.
Title: Re: Enlarging sprites?
Post by: calc84maniac on June 15, 2010, 05:20:12 pm
Ah yeah, you need to store each pair of bytes backwards because z80 is little-endian.

Edit:
To clarify, I meant *swap* the bytes in each pair
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 05:24:57 pm
I am unsure what you mean. Could you post in what format the sprite must be so I understand? I won't understand unless I got concrete example

This is raylin sprite, btw. I'm not sure what he used to convert it
Title: Re: Enlarging sprites?
Post by: calc84maniac on June 15, 2010, 05:26:47 pm
like, instead of [0123ABCD
you would do [2301CDAB
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 05:32:46 pm
aaah ok. I did not know sprite data needed to be stored this way, though. I never noticed any issue when working with sprites before, or is it just the way your routine works?

I don,t think I'll bother converting everything, though. It will take too long
Title: Re: Enlarging sprites?
Post by: calc84maniac on June 15, 2010, 05:35:00 pm
aaah ok. I did not know sprite data needed to be stored this way, though. I never noticed any issue when working with sprites before, or is it just the way your routine works?

I don,t think I'll bother converting everything, though. It will take too long
It's just how my routine works, because it loads two bytes at once.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 05:36:05 pm
Aaah ok I see. Thanks for the info. Could it be modified to work backwards, though? It would be more user-friendly if someone ever decided to use it.
Title: Re: Enlarging sprites?
Post by: ztrumpet on June 15, 2010, 06:30:19 pm
That looks like a neat routine.  Nice job calc84! :D
Title: Re: Enlarging sprites?
Post by: Runer112 on June 15, 2010, 07:04:51 pm
Zooming the whole screen will be too slow? Who said?
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 07:10:35 pm
Wow, could you explain in details how you managed to achieve such speed? I totally don't understand any of your code x.x
Title: Re: Enlarging sprites?
Post by: nemo on June 15, 2010, 07:16:58 pm
oh man, i am doing something cool with that right away.
Title: Re: Enlarging sprites?
Post by: Runer112 on June 15, 2010, 07:49:02 pm
This is a little weird to explain. This zooms by shifting the screen in parts to each edge. For vertical zooming, it's as simple as copying data from L₆+12 to L₆ and copying from L₆+755 to L₆+767 (reversed) multiple times, each time with a different copy size. Horizontal zooming was a bit tougher and takes up most of the variables and calculations. I multiply a certain number of bytes on the left side of the screen by 2 and divide bytes on the right side by 2, making sure to carry pixels that would be bumped off from byte to byte.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 08:16:16 pm
ugh that sounds too confusing. I don't think I'Ll ever be able to understand stuff to such low level. Maybe the vertical part, but not the horizontal one. I guess I'll have to stay away from zooming stuff. What I don't understand at all the most is how you say you work with stuff on edges of the screen, zooming it out, but don't talk about the middle of the screen. Doesn't the middle of the screen need to be zoomed out too?
Title: Re: Enlarging sprites?
Post by: Runer112 on June 15, 2010, 08:24:44 pm
What I mean is that everything is moved towards the edges of the screen. The distance from the middle in either the vertical or horizontal direction determines how far it will be moved towards either the vertical or horizontal edge closest to it. The middle pixels will move towards the edges by only one pixel, whereas pixels halfway between an edge and the middle will be moved all the way to the edge.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 08:32:46 pm
Yeah but I still don't get how do you move the stuff this fast outside of the screen and how you manage to extend the lenght between each pixels to make them bigger
Title: Re: Enlarging sprites?
Post by: Runer112 on June 15, 2010, 08:35:30 pm
And we don't want to leave grayscale programs stranded, though they'll take a decently sized speed hit: 4 seconds for black and white vs 12 seconds for grayscale. It takes an extra 4 seconds to shift the back buffer and another 4 to update the screen using DispGraphrr 128 times throughout the process. On 15MHz calculators, this routine should take about 8 seconds.

EDIT: Uploaded a new GIF and source, as I realized I was copying the pictures to the wrong buffers so the grays were reversed.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 08:37:15 pm
wow I'll never be able to reach your level in Axe skills. x.x
Title: Re: Enlarging sprites?
Post by: Runer112 on June 15, 2010, 08:53:52 pm
Yeah, the hardest parts about this routine were the horizontal zooming and indicating which pixel rows/columns to shift outwards from, and in what order. The horizontal zooming is quite math-based, and took a lot of pacing around my room and thinking to produce and finally get right.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 09:00:31 pm
indicating which pixel rows/columns to shift outwards from
yeah my issue was really understanding how you did that. I guess that clarifies things a bit, altough I am still wondering how do you shift parts of the screen. Do you just do like Conj(PTR+1,PTR,size of the part of the screen you want to shift) then update the lines of pixels that were left intact in the process? I'm not too sure how to explain my question better
Title: Re: Enlarging sprites?
Post by: Runer112 on June 15, 2010, 09:11:06 pm
Well the thing about shifting pixels outwards horizontally is that, whereas a vertictical shift of one pixel is 12 bytes, a horizontal shift of one pixel is only one bit. Shifting data by one bit cannot be done using conj().
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 15, 2010, 09:27:38 pm
Could you maybe post a frame by frame (except maybe if it's repeating the same code 64 times, just post two or three frames) chronology of what each lines of code do in terms of updating the screen buffer? I am sorry but I absolutely get no clue what you are saying. Is there any tutorial somewhere on how to understand such stuff (not tutorials on the actual zooming, but understanding the tutorials about them)?
Title: Re: Enlarging sprites?
Post by: Runer112 on June 16, 2010, 12:51:59 am
Here's a very slowed down example of horizontal zooming. Currently, it is doubling the X=24 column of pixels. After this, it would jump to the other side of the screen and double the X=71 (95-24) column, pushing pixels right instead of left. To end up with a fully 2x zoomed image, this is done on different pixel columns and until every column has been doubled.

Before a group of pixels flashes off, the data for those pixels is stored to a variable. (You can only see the flashes affect one or two pixels, but they in fact cover 8 pixels, because:) The pixels in this group are the pixels not being shifted and the single pixel being doubled in the byte containing the X=24 pixel, or in this case, all the pixels in the X=24 byte, because X=24 is the leftmost bit in the byte. We're removing them first so when the byte is multiplied by 2 and thus shifted left by one pixel, we can simply add back their values as they were without a shift. All the pixels to the right of and equal to X=24 will thus retain their values before the shift. Because we happen to be shifting a pixel that is the first bit in its byte, multiplying it by 2 will actually shift that pixel off the end of the byte. But we didn't lost it. Before we multiplied the byte by 2, we stored the value of the leftmost pixel (byte^128) to a variable so we could carry it over to the next byte. Therefore, we will end up with the X=24 pixel and the pixels to the right of it with the same value, but we will add back that carry-over value as the eight bit in the byte to the left, effectively doubling the X=24 pixel. We then move left byte by byte (8 pixels by 8 pixels), storing the leftmost bit, multiplying by 2, and adding back the leftmost bit from the previous byte, shifting bytes by 1 bit until we reach the edge of the screen. This will repeat for Y=0 to 63, then move to the other side of the screen and perform mirrored operations for X=71. This repeats until all pixel columns have been doubled and the outside pixels shifted out.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 16, 2010, 01:07:53 am
mhmm I think I am starting to understand the concept a bit. One part I got confused at is how to only store certain pixels in particular. I'm glad you explained it in details. I am still confused at paragraph 2 sentence 4, though x.x

Also in which order do you double rows, btw, after 24 and 71? I assume it's 12 then 83, right? But what would be the exact order afterward?
Title: Re: Enlarging sprites?
Post by: Runer112 on June 16, 2010, 01:14:00 am
mhmm I think I am starting to understand the concept a bit. One part I got confused at is how to only store certain pixels in particular. I'm glad you explained it in details. I am still confused at paragraph 2 sentence 4, though x.x

If by sentence 4 you mean "All the pixels to the right of and equal to X=24 will thus retain their values before the shift," here's the explanation. We stored the values of all these pixels (because we happen to want to retain the position of every pixel in this byte, we will store byte^256) to a variable before turning them all of, because we don't want these pixels to move. We had to turn them all off so when we multiplied the byte by 2, the other pixels will be shifted, but 0's will be in the spaces of these pixels, so we can simply add back the value we stored earlier to get these pixels as they were without a shift.

Also in which order do you double rows, btw, after 24 and 71? I assume it's 12 then 83, right? But what would be the exact order afterward?

24,11,36,3,29,15,42,24,9,38,30,14,45,18,1,34,25,7,42,19,37,27,7,46,12,32,21,42,14,36,24,47

It may be easier to understand the following, though:
24,12,36,6,30,18,42,3,27,15,39,9,33,21,45,1,25,13,37,7,31,19,43,4,28,16,40,10,34,22,46,2,26,14,38,8,32,20,44,5,29,17,41,11,35,23,47

The second list is the order in which I'd want to do each pixel column in the original picture. However, because doubling columns before I get to a certain column means the column I really want has been shifted over, I had to account for this, thus the first list.
Title: Re: Enlarging sprites?
Post by: DJ Omnimaga on June 16, 2010, 01:16:40 am
ah ok thanks a lot ^^

At least now I understand what all that list data was for before the code :P


EDIT: wow didn't see the other post edit, only the last one. After paragraph 4 there was nothing x.x

I think I am starting to get it, altough this seems like a lot of stuff to do x.x

I will probably stay away from that stuff unless I absolutely want to make a game using such stuff and may just use your routine

Thanks anyway, though, for your help
Title: Re: Enlarging sprites?
Post by: ztrumpet on June 16, 2010, 11:13:09 am
Wow, that's complex Runner.  Great job making it work! :D