Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

79 Excellent

About ScumSoft

  • Rank
  • Birthday 05/17/1981

Profile Information

  • Gender
  • Location
    Polysorbate 60
  • Interests
    Enslaving Programmers

Recent Profile Visitors

16,879 profile views
  1. Well...it just so happens that the next big project I started on earlier this year is just such a thing. It's a FORTH I've nicknamed Maestro. It's a completely new firmware for the Harmony/Encore carts which allows us to develop 2600 games in real time and leverages the ARM cpu in the likeness of the Sega 32X. I can make no eta on a release date just yet, but you're not the only ones that thought this was a great idea!
  2. I was chatting with Batari about the MAM bug, I found this bit of info on the timings, it's towards the bottom: NXP MAM Timings
  3. 30% here as well, anymore and it doesn't look right.
  4. I find it helps to verbally think out the problems. "If the player0x is greater than 20 then I need to start checking if player0x is equal to player1x" Leads to a super simple solution: if player0x >= 20 then if player0x = player1x then it wont run the "then if", unless player0x >= 20 did I understand your problem correctly?
  5. Looks good to me. I posted a color update and typo fix to your other thread this morning, so check it out and let me know if it was helpful or not. Lookin forward to the completed versions!
  6. I might have gone a bit too far with this. I know you're new to 2600 programming, so I implemented lots of stuff that you could learn from. Run the precompiled binary in the bin folder to check it out. Runs on the Harmony cart just fine also. You can edit the build.bat and point it to your installation of bB, then just run it to compile the game. rem ***** MAKE SURE ENVIRONMENT VARS ARE PRESENT ***** set bB=C:\Atari\bB path=%path%;C:\Atari\bB I split all my DPC+ projects into separate bank files, it makes it easier to work with larger games. Feel free to use whatever format you're comfortable with, copy and paste the code into your own, or continue on with my updated template style. Ask away if you have any questions! [edit] Posted a newer version with player colors and some typo fixes Karate_Game_DPC+.7z
  7. Okay I have a working solution with minimal flicker for both players, I've copied your code into my DPC+ template layout and making some optimizations. I'll post the new code here once I've got it all fixed up.
  8. I'm currently looking into your issue, I think there might be a way to do it without major flicker.
  9. It should be the same, I halved the fire buttons flap velocity and added it into the joystick/D-pad up direction.
  10. Yeah it worked out ok, didn't have to change much puzzle logic wise to compensate. Chickens cannot fly is the logic behind this, so Quackers resorts to some tricks to make it happen. Try holding fire and holding up on the joystick/d-pad to gain upwards momentum. You can also bounce a bit to get started or use the Powerflap for the initial upward boost. Sometimes if the angle and velocity is high you will still get some backward bounces, but not too often. This will be the last update for a little while, I have some other projects I got started on. I'll prioritize fixing any game breaking issues if any are found though. Thanks for checking out the game!
  11. Game has been updated to RC4 build, first post updated with changes. As always, feedback is appreciated. Enjoy Everyone!
  12. Hey get a room you two! j/k It would probably be better to split the thread where Thomas posted his example to it's own thread. This is my thread for game updates after all. Speaking of which: The next build will be posted later this weekend with fixes to many of the issues mentioned.
  13. Not at all, in fact it was rather trivial to get working properly last night. I had been referencing my old bouncing ball demo written in Pascal long ago and overlooked that I did conditional checks on the velocities, something I did not do in this code. It matters not if the Sprite isn't a bounding box, the non active pixels clipping into the playfield make no difference since the player sprite is fully reset into a safe area after collision is detected. My code was already setup for working with this properly, I just needed to separate out the X and Y velocity assignments and not set them both at the same time. Thanks for your interest in this issue though, you are a great coder for sure. You should look into bB sometime, its just a stepping stone for new users to get into 6502 assembler. Though it has it's shortcomings, its fun to push the limits of it. I'll post the next build of the game sometime soon, I had my cousin playtest the latest changes and he found some issues that I am currently correcting.
  14. Thanks for explaining your solution. I only need to make a small change then in my code and it should work similar to your example then. I do track the prior frame positions with SafeX,Y. The velocity rolloff is subtracted each frame at a constant value, along with limit checks. The only thing I wasn't doing was seperating out the velocity changes based on which direction we were moving, I thought pfreads would be required and those are too expensive to use. I wrote a gravity bouncing ball test just fine in other languages, but the code was simplified to a box, so I had trouble adapting the principles to the complex geometry in this. Looks like I only need to add two checks and we are done with the collision issues. Thanks for the insight.
  • Create New...