Bob,
Thanks for your help this far.
— Bob Pendleton wrote:
If I can’t access the VRAM directly (which is the
hardware), what does it mean that SDL gives you a
HWSURFACE that allows you to “access the framebuffer
directly” What is the framebuffer, then?
Since you original statement was wrong, the conclusion is wrong. If you
asked for a hardware surface and got it, then you have a pointer into
some part of the framebuffer.
I was going on what someone in the mail list just told me - that you usually
don’t have access to VRAM. I should have replied to him by asking “in the
likely case that you don’t have access to VRAM”.
But, either way, the first part of the sentence is not a conclusion, because it
starts with an “if”. Secondly, that latter part is certainly not a conclusion
since I’m legitimately asking 2 questions. I think the questions seemed
rhetorical, but they weren’t. I was confused.
It might have been useful for me if someone answered with something like: “in
the case that you don’t have access to VRAM via SDL for whatever reason, then
it means you won’t get the HWSURFACE and won’t be drawing to the framebuffer -
which is a buffer in VRAM. Otherwise, you might be able to get a HWSURFACE
which means you’ll have access to a piece of the framebuffer in VRAM. However,
that does not gaurantee performance gain over using a software surface without
direct access to the framebuffer” This is my current understanding of the
situation, now having read more documentation, including, I think, your
article. =)
Just some
ordinary place in main memory that that is the
specified location that the CPU ships to the VRAM.
How is it any more efficient that using QT or GTK that
supposedly don’t access it directly?
There is really no question here. All of the above, GTK, QT, and SDL
have to work with the same restrictions and can be equally efficient or
inefficient depending on what you want to do. Also, while GTK and QT are
GUI toolkits, SDL is not.
Actually it seems I was asking if the framebuffer is just some place in main
memory. My current understanding is that it is not. It is in VRAM, and you
don’t have access to it via SDL in all configurations.
Another question I was asking is how, and implicitly asking if, SDL is performs
better than QT and GTK for animation.
By the way, I’m making a GUI for an application. I was originally thinking of
using QT but thought it was too big and complicated and that perhaps SDL could
perform better because of HW access, so I’m not making a GUI in SDL - which has
been fine, but I’m still open to warnings to turn back for whatever
reasons/experiences people have to offer.
Does it just
save you having to copy some buffer in main memory to
the specified area for the “framebuffer”, which is
also just in main memory? What’s the performace gain
of using SDL over QT or GTK?
Why would you believe their is one, or could be one?
I should have said, what, if any performance gains are there because of direct
frame buffer access. I thought there might be performance gains because of the
whole direct access to frame buffer thing, but I know there are many other
factors involved.
SDL makes some
kinds of programming much easier to do. GTK and QT make other kinds of
programming easy to do. So, from a human time point of view their
efficiency depends on the application you are trying to build. But, from
a hardware point of view, they all work through the same layers and all
face the same problems.
Wait, they work through the same layers? What do you mean by this? You don’t
mean they can access the framebuffer on VRAM directly, do you?
Also,
Double buffered requirs pushing anywhere near 2^10th
more data? Doesn’t doubling the buffer only account
for needing to push around only 2^1 more data?
Double buffering just means you have two (or more) buffers. Nothing
more, nothing less. There is really very little relationship between the
amount of data you have to push around to create a scene and the number
of buffers.
Ya, I was a little confused that someone said there would be more data to push
around because of this.
Don’t know that game, but there are two main ways 2D games get speed. 1)
the old games were written for very slow hardware and don’t take into
account actual time so they just naturally run faster on faster
hardware. 2) The visual speed of an object moving on the screen depends
on how far you move it on the screen from frame to frame, If I move it 1
pixel/frame at 100 fps it seems to move at the same visual speed as if I
were moving it at 10 pixels/frame at 10 fps. Both give a visual motion
of 100 pixels/second. Though the 10 fps animation may look rather
jerky…
Of course. However, I’ve seen seemingly smooth, visually fast-scrolling,
ancient games on ancient consoles, so I thought that getting the same
smoothness shouldn’t take up 90% of my CPU (70% for X, and 20% for the
application)
In well written games there is no relationship between visual
speed and the number of frames that are being drawn each second.
Isn’t that overstated? If you get too few frames a second, you might not even
see an event happen, or won’t see everything that happened, or at least
possibly have difficulty interpolating where there object should be at the
moment, etc… Besides, my objective is not to communicate the visual speed at
which an object should travel, but to actally make that object travel along
that trajectory in a smooth, easy to follow, nice-looking fashion.
Thanks,
Gary
-bob
Let me reiterate, you are drawing a lot of conclusions from false
premises. I know from experience that doing that will cause great
confusion.
Thanks for sharing the learning from your experiences,
Gary>
Bob Pendleton
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250