Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Ikkerens on June 21, 2010, 05:20:32 am
-
Well, so I have been trying some things with axe now (RAM clear every 2 minutes ftw ;D)
And I came up with a scrolling tilemapper, which speed I think is fair.
I think it can be optimized in some ways, but I can't find any more ways.
P.S. I wanted to make a GIF for demonstration, but after loading the ROM with wabbitemu, nothing happens.
Edit: Uploaded the optimized version
-
Awesome! The code seems fairly simple. As far as optimizations, one thing that stuck out at me was that you were using X-(X/8*8) to do what is more simply just X^8. Same for Y. Also, you store the pointer to the sprite in P but only use it once. You can just put that whole expression where P is so that way you don't have to store and load to it. Its more convenient for the programmer too when you use less variables. Nice job again!
-
I don't see why you're doing X^8
X/8->N
X-(N*8)->I <-- The N given here is already rounded since axe doesn't support floating numbers, which im using in my advantage.
My guess is that X^8 would give all the wrong calculations,
N is my offset where to start drawing, where I would position it.
Could you please explain why you'd do that?
-
Both X^8 and X-(N*8 ) come up with the same answer. X^8 is an optimization of what you have already. It's not changing the answer in any way.
If you didn't know already, Axe uses ^ as modulus instead of the normal 'to the power of...'
If you don't quite understand modulus, maybe this will help:
Say X is 25
(25)/8=3.125 (the decimal/remainder is dropped. No floating numbers here.)
(25)-[(3)*8]=1
Now using modulus
(25)^8=1 (25/8 is 3r1. Division takes the whole number while modulus takes the remainder.)
Lets try again with 39.
(39)/8=4r7(remember to drop the remainder for division)
(39)-[(4)*8]=7
Back to modulus
(39)^8=7 (4r7, whole number is dropped.)
Hope this explains to you what he's talking about.
-
Well, I don't really understand it, but il just use it.
-
Oh, I totally forgot to actually look at the program. :P
...
Ok, I'm back. Looks nice. I'm sure this will help somebody out.
I think that this:
:If X≠64 and getKey(3)
:X+1→X
:End
:If X≠0 and getKey(2)
:X-1→X
:End
can be shortened to this:
:If X and (X≠64
:X+getkey(3)-Getkey(2)→X
Oh, another tiny optimization you can use is remove the Return at the bottom. Once it hits the bottom of your code, there is an implied Return.
-
Those getkey things won't work, I need seperate checks.
And the bottom return, its part of a subroutine, u sure its safe to remove?
-
Already got this in my own calc version:
:If X≠64 and X
:X+getkey(3)-Getkey(2)→X
:End
But can't get it to work.
And the bottom return, its part of a subroutine, u sure its safe to remove?
This is because the "and" is bitwise, not logical. This is why I wanted Quigibo to support logical and,or,xor statements...
-
Oh, and here I was thinking it was already supported. :P
Guess I'll have to wait until he implements that.
From the Axe documentation:
'If the last line of your program is Return, then remove it. Even if it was part of a
subroutine, the return is automatically added at the end for you so there's no need to
have 2 returns at the end. Saves 1 byte.'
EDIT:100th post. Wee! ;D
-
Instead, I did this:
X-(X≠0 and getKey(2))+(X≠64 and getKey(3))→X
Which works.
-
Awesome! Good to see that you worked it through. :)
-
Here's a gif, for anyone who wants to see it.
-
Nice, Ikkerens!
-
Here's a gif, for anyone who wants to see it.
Alot more fluid on calc tho.
-
Nice, Ikkerens! Excellent job! ;D
-
wow nice! I am surprised at how small the code is, too. Do you mind if I ever use parts of it in one of my program if I ever make a game again?
-
wow nice! I am surprised at how small the code is, too. Do you mind if I ever use parts of it in one of my program if I ever make a game again?
Go ahead, thats the main reason why I shared it.
But under 1 condition: Author credits :)
-
yeah don't worry if I use it ^^
Also I noticed a bug: when you scroll up/down from each edges of the map, it scrolls twice faster than in the middle
-
yeah don't worry if I use it ^^
Also I noticed a bug: when you scroll up/down from each edges of the map, it scrolls twice faster than in the middle
Yeh, I noticed that, dunno what's going wrong tho.
Thought it was optic trickery.
-
My guess would be that the number of sprites it has to draw is more/less causing the speed to change slightly.
-
mhmm I am confused... since he draws everything each frame regardless of their position on screen. Could it be that when trying to store them on certain screen sides, they aren't drawn at all?
-
I'd doubt that, my code only draws whats visible on-screen plus a right-side and bottom row.
-
really? Mhmm I didn't notice any checks x.x
-
really? Mhmm I didn't notice any checks x.x
In the drawing sub, change the fors to this:
For(T,0,7)
For(S,0,11)
You'll see the difference.
-
ok I'll check this after work
-
I was playing with this program yesterday and I modified it so that it masks a sprite over the map, then masks a forground over the entire screen.
Screenie and source (Credit for the original engine goes to Ikkerens of course :)) attached:
-
Wow, that is really awesome. Does it remind anyone else of George's old game that he was working on? I cant remember what it was called, but it had similar aspects with parts of the map placed on the top of the sprite. For example when he walked under an archway.
-
Looks really cool and a nice speed.
I did not see the Axe Parser source code to understand the method but in assembly horizontal scrolling is much slower too because shifting bits by rotating them is much more time expensive than moving entire bytes around in the graphics buffer.
-
Wow this is awesome. Look pretty great too. You should make it scroll 2 pixels so it moves a bit faster, though. Also, I discovered why it runs faster on edges and some other portions of the map, when scrolling vertically: it's because when sprites are aligned horizontally on the screen (displayed at multiple of 8 pixels), it takes twice less time to happen. Displaying them at different locations horizontally apparently requires more processing power because of how the memory works (each byte contains 8 pixels. Imagine when you need to display parts of a byte in another for 96 sprites).
Wow, that is really awesome. Does it remind anyone else of George's old game that he was working on? I cant remember what it was called, but it had similar aspects with parts of the map placed on the top of the sprite. For example when he walked under an archway.
Probably not a lot of people around here, since they all joined long after Dys left, but I remember the project quite well. It was amazing (It used Star Ocean 1 tiles, rigth?)
(http://www.omnimaga.org/images/screenshots/auraanim.gif)
-
Yep that would be the one. Brings back memories of how impressive/awesome it was.
-
Is there still a copy/demo of it around anywhere? I would like to just play around with it ^^
-
Unfortunately, nope :(
No demo were ever released
-
I was playing with this program yesterday and I modified it so that it masks a sprite over the map, then masks a forground over the entire screen.
Screenie and source (Credit for the original engine goes to Ikkerens of course :)) attached:
Well done, kinda like that effect.
Could always be nice when creating cinematics or sumthing.
-
Or for mapping Chrono Trigger style... *cough*
Actually Chrono Trigger is what inspired my mod of your engine.
-
I was playing with this program yesterday and I modified it so that it masks a sprite over the map, then masks a forground over the entire screen.
Screenie and source (Credit for the original engine goes to Ikkerens of course :)) attached:
Well done, kinda like that effect.
Could always be nice when creating cinematics or sumthing.
One idea I had using his trick would be to have a second tilemap displayed on top of the first that is smaller, but scrolls 2x faster. Example: when you are in a forest, leafs could scroll faster. That tilemap could just loop. Another use could be in a side scrolling game where you are in a cavern and you see stalagmites/stalacites in front of the game map, scrolling 2x faster when you move around. You could even add a background that scrolls much slower. Keep in mind this would become rather slow, though, especially if you had to use sprite masking.
-
I was playing with this program yesterday and I modified it so that it masks a sprite over the map, then masks a forground over the entire screen.
Screenie and source (Credit for the original engine goes to Ikkerens of course :)) attached:
Well done, kinda like that effect.
Could always be nice when creating cinematics or sumthing.
One idea I had using his trick would be to have a second tilemap displayed on top of the first that is smaller, but scrolls 2x faster. Example: when you are in a forest, leafs could scroll faster. That tilemap could just loop. Another use could be in a side scrolling game where you are in a cavern and you see stalagmites/stalacites in front of the game map, scrolling 2x faster when you move around. You could even add a background that scrolls much slower. Keep in mind this would become rather slow, though, especially if you had to use sprite masking.
Im doubting that, doesn't sound too difficult in my head.
Might try it out once, if no one else does.
-
well, the thing that could slow things down is the fact you would have to draw like 5 13x9 maps every frame (first, the background, scrolling every two frame, secondly, the middleground (where your character walks) mask, third, the middleground tilemap itself, fourth the foreground mask, scrolling 2 pixel by 2 pixel and finally the foreground tilemap. If all your tiles are sqares, then you don't need masks, though.
-
I'd say, 2 extra lines in my for loop, optimized not more than 100 bytes extra. (excl. Graphics)
-
I guess you should prbly try it, then, since you seems to find the idea pretty easy (I have a clue how, but I am not too sure how I would manage over 16 fps on a regular 83+ with it. I mean, it's between 351 and 585 tiles per frame you need to draw, after all)
-
I guess you should prbly try it, then, since you seems to find the idea pretty easy (I have a clue how, but I am not too sure how I would manage over 16 fps on a regular 83+ with it. I mean, it's between 351 and 585 tiles per frame you need to draw, after all)
Well, the main slowdown is DispGraph, not the Pt- functions.
But DispGraph still has to draw 768 bytes, no matter how many tiles.
-
I know, but drawing an incredible amount of tiles eventually adds a slow down. Trust me, I tried it myself. I got an engine right now that draws 14 sprites+tiles per frame. It's blazing fast! If I add a background of 96 tiles, regardless of their content, the speed drops by almost half.
Please show me proof that you can achieve similar speed between a tilemapper where 96 tiles are displayed every frame (unaligned horizontally) and one with 300-500.
-
Well, the foreground layer would be sparse, so it wouldn't be that many tiles. Its 117 tiles for the background. I'll give a conservative estimate of 20 tiles in the foreground and lets say for sake of argument that all 20 tiles are masked. Plus maybe a 4 tile character, that's 161 tiles per frame, which should be around 16 fps in 15MHz mode, but probably laggy at normal speeds.
-
I found a trick to make parralax scrolling much faster for when you use a background filled with the same 8x8 tile:
Instead of doing
X^16->Q/2->Q
Y^16->R/2->R
For(Z,0,12)
For(O,0,8)
Pt-On(Z*8-Q,O*8-R,Pic1)
End
End
I did
X^16->Q/2->Q
Y^16->R/2->R
For(Z,0,12)
For(O,0,1)
Pt-On(Z*8-Q,O*8-R,Pic1)
End
End
For(Z,1,7)
Copy(L6,Z*96+L6,96)
End
It's 77 bytes larger, but see the huge speed difference below! (the later code doesn't need as much processing power because only 24 tiles needs to be displayed unaligned). Note that due to the nature of the engine I am using in my game, the speed increase is much higher than it would be with a regular tilemapper. If your tilemapper is very complex, it's up to you to decide if the speed increase vs size increase is worth it
-
Thats ingenious :D I wonder if any Tilemapper Axioms will be written, because i hear there are mucho optimizations that are involved with displaying smooth tilemaps instead of just looping a sprite routine.
-
yeah same here. I would kinda prefer if it was implemented in Axe, though, so it can be used in the contest. I assume this is not a priority, though. Also I wonder how he would handle smooth scrolling?
I got the idea of Copying the buffer top content when working with unaligned tiles. I saw it was 2x slower and thought: hey, if I just draw enough tiles to fill the top 8 rows, why wouldn't I just copy the rest below afterward? It would need to draw 4x less tiles unaligned.
-
Looks nice DJ.
And makes me remember Sonic bonus levels. ^^
-
thanks ^^
-
Awesome job!
By the way:
For(Z,1,7)
Copy(L6,Z*96+L6,96)
Endcan be
Copy(L6,L6+96,96*7)Since once the first 8 rows are copied to the second 8 rows, the pointer is now on the 2nd row, so its now copying the second row to the third row, etc.
-
Nice, I didn't know it would repeat like this in this case. I'll give this a try. Thanks for the tip!
EDIT: Tried it and it works pretty well. I wonder if the speed increases? I am sure I am noticing something slightly faster
-
Nice! That's a really cool idea. Great job! ;D