STD 2D platform game- Following a hills heigt?

BlitzMax Forums/BlitzMax Beginners Area/STD 2D platform game- Following a hills heigt?

Damien Sturdy(Posted 2006) [#1]
Hi all!

I've had Blitzmax since pretty much day one.

Since ive moved into a flat ive decided to go back to Max and play aronud a bit just to keep me busy for a bit instead of my larger projects-

Heres the question:

How can I make the player/enemy sprites follow the ramp of a platform?

In Blitz3D i could quickly just do a readpixelfast from layer 1 and find the top of the platform.

How would I do it in Max? There are no image buffers, so I cant render the level three times, check height, then merge the images. (Or, not in the way I'm used to?)

It's a standard array-tilemap based platformer, built in 3 Layers- Layer 1 is the collision layer, Layer 2+ are just background images.
What i'd normally do is align the player to be *above* the current Y tile, then pixel-pick down until either more than the height of a tile has passed, or, a pixel has been hit.

So How can I perform this in Max? I'm probrably missing some important features ;)

I'm quite knowledged in the standard techniques involved in 2D tilemap based games- and have written many- but the angle used from blitzmax is a bit different from what i'm used to ;)

Any help apreciated!

[edit]

I have absolutely no clue what a "heigt" is.


Duckstab[o](Posted 2006) [#2]
You might be able to read readpixels from collision layers 1 to 31

CollideImage
CollideRect

readup on those functions

Collide rect can be used for pixelperfect


Damien Sturdy(Posted 2006) [#3]
Ive used these- they work for block>block collisions.

But I fail to see how to use it to do what i'm after- The collideimage and colliderect commands seem to cause a huge speed-drop, something I shouldnt get from a 2ghz computer ;)

Of course I will try these again just to see if i can speed any of it up- The slowness i believe is in checking a 30x30 set of images every frame.

Any more ideas?


SoggyP(Posted 2006) [#4]
Hello.

I experienced huge slowdown problems with collisions with lists - until I remembered to use flushmem. It's a thought.

Goodbye.


Damien Sturdy(Posted 2006) [#5]
Flushmem no longer exists ;)
[edit]

However there still might be a similar issue.

http://www.blitzwiki.org/index.php/GCSetMode

Thanks :D


Eric(Posted 2006) [#6]
Also ResetCollisions() Is over looked a lot


Damien Sturdy(Posted 2006) [#7]
hehe, I fell for that. Fixed it before I posted here though- It was still slow after :(

Good advice so far guys.


klepto2(Posted 2006) [#8]
I think you use a 2 color mask for your collision layer.

Then convert it to a pixmap, read each pixel and save true or false to an array.
Now you only need to check for the highest position in that array, what is a lot faster than reading a pixmap or doing a collide image.


Damien Sturdy(Posted 2006) [#9]
Ew.... :P

Thats a ton of work just to get a pixel :P

I'm going to go tinker- Cheers for your help- Anyone get any more ideas let me know :D


SSS(Posted 2006) [#10]
It sounds like your making a platform game, or something similar. In that case, I'd be inclined not to reset collisions on your tile layer (so you only draw it once) but only to your player layer. This should speed up collisions.


Damien Sturdy(Posted 2006) [#11]
Its a full on scrolling platform game, the levels are rather large and need to be redrawn each frame, I'm afraid.

For now i've overcome the problem using maths related to each tile- a function returns the height of the tile depending on where along the local X axis the player is standing :)


VP(Posted 2006) [#12]
I was going to say you could just store a heightmap relating to individual map tiles. This would be something done in your level editor, rather than computed during the game.

If your tiles are 32 pixels wide then you store 32 values representing the height of the topmost collision point relating to each column within the tile. Either your level editor can compute this from the actual drawn pixels in the tile, or you can manually edit. This way, you can have the player dip down into tall grass, or float above a particular area, corresponding to an obstacle not actually drawn as part of the tilemap.

In-game, you wouldn't need to bother with slow collision checks, you just need to compare the player's x coordinate with the appropriate column in the current tile.

This would use up a fair amount of filespace, but you could pack the heightmap data in one of 2 ways:

1) Assuming tiles are 32x32, heigtmap data fits into 5 bits which you could then stuff together into 20 bytes of data (rather than 32).

2) Store the start height of the left-most column within the tile as an absolute value and then only relative heights for the rest of the columns. 3 bits per column should be enough for general platform gaming (would allow a 1:3 positive or negative gradient maximum, plus a spare setting which could mean "treat next 5 bits as absolute" if you needed to, a bit like rice encoding I suppose!).

**EDIT** I've gone and assumed you're using a tilemapped level. Stupid me :)


VP(Posted 2006) [#13]
Anyhoo, storing a heightmap could still apply to a freeform level. CPU power being what it is these days, you could probably even approximate a per-pixel heightmap with vectors or splines and have the position calculated in your playerupdate loop/method/thing.

I'm tired.

Going to bed.


Damien Sturdy(Posted 2006) [#14]
Hey, vinylpusher, It is a tilemapped level ;)

Ive used a similar method to the above anyway, just having a start height and an end height for each tile, and just make a ratio out of the X position. Pretty quick and runs way quicker than pixel scanning :)

Thanks for the help.