Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: nxtboy III on March 15, 2012, 12:55:41 pm
-
Hi,
I was wondering if everyone could list off some limitations of platformers that use pxl-test for collision (I mean pixel-perfect collision, no tiles). That is what I am doing, and I want to know what is bad about it.
Here's some:
-Enemies cannot move off the screen or they will have no collision
-Takes up more storage than using tiles
Could everybody tell me more? And if possible, a solution to it?
-
Another disadvantage is the storing of your level data. Since you are not using tiles, your levels become a lot larger to store and display. Plus, you also have to keep in mind the size of your enemies and player when designing them.
-
it's typically slower than tile-based collision as well.
a possible solution would be to keep your map storage and drawing tile-based and then implement a pixel-testing system that looks for "pixels" within the tile data rather than on the actual buffer.
what i mean is that the character/enemy or whatever would first determine what tile is underneath it and then, rather than pixel testing on the screen buffer, would check pixels in the sprite that is used for that tile instead.
-
Well actually the pxl-test-like function I use for my NXT robot goes about 2,100 times a second. That's how fast it is.
So any other limitations and/or solutions?
Also, what is an efficient way to have multiple types of pixels, like destroyable pixels, killing pixels, etc?
-
The only real way to have different types of pixels is to have a different image for each property. The destructible image (often reffered to as a mask) would not be displayed, but instead used to test whether or not a pixel is destructible or not. As you can imagine this can increase your file size by large amounts, which is why people generally use tilemaps.
-
Is that the only way?
-
Can you store color onto your images?
-
sadly, no.
-
Then you are quite limited on how you define what type your pixels are. You can either use the multiple image method, which gives you a good speed, or you could store the position and type of all the 'special' pixels, which is likely going to be space efficient, but also quite slow.
-
???
How will using multiple images have good speed? I would have to draw every image, and each image takes about 3 milliseconds to draw. 3 milliseconds is a lot if you're making it grayscale.
-
no, you would draw the images at all, they would just be used for determining the type of a pixel.
-
But, how can you use pxl-test if they are not drawn??
-
Oh can you only do pixel testing on the screen, not on images? In that case the second method I suggested would be one of the only ways
-
Well, I am doing this on my NXT, and it is possible to turn on and off the screen refreshing. What I am doing now is turning off the screen refreshing, showing the solid and other type of pixel (kill pixels), then showing what you actually see, then turning the screen refreshing back on, so you only see the last picture. Is there a faster way to do this?
-
do you have other free-ram areas you can store to, though? you could store your images there. it may mean writing your own pixle test routines, but should still be faster.
-
Free RAM areas? Well there are 2 display buffers. Normal and popup. Sadly, I don't exactly know how to properly draw graphics on the popup.
If I used variables to store the location and type of pixels, how exactly would I do it?
-
I know you have been posting in the Grammer threads, too, so I will explain how to do it in Grammer (and probably Axe/Asm) and see if you can do it on the NXT:
First, can you draw or pixel test on other buffers? If so, for what I have been doing today. For each enemy, I have two sprites. One to be displayed and the other contains the hit as pixels on. For example, I draw this sprite to the viewing buffer:
(http://i1109.photobucket.com/albums/h438/Xeda112358/ENEMYView.png)
Then on the other buffer, I draw this hitbox at the same location:
(http://i1109.photobucket.com/albums/h438/Xeda112358/ENEMYHitBox.png)
There is no need to make it like this, either. You can have a huge hitbox for enemies with some kind of aura or things like that. Anyways, then all I need to do is whenever I move, I just pixel test the location I am moving to. If there is a pixel on, it means it is in the hitbox. so you just don't move there.
The nice thing is, you can have several buffers for other things. For example, one buffer for collision, one buffer for killzones, et cetera.
Again, this all relies on the ability to pixel-test other buffers. I don't know if this helped clarify things or not :/
-
Wait... You can create buffers??
-
I am not sure about the NXT, but in Grammer, yes (and in Axe/Asm)
-
When you say buffer, do you actually mean that it really is a real buffer?
EDIT: The way I do it is I just turn off screen refreshing, draw the solid pixels, test the pixels, then draw the
kill pixels, test the pixels, then draw what you actually see. Then I turn on screen refreshing, so you only see the last picture. But the problem is, is that the more different types of pixels, the slower it will go and the worse the grayscale will be.
-
When I say buffer, I mean, in this case, that if you were to display it, you would see all the hitboxes.
-
So it is as if each buffer is a layer of the screen?
-
Exactly :) I was going to call it a layer, but I decided not to to avoid some confusion. But yes, that is how I think of it :) I think of them as layers of the screen and you are just pixel testing what is underneath.
-
I wish I could create buffers on my NXT... :(
But that is basically what a map is for a tile-based game. A layer.
-
Eh, I think of tilemaps as just being able to get detailed pixels and showing the detail by blowing it up in scale. When you are still checking a tilemap, you are just "pixel testing" it, but getting more than a 1 or 0 result.
-
I have another question/problem:
In my pixel-perfect game, there are enemies. When you move up, everything else moves down, since it scrolls. Which also means the enemies move down. But a lot of times I have a problem that the enemies aren't in the exact position they are supposed to be. They might be one pixel off. I think it is because the velocity of player increases as you go down. Same with the enemies. Somehow it is messing up the enemy's Y position. How can I fix this??
-
Are you applying the same acceleration to the enemies? Also, do you have FP support, or just integers?
-
Yes, I am applying acceleration to the enemies, but only on the Y axis. Same with the character. And yes, floating point is supported.
-
Ah, okay, try starting both you and the enemies at a half pixel location. That is the way I solved it before :)
-
Your problem might be this, your code might be doing things in the wrong order, such as:
Move Player
Update Screen
Move enemies
As you can see, in this example the enemies only get moved *after* the screen is updated, so they will always be 1 frame behind in their animation. Might this be what is happening to you?
-
???
How would that solve it??
I have an integer for the X and Y. I made each pixel divisible by 64, so the X and Y are it's real x and y but multiplied by 64.
-
So the half pixel is 32. Think of this: If you and the enemy are at 0 and you move down 10 and they move up 10, they are now at pixel -1 and you are still at 0. However, if you are both at 32 (the half pixel), you will both cross the pixel boundary at the same time :)
-
Hmm.. Lemme try that.
Post after this so it doesn't count as a double post. :P
-
Okay, I will ;) I hope it works!
-
AARGGHH!! It doesn't seem to work!!
Why??
-
I won't be able to make sense of the code, but maybe post the code where velocity and position get updated?
-
I'll just explain it:
Variables you need to know-
X- the x axis of the player
Y- the y axis of the player
VY- Velocity Y axis of player
Xd- The X axis of the map(not really)
Yd- The Y axis of the map(not really)
Ym- How much player moved when going up a diagonal on Y axis
Xdt- version of Xd, before movement
Ydt- version of Yd, before movement
xt- How much the player moved on X axis
yt- How much the player moved on the Y axis
xtt- the X axis of the map divided by -64
ytt- the Y axis of the map divided by -64
ex- Enemy x axis
ey- enemy y axis
ex64- enemy x axis divided by 64
ey64- enemy y axis divided by 64
What it does (pseudo, just the main stuff):
X set to 3104 (48.5 when divided by 64)
Y set to 2080 (32.5 when divided by 64)
Game loop:
Change Xdt to Xd
Change Ydt to Yd
Check if 1 pixel above the player is solid
-if so, multiply VY by -1
Check if player can move down
-if not, set VY (VY is the velocity of Y axis) to 0
-if it can move down, subtract 8 from VY
Check if left button pressed
-if so, check pixels and if it can go left, subtract 64 to Xd
-If it cannot move left, check if to the left and above 1 pixel is clear, and if so, subtract 64 from Xd and add 64 to Yd and Ym, so it moves diagonal
(Same with going right, except it adds 64 to Xd, not subtracts)
Checks if center button pressed
-If so, check if 1 pixel above the player is clear, and if so, change VY to 64
Add VY to Yd
Change xt to Xdt - Xd
Change yt to VY + Ym and then multiply it by -1
Change xtt to Xd/-64
Change ytt to Yd/64
Add xt to ex
Add yt to ey
Move enemy and such
Change ex64 to ex/64
Change ey64 to ey/64
Draw all the stuff. Draws the enemy by using ex64 and ey64
End game loop;
EDIT: Sorry it took so long. :P
-
That looks a bit more complicated than needed, but did you also remember to set the enemies on half pixels?
-
Oh, forget to tell you. Yeah I set the enemy on 4128 (64.5) for the X and 2080 (32.5) on the Y.
Also, if you could help get it less complicated, that would be great.
-
Okay, here is one way to do it:
X=3104 ;sets X-coordinate to 3104
Y=2080 ;Sets Y-coordinate to 2080
XE=4128 ;Sets Enemy X coordinate
YE=2080 ;Sets Enemy Y coordinate
Vy=0 ;Zero out the y velocity
// Now you are ready to do the gravity stuff!
// First we update the velocity:
Vy =Vy+4 ;Increments the Y velocity by 4
//Now we update position
YE =YE-Vy ;Subtracts the new velocity from the position of the enemy
Y =Y+Vy ;Adds the new velocity to the position of you
//Now you divide the positions by 64 and use those as the coordinates :)
I am not sure how to do that on the NXT
Also, here is a very simple hitbox example that I made :)
-
Why increment velocity by 4?
Lemme try...
EDIT: Still, it doesn't work!!! Why?? :'(
-
Oh, I was incrementing the velocity by a number (doesn't have to be 4) to simulate a gravity-like effect. v=at, but t is measuerd in cycles, so you just add "a" every time. In this case, 4.
-
I can show you a screenie. It looks really bad because I am viewing the screen on the computer. (Doesn't look bad on NXT)
The number on the bottom left corner is the Y axis of the map minus the y axis of one of the enemies(The enemies are the squares). When the enemy is not moving it should stay the same. It should stay at -9. But it does not.
Sorry it's an .avi and it is so flickery (It is because of the screen capture program). Hopefully you are not epileptic. :P
I had to zip it up because of the size.
-
I have looked at it and it really does look quite nice, by the way. I see what you mean and I plan to see if I can come up with some working code. The enemies just follow you, but they cannot jump, right?
Also, I won't be back until 4 hours from now (supper, then work).
-
Yeah, they just follow, not jump.
On my NXT, the grayscale doesn't look to bad at all. :)
Thanks for the help. :)
Yeah, hopefully this can get working soon.
EDIT: So does anybody else know of any limitations and/or solutions for pixel-perfect collision platformers?
-
I am now back and have not had time to work this out, yet. (Also, I am distracted on the phone x.x) Still, I will try to figure this out <.<
As for limitations, all I can think of is memory. For systems with color screens, this is an extremely good system to use as you can generate scrolling maps easily and pack a few layers into each pixel.
-
A solution to the size issue is to use tile-based drawing, but pxl-test collision. That way, levels stay small and load fast, but you still get the precision of pxl-test collisions.
-
Yes, that is a great way and, also, enemies you just do by drawing their sprites to the layers.
-
So how can I fix the issue I had earlier, about the enemies not in the right place?
EDIT: BTW, my avatar is an NXT.
-
So, any luck with the enemy scrolling issue?
It might be because when the enemy's Y axis and the player's y velocity are subtracted for scrolling, since the enemy's y velocity is not a multiple of 64 or 32, the enemy's y axis rounds to a different number.
Hopefully that makes sense. :P
-
Ooooh, so the code will round. I did not know that. Is there some way to prevent it from rounding?
-
I was saying because, you cannot be at, for example, point(2.5,3.5). It's impossible to literally be at a fraction of a pixel point.
-
Yeah, I know, and rounding will indeed throw it off. So does it round when you divide or when you tell it the coordinates. If it is at the coordinates, then there should be a command called int( or floor(, I am assuming. You will want to use that on the coordinates.
-
Yeah, there are floor and ceil functions. So I use floor when dividing by 64? (Hey that rhymes :P)
-
Yep :) And nice rhyme!
-
I didn't even try to. :P
I used floor, and it still messes up! I think it is because since the enemy's Y axis (not multiple of 32 or 64) and player's y axis (also not multiple of 32 or 64) subtract/add (whatever they do), it goes to a different number for the enemy Y from the player Y.
-
So how can it be fixed?
-
I'm not sure, I haven't had time to put together a good example :/ I've never worked on a game where the player stayed in the same position XD
Pretty much, here is the best idea I have, but I think you are already doing it or have done it:
When you jump, you change the Y-offset of the viewing screen. Form there, just plot the enemies by doing this:
Compute the Y-Offset /64 with floor. Then compute the location of the enemies /64 with floor. THen just add the two to get the location on screen.
-
Yeah... That's what I'm doing. :P
I could make it so when the enemy hits a solid below (Stops moving), the enemy Y changes to a multiple of 64, then adds 32(since it's the middle of 64).
How do I do that, in code-like terms?
-
So I need help fixing another problem:
The pxl-test stuff is checked in the graphic displaying part of the program. The pxl-test outputs (1 or 0) are saved to variables. When moving, it checks those variables for collision. However, they are not correct, because it checks the variables first, then uses pxl-test stuff and saves it to variables. So the variable checking is too early.
How do I fix it?
Here's some psuedo:
Game loop:
Moves player, checks collision using variables (V) (Lets call the variables V)
Displays graphics and uses pxl-test function and saves output to variables (variable V) it uses earlier
End game loop
-
Could you use another variable for the two instances?
-
???
Explain, in psuedo, please. :)
-
Well, I mean instead of using V twice, why not use W or something for one of them?
-
???
I sort-of understand... i think... maybe not...
So like this:
Game loop:
Move and stuff, uses W
Change W to V
Displays stuff and uses pxl-test stuff for variable V
End game loop:
Or would that even help fix the problem?
-
That might. Why do you need to change W to V?
-
Because V is what is used for pxl-testing. It is the output of pxl-test (Actually, the function I use is called isPixelSet, but, whatever)
-
Ah, I see, now. Well hopefully that code above helps you :)
-
So what are some other limitations and solutions?
EDIT: Yay! So the scrolling problem is fixed(Not sure if that was even a problem...). The problem was that the enemy would try to go up a hill, but it wouldn't work. So I still need that V and W update-thingy I asked a little earlier to get working. So, you can post in my thread in "Computer Projects and Ideas". My thread is about the game I am making that I needed help with. The topic is the one called something about my new NXT game about a square.
-
So what are some other limitations and solutions?
-
So what are some other limitations and solutions?
Any?
-
move collision checking to before moving player, but still in the game loop.
Edit: Argh: Page turn fail.
Here's one I'm not sure was brought up: pxl-test doesn't work on black stuff, so you'll need a mask for collision unless you border everything. In fact, it's better in many ways so that you can have passable black stuff and such, plus background images don't collide.
-
So instead of doing this:
Loop:
Move
Check collision
end loop
Do this:?
Loop
Collision checking
move
end loop
?
-
yes, because then you'll get the closest values possible for the move command itself.
-
hmm... ya maybe so.
Any other limitations and solutions?
Also, I am making a platformer that does use pxltest-like collision, so if you could help in any way, go ahead (please). http://ourl.ca/15431
-
Well, looking over that it might be handy to have some form of basic compression, since most of your level data pics are blank space. You could save upwards of 50% space.
-
Another disadvantage is the storing of your level data. Since you are not using tiles, your levels become a lot larger to store and display. Plus, you also have to keep in mind the size of your enemies and player when designing them.
Isn't it the opposite? ??? Since one tile takes 1 bit (basically 8 tiles takes 1 byte, which is 8 times smaller than standard tilemaps). See Illusiat series for example.
It's more limited, though. Only two kind of tile can be used in such tilemap, unless you have dynamic tilemapping like Shmibs showed once or to a lesser extent like in Illusiat 12/2004 and ROL series. Basically enemies have to be stored separately.
-
What do you mean, "dynamic tilemapping"?
-
This is from my MazeChase game and it features dynamic tilemapping:
(http://www.omnimaga.org/index.php?action=dlattach;topic=12879.0;attach=12125;image)
Pretty much, it stores the tilemap as a 64x96 black and white picture. I pixel test a spot and then I pixel test the surrounding pixels. Depending on the surrounding, the tile changes. For example, pretend o is pixel off and x is pixel on. We are looking at the center:
o x o
0 x x
0 0 0
For the maze game, since the pixel above is black, I will use a tile with an opening upward and since the tile to the right is black, I use a tile that is also opening right. This way, each bit can be one of 6 tiles :) It makes it verrry easy to draw tilemaps and pipes and whatnot without the user having to cycle through tiles. Also, I noticed this method on my Advanced Wars 2 game (for the GBA). You can also apply this method to do multiple types of tiles as well (like mountains and trees that vary depending on the surrounding). For that, you will need more layers.
EDIT: As a note, when the program in the screenie is in map editor mode, all it is really doing is turning a pixel on or off on the map and then checking the surrounding pixels to see what changes. The method allows for easy editing and scrolling :)
-
Oh, so really it has a picture with each tile as 1 pixel, and the map shows it as each pixel being a larger box?
-
Yeah, I used a similar method in Graviter, so that I could reduce the number of tile types and thus have more compression.
-
What do you mean, "dynamic tilemapping"?
Google
J/k what I mean by dynamic tilemapping, to sum things up, is that each tile are drawn according to what's on each side of it in the map data. Shmibs did such tilemapper a few years ago and his even supported multiple kind of tiles. It requires a lot of tiles though. By the way Xeda's screenshot is a great example of what I mean. When drawing a tile, it checks all 8 sides surrounding it. Illusiat 12/ROL series use a dumbed down form of this, as it only checks the tile below where you're checking from (or above, if the hill flag is turned OFF)