Jump to content

Search the Community

Showing results for tags 'Sprite Multiplexing'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type

Marker Groups

  • Members


  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion
  • The Homebrew Discussion's Topics


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Product Groups

  • Subscriptions

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 4 results

  1. Guest

    GTD: IV

    GTD STANDS FOR Goofy Tech Demo, by the way. So I wasn't real satisfied with the way things looked yesterday; so I decided to give up using the sprites for the player's bullets, and use the missiles instead. This means no crazy weird shapes/colors for bullets, plus it also means no background starfield. But, you can actually see your bullets, which I think is a little bit more important. Plus I figure I can use sprites for special weapons that move slower and might be easier to see. So, changes: -Using M0 and M1 for player bullets, each flickered at 30 Hz (when necessary) for 4 bullets on screen at once. To my surprise, happily, four bullets, at the speed they are moving, is plenty to fill the screen. -Collisions between bullets and enemies are working, though sometimes bullets appear to pass through enemies. I think it is sometimes because I need to jigger the horizontal comparison between bullet and enemy and sometimes it is because the bullets are moving 4-pixels at a time and possibly jump right over enemies without ever hitting them. -Collisions between the player's ship and enemies are working; currently it just kills the enemies. -Sometimes the screen jumps a bit; I assume because the collision detection routine takes too long. ss.bin Screenshot:
  2. Guest

    GTD: Number Three

    I KEEP TINKERING and tinkering with this two-sprite flicker engine. I'm not real enamored with it, but I'm having fun playing with it. I haven't drastically changed the kernel; despite my bold words, I haven't been able to make it work. But I was able to figure out a quick sorting method that does work with the flicker engine. It isn't perfect, but objects don't disappear and it is slightly better than a 1-sprite flicker engine. The sort returns results like this: For 3 objects: 123132123 For 4 objects: 1234134214231234etc. In all cases, the first two objects are shown, only. So the highest object is shown on all frames and the following objects are rotated, once per frame. It's a little more complicated than that, but that's the basic effect. And the sort is fairly fast, almost as fast as the flicker sort.The sorting algorithm is as follows: 1. Does this sprite have the same Y-value as the next sprite (in the list)? If so, swap them and move to the next sprite in the list, returning to 1. 2. Does the previous sprite overlap the the next sprite? If so, swap this sprite and the next sprite, move to the next sprite and return to 1. As Manuel noted, and I was expecting, processing all these sprites (flicker-sorting, moving, etc.) takes a *lot* of time. Too much time, actually. So I split things over two frames. The current 2FP (2-frame program ) goes a li'l something like this: Move Sprites Display Flickersort Display repeat. The next big step (BIG!) will be adding collision detection. A complete, brute force collision detection routine would take too long; impossibly long. To test each sprite (my engine supports 22 currently) against every other sprite to see if they overlap and have collided - ! Yeesh! What is that, 22! comparisons? Ouchie. I wasn't sure exactly how I was going to solve that problem, then it came to me: if I assume that the flickersort will have the sprites in rough order (if not now then perhaps soon, anyway!), then I can just test each sprite against the sprites that are near it in the list. And since I only need to test collisions between the player's ship and enemies and the player's bullets and enemies (but not bullet-to-bullet and not enemy-to-enemy), that will cut things down to a (hopefully) manageable level. So the final 2FP will look like this: Move Sprites Display Flickersort Check Collisions Display With other assorted game logic fit into the cracks. At least that's the hope.Anyway, here's the demo without collisions working: ss.bin (See below!)Hit SELECT to change weapons. Screenshot: EDIT: Got collisions working! Screen jumps rarely, I think. Flicker also becomes a bit intolerable, but that can probably be cleaned up somewhat by tweaking what happens when objects collide. ss.bin
  3. Guest

    Goofy Tech Demo...Applied!

    INITIALLY I WAS PRETTY disappointed with the goofy tech demo I wrote (see previous post). It was pretty tricky, and a fair amount of work, to get the kernel working. And in the end, it didn't look much better than if I had just multiplexed a single sprite! But I kept playing around with it and I think it might be useful afterall. Maybe. Here's a possible way...look at this demo. At first, a mild-mannered, kinda-weak-looking Demon Attack clone: But you hit the fire button and then! Demon Attack On Steroids! daos.bin EDIT: And you could probably work a halfway decent 1942 (or similar) port out of this engine. EDIT II: New binary; flicker improved somewhat. Turn P0 and P1 on and off to see the difference between this one and the other ROM. daos.bin EDIT III: New DAOS binary. This one, at least, couldn't be done without a sprite multi-plexor. IMO doesn't look real great, but oh well. daos.bin
  4. Guest

    Goofy Tech Demo

    HERE'S SOMETHING I've been working on...can't decide if I like it or not. r1k.bin Screenshot. Background color is different in screenshot. EDIT: New version attached. Has 24 sprites instead of the 16 previously. Also added more boundary checking and changed the movement routine. r1k.bin New screenshot. For some reason Stella hates this binary...??? Runs fine in z26 at a (95%) constant 262 scanlines, so I don't know what's up. I think it has something to do with the RIOT timer.EDIT II: New version attached, that works with Stella. Will eventually crash. Still 24 sprites (I think that's the limit of RAM) but some are different now. r1k.bin And screenshot:
  • Create New...