Bomber Hero (WIP)

[+Muddyfunster]

? ?

 

[RushJet1]

I played the demo for a bit.  As for collision, I'd recommend checking these points (in yellow): 

 

 

That way his head can be a little on top of the ones above since that's how the games usually handled it.  Also enable diagonal movement because it feels a lot more stiff just doing up/down/left/right.

[Defender_2600]

One option would be to at least test the game under emulation, this version was released on TurboGrafx-16, Amiga, Atari ST, DOS, and Sharp X68000.

 

 

[TwentySixHundred]

9 hours ago, RushJet1 said:

I played the demo for a bit.  As for collision, I'd recommend checking these points (in yellow): 

 

 

That way his head can be a little on top of the ones above since that's how the games usually handled it.  Also enable diagonal movement because it feels a lot more stiff just doing up/down/left/right.

Yeah the collision code was very early, however i will probably be doing some re-writing in that department anyway. Now that the new rendering technique is in progress some things will be undergoing partial or full re-writes. Thanks for the suggestion and heads up ?

7 hours ago, Defender_2600 said:

One option would be to at least test the game under emulation, this version was released on TurboGrafx-16, Amiga, Atari ST, DOS, and Sharp X68000.

 

 

I was actually thinking i may really need to play these versions, as im sure they behave differently. Now that the graphics and rendering are getting a full revamp there will be many changes as to how the game runs. Some may take longer, while other code ill probably be able to directly port over from my existing project. Cheers Defender

[TwentySixHundred]

Progress is in the works, and im slowly nailing it down the more im understanding how the new concept works. Anyway this is where im at and i haven't tweaked the pallets yet, i just pulled random colour values from the top of my head to get things working.

 

[bomberpunk]

for the record, there's no diagonal movement in classic Bomberman. in fact there's a glitch in the original NES/FC game where if you are holding UP or DOWN and then you switch to LEFT or RIGHT before letting go of UP or DOWN, your character sprite freezes and he gets stuck for a split second before moving.

[TwentySixHundred]

4 minutes ago, bomberpunk said:

for the record, there's no diagonal movement in classic Bomberman. in fact there's a glitch in the original NES/FC game where if you are holding UP or DOWN and then you switch to LEFT or RIGHT before letting go of UP or DOWN, your character sprite freezes and he gets stuck for a split second before moving.

That is true, i think Jet was more referring to the sticky feeling with my last build. It was something i planned to fix as it became difficult to navigate unless in the precise spot. Basically the issue lies where my code would only allow one input at a time where it should allow diagonal inputs.

 

Reason being is when the player is wanting to change direction, you want to hit diagonally so the bomberman keeps moving rather then getting stuck on a wall if not in the correct line of the path. This was also an issue as player movement and collision detection were tied together. Anyway shouldn't be too hard to correct ?

[TwentySixHundred]

Slowly but surely getting there, pallets are throwing me for a loop as they're handled in a different way. Im still not exactly sure how they're handled as it's nothing like im used to. So for the moment every graphic i add im needing to play around with the indexes like crazy to match everything to the correct colours desired. Anyway atleast there is a map that looks very much like Defender_2600 had mocked up

 

[TwentySixHundred]

So after i had decided to throw bomberman on the board and had a look, i have a small dilemma. I really want to keep 160A mode across the board rather then mixing 160A with 160B modes. After playing around with the newer sprite im thinking the older sprite fits the build. It saves more render time along with a pallet i can use for something else.

 

The issue is i can't get that shadow effect the other versions have. I have 3 colours per sprite + transparency.  The NES 3 colour sprites save resources and im kinda leaning towards that direction for player and enemy sprites ect. Just not 100% sure as to what i should do for the moment

 

Anyway this is the two differences

NES

 

TG16:

 

Now after posting the two side by side im actually thinking the TG16 graphics look better even without the shadowing effect...

[+Muddyfunster]

160B can be expensive in terms of resources and palette fixing.

 

An option could be to use two 160A sprites and overlay. That would effectively give you 6 colours, at the cost of plotting an extra sprite.

 

 

[TwentySixHundred]

Yep that's what I did for the TG16 graphic. The other problem is it's a tall sprite. So the sprites are offset to make the height. That led to needing to use the 6th colour as white for his legs. Therefore still no shadowing. The only ways around that method I can think of is to sacrifice another colour or to crop bombermans height

[+SmittyB]

Other than the awkwardness of arranging palettes to make the most of it, 160B is more efficient than 2 160A sprites as it's the same amount of data to store and render the object, but with 1 header fewer and 6 additional colours.

[Defender_2600]

Excellent work, Anthony! You're just too fast and I can't chase you.   I need to get to my computer, maybe I can show you something that can help.

 

[TwentySixHundred]

11 minutes ago, SmittyB said:

Other than the awkwardness of arranging palettes to make the most of it, 160B is more efficient than 2 160A sprites as it's the same amount of data to store and render the object, but with 1 header fewer and 6 additional colours.

Sorry i should have explained what i meant about saving rendering time. With the NES sprite it's just an single 12x16 sprite using a single pallet. The TG16 style is using two sprites along with two pallets. So as im using sprite-based tiles i was thinking just using a single sprite will save the time of having to render an additional sprite

