Jump to content

Pat Brady

+AtariAge Subscriber
  • Content Count

    202
  • Joined

  • Last visited

Community Reputation

306 Excellent

1 Follower

About Pat Brady

  • Rank
    Chopper Commander

Profile Information

  • Custom Status
    formerly bizarrostormy
  • Location
    Madison, WI, USA

Recent Profile Visitors

3,758 profile views
  1. Sounds great! So how does it work? Is that an RMT or LZSS player for the 7800? I thought RMT supported sub-frame timing, which I thought would be tricky on the 7800 due to the unpredictability of MARIA commandeering the bus, but I could be wrong on any of that.
  2. How do you do that? You may remember that I worked on a routine for per-pixel collision detection between two arbitrary sprites but it consumed a lot of SALLY cycles.
  3. It looks like using direct mode for everything solves your problem, so my apologies for complicating things. If you're curious about those terms: DMA is how MARIA, the 7800's graphics chip, reads the graphics headers and data from memory. DMA holes have to do with how MARIA reads objects that are not aligned to zones — a DMA hole is an area in the same zone as an object but above the top or below the bottom of the object.
  4. Check out Appendix 3 of the Software Guide, if you haven't already.
  5. I totally agree with this! I am sort of baffled by 320C's bad reputation. It is really very similar to overlaid 320A, but with more colors and less DMA cost.
  6. OK, I will continue with it, hope to find time tomorrow to finish it. EDIT: I got it to a point where it can be tested. One of the routines works correctly, the other doesn't. I will sort that out.
  7. Right, need to do those POKEY labels and also the code that uses them. I don't see any STIMER — is that the same as RANDOM? The real problem is that the .a78 header format does not currently support dual-POKEY. It supports [email protected] and [email protected], but even if we enable both, I doubt a7800 or Dragonfly will treat those as separate POKEY chips. I know some single-POKEY games blindly write to both sets of addresses for maximum compatibility. @RevEng any thoughts?
  8. Sounds great! I think the easiest way to merge the players is replace all of the labels (both definitions and references) with specialized labels and update the main loop to call both players. Not beautiful or space-efficient, but that's okay for a gameless audio player. I can take a stab at that if you want.
  9. Even aside from development effort, DMA time is already an issue, so I don't think 320 is in the cards without cutting back drastically on the number of objects on screen, and also reducing the colors. IMO Darryl has wrought a fantastic balance of sprite size, colors, and number of objects. His original sprites, if you study them pixel-by-pixel, are indeed pretty busy, but overall they convey the essence of the characters. The new one-eye Brutus is definitely cleaner, and makes it more clear what each pixel represents, but to me he looks less angry. Your 320 sprites do look great, though. These are overlaid 320A? When I experimented with overlaid 320A, drawn pixels in my upper layers obscured their "companion" pixels in lower layers. In other words, transparency only works when both pixels of a pair are 0, as described in the Software Guide, though that document is not clear whether that applies for 320A. (With this limitation, 320C is almost always preferable to overlaid 320A IMO.) But in your Brutus sprite, I see beige-brown-beige, and also beige-purple directly above purple-beige. How do you get per-pixel transparency?
  10. I've been enjoying your lists. Doesn't seem spammy to me at all.
  11. Here is a routine that works on 2 objects of the same size, either both 1 byte or both 2 bytes. It's mostly useful for checking 2 sprites (as opposed to playfield; it does not care what DMA mode is used to draw either object). This turns out to be less processing work, because it only needs to compare 1 sprite to 1 other sprite, whereas checking a sprite against an indirect-mode playfield usually requires comparing the sprite to 2 playfield characters per line, plus logic at the zone crossing. I calculate this takes about 1500 cycles worst case for objects 8 pixels wide and 16 pixels tall. Still totally untested. My next task is to write up a small demo. But I wanted to go ahead and share the code. collisioncheckeachpixelsprites.s
  12. No. Update: The code I posted recalculated the vertical offset every line and used a very slow shift loop. Better to just decrement addresses and use a lookup table. I have a version that is under 3000 cycles, but think I can get it faster still.
  13. OK, the code I posted earlier had some massive inefficiencies. I think I can get it down to below 3000 cycles for a 16-pixel-tall, 2-byte-wide sprite, regardless of alignment. That's still expensive but possibly usable in some games. I'm ironing out the kinks, but probably finished for the night.
  14. I agree, this is an improvement.
  15. Indeed, although I think real games can achieve perfection more affordably than this fully general routine. (And looking back over the code, it can definitely be made faster.) Overkill for your needs, and also for everyone else's. When I started I knew it would be expensive, but I didn't know it would be that expensive. Another thought: many objects are solid, and for most that do have gaps, the gaps don't matter for collision detection. So we could store (or calculate) the boundaries per line, then check collisions on those. I think this would be general but much faster than comparing pixels. I'll take a stab at that tonight.
×
×
  • Create New...