Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: jsj795 on June 10, 2010, 02:15:19 pm
-
For the platform, if the character is at the edge of the tile (kinda like a cliff) standing on 1 pixel, do you make the character fall, or let it stay on the block?
It would seem unrealistic if it doesn't fall, but if it just falls, then it looks like it's going through the solid block...
Like, for example,
OOO
OOO
OOOOO
O
OO OO
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
-
You could just push the character off. Your choice. I have noticed how unrealistic it can be (every mario game I've ever played), but it may also be easier. At any rate, do move the character over if you plan to let it fall. Good luck with your game!
-
yeah, I was thinking of moving them over, because if I don't, it will be like he's going through a solid block :P
Hopefully it won't be too hard to implement them
-
Well if you're implementing physics into this (similar to the one Sir made for HL2) where you kinda skid when you stop moving that could kinda fix it so it is less likely you'll stop like that and just go over. I don't know if that is what you want. I think it'd be fine either way.
-
Yeah I wanted to implement realistic physics into this. But what if a player tries to make this happen? Do I let the character stand or make him fall?
I guess I'll just have to try them both to see which one is better :P
-
I think I'd personally let him stand, but it's your decision. :)
-
i think you should just let him stand. it may be more realistic to just push him over the edge, but i'd be pretty pissed off as a player if i had the game's physics well-known, and then i jump to another blocking thinking i'll make it by 1-2 pixels, my character's foot touches the block, but then he's scooted back and falls down.
-
Or how about this? For X amount of time that he happens to stand in the edge, he looks like he's falling. After this X amount of time, he falls unless he moves back.
-
You could always display an "unbalanced" sprite or something (then maybe push him off after a couple seconds)
-
That's what I thought. Hmm that might be interesting
-
i think calc84 and jsj795 just had the same idea. i think that would be best, with the unbalanced sprite
-
The unbalanced sprite sounds really cool. Good luck! ;D
-
I third that suggestion, since it's the best compromise. Have fun programming :)
-
Also, just a side note, since Axe is pretty fast and everything is either monochrome or grayscale you could possibly just let him fall through. Since there aren't multiple colors it might go unnoticed. Just a thought. What ever you do that I'm sure it'll look and feel good game wise :)
-
the unbalanced sprite seems like a nice idea, like some 3D games ^^
-
Also, just a side note, since Axe is pretty fast and everything is either monochrome or grayscale you could possibly just let him fall through. Since there aren't multiple colors it might go unnoticed. Just a thought. What ever you do that I'm sure it'll look and feel good game wise :)
The problem of just letting him fall is that in that case I have to update the tilemap every frame, which I don't want to do... It's a lot easier to just use pt-change( to erase the sprite and redraw another sprite.
So if I don't redraw the whole tilemap, when the sprite goes through the block, the block won't get redrawn which will erase the block so it won't look like it's not there anymore.
If somehow I can't do this, then I'll just stick with the sprite being able to stand on the edge :P
-
If you're using xor logic in Pt-Change() the blocks won't get erased. That's the beauty of using xor. It does however cause the pixels of the intersection to get inverted while the sprite passes through it. Another way to avoid redrawing the screen is to just use a backbuffer. Its just as fast recalling the backbuffer as it is to do a ClrDraw.
-
Oh, I haven't thought of using the backbuffer :) That makes my life a lot easier than trying to redraw the tiles that got erased :D
Thanks for the tip
-
HL2 updates the tilemap every frame (to accommodate for smooth scrolling later), and every sprite is updated each frame, and I haven't noticed slowdown. Also, I made the decision to allow the player to stand on the edge, because I would hate to be playing and find myself forced off of an edge. It is harder to implement, but I think it is worth it.
-
Harder to implement? It sounds like it would be easier to implement it since you wouldnt have to have any extra code, and all the hard coding would go into the sliding off an edge?
-
No, users can position themselves anywhere on the screen and interact with the environment in a realistic way. This is harder to implement because users will fall through the blocks on one side if you are not careful, and usually it will require about twice the collision code.
-
Mmm i thought he was just talking about the decision to have a character balance on an edge or be pushed off? I think the former is supported with simple collision, where the latter needs some sort of counter and other forces involved.
-
Well, the former is actually more complicated than it sounds, as I found out.
-
Hmmm maybe so, but wouldn't adding some sort of edge sliding make it more complicated, not less?
-
Nope, I can think of several ways to sort of fake the sliding.
-
really? I cant think of any way that would make it easier o.O What kind of method would you use?
-
If I saw a collision, I would stop the physics engine from updating, take manual control of the character, animate it sliding off the edge, and give the physics engine control again. I would probably play around with it to find a suitable method. That is, assuming that I was willing to do that to the player in the first place.
-
HL2 updates the tilemap every frame (to accommodate for smooth scrolling later), and every sprite is updated each frame, and I haven't noticed slowdown. Also, I made the decision to allow the player to stand on the edge, because I would hate to be playing and find myself forced off of an edge. It is harder to implement, but I think it is worth it.
I wonder if it would be possible with half byte tiles to actually just update the row/col of tiles the screen is scrolling from? Would it require insane coding? Updating the entire tilemap is usually fast, but my worry was about games like Sonic, that requires extreme amounts of speed. That said, IMHO it's best if the screen framerate is not too high either, though (I prefer a maximum of 15 FPS when I have scrolling), otherwise it's hard to see anything due to the crappy LCD and it's even worse on a TI-Nspire.
-
If I saw a collision, I would stop the physics engine from updating, take manual control of the character, animate it sliding off the edge, and give the physics engine control again. I would probably play around with it to find a suitable method. That is, assuming that I was willing to do that to the player in the first place.
Ah that would be an interesting solution. It might cause some weird complications but im sure they could be ironed out ^^
-
Well, I do something similar to the row/column updates in Advance Wars TI, but it usually runs super fast anyway. I have it optimized pretty heavily.
On a side note, Axe Sonic sounds like a good idea...
-
Axe sonic might be an interesting feat o.O Considering the asm version never seems to go anywhere...
-
Well, I'm not too eager to add to my already large project list, but I may try it out when I finish a couple of projects.
-
I do not plan to make Sonic, but I gave it as an example of speedy game, just to be certain for other type of games (such as top view racing games like megacar). If you can confirm to me that in 6 MHz mode, redrawing the entire half-byte tilemapper (6x4 16x16 tiles or 12x8 8x8 tiles) every frame gives at least 20 FPS with tile collision detection added, I'm ditching my idea of just updating the row/col of tiles my game is scrolling from immediately lol. That's what holds me back the most in any developpement of what I would like to make. I will most likely still need help, though, when you start coming again regulary on IRC
-
Hah me too, and just playing a small sonic game on the web shows how difficult the physics is to accomplish.
-
:/ I'm not sure, HL2 gets slowed down a little on 6 MHz, but I also do complex physics calculations and draw several extra sprites each frame, so I would guess it gets pretty good performance. Advance Wars TI runs fast with scrolling (not smooth yet) and unit drawing in 6 MHz.
-
Aaaah ok. Personally I would prefer adding smooth scrolling in what I want to make. That said, I could always make the project 15 MHz-only too, though. It would suck for non 84+ owners, tho
-
Smooth scroll probably won't hinder it too much, at most it would drop 1FPS if I'm predicting properly.
-
yeah that's what I thought. It would mostly involves drawing the map at a different offset and one additional row/col of tiles (unless you want to emulate a NES style scrolling glitching effect) and most likely not require as much code as checking in which direction I am scrolling to draw the appropriate row/col of tiles
Also btw, do your games check for vertical and horizontal collisions separately? Personally that's what I thought about doing because with diagonal movements I was worried about going through walls that looks like this:
O
O
But at the same time, would that slow things down too much?
-
No, there isn't too much slow down with fewer objects. I check horizontal and vertical separately, yet linked in a way. It's a bit complex. I explain it in The Complete Guide to Effective Axe. Also, I explain a method of smooth scroll that requires less effort than what you say, just by drawing an extra row/column of tiles, and some clever division.
-
aaah sounds promising :D