Calculating main character (sprite) over the background scenery

[Yaron Nir]

Hi all,

If you look at the preview of limbo game for the c64, you can see that the main character walks flawlessly on the ground in a perfect position and seems to stick with the ground as it has slopes and slides.

 

My question revolves how to calculate that on A8.

Main char is a PMG and that ground Chan be created out of chars in char mode or out of bitmaps in bitmap mode.

 

Is there a common practice for this? I know how to convert the PMG unit into char unit and compare, but I want to get the effect of the sticky ground thing.

 

Limbo c64 preview

 

Cheers,

Yaron

[Yaron Nir]

 

Here is a link to the game for reference....

[Rybags]

In a platformer there's various ways how it could be done but I imagine for such a complex scroller as this, it probably checks the actual character set data for the block his foot is on.

It could also be done by maintaining a height table for each character, but I imagine this game probably generates data on the fly. That said though, no reason not to generate extra tables while the rest of it is being done.

 

WTH? "Coming 2024" - I suppose he mightn't have much free time.

[Yaron Nir]

Tnx Rybags,

Yes it seems the developer is working slowly . Surely but slowly

 

Can go give an example of your thought around the ground height table and how do you compare it to the PMG?

[Rybags]

For the player sprite you have a set number of animation frames so it'd be fairly simple to have tables associated which represent the extremeties of hands and feet, a few bytes for each frame isn't huge.

 

For the terrain, it's not a lot of work to work out which characters are under the player's feet. From there you can fairly quickly work out the memory addresses to do a search for the "floor".

 

It's the sort of thing that wasn't done a lot in the day, with the result that you'd often see games with the player either floating or sunk halfway up to his knees.

Might have to look at Pharoah's Curse and a few others to see how they compare.

[tebe]

[_The Doctor__]

deleted

Edited April 9, 2019 by _The Doctor__

[Yaron Nir]

So, to put the confusion aside.

I was trying to understand what is the common practice to detect perfect collision for the A8 between PMG and chars in Antic mode 4.

As an example I showed a perfect collision detection from the game Limbo ported to c64, where the main character sticks to the ground even if it shifts up or down.

 

Would still like to hear from all you developers and your experience.

 

Cheers

[_The Doctor__]

ah you mean when hills and such are involved, looking at the example the player doesn't sink into the ground or float above it. though it doesn't seem the feet perfectly grips or plant at the spot it hits on stride. ever so slight slide might be do to youtube...

 

a bunch of example games with rough terrain and the player traversing it is what your after, I get it now.

[Wrathchild]

The OP has given Limbo as an example, he's more after the algorithms for handling such animation.

 

Tutorials etc on YouTube tend to be geared to modern engines that are handling sprites in a more abstracted way and so aren't so useful in this case.

 

I think the OP needs to be a little more specific on which way he wants to go as the A8 is going to present various ways of doing this in s/w.

 

To assist with that here are the main questions to consider:

 

1) Is the main character going to be implemented with software or hardware sprites.

2) If using h/w sprites, do you want to take advantage of player/playfield collision detection.

3) Are the 'floors' going to be of a specific color or will that colour also be used within background graphics.

 

As a very basic example, a simple test is to start with a scene where the player is placed above the floor with some artificial gravity to increment the y-position if not on a floor.

a) In the h/w sprite realm, the detection of a sprite being in collision with a floor colour can lead to, say, subtracting 1 away from the y-position.

b) In a s/w sprite realm, the detection of the sprite being in collision with a floor colour is done by 'peeking' the pixel colour below and where the feet are drawn, again reacting accordingly.

c) A alternative (and perhaps useful in the Limbo example due to the foreground graphics having the same colour as the floor) is to use a set of rectangles to mark game areas. These can be looped through to determine which is relevant based on x-position and then an in-or out of check done done based on the y-positions and a correction to the player's ypos made appropriately.

[Yaron Nir]

Sooo wrathchild you truest understood my post

 

As to your questions :

- I am building the char with tiles and I have a map of tiles Of the screen . Each tile is 8x16 . All is drawn in char mode antic 4.

- main character is HW sprite aka PMG.

- since this is a multicolor mode and scenery is combined from tiles with several colors per character inside a tile (4 chars equals a tile) I cant compare with background color by itself as it is used for other graphics in the scene.

- using the collision HE detection is also not good as the empty tile is combined from the transparent color and I use tile to draw it.

 

My thoughts were:

- using tiles surrounding the sprite . Now I came to an understanding that the best way would be to determine to which direction does the sprite move and always user 3 tiles surrounding to that direction .

For example, if sprite moves right then the following 3 tiles will be checked : upper right , right, bottom right . These tiles should be beside the sprite . When it is moving to.

So for each of the 8 direction the sprite could move I have 8 times 3 tiles that I can compare against . 3 tiles each time.

So each frame (WSYNC) I set the 3 tiles at the current moment depending on the direction of the sprite into an array.

Then I compare these tiles coordinates to the map at the exact position and if it is floor - all good.

I

I can optimize this by knowing that floor is always direction bottom right, bottom, bottom left. But I use this routine to get all tiles for the 3 surrounding places depending on the direction.

 

I would like to know if there is a better way?

 

Tnx again.

[Wrathchild]

If a tile is 16 high then how is the start of a floor denoted?

Within a tile would a floor be sloped, e.g. with a distance or 1 or even 2 pixels?

Can you have multiple floors in the same xpos (think Super Mario and jumping on a floating cube)?

 

Even with a HW/PMG sprite you can use the 'pixel under and below the foot/feet' technique but if you're not reserving a colour to denote the floor then you could opt to have a non-displayed buffer which just uses colours 0 and 3 and compare against that instead.

