Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ScumSoft

Members
 View Profile  See their activity

  • Content Count

    415

  • Joined

  • Last visited

Posts posted by ScumSoft

  4. Posted

    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?

     

    • Thanks 1

  6. Posted · Edited by ScumSoft
    Update with Colors and typo fixes

    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

    • Like 1
    • Thanks 1

  10. Posted

    5 hours ago, Thomas Jentzsch said:

    The improved bouncing makes a big difference. 

    Yeah it worked out ok, didn't have to change much puzzle logic wise to compensate.

     

    2 hours ago, Karl G said:

    I also think the bouncing is an improvement, but I seem to have more trouble getting airborne in this version. Not sure if the difference is in my imagination, though.

    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!

  12. Posted

    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. Posted · Edited by ScumSoft

    4 hours ago, Thomas Jentzsch said:

    Sorry, but there will be (a bit) more. Your shape is not a square like in my example. I am currently experimenting with my code to make it work with more random sprites.

    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. Posted

    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.

  15. Posted · Edited by ScumSoft

    I've written this game in 99% pure bB, so your example would have to be adapted to that. I'm not opposed to assembler at all, just trying to stay in bB as an exercise of the language.

     

    Currently the variables are defined as 8.8's 

    Quote

        dim P0posX       = player0x.a
        dim P0posY       = player0y.b
        dim P0velX        = c.d
        dim P0velY        = e.f

     

    and the collision code is done simply as: (With SafeX and Y set when there is no collision happening)

    Quote

            P0velX = 0.0 - P0velX
            P0velY = 0.0 - P0velY
            player0x = SafeX
            player0y = SafeY

    I did not entirely understand what you were talking about, so could you explain in a bit more detail? It looks like from your example that this is a very elegant solution to the problem I have here.

     

  17. Posted · Edited by ScumSoft

    In the original 2011 builds there were no joystick/D-pad velocity adjustments so it was demanded from the player that you control the characters movement precisely, there was no room for sloppy control when the playfield would kill you on contact. This is akin to your game Thrust. 

    In my game the level geometry is very jagged and there are tight spots to fly through, so during initial design my family found it very frustrating to play and wanted it to not kill the player on contact.

    I initially added a health meter that would deplete on playfield contact before killing the player, but they didn't like that the playfield was sucking in the player due to the complicated collision code not reversing the players directions on hit. The first builds did have real world trajectory physics! but this lead to complications in collision detection, normally 2600 games have very flat surfaces which greatly simplifies the collision detection and/or prevention, something that was NOT easy to do in this games complex level geometry with its multiple collision points.

    After lots of testing and changes, the collision code was doing a much better job preventing the player from getting stuck, however this made the world VERY bouncy.

     

    I am still fine tuning it to not go so out of control, so that is still WIP and not final ;) I had added a few puzzle mechanics that make use of the bouncing, so if I get rid of it entirely or tone it down then those elements will have to be changed as well.

     

    I'll see what I can do to balance everything out, I want everyone to enjoy the game without it being too frustrating.

    Thanks for the feedback, it is greatly appreciated!

    • Like 1

  18. Posted

    7 hours ago, Thomas Jentzsch said:

    After playing myself and watching last night's ZPH show, I feel that I should add some feedback too.

     

    I really tried to play this update, but currently IMO it plays (much) worse than the old version. It looks great and promising, but the controls and the bouncing are totally killing it for me. And I am a great fan of gravity games.

     

    The playfield bouncing is just too much and also feels more like being inside a pinball than a real world. E.g. when I fly to the right and down and bounce at the bottom, I should bounce to left and up, not right and up. Also the bounce must not add energy but at least slightly reduce it.

     

    As much as I would have liked the game (lots of potential), currently it doesn't work for me at all. Sorry.

    I appreciate the feedback, this is why testing is very important. The level geometry does not simplify the collision detection and makes it much harder to deal with, the reverse bouncing is also part of the games puzzle mechanics and as stated in the first post "might" be required for the more advanced modes areas. However I do agree that it can get out of control and hard to recover from and this is something I am looking into tightening up, if the players wish to bounce on a trajectory off the floor that is something I can probably do without breaking some puzzle mechanics, however as it stands right now the old version would kill you on playfield collisions, I do not really understand how this was "better" as it was deemed too difficult?

     

    I will probably post a video showing how the mechanics are intended to work, but I also don't want there to be a massive learning curve involved with the game.

    Thanks for the feedback, in the upcoming updates things will be balanced and improved to avoid frustrating any players.

    • Like 1

  20. Posted · Edited by ScumSoft

    Not sure if this addresses your 2nd question directly:

    The template was made by me a long time ago, I don't know if it was updated after iesposta noticed an error in it.

    Batari Basic indexes the banks starting at 1 through 6, the template said that bank 6 was reserved for the graphics bank because I had indexed the banks starting from 0 back then. Bank 6 is in fact usable as it translates to bank 5 as SpiceWare posted above.

     

    So if your coding in ASM then DPC+ uses banks 0-5 for user code, bank 6 is reserved for the graphic data copies and fast fetcher access.

    In bB you have banks 1-6 for use, and bank 7 is the graphics bank.

    • Like 1

  23. Posted · Edited by ScumSoft

    Updated first post, the game is complete! demoted to Beta Feedback Version!

    Bumpity bump bump!

    Enjoy everyone, there is a strong possibility of a cartridge release provided that this plays properly on everyone's real hardware,

    so in the mean time I'll be optimizing the game and getting it to running 100%.

    • Like 2

  25. Posted

    On 11/12/2013 at 6:41 PM, iesposta said:

    Random Terrain,

    I just wanted to repeat this info, I don't know if you have it on your site or not.

     

    The older DPC+ template is wrong. Put temp1=temp1 in Bank 6. It is a whole bank, and not reserved for anything. (ScumSoft had his info wrong about that bank.)

    The next bank (after bank six) is used for graphics and sprites and colors. Those definitions and data for players, playfields and colors get copied to that bank.

    In other words, the Playfield defined in bank 2 and Playfield colors defined in bank 2 and sprites defined in bank 2 don't use any bank 2 space, they use space after bank 6.

     

    So your batari Basic DPC+ rom gets compiled to:

    Bank 1: batari Basic code (a few free bytes)

    Bank 2-6: Your game code

    Bank 7: Graphics bank (no user control)

    Bank 8: ARM code (no user control)

    Each bank is 4K

    8 Banks times 4K equals your 32K binary!

    I would have responded earlier but Hiatus ect...

    See Batari's original comment here of Bank 6
    We were indexing the banks from 0 in ASM back then, and Batari Basic indexed them from 1.  It became worse as I did lots of ASM work back then and my Bank6 was purely for graphic content...

    Sorry for the confusion, the template is for sure wrong and Bank 6 in bB is free for normal usage ;) in ASM however, Bank 6 is your bB Bank 7 and only for DPC+ prefetching usage.

     

    I hope this massive bump doesn't bother anyone, I feel bad for causing so much confusion with that template.

    Poor iesposta had to keep correcting it all over the place.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...