TwentySixHundred

From having a quick look i see you're using player0 for the pallet jack. I threw this line of code in: if collision(player0,playfield) then temp3 = (player0x - 16) / 4 : temp4 = (player0y/8) - 1 : pfpixel temp3 temp4 off Commented out this: if collision(player1,playfield) && player1x>22 && player1x<100 && player1y>50 && player1y<75 then pfpixel temp3 And it removes the pfpixels without a worry, only problems is one it would need some tweaks and further checks to iron out the bugs. Obviously the ball didn't appear as i had removed that d{0} bit and you would need to shuffle some code around. Anyway i hope this steers you in the right direction. I used player0 collision detection because it's easier to determine when and where the pixel should be turned off in accordance to the pallet jack. Basically i would go on to make the program skip this condition if the ball is greater then 200 or whatever 👍 I used a very similar method to this for the destruction of the city buildings in City Defence

Nice work mate, yeah obviously it will take alot of tweaking to get things right. It's just a matter of experimenting and learning as you go to find what works for you. Many ways alot of this can be done and i do think you have the right idea with using the ball as a 'box'. You want that 'box' (ball) to have smooth movement like the other sprites as it's the one being moved. After all, games are just an illusion and all that matters is what the player see's on screen. Good thing about the ball is it's the same colour as the playfield so the player thinks it's actually a pfpixel however you will have smooth movement. As for finding the right placement for player vs pfpixels and what pixels can be used/taken. All you really need to do is add coordinates conditions to the collision statement/s. If that condition is not met then the rest of the code isn't executed thus making only certain pfpixel locations having the ability to flip the pixel and replace with the ball. This will also help making the player get the correct alignment in order to pick up the 'box' (we all know you can't pick up a pallet with one tine ;).

Yep as for full screen well i rarely play emulation in windowed mode as my OCD will kick in and drives nuts. Full screen works fine with Fusion on both my desktop and laptop Win10 systems so maybe i am one the lucky ones. Nevertheless it's still a known issue and would be nice if Steve released another update to fix these small issues. I agree with the audio emulation in Fusion, there is nothing wrong with it to my ears. I have read in the past some say the accuracy isn't exactly spot on. Having said that and reading Byuu's blog about emulating the Genesis he has mentioned it's extremely finicky and cycle dependent. Went on to say about how hard it really is to get right and probably the hardest part of emulating the system. So a thumbs up from me to anyone who can get close, because if Byuu who has arguably near perfect emulation for the SNES has mentioned it's challenging then i have no doubts. As im going through my Genesis binge gaming at the moment i just wish there was another update to Fusion. Atleast the small Win 10 compatibility fix and some peace of mind. That way knowing it hasn't been 10 years since development lingering in the back of my mind would be reassuring 😉 Anyway yeah BlastEm just doesn't do it for me at the moment, i have my favorites and will have to wait and see what happens in the future 👍

Thanks for clearing it up (not really a bug) as it's how i always assumed DPC+ worked with the need to update those lines before calling drawscreen. Kind of why i was left in confusion and started thinking it must be a bug after the discussion was raised and i had a hunch it's where the OP was going wrong with text adventure 👍 Makes sense now as it's more for Stella's emulation vs hardware side of things. I was thinking it may have been a bug due to what driver was used. All good i get where you guys are coming from now, cheers 👍

Ok so i have thrown this together quickly for the purpose to test this and have made the program deliberatly only update DFxFRACINC line during the main loop. Further more i have made sure those lines are not updated when switching between rooms. You can see the jitter in Stella with dev settings enabled. If i was to add those lines or revert back to the mainloop before calling drawscreen the jitter is gone. This is using the latest RevEng v1.5 build of bB. So having said that and from my understanding the latest build of bB does this? jitter.bas jitter.bin

Edit: yes sorry i meant all 6 DFxFRACINC lines in my previous post. Interesting, how would we know exactly what driver is being used? I am assuming the driver is integrated into the IDE and depends on the build of Visual bB used? Rather then the version of batari Basic if i am correct? Just so i got a clear understanding.

Ah, i see so for something like that i would go with your first idea of using the ball. Basically i would push values using a global timer to switch on or off pfpixels for the "conveyor"? belt animation. All you would need to do from there is check for collision with playfield in certain locations and switch the pixels on/off and replace some with the ball when selecting the box. Same with when storing the "box" once the box is released within the correct area you can just flip that playfield pixel on again and remove the ball. Reason as to why i would use the ball is for smoother movement because the pfpixels move in a very coarse manner. Especially as the player sprite and pallet jack will both have smooth movements. Secondly ironing out the bugs will be alot easier with the ball. You can basically set the ball to the pallet jack and forget about it. No updates - no bugs - little cost - no drama 👍

Thanks, so i am guessing DF4FRACINC is the only line that needs to be updated every drawscreen. This is interesting because once the colours are pushed to the TIA i would think they only need updating once unless the colour is changed ect? Does this have anything to do with how DPC+ stores the graphics data into RAM? Personally i update all 5 DFxFRACINC's after any changes to pf colours or pixels ect and that seems to prevent any issues on my end. I will have another look in the area i was having some issues with Missile Defence. I can't remember off the top of my head if there was any PF changes that would require a DFx update in that code block. 👍

It works fine on my systems also however i am not running the latest rigs so that maybe where people are complaining (hardware compatibility). The most common complaint i see is fusion crashes in full screen mode with Win10. I think fusion is the best emulator for Sega by far however it's known to not be as accurate as it could be. I have experienced multiple random crashes while playing Road Rash 3 over the years and many have mentioned emulation of the Yamaha YM2612 is not perfect. Others have said although the emulation is fairly accurate it's not on a level of cycle-accuracy like other emulators that have continued development over the years. It would be nice to see someone pick up the pieces or if the source was released to someone that could stay faithful to the emulator Steve created. In the interview with Steve even said there could be a chance of releasing a new version for Win10 to fix a few small issues he knows of. Having said that i found that audio interview a few years ago (see if i can find it again). Edit: here it is, might have a listen again myself

Is it just me or has emulation for the Genesis gone on the decline? I use Fusion by Steve Snake however the emulator hasn't seen an update for over 10 years now. I feel everything else i try that claims to still be in development doesn't live up to the quality. Not just the core as Fusion clearly needs some more refinement but rather as an overall package. I mean the UI is also an important part of an emulator and when it comes to Windows ports everything else seems either too fancy or a quick throw together. Emulators like Stella, Snes9x ,Higan, Mesen and many alike have simple yet user friendly UI's with no fancy or shotty gimicks leaving the user somewhat confused as to how to navigate, assign controllers with ease and the general standard hotkeys ect. Genesis seems to get some love when it comes to emulation on consoles yet when it comes to Windows IMO Fusion is still by far the best. I know Steve Snake said he would like to make another release for Win10 compatibility and some small changes. however that was years ago and doesn't look promising. On Reddit many are mentioning BlastEm which does run half decent although assigning controls and the overall UI experience is fairly lackluster and a PITA TBH (no offense). It's no secret many are also still sticking with Fusion as their choice of Genesis emulation. Problem is it's not going to be compatible forever along with a much needed polish. As far as i see Byuu is probably the best hope with Genesis emulation in Higan although it still has a long way to go.

So i am assuming you're after something like this (excuse the bugs)? You can see in this example the pfpixel moves much like the ball would when bouncing off the player. In this example the player can only push the pixels upwards. It's a rough demo with a bug however shows the concept. move_pfpixels.bin

Personally i use variables when wanting a moving pfpixel to behave like a missile. Depends on the application in mind and if it's worth using variables or just pushing values. Im interested as to how others tackle this feature so i will wait till others respond before giving too much advice. As for cost, once the pixel is turned on/off it's a one time deal if your code doesn't need to execute redundant routines. Also from my experience the highest cost is when trying to draw large chunks of playfield using the push method without using data tables. Pushing many pixels manually takes alot of ROM space and chews cycles requiring a drawscreen call often. Having said that making a single mid resolution pixel turn on and remove redundant pixels in it's wake i find not very costly. As long as the pixel placement is updated once every frame. However what works for me may not for others so probably best to wait for others to chime in.

Thanks im glad you like it, yeah it's supposed to be the moon that goes though phases. It helps show the passing of time from wave to wave represented as a month per phase. Not completely accurate to real life and is drawn with playfield so it's low resolution compared to sprites. Either way i think it came out ok 👍

New build! Small bug fix where the points display would sometimes not remove the points after said time. Changlog: bug - points display removal Latest Build: City Defence 20200307.bin

Nevermind i was all doped up from after the hospital (whatever they gave me)

That's all possible and i had no idea about changing difficulty switches in Megamania (one my other favorite games). The ability to change missile trajectory has been a conundrum of mine from the very start, believe it or not. However i have opted, not to, due to my problem of hoarding resources . The question is do i tackle the player missile trajectory with what little space i have left or keep adding features. I am really not wanting to breaking my rule of no backswitcking during the mainloop. It's hard because i think the way it is isn't all that bad and adds that homing like feature/look. However some may think it needs improvement until they really jump aboard. The problems are ROM space, cycles and available resources as opposed to what players really want. From my perspective the guidance of the missiles is a small issue yet i try to keep space for when i want to tackle this issue... 🤔 Thanks for the advice and feedback it's much appreciated and helps with development 👍

BROKEN! thanks to cafeman lol I was actually hoping someone wouldn't try/ask this, to be honest left difficulty will do nothing as the code is executed as pre-startup data and has no effect during the main gamloop or during intermissions. However the right is a different story as the code is executed during intermissions. So the result of capped or infinite can be changed during gameplay, you could call that a bug or somewhat of a cheat move. It's not cheat proof as of this moment and is where the GUI would probably be the better idea, for the cost of a variable broken into bits. I am actually impressed with your curiosity 👍

Thanks @stephena much appreciated, after having a quick look at @satyrsfaction code it's hard to determine. There is multiple maingame loopes and i was suspecting a collision statement was taking place then reverting back to code that alters sprite placement. I could be wrong as everyone has their own style of coding and have vastly different from my mine, however if this is a case of a Stella the bug please report what the issue is as this would be very helpful for us programmers. Thanks for taking your time to look into it 👍

New build! Ok so after having a think about difficulty i have decided at such a low cost of resources i can give players 4 unique options to choose from For now they're controlled via the difficulty switches and corresponds to what position you start the game with. There is a capped mode so once reaching wave 25 the speed of the warheads is capped and will not increase. Then there is the advanced mode for those who want fast gameplay off the bat. You can mix these up so it starts off fast then capped of have the game run infinite vice versa. If it turns out that many like this feature, i may consider creating a GUI menu screen at the start of the game, so the player can chose these options via joystick rather then console switches. Some advice from @sramirez2008 as to where you're thinking the tipping point is for adding the cap (wave), None of us others are at that level yet so im just taking a wild guess at 25 when there is no physical chance. Much appreciate your testing mate 👍 How it works: game BB: Starts slow and is capped game BA: Starts slow with no cap game AB: Starts fast however capped game AA: Starts fast and isn't capped Changelog: difficulty options - for those who want variation and a real challenge or a progressively relaxed game Latest Build: City Defence 20200306.bin Once again as per usual any bugs, issues or feedback please don't feel shy to report them, cheers 👍 -Anthony

Thanks for the kind words Cafeman, yeah i have had to lower the bar during the start off period so all skill levels can get the satisfaction of completing a few levels. I also lowered the learning curve so id doesn't feel like one extreme to the next. Wave 10 is where things really start to ramp up and by round 20 it starts getting chaotic making the player feel very vulnerable. I can't speak for round 30 onwards however sramirez2008 seems to be where things get ultra and hard close to breaking point. This leaves me with the old question of creating a cap and where is the tipping point of when the player has no physical chance of defending the city. It's all well and good to let the game continue increasing in difficulty although it's just becomes frustrating and not fun when it becomes impossible. I can always have the option for difficulty settings (left and right) of infinite difficulty or capped and maybe another so the starting difficulty could be higher for those who want fast gameplay off the bat rather then waiting. No issues there i can just move the option to restart with reset to the BW/Color switch 👍

Yeah the easiest way to explain it is, there is one sprite, so depending on the last updated collision location the sprite will be placed there. The only difference with the sprite is the data of that score is fetched (read and write) depending what missile is hit. So essentially if i had two sprites then i could have the first missile struck remain for the period of time. If i had the resources i probably would after seeing how well this feature works, however I haven't so for what it is i think it's acceptable.

Yep that's a huge difference and on the right track, only a very small amount of jitter. It's probably something to do with the collision detection code now 👍

Nice score! Yeah i still struggle to get that far, probably due to watching for any bugs and issues as i play. Thanks i really like how they turned out and it really adds that depth to the game. Wave counter is much needed as it shows how many buildings the player manages to save vs warheads destroyed each wave on an average. Points on-screen adds vibrancy to the repetitive nature of the game and satisfaction of destroying the enemy as some sort of reward. Im really happy with this build and thanks for testing on hardware 👍