Wrong tag in simplebuffer?

[timfel]

Simplebuffer has the same VPM ID as scrollbuffer. That means I cannot look one up. Is that intended?

https://github.com/AmigaPorts/ACE/blob/7f82b9995ec0aa306a67744bf7b0c9fb1bfa88de/src/ace/managers/viewport/simplebuffer.c#L154

[tehKaiN]

I kinda wrongly named that - it should be a category instead of ID. My idea was that each vport manager falls into specific category which enforces order of processing and you shouldn't have two managers of same category on single vport.

Do you need to query in runtime whether you have simplebuffer or scrollbuffer?

[timfel]

I'm building a new buffer manager based around simplebuffer instead of a scrollbuffer, and I was taking inspiration from the tilebuffer and how it wraps a scrollbuffer. The way it is I guess I cannot actually query if a simplebuffer is already there, right?

[tehKaiN]

yeah, you should construct a simplebuffer with your manager, I guess - same as tilebuffer constructs scrollbuffer. What's your plan / intended principle of operation? perhaps I can suggest something better.

[timfel]

The plan is to have a tilemap display driven entirely by the copper. A bit like a char display on a c64, where I would just modify one byte, and the entire bitmap for that manager is redrawn on the next frame without CPU, driven by the copper.

[tehKaiN]

Whoa, good luck with that! I don't think it'll work though - copper will eat some chip bus bandwidth and I don't think you can redraw the whole screen each frame, especially when doing small tile-sized blits - unless you target 25fps or something. Unless you want to do some selective redraws, but I guess that's gonna take more than one change on the copperlist data. Looking forward to your results, I'm a bit puzzled, but very interested. :)

I guess you should use your own VPM which is higher than simple buffer's VPM in order for your things to work after processing of simplebuffer. If you want to do it otherwise, you can multiply ACE's VPM categories by 10 or something so that there are spaces between them and inject your VPM with lower category than simplebuffer's. If that's the case, I'll of course accept the PR with changed VPM values. The other option is to create simplebuffer with your VPM and process it manually in your process fn.

[timfel]

Whoa, good luck with that! I don't think it'll work though - copper will eat some chip bus bandwidth and I don't think you can redraw the whole screen each frame, especially when doing small tile-sized blits - unless you target 25fps or something. Unless you want to do some selective redraws, but I guess that's gonna take more than one change on the copperlist data. Looking forward to your results, I'm a bit puzzled, but very interested. :)

Yeah, I'm going to cut the fps in half. I just don't see any other way, I need to be able to redraw the entire map screen in a single frame (when you click anywhere on the minimap, all tiles need to be redrawn and then all the moving units on top also).

The alternative I considered was to have the entire bitmap be in memory, but that's 512k for a 4 bitplane map, more than I am willing to give up. I found some code on abime that does the copper driven blit and claims to be able to redraw an entire screen of 20x16 16px tiles at 60fps. That means if I accept halved framerate, I'll have one frame for the entire map draw, and one frame for unit and UI drawing.

[tehKaiN]

or you can just assume that clicking on minimap is so rare that you can just busy-redraw screen in this case and noone will notice. Still, 25fps for strategy game is not that bad, I think.

[timfel]

Well, I've been playing with it a bit, and on an empty map the tilebuffer is already too slow for my taste even when I'm just using the arrow keys ;) I had to slow the camera down to 4px per frame to get diagonal redraw to be fast enough, and that feels very slow to me :)