Re: [MiNT] Allocation of video RAM

[Johan Klockars <johan@klockars.net>]

>> Well, the advantage of offscreen bitmaps is that you can either write directly to it or have the VDI draw to it. So you can use both. You can allocate an offscreen bitmap at the size and pixel layout of the physical screen, and then point physbase to this bitmap. Then you
can draw directly to the screen legally, and even combine it with
using the VDI to blit

Coming from the Eclipse/RageII side, I'm very much biased against any
kind of direct drawing to the screen. There it is at best frowned upon
(and _slow), and at worst a recipe for disaster (as in infinite bus
errors).

Still, I certainly understand that some people want to do it.

> sprites from other offscreen bitmaps while taking advantage from any hardware acceleration provided by the VDI.

Quite so. I hope no one is arguing for making the lineA "blit"
functions usable on graphics cards? On the other hand, better blit
facilities in the VDI would be very welcome.

> I don't think one rules out the other. TOS/FreeMiNT does have a layered structure, and I can't see why one should break that approach if it isn't for a very good reason. Maybe I'm completely lost, but does it really make sense to implement low level functions in a higher level API such as the VDI?

In my opinion, having the VDI take care of it makes sense. The default
could then be that the VDI has exclusive access to the entire screen
(After all, no one else even knows that there is any memory there
until someone configures the video card, and that would normally be
the VDI.). It could then allow applications to get their own slices
when asked for.

Obviously, the VDI should do the memory mapping by calling lower level
functions, though.

> Does fVDI have a built-in memory allocator? I've been browsing the sources for a while, and I can't find it (maybe it's too obvious and I've missed it).

If you are talking about general memory allocation, I use a pool
allocator and a wrapper around Mxalloc(). On the RageII I have some
very rudimentary stuff, mostly for caching icons and menu/dialog
backgrounds, nothing generic and not usable explicitly.

>> If someone wants to use VRAM for sprite buffers, can they take advantage of fast VRAM->VRAM blits without writing directly to the hardware or use some sort of driver (VDI)?
>
> No of course they'll need driver functionality or some easy to use API for that, and that may very well be the VDI. But the VDI does afaik not cater for texture mapping, or even alpha blits.

But we definitely should add at least the latter. Perhaps we already
did in ARAnyM, since we have that beautiful anti-aliased text drawing
there, I don't recall.

Texture mapping could perhaps be made to fit into the VDI, but I have
not looked at OpenGL etc much beyond what's used to draw 2D in ARAnyM.
Aren't those things usually handled completely outside the 2D API's,
though (perhaps with the 2D as a higher level layer)?

/Johan