[Yaron Nir]

So you dont think that having an array of 3 tiles (depending on the direction of the moving sprite as I explained above ) is not better?

Comparing colors is the best practice ?

[Wrathchild]

Walk us through a small section of your screen (including how that is constructed from the tilemap) and how a PM 'walking' across it would be handled by the '3 tile' approach. (pun alert) In doing so that should stumble across any pitfalls in the approach.

[Wrathchild]

Might also be worth asking in the atarionline.pl forums as many good titles originating from there use techniques that could be right for you, e.g.

 

https://youtu.be/nl8f5oEETzU

 

[Edit] so another thought would be to reserve a range of characters to be floor markers. Then based upon which character is just below the PM, check if it is within that range.

Edited April 9, 2019 by Wrathchild

[Yaron Nir]

Soo, the game suggested above (from the Atari online ok site) was exactly what i was aiming.

 

This is tile comparing, so as for the reserved, it would be tiles not chars. As floor can be combined from 3 tiles (each tile combined from 4 characters)

 

I guess having a collision routine that not only checks the floor but also selecting objects, dying of objects , sticking to moving platform and much more.

The routine can work as I mentioned above - based on the direction of the main character and the tiles that relates to that direction (3 total)

[Rybags]

Collision detection in the GTIA sense isn't so useful here since you have to be overlapping the terrain which would mean the character would bounce. Plus knowing there's a collision doesn't tell you how much correction is needed or what direction.

 

Realistically what you want are a set of bounds tables associated with the player and a methodology to easily do the terrain/character graphics stuff.

In some cases you could simplify to bounding box techniques.

But really it comes down to what sort of interactions can occur. With Limbo just about all things can happen, though I'm not sure there's areas where you lose headroom

[R0ger]

Indeed, you simply can't use HW detection for this. Everything has to be done in software, and there are many way how you can do it. Typically you use the same structures you use for drawing the map.

[playermissile]

Jumpman uses a single PMG for the main character and uses collision detection to walk over arbitrary slopes. The method used requires sacrificing a 2nd PMG as a one pixel high "shadow" below the Jumpman character that tracks what the character is walking on. If the shadow doesn't have a collision with the floor color, it increments the Y position of the character, which could mean the character is falling or just going down a slope... won't know till the next frame when it does the check again.

 

If the shadow has a collision with the floor color and the player also has a collision with the floor, the Y position is decremented because the character's foot is touching the floor and must be going uphill.

 

It's a cool technique, but the cost is an additional PMG (or, I suppose you could do it with one player with a complicated variable-positioned DLI to reset the collision register for the scan line below the player's feet).

[_The Doctor__]

Jumpman uses a single PMG for the main character and uses collision detection to walk over arbitrary slopes. The method used requires sacrificing a 2nd PMG as a one pixel high "shadow" below the Jumpman character that tracks what the character is walking on. If the shadow doesn't have a collision with the floor color, it increments the Y position of the character, which could mean the character is falling or just going down a slope... won't know till the next frame when it does the check again.

 

If the shadow has a collision with the floor color and the player also has a collision with the floor, the Y position is decremented because the character's foot is touching the floor and must be going uphill.

 

It's a cool technique, but the cost is an additional PMG (or, I suppose you could do it with one player with a complicated variable-positioned DLI to reset the collision register for the scan line below the player's feet).

the problem being the background moving object and foliage may be the same color as the floor of the forest... the technique will work for alot of the forest but not for those situations.. there isn't really a way to hide something both behind grass and in front of a tree or shrub. the way they use the monochromatic artwork gives a sense of depth as our hero's eyes always seem to be in front of all objects for a while and the behind scrolling tree trunks and foliage later. we've got the horsepower for software map solution, might as well use it.

 

might be good to look at how they've done it on these other platforms and come up with a pseudo method drawn from all of these ideas.

Edited April 11, 2019 by _The Doctor__

[Yaron Nir]

Playernissile, Tnx for the reply. This is a technique I am familiar with. In jumpman it is much more easier as the color of the floor is fixed and not serve as other screen purpose. If you take the game crownland for example the floor is combined from color that is used for other things in the scene, and going with this technique will not work properly.

 

In simple games like jumpman this can be accomplished, but in more graphics-complex games , it cant.

 

Arrays of positions of tiles and comparing to the tiles in the map are the answer to this

[_The Doctor__]

the tiles may be too granular for nice slopes...

[Yaron Nir]

might be good to look at how they've done it on these other platforms and come up with a pseudo method drawn from all of these ideas.

 

Any ideas from where this can be taken?

[_The Doctor__]

well you could contact the c64 programmer who's working on the port at his youtube channel or one of the 64 sites....

https://www.youtube.com/channel/UCwnTNGvMnNbFuIN13mRxVMw

and ask if he would allow you to look at his work or if you might even collaborate to get it done for both platforms... he's been at it for 2 and a half years... you might be able to help each other.

 

Interestingly, the other versions on windows, xbox, mac, playstation and the like show the background and foreground are different shades from the normal objects and floors.. using the shades of grey modes on the Atari and the jumpman method alongside some map defined or tile methods as a combination might be the answer. The commodore version we have been watching doesn't seem to be using enough shades of grey for us to see it the way it is on all the other ports. the commodore looks to be using 4 maybe 5 shades with dithering. You've got a lot more shades to choose from so judicious use of our shades might actually allow for pm methods after all

Edited April 11, 2019 by _The Doctor__

[Yaron Nir]

I am currently working on a beatemup A8 game .

I will sure could use some of his techniques