Boulder Dash Forum

I don't understand, how you calculate the frames. But in my opinion, it works as it should.

At first I noticed it by sight. After that - writing screenshost, and by-frame video. Of original Boulder (atari/spectrum versions), of my own and of Remake to compare. The spaces between falling diamonds to the left and to the right for original boulder are folowing: diamond, space, space, diamond, space, space, etc.
For Remake to the right they are the same as original, but to the left they are consumed more faster: diamond, space, diamond, space, etc.

Better to check it by yourself.

I didn't mean that you were wrong. I only wanted to bring out that in my opinion, the Bremake works as it was intended to work. Maybe I'm wrong and it is really a bug. But I try to explain why I think it isn't.

Volutar wrote:By the way this issue can easely be the reason of Rockford death, when he's turning from right to left (two rows of diamonds, Rockford starts from down-left, going right, and immidiatly left). Turning from left to right is safe, though.

I take this condition to analyze how it works in different games.
I checked out Bd1 for C64 and I wasn't hit by the diamond as you described. I also checked out another fanmade game built with the construction kit and I was hit by the diamond as in Bremake.
I guess the diamond behaviour depends on the game engine the game uses. And the problem is that there isn't such a "standard". All game engines work different. Did you already know that there is a game engine that uses 7 frames for an explosion instead of 6. That's getting me nuts.
If in Bremake the movement of rockford was performed after or before the scan routine, it should work as it works in bd1.

Besides, did you check this issue in gdash?

subotai

No. Actually I didn't. But AFAIK, all classic BD algorithms was implemented accurately in GDash. Classic frame-by-frame paradigm wasn't touched. There wasn't any need to make smooth movement and implement intermediate moving states, so GDash author's task was much easier.

I don't think it's an "absent of standart" problem. Because there is simple logic for BD-like labyringh game: player movement rules must be symmetric. This rule is violated in Kit (according your words) and in BRemake. Really it have no logical excuse for situation when you're dying when turning left while it's okay with turning right.
It doesn't affect on anything except for stupid sudden death.

By the way - have you checked jewel consuming speed to the left/right in Kit (go-without-go-action)? BD1/2 is symmetric, and BRemake isn't.

Volutar wrote: By the way - have you checked jewel consuming speed to the left/right in Kit (go-without-go-action)?

No I didn't. I agree with you. I don't really like the fact getting hit by a falling diamond this way. My aim was to create a clone that makes it possible to play many games as accurate as possible. I think most games have been created with the construction kit or crazy light tools. If you want to be accurate, you should implement your game the way these engines work!? Maybe I'm wrong, but I think in gdash there is no difference to bremake concerning the issue getting hit by a falling diamond when turning to the left. I don't know exactly how bremake was coded. But I know that the author used Peter B.'s documents. Me to and my clone works as Bremake does. But I implemented the smooth scrolling after I built the game engine. The smooth scrolling doesn't have any effect to the gameplay because it works independent from the game engine.

subotai

Hi all,
I know this is an old post, but does anyone know if Marcin Liwak has a homepage for his Boulder Remake, or contact details (email)?

