Sprites, BOBs and MOBs on the MEGA65

Quote from atomcode

Sorry, but I don't really like 3D stuff on 8-bit machines. I would rather see a demo that shows how many software sprites (e.g. 8x8 and 16x16) you can move smoothly - with C65 and with M65.

Something like this ?

One problem I have to solve for myself with watching threads, is that I don't get automatic notification of posts on threads I have not previously answered. Perhaps someone with more F64 wizarding experience can show me how to fix this...

But back to text bobs on the MEGA65 using the raster rewrite buffer (needs a shorter name ;), you can set the X position on a pixel by pixel basis, so you don't have the 8-pixel jumps like on VIC-II/VIC-III text mode. The only thing it can't currently do is smooth Y positioning, because it requires a row of text to span multiple screen rows, which would require more than one line of raster buffer, which we don't (and won't) have.

Otherwise, it is always a joy to see how even disagreements are generally nicely and politely handled here on F64. It's much better than the "you looked at me strange!" <fist fight follows> <escallation to strategic nuclear weapons> <release the clone armies!> <put wax lips on giant yak> <take many armed statue> <deploy chemical weapons> sequence that typically happens on some of the other C64 forum platforms.

LG

Paul

Quote from adtbm

Something like this ?

By the way. This owl is the playersprite from the Amiga-game "Agony". The animation-steps also seems to be the same.

Just wanted to make a quick note about that, because i find it interesting, seeing this Amiga-sprite animated on the M65.

Yes, it's a 15 color Sprite and tbh it's made out of 2 Sprites

It would be lovely to get it on the DevKit.

Quote from mega65

One problem I have to solve for myself with watching threads, is that I don't get automatic notification of posts on threads I have not previously answered. Perhaps someone with more F64 wizarding experience can show me how to fix this...

Hi Paul,

You need to subscribe ("abonnieren") a thread, which you wish to receive notifications on new postings:

Once inside the thread, choose on the following menu icons:

pasted-from-clipboard.png

So, back to BOBs, Sprites and strategies:

1. MEGA65 has only 8 hardware sprites, but they can be bigger and more colourful, so you often need only one for a thing.

2. You can HORIZONTALLY multiplex sprites on the MEGA65, because the sprites use a ring buffer instead of shift register, and because at 40MHz you can race the gun more effectively. Each CPU cycle is only 2/3 of a display pixel wide. There is a raster X position register so you can know where you are. This can potentially be used to multiply bullets etc.

3. The Raster Rewrite Buffer is VERY powerful, once you get the hang of it. You can keep on drawing characters over the top of a raster line, for as long as the VIC-IV has spare cycles on the raster line. At 320x200 you have many more spare cycles than used ones. You can probably overlay something like 600 pixels wide of stuff in a 320H mode. As the re-write happens will pixel level control over the horizontal position, so the layers can smoothly scroll over each other -- all without wasting a cycle of CPU power, or requiring any extra memory to hold the composited values in.

4. Sprites take a surprising amount of hardware in the MEGA65, partly because of the extra features, and partly just because each sprite requires data plumbing, and adds a stage to the video pipeline. I could probably optimise it somewhat, but I also worry that if we have too many sprites, then there is no challenge left.

LG

Paul.

Quote from mega65

4. Sprites take a surprising amount of hardware in the MEGA65, partly because of the extra features, and partly just because each sprite requires data plumbing, and adds a stage to the video pipeline. I could probably optimise it somewhat, but I also worry that if we have too many sprites, then there is no challenge left.

As far as I remember, even VIC-II has something like 2/3 or so silicon area for sprites of VIC-II die ...

Yes, it does. Partly just having all the registers for the sprite pixels, and also the logic to load and manipulate them.

Paul.

Bit of a necro but I don't think this question is big enough for it's own thread...

Is there currently any way to put sprites BETWEEN raster-rewrite pseudo layers or will we be last ninja 3-ing it? (Or using other sprites to achieve the effect, the large single coloured ones I forsee being super useful for this purpose ...or just drawing 'em with the raster rewrite buffer itself)

There is currently no way to put the sprites between layers. The trick is that the raster buffer indicates only if each pixel is foreground or background, as there is only one bit per pixel available for that. What we might be able to do, is to have some flag to mark all pixels in char as background or foreground, so that you can selectively set this for the layers to get the desired effects.

In the meantime, you might be able to use tricks like the fact that the presense of a sprite at a given pixel allows switching the palette that the normal graphics uses there. By careful palette construction, you could create the illusion of a sprite between layers.

Like on the C64, there is a lot you can do without thinking hard, but plenty of effects that will require a lot of thought to pull off.

LG

Paul.

Quote from LGB-Z

As far as I remember, even VIC-II has something like 2/3 or so silicon area for sprites of VIC-II die ...

That makes you wonder how the Nintendo NES achieved 64 hardware sprites in 1983. It does have the limit of max 8 sprites visible per rasterline - but it still has to handle sorting and multiplexing for all 64 on top of the rendering.

Yes, there are ways to do it. NES sprites are tile based, IIRC, and probably loads the sprite coordinate info in from memory, rather than requiring on-die registers, as that would take much less die space then.

LG

Paul.

... yes, that's how the NES does it:

https://wiki.nesdev.com/w/index.php/PPU_sprite_evaluation

One day, we could make an automatic sprite multiplexor for the VIC-IV that loads the sprite registers with the correct magic values based on a larger set of sprites. But I don't think its needed.

LG

Paul.

The mouse pointer of the sprite (e.g. MOUSE ON 1,1) is always in foreground color black. No matter which colors are assigned to the sprite. At least under XEMU.

I hope this problem is not also with the mega65.

Has anyone ever tried this.

In the 320*200 graphics mode of the mega65 (screen def 1,0,0,2) you cannot display sprites at the same time. In other resolutions it works fine. (ROM 911210) Does anyone know the cause?

LG

Udo

I've forwarded you question.

Thanks !

OK, we've discussed this and the most reasonable answer why it doesn't work:

I quote Bit Shifter :

"The problem with the 911210 ROM is, that it has a dangerous memory layout.

Graphics memory overlaps BASIC program memory and variable and string space.
So dependent from program size, variable usage and graphics memory, strange effects may happen.
Using sprites is there only safe in text mode.
The unpatched 91xxxx ROMs restricted BASIC and variable memory to 24K each, in order to separate them from graphics memory,
but the 911210 expands into the upper 64K of the banks, which is used for graphics."

So this problem should be fixed with the MEGA65 92xxxx ROMs.