ACE
ACE copied to clipboard
AmigaPorts
Sprite view manager?
On Amiga hardware, sprites are each a continuous DMA with an individual line of pixels separating each "window" of graphics data. During that separator, the chipset fetches the next location vertically and at what horizontal offset. Effectively, each window of displayable pixels is an interleaved 2-bitplane screen. Would it be an effective use of sprite and blitter hardware to treat the sprites like narrow screens?
Sometimes blitting text to a sprite makes side-bars easy as a HUD on vertical scroller games. It's also an easy way to get around the one-viewport-horizontally limit of the View Manager. Likewise, using the blitter to do the copying to the sprite DMA is much more efficient than the way the OS likes to use the CPU to do it.
The downside I see to this approach is that dealing with horizontally stacked sprites and 4-bit-depth 15-color sprites combining 2 DMA channels, could result in weird clipping requirements with multiple blits necessary to resolve one window of display.
Yes, I was thinking about something like this too, not sure if/how it should be implemented as vport manager, but I'm open to suggestions. Perhaps in same layer-ish way as double playfield stuff, since one could use it in many ways:
- as single, sole viewport
- as layer on top of other viewport using sprite transparency
the first case is a second one with background viewport layer disabled. And also regarding size and depth:
- no-repeats, 8x16 = up to 128px wide screen with clunky 3bpp palette
- with repeats using Copper, AFAIR one can repeat a sprite using 2 8px-wide copper instructions, it will surely fail in 5bpp screens when copper slows down to 12-px per instruction
- with repeats with stacked sprites in 4bpp mode - AFAIR you need 4 instructions to reset sprite, so you can't regenerate all sprites in time - during display of 4 4bpp sprites you can reposition 2 of them, then another one and that's all - gives you 112px wide continuous display
- also one may want to do two HUDs - one on left, one on right - this allows for dual 64px-wide 4bpp bars, provided there is enough space between them for copper to reset sprite hardware
so many possibilities. ;)
ACE generally gets it's features when they are needed for games greating using it - first it is game-specific code, then it gets generalized. So If you need such feature in your game/app/demo, tell me exactly what you need for your use case, and we'll think about how to do it. When it's done it could become a part of ACE... or not, if it can't be generalized easily - then we'll try to write convenience functions to easily recreate similar effects in the future.
Sprite layers with copper repeats are very sensitive to DMA usage. I'm not sure it can be easily abstracted into an engine unless the game developer really knows what they are doing, eg. using simple mode for the copper manager instead of blocks mode. Making things more complicated is that the sprites are wider on AGA and typically use scan-double hardware abuse to display sprites twice per row instead of the copper.
When I was talking about stacking sprites it was to get 32-pixel wide images or more by moving sprites side-by-side. I think these should be abstracted because in the future we could be using wide AGA sprites with the same engine. We would not want to use up all of our sprites on just one wide image when using AGA.
What I've been able to do with the OS is transplant pointers from an AGA simple sprite into a bitmap structure, open an Intuition screen using the same memory buffer and draw to it using the Graphics.library RastPort structure. This allows me to blit to a sprite but is not ideal for non-OS code and is cumbersome as well because you also have to manually remove the resultant screen from the Intuition screen list. It works as a sidebar screen though.
Another use case I had in mind was bullets being sprites in a shoot-em-up game and all being identical to one another. Having to blit them manually to the sprite DMA with the CPU as the OS would require is out of the question on a 68000. Blitting to each sprite DMA "window" using the actual blitter is much easier and might be able to take advantage of some sort of "multi-blit" operation for batch rendering so that most of the registers on the blitter wouldn't change between blits.
As is often the case, have other use-cases besides games such as movable tool-bars for editors and so-forth but you get the idea. As a mind-bender, you could even have BOBs blitted onto a sidebar screen made from a sprite but that's a mere academic exercise with little use in real-world applications.
As far as setting it up reusably, I'd use something like a block mode for the sprite images with the coordinates of the control word set in the header of the block. Maybe having a separate sprite port manager for each DMA would be handiest because of the priority of overlapping sprites sometimes has importance that the OS routines don't consider.
There may be a second layer of routines for handling the horizontal stacking and 15 color blitting on top of the first. The 15 color depth can be done with custom blitting routines for convenience of having 2 interleaved blits. A bitmap structure to wrap the image might be handy for blitting routines but stacking multiple images horizontally would be more difficult and would require multiple blits with different clipping rectangles for each. Maybe a custom blitting routine could factor in for that also because the blit modulo registers would be the same width for each sprite in the horizontal stack.
Yep, I get the idea. For me this problem is waaay too big to take care of in a single try, so I'm all for doing it iteratively.
- let's come up with one, simple use case (the one most needed/attractive atm), code it in and refactor existing code base until it works
- then, add another use case and we'll see how we need to refactor existing code to make it work
- then another, etc.
Perhaps we'll be able to make a single manager for all of it, or we'll end up with mutually exclusive managers. Can't predict atm how it's gonna look codewise. That's how whole ACE got written to this point. I'm not good at long-term planning. ;)
For me the code should be as thin as possible - Amiga knowledge should still be a must (that's the most fun part of it!), so I'd not do it too failproof. This also reduces the footprint and code bloat, which makes it usable even on unexpanded hardware.
AGA is unfortunately at the end of my list since I don't own any AGA machine, and I only write games for hardware which I have. But it's nice to have someone onboard who cares about it! This way we can work on some kind of true support for it, not just workarounds to make engine work.
I think we have 2 issues mixed together here: sprite manager and blitter batch rendering.
Sprite DMA can be set up as a set of bitfields for each header to set the coordinates and height of the image. The function that generates the header can return a pointer to a bitmap structure for that image. Double zeroes terminate the stream. Simple, thin abstraction of the sprite hardware.