Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by Trip2018

  1. I haven't been making anything in the past couple of years for the 2600 but this idea has been nagging me for a while. I'm probably blind and this has been asked many times before, but basically, would it be possible to "race the beam" turning playfield bits on/off mid drawing to "double" the playfeild resolution? Or even simpler, simulate a sub pixel offset for smoother scrolling?


    I'm sure there are a few drawbacks to this like with reading pf bits directly, but it's worth a try

  2. Welcome! If you haven't already, please read the rules before posting. It is prefered if you post an art piece or ref sheet of your fursona. You can rp with others here as long as it stays to a simple meetings, greetings, or welcomes! Anything beyond that and you will be asked to start a new topic.

  3. Rules:

       - All chat/rp content must be safe for work.


       - Try to keep swearing to a minimum.


       - Be respectful.


       - No politics, arguing, or hate. (Take ur beef elsewhere)


       - Constructive criticism is allowed.


       - Nothing is stopping normies from entering, try to be as welcoming as possible!


    And most importantly:

       - Have Fun!!!


    • Like 1

  4. I've been thinking about using a bit to make your increments 2 pixels instead of 4 when you start moving as a momentum buildup, and then when you move twice under that you go back to a full 4, keeping your increments even. It shouldn't throw off my platform checks and it won't do a screen scroll, which by in of itself eats a lot of cycle time.

    So like how super Mario bros. does it with sub-pixels? I was thinking of that too but I figured frame buffer method would be more efficient.

  5. Yes, the movement speed is difficult to try and tack down, because I changed the method from Princess Rescue, to be more efficient on how it checks screen memory for platforms to save on CPU cycles, but it also assumes that you move 4 pixels at a time, which is the length of each playfield block. Since the playfield scrolls at 4 pixels per scroll (and there is no way around it), I thought it'd make sense to match that rate, but it also makes the movements pretty touchy. I added a stop when you land from a certain height or change direction to try and help out, but it only lasts a frame or two. Maybe I need to make it last longer.

    You could probably use a frame buffer bit on player movement to fix it. You'd likely gain a lot of extra cpu cycles, which is always a win in my opinion.

  6. Really nice! It has wonderful animations, good platforming segments, nice character design that isn't to unfamiliar to what you would normally see out of the 2600 games, a nice controller scheme, and a sort of a megaman feel. The only criticism I have is that movement is way to fast. Even then, it didn't take that much away from the experience. 4 stars! Keep it up man!

  7. The main issue I've had is using too much CPU time with the pfread command to check for projectile <-> player collisions. At times I've gone over cycle with just 4 pfread commands in one game loop.


    Probably can mitigate this by checking only every other frame or more.

    Agreed. I had the same problem with my 3d tennis game.

  8. 1: It seems like the problem is that u used too many cycles not sure how to fix this but the way I fixed it was to alternate instructions into separate frames.


    2: I'm not quite sure on this one. I do know it's possible as they can be called to the score and output corrupted graphics.


    Ideally something that uses one hardware channel for one tone. The DATA statement could just hold the frequency of a single note. Bonus points if the music engine is smart enough to pick the closest tone that 2600 can actually generate :)


    It's accually based of randomterains bB music engine.

    • Like 1


    Sounds good for a title screen. I'm not sure if it will butt heads with space needed for playfield data and sprites. bB programmers will have to find out :)


    A single channel low CPU usage version would be amazing for in-game background music.


    You mean almost like how the multisprite kernel does it (using one channel to simulate two)? If that's the case it'll probably cost 8 (9 on sdata) variables.

  • Create New...