From mint-bounce@lists.fishpool.fi Mon May 31 10:27:58 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=oTs/p30k1/S/lGWgd+xri5z89dHJnzJW0WNWtYLpacQ=; b=QQ2b53qHGa4dLoFTXJ9RLcg2gZ0b8fhRJFTTfcdYKg17UvQbNBQ7ZGV9SROlyYdtXR BA3lPhXKovQKZ6bP9Pt39r5lGtJJkFIzOOwVYY33d7CpQAxroIR/pUMgwPczF32qCcQR +7CtLN/NYVtlUExrv/M3lQY52XV/Zl3lTRd2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=Ht0J1qLC+ISrypS37VqlU+o19Y0qU4HOivlXC3x+Qn0J4aCH5ueve4DkMxvX+i9Ii8 VgtrepfK4WM3kvq5DEiyHkoAN5Ym3siuGnkyFE22q61JFAMq/PIqnEsEC+y7WU609f+s sE8QnaPaVp5JBwtuHnjrGNgjHhnC7zQ/qujxQ= Subject: Re: [MiNT] Allocation of video RAM Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Peter Persson X-Priority: 3 In-Reply-To: <2B2620D5C3CC4FFB9D9BA58B5F048B2F@mercatus.local> Date: Mon, 31 May 2010 16:25:10 +0200 Message-Id: <4BC20831-B262-4555-B24E-D1E987F9BEBC@gmail.com> References: <4ACDF5FD-74ED-459F-8C45-A6124A3B0BF9@gmail.com> <2B2620D5C3CC4FFB9D9BA58B5F048B2F@mercatus.local> To: MiNT Mailing List X-Mailer: Apple Mail (2.1078) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: pep.fishmoose@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id o4VERwQj011380 31 maj 2010 kl. 15.54 skrev Jo Even Skarstein: > -------------------------------------------------- > From: "Peter Persson" > Sent: Monday, May 31, 2010 2:38 PM > To: "Jo Even Skarstein" > Cc: > Subject: Re: [MiNT] Allocation of video RAM > >> It's also important to accept the fact that many coders around does not want to use the VDI. They want a framebuffer >> that they can draw to directly, and they may want VRAM buffers for sprites etc. Trying to force these guys into using >> the VDI will only put them off, and it just won't happen. They'll chose another way to do things, or ignore the platform. >> If there is a clean alternative which still works with the way these coders work, that clean alternative will be used. > > 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 sprites from other offscreen bitmaps while taking advantage from any hardware acceleration provided by the VDI. 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? 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 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. -- PeP