Jump to content

TwentySixHundred

Members
  • Content Count

    1,739
  • Joined

  • Last visited

Everything posted by TwentySixHundred

  1. Yes of course What i was meaning is have a tile that mainly consists of transparent so the green background colour acts as a secondary colour. That way the little sprouts (secondary colour) is actually only one colour on the tile. It would look exactly the same other then having two colours on the tile itself. Would more give the illusion of two colours on the tile and the plus side is that pallet could have two other colours remaining for other sprites. Especially if im stacking pallets in 160B mode for certain sprites.
  2. Thanks for the link Mike i will definitely be looking into it. The way i originally went about it was if an input was pressed and an non walkable tile was detected the code would skip any other inputs. That's why i was leaving the player stuck on "sticky walls". Was very early code but this link you provided could really help open my eyes to other ways around it 👍 That's actually a really good idea and i hadn't thought of that approach. It would surely save rendering time and the need to overlay explosion sprites. Thanks RushJet it should be just a matter of poking the tiles needed 👍 Yeah i noticed the four colours with the brown rocks and actually slightly modified them to have just three. It worked for now to get the map displayed and the tradeoff is hardly noticeable. I can always set the background colour to green and just use a transparent tile for the grass. This would also help with flipping the tiles to explosion tiles as the transparent part around the explosion tiles would still be green. Just means the tradeoff would be the green boarder remaining around the edges of the playfied 👍
  3. 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.
  4. 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
  5. 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
  6. 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...
  7. 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
  8. 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 👍
  9. 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.
  10. 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 👍 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
  11. Well well well, would you look at that... im absolutely ecstatic Couldn't help myself it was bugging me i hadn't made enough progress for the night and boom! Still got to figure out pallets and some more tweaks to the code to get things just right. There is alot to re-write and fit around what i had as the whole concept has changed - im assuming my whole collision detection code will need a re-write too. However im over the moon as this is starting to look more like it.
  12. Ok so thanks to Matt's links and having a look at your example code i have managed to decipher some of the code so i can get an understanding. From there i have taken snippets, created a bankswitched ROM and started breaking down the code. So the 'for' loop is kinda throwing me for a loop (pun intended) as i haven't a full understanding yet. Also im yet to work out exactly how the pallets work as it's not getting the results im after at this moment. Anyway i will keep at it tomorrow as im running out of time tonight but there is some small progress I started with this as obviously i will be using a smaller table as the sprites are 12x16 supplied by Defender I now have this as im thinking i will need to set the zone height to 16 rather then 8 May not look like much but i have something on the screen, even if the colours are all wrong and the tiles are a garbled mess haha. All in all it shows i haven't a full understanding yet.
  13. Thanks for the well wishes for my daughter Matt. Also thanks for chiming in and offering some help with sprite-based tiles. I will have a look into the links you have listed, to be honest "under the hood" is probably one of very RevEng few examples i hadn't looked into yet. And as i suspected going from your other link data tables were used to manage the sprite-based tiles. Im actually more then happy to stick with 160A mode as much as possible where i can. 160B im just not very familiar with yet and can see myself probably running out of render time. Anyway i may very well need some help to get me started with the new concept. Once i have a clear understand of what's happening, will be off and racing 👍 Thanks Defender, yeah i couldn't live without ADS. It's brilliant and a very comfortable environment to work in. It's exactly the IDE extension that the 7800 needed and Matt did a great job of it 👍
  14. It will definitely take some study and most likely a re-write. I would really like to go this approach as it would look amazing. Only issue im seeing here is how fast of a timely manner i can pick up the concept and put it into practice. It's looking like there is more to it then just plotting sprites around the screen. Ill have a good at the link you provided and may ask those who have used this approach for some tips and where to start 👍 Yeah it's an interesting way to handle background tiles that's for sure. I do like the idea as it's working with the 7800's strengths and like you said the more tools to work with the better. Im assuming they're using some sort of a data_table to manage all these sprites, rather then just plotting a bunch on the screen. Also thanks for the thoughts about my daughter, she's still a bit beside herself at times but feeling much better overall 👍
  15. Thanks Defender, yeah no worries she's getting better day by day and should be back to herself soon. I will have a look into this sprite-based tiles you have mentioned as the technique used by mksmith. I thinking it's basically what character graphics is but the user has more control over the tile size and soforth rather then preset tilesizes/sprites used with character graphics. This of course would probably require a rewrite of how the map is handled although im not sure until looking into exactly how it's done. Sounds amazing and hard to believe this is composed only using the TIA. Brilliant work RushJet1! The attention to detail is spot on and is my favorite track on Bomerman2, so even better Yeah i always write my games in NTSC format and if i feel the need i will create a PAL version later. Thanking you very much so
  16. Sorry for the late replies guys, incredible work and thanks for reaching out to the project. I don't want to make a sob story but the past few days i have been in and out the hospital with my daughter. She is doing ok but was a rough few days and is why i hadn't responded yet. Im honored for the help being offered and im convinced @Defender_2600 has the right idea. I will have to take a decent look tonight and im thinking this will warrants a DM/PM. That way we can make this happen as i can't express enough how incredible the conversion table looks. I will be sending a message through tonight if you're ok with that @Defender_2600. @RushJet1 Im sure this new update will also be amazing like the last. Im very very interested the product you can produce. If you would like you composed BM music in the game later down the track when you're happy with it. Im more then happy to give credits to you both rush and defender for the help and hard work. Ill have a good listen tonight and see what you have 👍 I must say this help is very much appreciated and DM/PM's will be sent if you're both happy with me adding this work to the project. -Anthony
  17. Thanks Defender, yeah the plan is/was to make the game somewhat of a hybrid of BM1 and BM2. Even on the NES BM2 visually looks pleasing on the eyes and the soundtrack is amazing. To start with i really just wanted to get some graphics on the screen and work on the engine. Now as the project has progressed, i have been contemplating whether to make it faithful to BM1 and keep the original graphics, or go with the hybrid concept. As for pallets for the background tiles, i was always under the assumption that in 160A mode you can only use 1 of the 3+1 colour pallets per background. And to change the colours it requires changing the pallet values or use a different pallet index. AFAIK 160B would allow up to 12 colours to be used for the background tiles or sprites which uses 4 of the 8 pallets. -Anthony
  18. Wow that's incredible work using the TIA, sounds great. Music is my weak area with projects, im really liking the tunes 👍
  19. Thankyou the sprites are looking good, i had gone with 16x16 due to the limitations of the system along with most NES sprites are 16x16. So they're basically a straight swap, however the 7800 has a tendency to stretch those sprites in 160A mode. I have had to modify all the sprites to make them scale to size, so in reality they aren't a straight swap but rather modified to fit to scale. Atleast Nintendo can't say i have stolen them haha. Anyway yes i know the half blocks is a pain and there is two ways around it. Firstly i have some code (not tested) that detects if any of the one bricks is destroyed then follows on to remove the other. I think that would work fine, or there is the traditional way that automatically places the bomb central to that tile block. On the NES and most bomberman games i have seen they use the later as it detects what tile block you're placing the bomb and centralizes it. Not sure exactly how they achieved that or what method im going with. It's something i will sit on for now and have a good think. Annoying but the game is still playable even with the bug once the player is mindful of it. As for Quadtari im really not sure yet, Lewis (Muddy) had mentioned it on the discord. Im not even sure whether 7800Basic supports it yet (may need to look into it). Two player on the other hand is on the bucket list and in the works. Multiplayer really is a must for a game like this as many only enjoy that mode over Singleplayer. I want both as not everyone has another person or 4 to play with so the game should be enjoyable in all forms. But yes two player battle mode will be implemented in a near release. Which also means i will need to get my A$$ into gear and design a title screen for the options ect. Lots of work to go and thanks for checking it out and sprites 👍
  20. I tried those settings, it's something going on with JS7800. Sometimes they will change to the correct colours when completing a level. Then mid level it will revert back to the incorrect. The Balloms eyes and bombermans helmet are the same shade of white IRC although they will flip. Meaning sometimes when a new level loads bomberman will have the correct colours and others the Balloms will be vice versa. Even the explosion colours seem garbled. Im assuming it's an inaccuracy with pallets on JS7800. A7800 there is no issues and everything works perfectly. I still haven't reported the bug to JS7800 as no one else has had the issue with their games AFAIK. Although i probably should. I will also mention during the ZPH stream all the colours were correct on real hardware, so everything points towards JS7800.
  21. So new build, with 4 more fixes since the ZPH stream. There is quite a few decent fixes here that really needed to happen. Also note that it's still possible to destroy only half a block if your explosion radius is a certain distance from the block. The bugfix listed is actually the critical bug causing a block to break that was nowhere near the bomb. Changelog: content: level framework and 5 levels added to the game with exiting doors feature: bomb button restrainer feature: reboot from gameover on joy0fire0 bugfix: incorrect blocks getting destroyed from explosions bugfix: player graphic glitch As always latest build here or first post bomberhero_20210114_144k.bas.a78
  22. So tonight i went bug hunting as to why the random blocks/tiles would get destroyed. I have nailed it down to a single routine after many tests and fairly sure i know why. Im suspecting a wrap-around effect with my math. The issue only occurs on the first vertical row of destructible tiles. It also only happens when the bomb is placed above the tiles rather then the side or below. So it's obviously the code im using for detecting what tiles are below the bomb, well (explosion radius). So if im right then i basically have two options: Option1: Write some hacky prevention code for that column to prevent wrap-around. Option2: Revert back to narrowing the mapsize like my previous build and use well thought out placement of walkable and non-walkable tiles. This of course means i lose one-two columns of walkable space. Im in need of some sleep and will have another look tomorrow to make sure i haven't overlooked anything. There is a chance im thinking my math is correct yet having a mental blank. I will say as of the moment id rather go with option 2, as i usually try to stay clear of hacky workarounds. From past experience they can snowball into a mess of continuous hacky workarounds trying to fix the previous prevention code that breaks something else. Anyway sleep for now 👍
  23. Thanks for the kind words @phattyboombatty Yeah i have kind of put the project to the side for a few reasons i had mentioned in older posts. I do open the source from time to time and think i really should work on the enemy AI and add some content. The first level was never completed other then the screen layouts. I had some decent background tiles ready for the following levels that only ever made it into an early demo. Anyway i would really like to fix the enemy AI and items some time in the near future. Im sure the motivation will arise someday as i always liked the DOS game. Thanks for checking it out
  24. Thanks for the bug report about blocks being destroyed that aren't nearby. Yeah the colours is a known problem and i suspect JS7800 is detecting the ROM as PAL although im not why. It's correct with A7800, so i may have to make a bug report with JS7800 so it can be looked into.
  25. Ok so new build, i have changed a few things and made some improvements. Checks for the player position in regards to tile locations still isn't right so the code is inactive at the moment. I hope to nail it down soon in the near future, anyway this is what i have. Feature: System reboot on reset requested by Slidellman Bug fix: Explosion radius - blocks below would sometimes not destruct after explosions. Graphics: Breakable blocks have a different style Design: Map layout has slightly changed for a couple of reasons. 1) To accommodate score and other future HUD display. 2) Half tiles used on side boarder to compensate the space that would have otherwise been lost. That's about all i can remember for tonight as i was messing around with the player coord checks for the later half. Video Latest Build: bomber_hero_20210108.bas.a78
×
×
  • Create New...