MateoConLechuga wrote:
Use the Tilemap function please. It has the offsets there for a reason.


But the tilemap only moves the tilemap around... which includes Spherix. Also there are objects on the map that need to be moved around also. How do the offests on Tilemap() do that?
MateoConLechuga wrote:
Use the Tilemap function please. It has the offsets there for a reason.
You then render sprites on top of the tilemap.
Alternatively you should read the tilemap from the appvar, store it in ram, and then use the TilePtrMapped (or TilePtr) function (Which you should already be using for collisions!!).


What Mateo is trying to say, use the built in functions. They are written in Assembly, and will always be faster than any compiled language.

TilePtrMapped(TILE_OFFSET_X,TILE_OFFSET_Y
TilePtr(PIXEL_OFFSET_X,PIXEL_OFFSET_Y

Those will return a pointer to the tile, not the tile itself.
so to get the current tile at coodinate X,Y
*{TilePtrMapped(X,Y

but for collisions:
*{TilePtrMapped(X+LOOKINGAT_X,Y+LOOKINGAT_Y

where LOOKINGAT_X and LOOKINGAT_Y are the vectors to the tile that Spherix is moving onto, and you would like to check the value of.
Ex.
x, y=(1,2)
vx, vy=(1,-1)
x+vx, y+vy=(1+1,2+-1)

You could also store the tile pointer and use some kind of loop to check more than one tile without needing to calculate the current tile pointer every time you need it.

Just don't forget how to get an element of a "2D" array:
A[x,y]=A[x+y*width(A)]

For drawing a player sprite on top of a tilemap, either the player moves, or the map moves. Much simpler to calculate the draw position.
Usually I pick the screen coordinate at the center of the tilemap to be the player position, and I move the map around beneath.
Although, I think what you're going for is to have the player move, and the map stay still.
So go with what you think will look best in your game.

Hope this helps Smile
beckadamtheinventor wrote:
MateoConLechuga wrote:
Use the Tilemap function please. It has the offsets there for a reason.
You then render sprites on top of the tilemap.
Alternatively you should read the tilemap from the appvar, store it in ram, and then use the TilePtrMapped (or TilePtr) function (Which you should already be using for collisions!!).


What Mateo is trying to say, use the built in functions. They are written in Assembly, and will always be faster than any compiled language.

TilePtrMapped(TILE_OFFSET_X,TILE_OFFSET_Y
TilePtr(PIXEL_OFFSET_X,PIXEL_OFFSET_Y

Those will return a pointer to the tile, not the tile itself.
so to get the current tile at coodinate X,Y
*{TilePtrMapped(X,Y

but for collisions:
*{TilePtrMapped(X+LOOKINGAT_X,Y+LOOKINGAT_Y

where LOOKINGAT_X and LOOKINGAT_Y are the vectors to the tile that Spherix is moving onto, and you would like to check the value of.
Ex.
x, y=(1,2)
vx, vy=(1,-1)
x+vx, y+vy=(1+1,2+-1)

You could also store the tile pointer and use some kind of loop to check more than one tile without needing to calculate the current tile pointer every time you need it.

Just don't forget how to get an element of a "2D" array:
A[x,y]=A[x+y*width(A)]

For drawing a player sprite on top of a tilemap, either the player moves, or the map moves. Much simpler to calculate the draw position.
Usually I pick the screen coordinate at the center of the tilemap to be the player position, and I move the map around beneath.
Although, I think what you're going for is to have the player move, and the map stay still.
So go with what you think will look best in your game.

Hope this helps Smile


Yeess! Very Happy Very Happy

Thank you very much. I understand now. My question is that when you use *{TilePtrMapped()}, it stores 1 byte of that tile to the pointer which is is stored in. The pointer would store the memory address of that value in the calculator's memory. My question is then, when I ask for the pointer for the floor tile for example, it is always 193. Why is that? I would have thought since it is just storing things in the memory, that the memory address "193" would have been already taken. Also can I use "193" to check for collision. Will the floor tile ALWAYS point to the memory address 193 - Under every circumstance? If so, should I use "193" to check if the tile spherix is moving to is legal? Thanks!
193 is the tile index that you defined in your tilesheet, not the pointer address. Nothing is getting "stored" to memory. You need to go back and understand how pointers work.
I know it has been a while since the last update, but I have decided to work on it again. So far, all I have is the tilemap moving around Spherix.


I tried looking at different forums to see if I could resolve the problem below, but I' still not doing it right.

Code:
[i]DATA
CloseAll
Open("SpherixL","w+"->A
Write("010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010000000000000000000000000101010101010101000202000202000201020200010101010101010100020202020200010102020001010101010101010000000002020202020202000101010101010101000202020202020202020200010101010101010100040202020202020202020001010101010101010002020202020202020202000101010101010101000202020202020202020500010101010101010100000000000000000000000001010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101",300,1,A

Read(DATA,300,1,A
Copy(Str1,DATA,301 //Extra Terminating Byte?
Disp Str1
Pause

When I display the string, a bunch of random characters pop up on the screen. I've tried changing the size of the copy from 301 to 300, and the string still displayed the same random characters. What am I doing wrong?
Alright, I did a ton since last update including collision detecting, sprite displaying (everything but the walls, the black outside, and the floor are sprites), opening chests, and entering the portal after each level (the green crystal is needed). Additionally, a white crystal is needed (which can either be found in a chest or on the ground) to be able to cross over a black area. (And once you do, you lose the white crystal. I kinda imagine that the white crystal is dropped into the black hole to create a floor). There are multiple instances of optimization of code especially for displaying the sprites, since there is slight blinkage of the sprites when Spherix is moving. Ideally, I hope to clean up the code (it's a bit of a mess right now) to be able to stop noticeable blinkage, but it is acceptable at the moment.

Eye Candy Very Happy :

By the way, when Spherix isn't moving anywhere and the screen blinks, I'm testing out the collision detection. Probably should put the detection code in a loop so the tilemap doesn't keep re-updating. Good Idea
Kaluwolf wrote:
Alright, I did a ton since last update including collision detecting, sprite displaying (everything but the walls, the black outside, and the floor are sprites), opening chests, and entering the portal after each level (the green crystal is needed). Additionally, a white crystal is needed (which can either be found in a chest or on the ground) to be able to cross over a black area. (And once you do, you lose the white crystal. I kinda imagine that the white crystal is dropped into the black hole to create a floor). There are multiple instances of optimization of code especially for displaying the sprites, since there is slight blinkage of the sprites when Spherix is moving. Ideally, I hope to clean up the code (it's a bit of a mess right now) to be able to stop noticeable blinkage, but it is acceptable at the moment.

Eye Candy Very Happy :

By the way, when Spherix isn't moving anywhere and the screen blinks, I'm testing out the collision detection. Probably should put the detection code in a loop so the tilemap doesn't keep re-updating. Good Idea


Do this to avoid flickering:

Code:

det(9,1
//start of loop
//draw everything
det(10
//update stuff, then loop
Thank you!

Level 1 in action:



More levels coming shortly! (and main menu... and all the others stuff it needs)
Alright, as I was going back to optimize my code, I went back to implement TilePtrMapped() for movement. I have circumvented this by creating a list with each tile "code" and used the list to detect valid moving. Obviously since TilePtrMapped() isn't working in my code, I'm using it incorrectly. I went and delved into PT's The World's Hardest Game code in ICE. When I got to his sprite movement, I had not idea what was going on:


Code:
If getKey(1) and *{TilePtr(TILEMAP,X,Y+14)}plotcross*{TilePtr(TILEMAP,X+13,Y+14)}<4
         Y+2->Y
      End
      If getKey(2) and *{TilePtr(TILEMAP,X-1,Y)}plotcross*{TilePtr(TILEMAP,X-1,Y+13)}<4
         X-2->X
      End
      If getKey(3) and *{TilePtr(TILEMAP,X+14,Y)}plotcross*{TilePtr(TILEMAP,X+14,Y+13)}<4
         X+2->X
      End
      If getKey(4) and *{TilePtr(TILEMAP,X,Y-1)}plotcross*{TilePtr(TILEMAP,X+13,Y-1)}<4
         Y-2->Y
      End


I have no idea how, say the

Code:
*{TilePtr(TILEMAP,X+14,Y)}plotcross*{TilePtr(TILEMAP,X+14,Y+13)}<4
works or what this saying, just that some byte is being flipped. Sad
If someone could clarify what this means and if I can implement in my code, that would be great. Looking at PT_'s documentation and commands list isn't helping out very much.
Why can't you just use TilePtrMapped()?

Anyway, breaking it down:

Get tile byte at pixel X+14 and Y: (TILE1)

Code:
*{TilePtr(TILEMAP,X+14,Y)}


Get the tile byte at X+14 and Y+13: (TILE2)

Code:
*{TilePtr(TILEMAP,X+14,Y+13)}


Bitwise OR the two bytes together. This allows us to only have to do one comparison.
I imagine 0,1,2,3 are tiles that allow movement based on context.

Code:
(TILE1)plotcross(TILE2)<4


Now, why the heck aren't you just using TilePtrMapped(). It's perfect for your game's use case.

Anyway, the above code would look like this in C:


Code:
(GetTile(tilemap, x+14, y) | GetTile(tilemap, x+14, y+13)) < 4
Alright, TilePtrMapped(). Would the syntax then just be *{TilePtrMapped(TILEMAP,X,Y)} and that will return the pointer to the tile which I can use to detect collision, correct?
No, that would return the value of the tile which you can use to detect collision. Note that it uses tilemap offsets, not pixel offsets, so you can't just give it the player's coordinates and expect it to work.

Or you can just use TilePtr(), and add the offset of the map to the offset of the player. Whichever is easier for you.

Code:
[i]TEST
Open("SpherixT","r")->TILES
LoadData("SpherixT",0,15->A
DefineTilemap(32,32,15,20,5,5,15,20,0,0,A)->TILEMAP
Disp *{TilePtrMapped(TILEMAP,1,5)}
Pause

I'm still not getting why this won't return anything BUT 193 (for any value, not just 1 and 5). Mateo said that 193 was the tile index I did in the spreadsheet. How do I get the pointer to the tile than?

Edit: I also went through countless different ICE games published in cemetech archives to see how to actually do this correctly. From two minecraft games (one didn't even have a source!) to color switch and others, there wasn't a single one who used TilePtr (or TilePtrMapped) for collision detection! The only who has used TilePtr has been PT_ in his The World's Hardest Game!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement