|
|
> The GPU will read the 9 MB of pixel data from one location,
> then write
> it to another location, therefore using 18 MB of bandwidth.
Oh, so you were already assuming the surface was on video memory? Because I was
thinking it was going from RAM to vRAM. hence much slower.
> I really need to clean that junk up. :-)
huahahahaha
> I'm not sure I see what you mean... You want to
> minimize the amount
> copied? If stuff is in video memory, using the hardware
yep.
> blitter to
> copy everything without bothering to optimize might
> actually be
> faster, as it is fewer commands than the detailed
> "instructions" that
> would be necessary to optimize that. Even when doing it in
i dont know.. after all each blit, on the lower level, is actually repeating
memory copies for each pixel(assuming a 32 bit depth on a 32bit machine). so
the fewer pixels the better.
> main memory
> with the CPU, your code being simpler and having fewer
> branches might
> compensate for the speed gain of doing it optimally, too.
>
> But, again, I'm not sure I understand what you meant.
actually it would have the same number of branches (if i understood correctly
what you mean), when I do dirty rectangles i have to copy the BG, and then blit
it on the previous position of the moving sprite. Then I blit the actual sprite
at the new position. This last blit is already colorkeyed(otherwise I would
blit only the sides that moved and exposed the BG, like I said previously), the
idea is to do the same with the first blit. :)
The catch though is that its a little trickier, because i would have to use a
'negative mask' of the sprite... and the way im seeing with SDL, i would need
an actual blit of the whole BG rect to a new surface, then paste the mask to
it, and only then pass it to the video card... and though this can save data
going to the card, it could be done in a direct blit if I could 'modify' the
colorkey code of SDL, and use the 'negative mask' at the AND phase.. SDL could
have a blit with a mask parameter :)
Cheers,
AM.
--- Em fri, 30/1/09, Pierre Phaneuf <pphaneuf@xxxxxxxxx> escreveu:
> De: Pierre Phaneuf <pphaneuf@xxxxxxxxx>
> Assunto: Re: [SDL] DirectAccess to Video Memory [was: Hello, new member
> reporting]
> Para: "A list for developers using the SDL library. (includes SDL-announce)"
> <sdl@xxxxxxxxxxxxxxxx>
> Data: Sexta-feira, 30 de Janeiro de 2009, 22:33
> On Fri, Jan 30, 2009 at 4:38 PM, Antonio Marcos
> <amcmr2003@xxxxxxxxxxxx> wrote:
>
> > I still dont get why I need 18MB bandwidth for 9MB..
> :)
>
> The GPU will read the 9 MB of pixel data from one location,
> then write
> it to another location, therefore using 18 MB of bandwidth.
>
> > now that I know what SDL_Flip really does, I agree :)
> But the idea was just to change the pointer, So what I would
> actually do is update the portion of the screen that would
> be seen next, and scroll the "camera" there. The
> changes could be very small actually.
>
> Yeah, I remember some pinball games that did that for DOS,
> and I did
> do some game development on DOS, back in the days. In fact,
> in my main
> game project, Quadra, you can still see some
> "need_paint = 2" being
> set in some Zone objects (an object that represent an area
> on the
> screen, used for widgets and things like that) when
> they're updated...
> The reason is of course that we need to used to do
> double-buffering
> with page-flipping, using DirectX and Svgalib at the time
> (we started
> right about at the same time as SDL, so we made our own
> abstraction
> library at the time, good times!), so when a button
> changed, we needed
> to update it in both buffers.
>
> I really need to clean that junk up. :-)
>
> > I had a new idea considering dirty rectangles.. When I
> have colorkeyed sprited (most of them), or even
> alpha-enabled (though not that much), I cant just copy and
> paste the sides of the rect(tipically 2 rects per sprite), I
> would like to use a "negative mask" to read from
> the background and then paste on the new position. Im sure
> it would be able to use RLE acceleration (though i dont know
> how it works). Any thoughts?
>
> I'm not sure I see what you mean... You want to
> minimize the amount
> copied? If stuff is in video memory, using the hardware
> blitter to
> copy everything without bothering to optimize might
> actually be
> faster, as it is fewer commands than the detailed
> "instructions" that
> would be necessary to optimize that. Even when doing it in
> main memory
> with the CPU, your code being simpler and having fewer
> branches might
> compensate for the speed gain of doing it optimally, too.
>
> But, again, I'm not sure I understand what you meant.
>
> --
> http://pphaneuf.livejournal.com/
> _______________________________________________
> SDL mailing list
> SDL@xxxxxxxxxxxxxxxx
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
_______________________________________________
SDL mailing list
SDL@xxxxxxxxxxxxxxxx
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
|
|