Jump to content

SmittyB

+AtariAge Subscriber
  • Posts

    861
  • Joined

  • Last visited

Posts posted by SmittyB

  1. To get the most action on screen with the fewest glitches and slowdowns I can manage I'm making a big effort to minimise the amount of objects used to build the background.

     

    In that gif everything is zone-aligned so doesn't need to be drawn twice, and it's all 160A to give MARIA more time to process the 160B ducks and dogs.

     

    The clouds and bushes are separate objects, but each section is only as wide as it needs to be, and the scrolling is done by updating the position of the existing objects rather than re-adding them to the display list each frame.

     

    Objects can't be as wide as the screen on the 7800 so the wall is 6 objects (2 halves across 3 zones), and the scrolling is achieved by reducing the width of the left half while increasing the width of the right half and shifting it across using the same method as the clouds. Once it gets far enough for the pattern to repeat it's all reset.

     

    The grass is also 6 objects (2 halves across 3 zones) but each zone has its own copy of the graphics in RAM. 6502 assembly conveniently has a 'rotate left' command for shifting multiple bytes of data, only in this case it's graphics data and by rotating a line twice to account for 2 bits per pixel it'll move that line. If I move some lines more than others I'll get the effect and all without MARIA having to do more work.

     

     

    I'm in the process of moving where these graphics sit in RAM to free up room for the player graphics alongside the ducks. The benefit is that when things aren't zone aligned I only have to draw 2 objects instead of 3 and it all adds up.

    • Like 4
  2. Just for you I've had a look to see what I might be able to do and this is what I've come up with on the mockup I use for testing ideas. By moving one of the greens from palette 0 to 2 I was able to give the clouds an extra colour for shading, and as the clouds and bushes share graphics it's improved both. I've adjusted the shades of green to allow the green player markers to stand out a bit more, and with 2 shades of green in palette 2 I was able to make a rough pattern that could be considered grass. In my old proof of concept version I had some brown areas that was intended to be the dirt the vegetables were grown in so I had a go at drawing some dirt mounds using the existing orangey palette but I'm not sure if I like them yet.

    image.thumb.png.cc870fe61277d3edfd9fedeb37eb28aa.png

    • Like 6
    • Thanks 2
  3. On 2/16/2024 at 6:29 AM, KrunchyTC said:

    Wondering if you plan to add a texture to the grass? Really tie the look of the game together :P

    It's something I've considered but I don't want to do it unless I can make it look right with the scrolling, not be too distracting, and I have to be very careful about the palettes I'm using.
    There are many plans, it's just that graphics have been a low priority for a while.

  4. If I had to guess I'd say somebody on the nomination committee is a trigger-happy duck-hater because Ducks Away has been nominated for an award in the 6th Annual Atari Homebrew Awards!

    Thanks again to the nomination committee, to James for all the unseen work it takes to make these awards happen, and to the AtariAge community for whom this game was made.

    Don't forget to don your stale bread-armour and dive to the polls before the deadline on the 18th of February.


    image.thumb.png.a09c54812e338eb4f9a07e35f25ede32.png

    • Like 11
  5. Awwww shucks it happened again. Plumb Luck DX has been nominated for another award in the 6th Annual Atari Homebrew Awards!
    Thanks again to the nomination committee, to James for all the unseen work it takes to make these awards happen, and to the AtariAge community for whom this game was made.

    However as the late, great Bruce Forsyth would say "You don't get anything for a pair, not in this game." so don't forget to vote for your favourite games in each category before the deadline on the 18th of February.

    image.thumb.png.6ed170ad949a2e1bc896b2adbf0536e2.png

    • Like 6
    • Thanks 1
  6. You both flatter me, thank you very much.

     

    As I define more waves it'll definitely get crazier. At the moment I have 20 defined that it just loops through and 99 is the current limit, so I do intend to balance things so that getting anything close to 99 is a challenge. I have to balance it so that anyone can play so the first few waves at least will be easy enough. There's also a limit to just how much chaos I can have on screen at once because potentially with 4 dogs the whole thing will slow to a crawl. At least it turns out 4 lightguns isn't unplayably flashy even if it is hard on the eyes.

  7. The 7800GD has the option to somewhat calibrate the gun on the NTSC version of Crossbow as part of its cheats functionality, but besides that no.

    The way most lightgun games on the 7800 work is by flashing the screen white and then using strict timing to calculate where on the X axis the gun is pointing. There's a limit to how accurate this method can be on a relatively slow system like the 7800 and there's a good chance the accuracy will depend on the specific console. It also doesn't help the developers hardcoded their own offsets into the game instead of allowing for manual adjustments.

    Best you can do is make sure the brightness / contrast of your TV is high enough for the gun to more easily see it, make sure the lens is clean, and sit as square-on to the TV as you can.

    • Thanks 1
  8. Detecting the QuadTari works so that if INPT0 is clear and INPT1 is set then it's plugged into the left port, and likewise if INPT2 is clear and INPT3 is set then it's plugged into the right port.
    Setting bit 7 of VBLANK to dump them to ground enables reading of controllers 3 and 4 so during normal gameplay that bit is toggled each frame.

    Unrelated to the QuadTari but I'm also toggling bit 6 of VBLANK during the gun's hit detection to latch the fire button as the light sensor is equivalent to a button press. The gun's trigger is equivalent to holding up when released, and releasing up when it's pulled. I auto-detect the presence of a lightgun by whether up is held shortly after the game starts. (James let me know to delay this a bit to give the Mega7800 time to kick in its appropriate mode).
    Oh and I'm disabling the 7800's 2 button mode as the first thing I do because that just breaks compatibility with every other controller and I'd love to know what GCC were thinking.

    • Like 1
    • Thanks 1
  9. Fair enough. The point still stands that the NES can't do anything close to SMB3 without extra help, though I was sure mappers are required somewhere for the scrolling to work hence only later games having multi-directional scrolling.

  10. The stock NES can only scroll left/right or up/down but never both together which is a big part of SMB3.

    I'm not sure if SMB splits the level into zones like SMW but the format wouldn't be too much of a blocker to scrolling left, but with the ability to break blocks moving left would require keeping track of the state of the level otherwise blocks, power-ups and enemies would respawn.

  11. 6 hours ago, christo930 said:

    While SMB was a very good game, it wasn't especially technically impressive.  SMB3 would be more impressive on the 7800.

    You might not be aware of how much of a compliment this is to the 7800.

     

    SMB actually is a very technically impressive game for the NES. It was specifically designed to push the NES / Famicom to its limits as a swan-song before all game production moved to the Famicom Disk System and apart from some simplistic graphics design it achieved that objective. The FDS ultimately wasn't as successful as Nintendo wanted and developers moved to using extra hardware on the cart in the form of mappers.

     

    Just about every NES game past its initial Western release including SMB3 relies heavily on that extra hardware and if you were to take SMB3 and strip it back to work on stock hardware you'd just end up with SMB1 again. You'd lose the 8-way scrolling, the music wouldn't have any of the drum samples, the HUD would need to be removed, the tile animation wouldn't work, the graphics would need to be reduced, and with a lack of extra RAM you'd need to limit gameplay to moving right again so as to not keep track of what the player has already done.

    • Like 4
  12. 12 minutes ago, SlidellMan said:

    Blake, will there be options to use the ST/Amiga Mouse and 7800 Trak-ball?

    I hadn't considered it but if I can make it work then I think that'll be a good idea. The difficulty will be in having a good way to select them as I don't know how I can auto-detect them like I can the light-gun, and I'll need to handle them separately so as to not break the QuadTari stuff when they're not in use.

    • Thanks 1
  13. 22 minutes ago, Trebor said:

    What does not work correctly?

    It works in that it'll register hits, but not necessarily where the cursor is pointing in my experience. It seems to register hits on what I assume would be the first target only.

  14. 1 minute ago, SlidellMan said:

    Coding that must not have been easy.

    Actually the hard part was adding QuadTari support when I don't have a QuadTari to test with. Fortunately I've had a lot of help in that regard. Once the code for one gun worked I could extrapolate that to the others just by keeping track of which gun pulled the trigger.

    The light-gun stuff itself was dead simple because I'm using 'target selection' where it'll flash hitboxes on screen and I only need to know if the gun saw something that frame, compared to the other method where the whole screen flashes and then strict timing is used to determine where the gun was pointing before running through a bunch of other logic to see if there was something at that position.
    In theory target selection is more accurate, but with all the action on screen there'll be a lot of flashing with 4 players.

     

    • Thanks 1
  15. DAIntro_231231_1524.gif.6fe61365ff2c3668134270a3e6287ca4.gif
    DAWave20_231231_1601.gif.699e27f29d3048036cd6adf0c757e34a.gif
     

    Ducks Away is the 7800's first light-gun compatible homebrew and one of a very few light-gun games in general to support 4 players (in this case via the QuadTari). You and up to 3 friends must defend your vegetable garden from the local ducks who have grown sick of stale bread. Use your popgun to shoot corks at the ducks, or play as the family dog and jump at them to scare them away.

    Note that A7800's light-gun emulation doesn't work correctly for Ducks Away.
    ~Controls~
    Intro:
    Pressing the button skips to the next section of the intro.

    Player Select Screen:
    Left / Right on a controller chooses whether to use the popgun via an onscreen cursor, play as a dog

    Fire button on a light-gun toggles playing as the popgun or not.
    When the timer runs out the game will start with the selected players

    Gameplay:
    Point and shoot with the light-gun as one would expect.
    Use the joystick to move the cursor around and shoot with the button.
    Left / Right move the dog, down barks (does nothing), and the button jumps. 

     

    ~TO DO LIST~

    • Add PAL colours.
    • Fix Rice in ground bug.
    • Fix 1 frame graphical glitch on Intro > Player Select transition.
    • Fix 1 frame graphical glitch on Player Select > Game transition.
    • Fix 1 frame graphical glitch on Light-gun Detection > Game transition.
    • Complete Intro Sequence.
    • Add intro skip for light-guns.
    • Add Music.
    • Improve Sound.
    • Animate Dog.
    • Add effect when bread-ducks' armour is shot.
    • Limit cursor to screen bounds.
    • Improve feel of cursor handling.
    • Improve feel of cursor hit detection.


    Play on JS7800

    DucksAway_231231_1549.a78

    • Like 21
  16. I don't have any code examples to give, but as a general overview for how I do things I'd keep track of the velocity of the player, then based on that velocity check a few specific points on the player to check for collisions in that direction. If they hit something then move them to a valid position and zero out their velocity on that axis.
     

    1. Update player based on their current velocity
      1. PlayerX = PlayerX+PlayerXVelocity
      2. PlayerY = PlayerY+PlayerYVelocity
    2. Apply typical physics stuff
      1. PlayerYVelocity = PlayerYVelocity+Gravity
      2. If PlayerYVelocity >0 then PlayerYVelocity=PlayerYVelocity-Friction (or whatever gets it to zero)
      3. If PlayerYVelocity <0 then PlayerYVelocity=PlayerYVelocity+Friction (or whatever gets it to zero)
    3. Do controls
      1. Left = decrease X velocity
      2. Right = increase X velocity
      3. Jump = set negative Y velocity (only if a flag states they can jump)
    4. Do collision (Might want to add extra checks so there's no gap between points that a block could fit in)
      1. If X velocity negative check collision on left side of player
        1. Compare upper left, middle left, and lower left coordinates of the player against the level. If any touch a block then reset X velocity to zero.
      2. If X velocity positive check collision on right side of player
        1. Compare upper right, middle right, and lower right coordinates of the player against the level. If any touch a block then reset X velocity to zero.
      3. If Y velocity negative check collision on upper side of player
        1. Compare upper left, upper middle, and upper right coordinates of the player against the level. If any touch a block then reset Y velocity to zero.
      4. If Y velocity positive check collision on lower side of player
        1. Compare lower left, lower middle, and lower right coordinates of the player against the level. If any touch a block then reset Y velocity to zero then set the flag to enable jumping; if no collision then clear the flag.
×
×
  • Create New...