Boulder Remake

Everything about the modern clones and remakes.

Moderator: Admin

Volutar
Member
Posts: 10
Joined: Wed Mar 25, 2009 11:20 am
Location: Nizhnevartovsk, Russia

Post by Volutar »

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.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

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
Volutar
Member
Posts: 10
Joined: Wed Mar 25, 2009 11:20 am
Location: Nizhnevartovsk, Russia

Post by Volutar »

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.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

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
User avatar
paul_nicholls
Member
Posts: 108
Joined: Sun Dec 12, 2010 6:16 am
Location: Tasmania, Australia

Post by paul_nicholls »

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
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

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
User avatar
paul_nicholls
Member
Posts: 108
Joined: Sun Dec 12, 2010 6:16 am
Location: Tasmania, Australia

Post by paul_nicholls »

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! :D

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
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

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. :P Don't worry too much about it.
User avatar
paul_nicholls
Member
Posts: 108
Joined: Sun Dec 12, 2010 6:16 am
Location: Tasmania, Australia

Post by paul_nicholls »

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:

Code: Select all

--------------->
|
|
|F
|
|
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
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

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.
User avatar
paul_nicholls
Member
Posts: 108
Joined: Sun Dec 12, 2010 6:16 am
Location: Tasmania, Australia

Post by paul_nicholls »

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
User avatar
paul_nicholls
Member
Posts: 108
Joined: Sun Dec 12, 2010 6:16 am
Location: Tasmania, Australia

Post by paul_nicholls »

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
zaphod77
Member
Posts: 6
Joined: Sat Aug 18, 2018 7:17 pm

Post by zaphod77 »

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.
zaphod77
Member
Posts: 6
Joined: Sat Aug 18, 2018 7:17 pm

Post by zaphod77 »

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.
dj--alex
Member
Posts: 2
Joined: Tue Feb 04, 2020 9:08 pm

Post by dj--alex »

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
M2k engine dev
Post Reply