Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Builderboy on November 05, 2010, 06:17:00 pm
-
So one thing i have noticed in Axe is that smoothscrolling tilemappers tend to be fairly slow. Slower that is than asm by far for some reason. SO i am creating this thread for people to post their best efforts at making a smoothscrolling tilemapper. Post the engines constraints, speed (frames per second) and any other facts.
Note that when measuring tilemapper framerate, have the tilemapper scroll in both directions so that allignment doesn't throw the readings off.
Here is my current fastest tilemapper stats:
12 frames per second
does *NOT* redraw screen every frame
Max of 4 pixels scrolling per frame
i'll upload the engine in a bit
-
my best effort was lower than that, maybe I'll post it later :P
-
I actually never managed to make a proper one X.x
It would be nice if it was possible to have one that runs fast enough for something like Metroid or even Sonic at regular 83+ speed.
-
Wait didn't you make a smoothscrolling parallax scrolling mapper for your ball game? o.O
-
How do you measure frames-per-second anyways? I never really understood that.
-
The way i do it is have the engine quit after 500 frames or so, and start a timer right when i start the program. When the program ends, i stop the timer. Divide the 500 by the time and you have frames per second :D You can have an on screen counter of the frames as well, but then it lowers your framerate a bit too.
-
just tried that with my old SOLDAT engine (from the summer, never really got far) and got ~11 FPS. :P
-
The way i do it is have the engine quit after 500 frames or so, and start a timer right when i start the program. When the program ends, i stop the timer. Divide the 500 by the time and you have frames per second :D You can have an on screen counter of the frames as well, but then it lowers your framerate a bit too.
Ah ok, never thought of that. Thanks :)
-
sweet!
after a couple of tests, i've gotten
13.8 fps
consistently, and that's with some basic acceleration code included(as well as the engine itself being horribly messy because i was experimenting whilst writing it.)
this does not update the entire screen, can handle 256 tiles, and can jump1-8 pixels at a time
EDIT: oh right. this is at 6mhz
-
The way i do it is have the engine quit after 500 frames or so, and start a timer right when i start the program. When the program ends, i stop the timer. Divide the 500 by the time and you have frames per second :D You can have an on screen counter of the frames as well, but then it lowers your framerate a bit too.
<10 for Battle
-
thats awesome everybody :D shmibs looks like he is the current leader with 13.8 FPS :) I assume you incorporate screenshifting and filling in of edges like mine?
-
/\yup(so vertical scrolling has to draw 26 sprites altogether o_0)
-
Huh, my engine has to draw 22 sprites max, no matter the scrolling direction o.O
-
yeah, because(like i said) this has to draw two rows per direction(meaning my max is 44)
hopefully i'll be able to fix that.
also: i tested a more updated version with a basic character made of 4 or'd sprites and collision detection. it was a bit harder to get decent data from, but i'm seeing around 11.5 fps
-
Ooh i see what you mean, yeah i only draw in the direction the tilemap is moving. Yours must be a lot more optimized then to get so much more speed than mine, its displaying twice as many sprites ;D Imagine when its only half O.O
-
Wait didn't you make a smoothscrolling parallax scrolling mapper for your ball game? o.O
Yeah but that isn't a real tilemapper. It's like two rows of tiles displayed at specific locations, not a full grid-based tilemapper.
-
Ouch, the one I'm using for A:P is only 8 fps. Does not redraw every frame, walking up/down is slightly slower than right/left. But mine also uses 12x12 masked grayscale tiles..so that means it's drawing 64 masked tiles per frame walking up and 56 when walking side to side x.x
-
Oh btw, I forgot to specify something, the thing Supersonic Ball to draw stuff that looks like a tilemap draws 65 tiles per frame.
1) The background (Parralax scrolling) is made of 13 tiles, which are copied on the rest of the screen with Copy() to save a considerable amount of time.
2) The ceiling, made of 26 tiles, 13 of which are always plain black, drawn on the back buffer, for collision detection.
3) The floor (same way) :P
-
Come to think of it, 8 fps is quite nice with having to draw over 50 tiles per frame with Pt-Mask() as opposed to Pt-On() or Pt-Off() and with 3lvl gray. Maybe I should try regular 8x8 monochrome and see how fast it gets :P
-
Regular 8x8 monochrome seems to work pretty fast for me. I get about 60 fps scrolling for the most part (about 75 for aligned vertical scrolling). The screen is updated after every arrow key has been checked and the buffer image has been scrolled for each pressed key.
The screenshot will probably appear to have more blocky movement and/or move slower, but the above statistics are correct.
-
Wow that's fast! Is that drawing 96 tiles per frame?
One thing I dislike with the calc data is that when not aligned, it takes much longer to display than when aligned, so horizontal scrolling games seems a bit slower than if they just scroll vertically.
-
One thing I dislike with the calc data is that when not aligned, it takes much longer to display than when aligned, so horizontal scrolling games seems a bit slower than if they just scroll vertically.
If you want it to be the same, you can use ClrDraw:Pt-On() instead of Pt-Off(). :)
That looks great Runer. Can you post the source? It's sure fast. ;D
-
Could you clarify what you mean? ??? Do you mean Pt-On doesn't slow down when not aligned?
-
That looks really sweet Runer :)
Z, didn't you have a smoothscrolling engine a long time ago with an early Axe version?
-
Wow i am astounded by the speed you get! O.O How in the world do you do that? I did some tests and displaying 96 sprites every frame yielded a 22 FPS at the worst case scenario, and 60 FPS at best case scenario (alligned)
-
Could you clarify what you mean? ??? Do you mean Pt-On doesn't slow down when not aligned?
Pt-On has the same speed because it does not speed up if it is aligned. :)
Z, didn't you have a smoothscrolling engine a long time ago with an early Axe version?
http://ourl.ca/4161/79940
-
Pt-On has the same speed because it does not speed up if it is aligned. :)
Hmm tests would say otherwise, i got 60FPS with PtOn(0,0) 96 times, and 22 FPS with PtOn(7,7) 96 times
-
Pt-On has the same speed because it does not speed up if it is aligned. :)
Hmm tests would say otherwise, i got 60FPS with PtOn(0,0) 96 times, and 22 FPS with PtOn(7,7) 96 times
Okay, looks like I'm wrong. :-[ Sorry.
(I think I must be remembering from a previous version of Axe or something. :-\)
-
My program only draws tiles as they scroll onto the screen. That means it's drawing at most 13 8x8 tiles per frame. This means you couldn't have animated ground tiles, but it would work great for static ground tiles. It could also be easily extended to working with grayscale tilemaps.
-
My program only draws tiles as they scroll onto the screen. That means it's drawing at most 13 8x8 tiles per frame. This means you couldn't have animated ground tiles, but it would work great for static ground tiles. It could also be easily extended to working with grayscale tilemaps.
can you post the source? great job on the speed
-
Wow thats amazing, i tried to do that approach myself but i got a max of 18 FPS and the code looked horrible, i second the request for the source :D
-
That is awesome Runer, incredibly fast.
-
Some notes about this test program:
- It uses a 32x32 tilemap, with each tile being 1 byte. For testing purposes, the value of each tile is the sum of its x and y positions in the tilemap.
- For testing purposes, each tile is an 8x8 tile displaying its base-10 tile number with the left half (tens digit) inverted.
- Arrow keys to scroll, CLEAR to quit.
EDIT: By the way, sorry if the lowercase comments don't look right. I wrote this program with TI's Program Editor, which turns any lowercase letters that are also statistics variables into those special tokens instead of just treating them as lowercase letter tokens.
-
Thats very impressive, awesome work on this!
-
I didn't comment it much, but hopefully it's still understandable. If not, just ask me about it.
-
:!Ifθ+1→θ-10
:→θ
so... if, after being incremented, θ=10 then 1→θ?
runer, your optimisation is incredible.
EDIT: i just realised that i've been storing data to GDB1 or whatever, using another variable as the offset, and then calling GDB1 plus the variable (habit carried over from BASIC) when this whole time i could have just stored GDB1 to the variable initially. see, i'm learning already ;D
DOUBLE EDIT:0→θ, eh? so answer isn't carried from if statements. i should really learn the syntax BEFORE messing around with a code.
-
:!Ifθ+1→θ-10
:→θ
so... if, after being incremented, θ=10 then 1→θ?
runer, your optimisation is incredible.
Increment θ, and then if it equals θ=10, then 0→θ :P
-
Darn, I think you should maybe put this (and the sprite editor that came out a while ago) in the downloads section, that really could be useful in the future, and it might get lost in the Axe sub-forum. Nice job! :)
-
This isn't a project or anything, I just whipped this up as an example in all of 30 minutes or something. :P
-
Wow, you're source is wonderful. I like the optimizations... wow... ;D
I must learn to code like you in Axe! >:D
-
I wonder if this can be modified to scroll in arbitrary distances... (up to 8 pixels of course)
-
DOUBLE EDIT:0→θ, eh? so answer isn't carried from if statements. i should really learn the syntax BEFORE messing around with a code.
The answer is carried from if statements, but that was an !If statement which activates when the expression following it equals zero, so zero carries to the next line.
Wow, you're source is wonderful. I like the optimizations... wow... ;D
I must learn to code like you in Axe! >:D
I've been debating making a super-optimization guide for Axe. Should I?
I wonder if this can be modified to scroll in arbitrary distances... (up to 8 pixels of course)
I'll try my best :P
-
Wow, you're source is wonderful. I like the optimizations... wow... ;D
I must learn to code like you in Axe! >:D
I've been debating making a super-optimization guide for Axe. Should I?
Please do. :) I'd love to learn to coding like this. :)
-
Yes, definitely.
-
I wonder if this can be modified to scroll in arbitrary distances... (up to 8 pixels of course)
I'll try my best :P
I've deduced that scrolling more that 1 pixel per frame means that you would have to display more than 1 column of sprites per scroll, so it would be slower for sure, but i don't think the speed difference would be that large hopefully.
-
I've been debating making a super-optimization guide for Axe. Should I?
PLEASE. I would love to code like this - I still treat Axe sort of like TI-Basic, and I never really learned how to optimize that either, beyond the normal tricks.
(I just printed out your code - I'm going to be poring over it before I go to bed! :))
-
The answer is carried from if statements, but that was an !If statement which activates when the expression following it equals zero, so zero carries to the next line.
wow, i don't think i've derped that badly in some time. thanks for your patience XD
Quote from: Builderboy on Today at 23:02:34
I wonder if this can be modified to scroll in arbitrary distances... (up to 8 pixels of course)
I'll try my best Tongue
that would be EXCEEDINGLY helpful!
I've deduced that scrolling more that 1 pixel per frame means that you would have to display more than 1 column of sprites per scroll, so it would be slower for sure, but i don't think the speed difference would be that large hopefully.
wait, so i got something right?
-
Yeah, it seems i was unaware of how many sprites my engine was displaying O.O I was convinced i was only doing 1 column but it seems i was accidentally doing 2 columns. I was mistaken before by what you meant by 2 columns, i thought you meant 1 column each side of the screen (for some reason o.O) since i was convinced only 1 column was needed for a scroll up to 8 pixels
Now to find out how i managed to write a scrolling tilemapper with this incorrect knowledge...
-
/\i do that type of thing all the time(get a hunch as to how something could work, write it out as quickly as possible, and, if it doesn't work[which is usually], fiddle with it blindly until it does). after this process, i usually fall asleep(it tends to occur when i'm really tired), and then read over it in the morning, try to understand it, and re-write it from scratch.
-
Great job on the optimizations! By the way, you can use this for convenience:
Zeros(1024)->GDB1
And it will work the way you expect it to, no need to use the [] before it.
-
The old engine only scrolled 1 pixel per frame, so it got 60 fps, but therefore it only scrolled 60 pixels per second. Behold, the new engine that can scroll an arbitrary number of pixels from 1-8 per frame! In the example screenshot (which probably looks like crap and doesn't accurately reflect the realistic performance) I'm scrolling 3 pixels per frame (controlled by the value of S set in the program) and get about 35-40 fps, giving scrolling rates of 100-120 pixels per second!
Also, with the old engine I didn't realize how interested people would be in this so I didn't bother to optimize it much. This time I went ahead and optimized it to the fullest of my abilities.
-
This is great! You should definitively write a small guide showcasing some hardcore optimizations.
One thing, though: make sure to provide both the optimized and unoptimized/easier piece of code that do something and screenshots. Try to not do this Axe optimizing guide the Asm28day way, where it provides no real example of code and just stuff that does nothing. That way, your tutorial will be useable not only by people who understand fast through text, but also visual people.
-
Hello there !
I have a question concerning the former ztrumpet's smooth scrolling tilemapper :
I tried to increase width by changing the right variable and adding bytes at the end of each line in GDB1 but it doesn't worked. Though to increase height I added some rows to GDB and it worked...
does anyone can help me please ?
ps: i'm not english nor american and I still learning that language then I apologize for my possible mistakes :)
-
@Runer: That really looks fantastic! Nice work!
@Ti-Dks: Hello, welcome to Omnimaga! I don't have much experience with Axe, but I'm sure someone here will be able to help you. Don't worry about the language too much. We have users from all over the place, many speaking French or Dutch as their first language. Have a look around, and we hope you enjoy your stay here. Feel free to introduce yourself in the introduction section here:http://www.omnimaga.org/index.php?board=10.0 (http://www.omnimaga.org/index.php?board=10.0)
-
hello!
do you mean the smoothscrolling engine in this topic (http://ourl.ca/4161/79940)?
if so then z is probably the best person to answer your question.
and don't worry about language stuff; everyone can understand you perfectly =D
also, you should introduce yourself here (http://www.omnimaga.org/index.php?board=10.0)!
-
Hello there !
I have a question concerning the former ztrumpet's smooth scrolling tilemapper :
I tried to increase width by changing the right variable and adding bytes at the end of each line in GDB1 but it doesn't worked. Though to increare height I added some rows to GDB and it worked...
does anyone can help me please ?
ps: i'm not english nor american and I still learning that language then I apologize for my possible mistakes :)
Hi, welcome to Omnimaga! :)
Adding bytes to the end works pretty easily, as you've noticed, but adding bytes on the side is much harder. This is how to do it on my tilemapper:
Change W (I think this is what you did).
Change O to the number of total columns. For example, the demo I made had 10 columns, so O=10. If you want to add 3 columns, O would have to equal 13.
Finally, change the tilemap itself. Let's say it looks like this:
00010203040506070809000102030405060708090001020304050607080900010203040506070809And let's also say that you want to add 3 new columns on the right. Add those where I put 'XX's:
0001020304050607080900XXXXXX0001020304050607080900XXXXXX0001020304050607080900XXXXXX0001020304050607080900XXXXXX
I hope this made sense to you. :) Good luck. ;D
-
Okay ! Thanks for your answers :D I will try this as soon as I can !
( I hadn't seen var O :-\)
-
Hey Ti-DkS, welcome here :)
-
thank you Dj ! I'm going on omnimaga for a while to find things about Axe, for example when I have problems in my code and I think its forum is very useful, mainly because there are many members with a very good knowledge of Axe, then I registered :)
ps for ztrumpet : your code worked perfectly of course :D
-
Ah glad to hear. I can't wait to see some of your programs :D
-
I'm working on one I wanted to achieve, precisely :) It's why I asked ztrumpet about his 16x16 smoothscrolling tilemapper ;D
-
Ooh I see in your signature. Sounds interesting. I hope you can manage to finish it. I made a Metroid game before that is called Metroid II: Evolution/Metroid II: The Last Chozo Expansion Set, but it used xLIB so it was pretty slow on a regular 83+ and controls were wonky (although when using Doors CS7 or Celtic III it was slightly faster). When you have some progress done, are you planning to post updates in a new topic about it? :)
-
Metroid II is a very good game and very impressive regarding Ti-basic power and it's why I wanted to create another one (but more Fusion-like) with Axe because I think power of Axe sufficient to make this game. I tried to do it with xLib but after coding shooting system I was forced to stop because it was too slow :(
Then I wanted an ASM compiler and I found Axe ;D
For the topic it is a good idea and I will foresee that :)
-
Yeah with BASIC it's hard to keep things fast. Also data is pretty large. If bosses aren't hard-coded, I am sure it could remain pretty small. I think Metroid II was about 15 KB if we exclude map data and xLIB APP.
-
Yeah with BASIC it's hard to keep things fast. Also data is pretty large.
Especially if you're manipulating a large amount of data. The full screen tilemapper in Battlefield takes a whole five seconds to run (optimized from 9 seconds). You really have to be conscious of how much of the screen you're trying to draw at once.
-
Yeah that too. But by large data I meant for example if you use matrices or lists, each tile takes 9 bytes when stored in matrix files and in the program they take 2-3 bytes. With 300 12x8 maps that grows pretty fast compared to Axe's 1 bytes per tile (or 0.5 if you use 16 tiles per map). You can use strings, but if you use 2 byte tokens like lowercase letters in your maps, those takes more space in the string, plus pasting large strings containing 2 byte tokens with 2nd+RCL can cause RAM clear in the PRGM menu if you're low on memory due to an OS glitch. There are also pics, but then you're limited to 2 tiles, unless you use some form of dynamic tilemapping pixel-testing every side of the tile, which is slow.
-
Yeah... Does anyone think it is possible to bring some optimizations to increase the speed of ztrumpet's 16x16 tilemapper, however without using "vertical" and "horizontal" commands ? (redrawing tiles each step)
-
What do you mean by 'redrawing tiles each step'?
as far as I know, vertical/horizontal method of tilemapping is the best one since then you can get away with only drawing the tiles at the edge every frame rather then having to redraw the whole screen.
-
yes I know... But I want to preserve the back-buffer too :)
-
You can draw directly to the screen in Axe.
-
Does anyone think it is possible to bring some optimizations to increase the speed of ztrumpet's 16x16 tilemapper?
I'm sure it's easily possible, just I don't want to wade my way through the code right now. :P
Maybe Runer would like to optimize it. ;D
-
I actually managed to get a tilemapper working at 22 FPS with total redraw, and while thats 3 times slower than Raylins its pretty darn good for complete redraw ^^ But its a bit weird right now because it is jerky because of the different speeds. I'll see if i can smooth it out.
-
Wow, I didn't realize how much progress had been made on this. Someone should give a final version to Sir for his Axe guide. (Which you should finish, btw, Sir O0)
-
I think he was planning to rewrite a new guide at one point that was up to date and more complete, but I don't know what happened to it.
-
I think a powerful tilemapper what redraws the whole screen can be interesting to develop multi-level grayscale 2d sidescrolling plateformers because it uses only the main buffer and the other can be used to draw backgrounds using "horizontal" and "vertical" commands. Isn't it right ? :)
A guide will be interesting also ;D
-
Do you mean like parralax scrolling? I kinda used such stuff in Supersonic Ball, although it's more basic.
-
Yeah, it is that ! The tilemapper redraws the whole screen then it draws the background which scrolls 2 times slower using the "vertical" and "horizontal" method :)
-
Ah nice. Also if your background is repeating vertically you can simply fill the first row of the screen with 8x8 tiles then use the copy command over the rest of the screen. It speeds things up a lot compared to when you just fill the screen with the tiles.
-
Yeah, it is a good idea !! I hadn't thought of it :)
But there is a thing I don't understand : how do you draw characters and ennemies on a tilemapper which uses "vertical"/"horizontal" commands without using the back buffer ?
-
Hmm I'm not sure how to do that without using the back buffer. I think you need to redraw the tiles around the enemies to hide those enemies, scroll, then redraw the enemies. That may be complicated, though. The only other solution is to redraw the tilemapper every frame. You could use another memory location and store a copy of the buffer (before drawing the enemies) there, then when it comes times to scroll, you display that copy on the screen, erasing the enemies in the process, scroll, then display the enemies.
-
Okay ! It's why I think a tilemapper wich redraws the whole screen every frame is better for the main buffer, and a tilemapper with vert/hor commands for the background :) It is what I use for my Metroid :D
-
Hmm I'm not sure how to do that without using the back buffer. I think you need to redraw the tiles around the enemies to hide those enemies, scroll, then redraw the enemies. That may be complicated, though. The only other solution is to redraw the tilemapper every frame. You could use another memory location and store a copy of the buffer (before drawing the enemies) there, then when it comes times to scroll, you display that copy on the screen, erasing the enemies in the process, scroll, then display the enemies.
I actually tried that, and I modified Runer's tilemapper to use 4 lvl greyscale and draw a character over the fore-ground, and it works pretty well.
What I did was copy both buffers from an appvar before moving, scrolled and stored the buffers to the appvar, then drew the player.
Here's the code:
:.TILEMAPR
:prgmSERENA
:.TILEMAP
:[]→GDB0M
:det(1024)
:
:.TILES
:[]→GDB0T
:det(504)
:GetCalc("vSMBuff",1536)→B
:
:.CREATE TILEMAP
:GDB0M-1→D
:0→Y
:While -32
: 0→X
: While -32
: X+Y→{D+1→D}
: X+1→X
: End
: Y+1→Y
:End
:
:.CREATE TILES
:Fix 5
:ClrDraw
:EF0→{L6}r→{L6+12}r
:GDB0T-1→D
:0→Z→θ-1
:While Z*10+θ-63
: Fix 3
: E0200→{E86D7}r
: DrawF Z►Dec
: Fix 2
: E0204→{E86D7}r
: DrawF θ►Dec
: 0→Y
: While -8
: {Y*12+L6}→{D+1→D}
: Y+1→Y
: End
: !If θ+1→θ-10
: →θ
: Z+1→Z
: End
:End
:Fix 4
:
:.DRAW INITIAL IMAGE
:GDB0M-1→D
:0→Y
:While -64
: 0→X
: While -96
: Pt-Off(X,Y,{D+1→D}*8+GDB0T)r
: X+8→X
: End
: D+20→D
: Y+8→Y
:End
:conj(L6,B,768
:conj(L3,B+768,768
:
:.INITIALIZE POSITION VARIABLES
:0→X→Y→Z→θ→D
:
:
:.MAIN LOOP
:FnInt(DG,2)
:Repeat getKey(15)
:
: .MOVE DOWN
: If Y-24
: FnOff
: If getKey(1) and (D=1
:conj(B,L6,768
:conj(B+768,L3,768
: θ-1→θ
: Vertical -
: Vertical -r
: Y+8*32+X-1+GDB0M→r5
: 0→r6
: While -104
: Pt-Off(r6+Z,θ+64,{r5+1→r5}*8+GDB0T)r
: r6+8→r6
: End
: !If θ+8
: →θ
: Y+1→Y
: End
:conj(L6,B,768
:conj(L3,B+768,768
:sub(SM)
: End
: FnOn
: End
:
: .MOVE LEFT
: If X-Z
: FnOff
: If getKey(2) and (D=2
:conj(B,L6,768
:conj(B+768,L3,768
: Z+1→Z
: Horizontal(+
: Horizontal(+r
: Y-1*32+X+GDB0M→r5
: 0→r6
: While -72
: Pt-Off(Z,r6+θ,{r5+32→r5}*8+GDB0T)r
: r6+8→r6
: End
: !If Z-1
: ‾7→Z
: X-1→X
: End
:conj(L6,B,768
:conj(L3,B+768,768
:sub(SM)
: End
: FnOn
: End
:
: .MOVE RIGHT
: If X-20
: FnOff
: If getKey(3) and (D=3
:conj(B,L6,768
:conj(B+768,L3,768
: Z-1→Z
: Horizontal(-
: Horizontal(-r
: Y-1*32+X+12+GDB0M→r5
: 0→r6
: While -72
: Pt-Off(Z+96,r6+θ,{r5+32→r5}*8+GDB0T)r
: r6+8→r6
: End
: !If Z+8
: →Z
: X+1→X
: End
:conj(L6,B,768
:conj(L3,B+768,768
:sub(SM)
: End
: FnOn
: End
:
: .MOVE UP
: If Y-θ
: FnOff
: If getKey(4) and (D=4
:conj(B,L6,768
:conj(B+768,L3,768
: θ+1→θ
: Vertical +
: Vertical +r
: Y*32+X-1+GDB0M→r5
: 0→r6
: While -104
: Pt-Off(r6+Z,θ,{r5+1→r5}*8+GDB0T)r
: r6+8→r6
: End
: !If θ-1
: ‾7→θ
: Y-1→Y
: End
:conj(L6,B,768
:conj(L3,B+768,768
:sub(SM)
: End
: FnOn
: End
:0→D
:If getKey(1) and (D=0
:1→D
:End
:If getKey(2) and (D=0
:2→D
:End
:If getKey(3) and (D=0
:3→D
:End
:If getKey(4) and (D=0
:4→D
:End
:End
:LnReg
:Return
:
: .COPY IMAGE TO SCREEN
:Lbl SM
:0→D
:For(A,12,44
:For(C,36,52
:Pt-Off(C,A,D+Pic1S
:Pt-Off(C,A,D+8+Pic1S)r
:D+16→D
:C+7→C
:End
:A+7→A
:End
:Return
:
:Lbl DG
:Normal
:DispGraphrr
:Full
:Return
:
:.VARIABLES
:.D=Data pointer
:.X=X position in tilemap of top-left corner (0-20)
:.Y=Y position in tilemap of top-left corner (0-24)
:.Z=X offset of top-left corner (0-‾7)
:.θ=Y offset of top-left corner (0-‾7)
prgmSERENA holds the data for the sprite. I just grabbed a sprite from my computer and it turned out to be a Sailor Moon sprite.
Programs attached.
-
amazing engine :) Very nice job !!
-
Could you clarify what the code does? Does it do the first thing I said, does it do the second or does it do the last?
-
Could you clarify what the code does? Does it do the first thing I said, does it do the second or does it do the last?
The last thing you said.
-
Ah ok thanks :)
-
Are byte-based tilemappers faster than nibble-based mappers?
-
From what I remember, they were, but with the arrival of nibble commands in Axe, I wonder if this changed?
-
Its probably a bit slower and larger, but with the size advantage it is pretty significant ^^
-
My problem is that I'm actually thinking about sacrificing the +100% in data size in exchange for the small amount of speed and executable size gain. It would also make my code a bit more flexible too, so I'm not sure :P
-
Same here squidgetx :) Unless i was absolutely forced to use nibble maps, i would go full byte every time ^^
-
Thanks ;) That little bit of support has now convinced me to change it around. Ironically this will lessen the amount of free RAM I need since I will be changing map sizes from 100x100 to 50x50, and even with the change from nibbles to bytes that still means we're going from 5000 bytes per map to 2500 :)
edit: actually maybe I'll make it 64x64 instead...
-
yeah powers of 2 make things a lot faster and simpler in some of the tile detection code
-
About preserving the back-buffer: there are 3 saferam areas designated for saving the screen. They are plotSScreen (default buffer used w/ drawing bcalls, also is the buffer in Axe, L6), appBackUpScreen (back-buffer in Axe, L3), and saveSScreen (L1 in Axe). This is obviously all well and good, but Quigibo used the first 56 bytes for the A-Z+THETA vars. If you don't mind overwriting those, or don't mind adding free mem in-program to use as vars, you can use saveSScreen as a backup-back-buffer (it's L1-56).
-
I'm trying to figure out how best to RLE my maps for an upcoming game of mine, since I have little motivation to work on HL2. Any suggestions? The maps could get quite large, and tilemapping should be fast.
-
RLE? HL2? (Sorry, I'm bad with acronyms)
-
Run Length Encoding (Compression scheme)
Half-Life 2 (Video game)
-
Are you looking for a method or an explanation?
-
Thanks calcdude. Here would be my suggestion for RLE, (I'll refer to the leftmost bit as bit 7), bit 7 will be 0 if that byte will include the data, or 1 if the next byte will give the length.
-
Didn't Nemo write a compression/decompression routine for tilemaps? You might want to ask him or run a search on the forums to see if you can find it. Maybe he just had compression, though.
/me thinks this is when we need a !call function on the forums.
-
http://ourl.ca/7818
Look for "RLE". ;D
-
Ah, right, decompression was done, too. I wasn't sure anymore. :)
-
Okay, I'm having a problem with one.
It has a few display glitches...
Still can't figure out the tilemapper though.
When scrolling both horizontally and vertically, there's display issues.
To test: make a tio level using any of the versions, then run this. It uses the Tio map for data.
attached is (non-playable) level that really shows the graphical problems...yay :P
EDIT have some code:.DTILEMPR
:[F0F0F0F000000000]?Pic0N
:[A0A0505000000000]?Pic1J
:[6040206000000000]?Pic1S
:[6040604000000000]?Pic1F
:[9000009000000000]?Pic1R
:[A050A05000000000]?Pic1D
:[000C030000000000]?Pic1W
:DiagnosticOff
:"vTIOLVL"?Str1
:GetCalc(Str1)?P
:Return!If P
:conj(P,L1,384
:0?N?O?I?J-1?E
:.I and J are coordinates of top left corner
:.N and O are tile offsets
:
:ClrDraw
:.draw init image
:For(Y,0,15
:Y*4?T
:For(X,0,23
:X*4?S
:E+1?E
:sub(DRW
:End
:End
:DispGraph
:Repeat getKey(15)
:Repeat getKey(0):End
:If getKey(54)
:ClrHome
:.display stuff
:Disp "random info",i,"I",I?Dec," J",J?Dec,i,"N",N?Dec," O",O?Dec
:While getKey(54):Pause 10:End
:End
:
:If getKey(1) xor (getKey(4))
:.vert movement
:
:If getKey(4)
:Vertical +
:O+1?O
:If O>>3
:J-1?J
:O-4?O
:For(A,0,23
:A*4-N?S
:0-O?T
:J*24+I+A?E
:sub(DRW
:End
:End
:End
:
:If getKey(1)
:Vertical -
:O-1?O
:If O<<1
:J+1?J
:O+4?O
:For(A,0,23
:A*4-N?S
:64-O?T
:J*24+I+A+360?E
:sub(DRW
:End
:End
:End
:
:End
:
:If getKey(2) xor (getKey(3))
:.horiz movement
:If getKey(2)
:Horizontal +
:N+1?N
:If N>>3
:N-4?N
:I-1?I
:For(A,0,15
:0-N?S
:A*4-O?T
:J*24+I+(A*24)?E
:sub(DRW
:End
:End
:End
:If getKey(3)
:Horizontal -
:N-1?N
:If N<<1
:N+4?N
:I+1?I
:For(A,0,15
:96-N?S
:A*4-O?T
:J*24+I+(A+1*24)?E
:sub(DRW
:End
:End
:End
:
:
:
:End
:DispGraph
:End
:
:
:Lbl DRW
:Pt-On(S,T,Pic0N
:Pt-Change(S,T,Pic0N
:.pt-on stuff
:!If {L1+E}-1
:Pt-On(S,T,Pic0N
:Else!If {L1+E}-2
:Pt-On(S,T,Pic1J
:Else!If {L1+E}-3
:Pt-On(S,T,Pic1S
:Else!If {L1+E}-4
:Pt-On(S,T,Pic1F
:Else!If {L1+E}-5
:Pt-On(S,T,Pic1R
:Else!If {L1+E}-6
:Pt-On(S,T,Pic1D
:Else!If {L1+E}-7
:Pt-On(S,T,Pic1W
:End
:.Return
See this post for screenshot and attachments (http://ourl.ca/8025/174482)
-
Ok, that's been taken care of since, and I have a pretty good idea of how it works.
A random idea I got was to make simply written, heavily commented source code, so other people can learn from them.
So far, I have basic 8*8 tilemapping (no scrolling) covered.
Quick question: there's a type of scrolling, not smoothscrolling, but it scrolls like 8 pixels at a time. Kind of like, say, pyyrix did scrolling. What's that called?
btw yes, i'm still working on Tio, I'm just trying to learn more on how to do this so i don't screw up big time then i try to add it.