[+Muddyfunster]

@SmittyB thanks for the clarification on that (1 header vs 2 etc). I wasn't 100% clear on the cost vs speed trades.

[+SmittyB]

As a rule of thumb, if you have 2 sprites that overlap for more colours you're better off with 160B.

[Defender_2600]

20 minutes ago, TwentySixHundred said:

Sorry i should have explained what i meant about saving rendering time. With the NES sprite it's just an single 12x16 sprite using a single pallet. The TG16 style is using two sprites along with two pallets. So as im using sprite-based tiles i was thinking just using a single sprite will save the time of having to render an additional sprite

 

If an example reassures you a little, the head graphics of DOH is made entirely in 160B and, if I remember correctly, in a previous version it was even superimposed on the background tiles in 160A.

 

 

[TwentySixHundred]

20 minutes ago, Defender_2600 said:

 

If an example reassures you a little, the head graphics of DOH is made entirely in 160B and, if I remember correctly, in a previous version it was even superimposed on the background tiles in 160A.

 

 

Thanks Defender, im keeping in mind of what Matt has said earlier about running out of rendering time when using both modes. I still may very well use both but not sure if it's a good idea at the moment. The last thing i want is to run out of rendering time and get stuck in the mud. I still need to add alot to the board like enemy balloms, bombs, HUD and explosion graphics which will take multiple sprites that need rendering. Not to mention upgraded explosions and other additional upgrade items to pick up. I would hate to get long into the development and have issues with say displaying the explosion effects correctly ect. Horizontal is fine as i can have wide sprites, however with a zone height of 16 i will need multiple explosion sprites vertically. Problem is i just don't know how expensive this sprite-based tile concept really is, until i hit that brick wall i guess.

On 1/19/2021 at 2:15 PM, mksmith said:

You can mix 160A and 160B for backgrounds but it can be a fair bit of work to make sure it is setup correctly and the images are in the correct gfx blocks (The Doh level in Arkanoid is does this but it was very tricky!).  I would definitely recommend 160A only for the backgrounds - your moving overlaid sprites could be 160B if required but you still have potential to run out of render time very easily even with this method.

Edit: I could however have the explosion sprites dissipate as they run along the rows. Meaning i wouldn't have to use as many sprites but rather change the sprites x and y pos over multiple frames. I can see this would save rendering time as it cuts down the amount of sprites needed at one given time.

Edited January 20, 2021 by TwentySixHundred

[Defender_2600]

No worries, Anthony. Just another consideration, you don't have to necessarily use 160B for all sprites, initially you could only use it for the player sprite. You have great flexibility with the palettes, at any time you can use each of the 4 palettes with 3 colors, that make up the 160B palette with 12 colors, individually as 160A.

[Defender_2600]

If it can be useful in any way:

 

 

 

[RevEng]

Since you're working on movement and collision detection, you might consider smooth cornering - if you move the player character toward a corner with an opening nearby, you can nudge the player position over to align with the opening.

 

It's easier to try it out and see for yourself, than to explain it in more detail. Check out how @Atarius Maximus's Adventure Demo deals with walking toward blocks that are partially blocking your path.

 

This sort of scheme is more forgiving, and Tanya might even be able to play it with the prolines.

 

[RushJet1]

2 hours ago, TwentySixHundred said:

Thanks Defender, im keeping in mind of what Matt has said earlier about running out of rendering time when using both modes. I still may very well use both but not sure if it's a good idea at the moment. The last thing i want is to run out of rendering time and get stuck in the mud. I still need to add alot to the board like enemy balloms, bombs, HUD and explosion graphics which will take multiple sprites that need rendering. Not to mention upgraded explosions and other additional upgrade items to pick up. I would hate to get long into the development and have issues with say displaying the explosion effects correctly ect. Horizontal is fine as i can have wide sprites, however with a zone height of 16 i will need multiple explosion sprites vertically. Problem is i just don't know how expensive this sprite-based tile concept really is, until i hit that brick wall i guess.

Edit: I could however have the explosion sprites dissipate as they run along the rows. Meaning i wouldn't have to use as many sprites but rather change the sprites x and y pos over multiple frames. I can see this would save rendering time as it cuts down the amount of sprites needed at one given time.

 

Wouldn't the explosions just be background tiles that animate?  I'm pretty sure that's what Bomberman 2 did on the NES.

[+mksmith]

4 hours ago, RushJet1 said:

 

Wouldn't the explosions just be background tiles that animate?  I'm pretty sure that's what Bomberman 2 did on the NES.

That was my thoughts too!

[Defender_2600]

It was also my thought, in fact I had used four colors for the brown rocks, including the brown background color.
 

However, using the background tiles for explosions in 160A, the color green should be used for the background in order to leave the other three colors free for the explosions.

Edited January 21, 2021 by Defender_2600

[RushJet1]

1 hour ago, Defender_2600 said:

It was also my thought, in fact I had used four colors for the brown rocks, including the brown background color.
 

However, using the background tiles for explosions in 160A, the color green should be used for the background in order to leave the other three colors free for the explosions.

Either that or you can simplify the backgrounds to only use one green during the explosions, but use the more colorful background when it's not exploding, shouldn't be too noticeable.