I am making a boulderdash inspired game (http://theprobegame.com), and had some questions for Marcin if I can find him...

cheers,
Paul

Hi Paul,

just take a look at the ReadMe.txt in the game folder.

But maybe we can also help you to answer some questions.

Greetings,
subotai

subotai wrote:Hi Paul,

just take a look at the ReadMe.txt in the game folder.

But maybe we can also help you to answer some questions.

Greetings,
subotai

Thanks subotai, I didn't think of looking in readme.txt...D'OH!

I was going to ask him about how he did his smooth scrolling in the game since I was having some trouble with mine, but I think I might have figured it out since I did this post LOL

If I have any questions I will ask here too...thanks!

cheers,
Paul

paul_nicholls wrote:I didn't think of looking in readme.txt...D'OH!

HAAHAA

paul_nicholls wrote:I was going to ask him about how he did his smooth scrolling

Well, he used DelphiX, and I think as long as the game runs at maximum speed on your PC, the scrolling is always smooth. I was also impressed by the smooth scrolling the first time I played the game. After that, I tested BoulderRemake on an other PC where the scrolling was not that smooth, because the engine had to slow down the game speed.

I use SDL, and in older versions, I had also a smooth scrolling, because I had not to slow down the game speed. But now it's also a bit rough.

But finally, I think that nobody cares if the scrolling is not 100% smooth. Don't worry too much about it.

Hi all,
I have sent Marcin (Boulder Remake) an email about this, and I thought I'd ask you too just in case Marcin doesn't answer...

I have been trying to make my own boulder dash inspired game using the information found here:
http://www.elmerproductions.com/sp/pete ... eInfo.html

for the algorithms and logic.

Everything works fine so far, but now I want to add in smooth scrolling like Marcin has done.

Boulder Remake seems to work very closely with regards to the physical boulder dash rules even though it is using smooth scrolling.

I HAVE gotten a version of smooth scrolling working, but it doesn't follow the boulder dash rules correctly.

This is what I do in my game:

Update (scan) phase:

1. Reset all boulder dash objects in level to not scanned.
2. If any objects are moving (see step 4.), move them to the new location and put a space at the old location.
3. For each level location scan the boulder dash object there.
4. If this object can move this frame, then do this:
a. Flag the object as moving (+ scanned) and in what direction.
b. Put a placeholder (solid, but invisible object) at the new location so other objects can't move there during this scan phase.

Render phase:

During the rendering phase each object is rendered.
If that object is moving, then offset it by some amount equalling to the X/Y direction it is moving in for smooth scrolling.

This works, but my biggest problem is that it is not correct regarding boulder dash physics.

In boulder dash, you can for instance do this little trick:
Moving up from the left and below of a firefly/butterfly WON'T explode it due to how the scanning order works.

In MY version, my character ends up next to the firefly/butterfly (update phase, step 2.), and then that same scan frame, the firefly/butterfly is processed, and BOOOOMMMM!!!

I was wondering if any of you could share how you have done your boulder dash physics IF you are also doing smooth scrolling?

thanks for your time

cheers,
Paul

paul_nicholls wrote:4. If this object can move this frame, then do this:
a. Flag the object as moving (+ scanned) and in what direction.
b. Put a placeholder (solid, but invisible object) at the new location so other objects can't move there during this scan phase.

No way. Of course, this will alter the original physics. Smooth rendering has to be done completely isolated from the actual physics.
You would have to move any object instantaneously in memory like original BD does. Then, the rendering code has to interpolate the movements between frames.

LogicDeLuxe wrote:

paul_nicholls wrote:4. If this object can move this frame, then do this:
a. Flag the object as moving (+ scanned) and in what direction.
b. Put a placeholder (solid, but invisible object) at the new location so other objects can't move there during this scan phase.

No way. Of course, this will alter the original physics. Smooth rendering has to be done completely isolated from the actual physics.
You would have to move any object instantaneously in memory like original BD does. Then, the rendering code has to interpolate the movements between frames.

Ah! I see now

Ok, I will try moving the objects to their new positions just like boulder dash, but smooth scroll from the old position to the new position during the render phase

Thanks LogicDeLuxe, that was indeed logical LOL

Happy new year to one and all!

cheers,
Paul

Yay! The new way of moving boulder dash objects and smooth scrolling them works a treat!

Thanks again LogicDeLuxe

I can't believe I didn't think of it sooner myself! D'OH!

It even fixed up another issue I had too with how the player interacted with the objects

It is only a simple prototype, but I will see if I can get a video up for you to look at soon

cheers,
Paul

This causes a really ugly looking artifact where if you approach a firefly from left or top, it explodes while you still look like you are in the previous square.

if you wish to replicate the engine properly, you have to put up with this visual wart.

I think i know what's going on with the right to left turn.

I think there's a special exception that says if a falling object lands on another diamond, it immediately is flagged stationary after the move, to allow it to not crush you.

the diamond space space happens with rolloffs. otherwise, it's diamond space diamond space.

Interpreted directly by the bdcff specs, getting killed when switching from moving right to left is correct. Yet you do not.

But if an object falling onto a diamond specifically becomes stationary immediately after the move, then the collection is safe, and you do not die. This hack does not affect boulder physics in any way, just the ability to collect them.

we must go back to the atari 8 bit original to get the full story, as that's the original game. it's entirely possible this protection was added in for c64 BD1 because that death is unfair, or it could have been there all along.

Alternatively it could be that moving into a square that was not empty immediately flags the above object as stationary, so it doesn't drop on you. this does NOT happen if the square you moved into was empty.

Or it could be that if a boulder or diamond is flagged stationary, the one ABOVE it is also flagged stationary. Considering the way that the gave seems to slow down a lot when massive boulders are colliding, this one is most likely to be the truth i think. the construction kit slows down less i think, so they removed this check, which causes the death behavior observed in it and not in bd1 engine.

https://www.youtube.com/watch?v=C6Ocpqcyyn0

yes it another remake =) Im doing simple game engine M2K
I have problem with collision with player. it's buggy detecting
and i don't understand logic of monsters.
And bug with gravitation.
I waste a WEEK but any rock dropped ANYWHERE kills player instantly

bug bug and another bug...


code of Linux port on github if needed. https://github.com/dj--alex/m2k
if anybody need can use it