I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scope
Do I need to #include something (beyond SDL.h) to use these?
I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scopeDo I need to #include something (beyond SDL.h) to use these?
Those isn’t in “plain” SDL - but check out
http://www.libsdl.org/cgi/docwiki.cgi/Pixel_Access
for an example implementation and comments.On Thu, 02 Apr 2009 09:41:30 -0500 Michael Sullivan wrote:
–
Andreas Ronnquist <andreas.ronnquist at meritkonsult.se>
So I need to explicity implement them? (Copy and paste the code on the
page into my code) I don’t see any #include lines on the page you sent
me.On Thu, 2009-04-02 at 17:11 +0200, Andreas Ronnquist wrote:
On Thu, 02 Apr 2009 09:41:30 -0500 Michael Sullivan <@Michael_Sullivan> wrote:
I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scopeDo I need to #include something (beyond SDL.h) to use these?
Those isn’t in “plain” SDL - but check out
http://www.libsdl.org/cgi/docwiki.cgi/Pixel_Access
for an example implementation and comments.
I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scopeDo I need to #include something (beyond SDL.h) to use these?
Those isn’t in “plain” SDL - but check out
http://www.libsdl.org/cgi/docwiki.cgi/Pixel_Access
for an example implementation and comments.
So I need to explicity implement them? (Copy and paste the code on the
page into my code) I don’t see any #include lines on the page you sent
me.
Yes. I guess one reason for these not being availible in SDL is that
the implementation requirement might vary quite a bit - some
implementations require clipping rectangle checking while others don’t,
and sometimes you might know how many bytes per pixel you are putting
beforehand. And of course, many times you don’t need it at all in a
program - you just use the image loading / font loading functionality
to get all the graphics you require and are satisfied with that.
Anyway, hope I have shed some light on the mystery.On Thu, 02 Apr 2009 10:14:52 -0500 Michael Sullivan wrote:
On Thu, 2009-04-02 at 17:11 +0200, Andreas Ronnquist wrote:
On Thu, 02 Apr 2009 09:41:30 -0500 Michael Sullivan wrote:
–
Andreas Ronnquist <andreas.ronnquist at meritkonsult.se>
Doesn’t the SDL 1.3 API include something like this? They would
probably have SDL_ prepended to them.? Anyhow, if you need it or
you’re using SDL 1.2, check out Sprig or SDL_gfx:
code.bluedinosaurs.com/SPriG.html
www.ferzkopp.net/Software/SDL_gfx-2.0
Jonny DOn Thu, Apr 2, 2009 at 11:32 AM, Andreas Ronnquist <andreas.ronnquist at meritkonsult.se> wrote:
On Thu, 02 Apr 2009 10:14:52 -0500 Michael Sullivan wrote:
On Thu, 2009-04-02 at 17:11 +0200, Andreas Ronnquist wrote:
On Thu, 02 Apr 2009 09:41:30 -0500 Michael Sullivan wrote:
I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scopeDo I need to #include something (beyond SDL.h) to use these?
Those isn’t in “plain” SDL - but check out
http://www.libsdl.org/cgi/docwiki.cgi/Pixel_Access
for an example implementation and comments.
So I need to explicity implement them? ?(Copy and paste the code on the
page into my code) ?I don’t see any #include lines on the page you sent
me.Yes. I guess one reason for these not being availible in SDL is that
the implementation requirement might vary quite a bit - some
implementations require clipping rectangle checking while others don’t,
and sometimes you might know how many bytes per pixel you are putting
beforehand. And of course, many times you don’t need it at all in a
program - you just use the image loading / font loading functionality
to get all the graphics you require and are satisfied with that.Anyway, hope I have shed some light on the mystery.
–
Andreas Ronnquist <andreas.ronnquist at meritkonsult.se>
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scopeDo I need to #include something (beyond SDL.h) to use these?
Those isn’t in “plain” SDL - but check out
http://www.libsdl.org/cgi/docwiki.cgi/Pixel_Access
for an example implementation and comments.
So I need to explicity implement them? (Copy and paste the code on the
page into my code) I don’t see any #include lines on the page you sent
me.Yes. I guess one reason for these not being availible in SDL is that
the implementation requirement might vary quite a bit - some
implementations require clipping rectangle checking while others don’t,
and sometimes you might know how many bytes per pixel you are putting
beforehand. And of course, many times you don’t need it at all in a
program - you just use the image loading / font loading functionality
to get all the graphics you require and are satisfied with that.
remember pixel access is slow and should be avoided depending on the
application; for some applications pixel access is the only way.
by the way, i believe that code on the wiki is wrong too. the correct way
is to use the mask or shift.
http://www.libsdl.org/cgi/docwiki.cgi/SDL_PixelFormat
most desktop graphics will work assuming rgba or abgr. i only found my
error when i tested on the ps2 using the sony linux runtime disc.
better to code the correct way even if you are only targetting the most
average hardware.
does anyone know of any other hardware that does not have a common or
expected pixel format ?
matt
I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scopeDo I need to #include something (beyond SDL.h) to use these?
Uh, am I missing something, or there is no trace of anything like
these two functions in SDL, at all?
Doing a search in the whole thing only gives me two hits for
glReadPixels and glDrawPixels, in the OpenGL binding headers.
Where did you hear of there functions at all? Hmm, I see a DrawPixel
function defined in some SDL example code… It’s supposed to be an
example of code that you might write yourself, using SDL, not
something provided by SDL itself, if that’s where you saw it (and as
others have said, not the best way to do things, by a long shot).On Thu, Apr 2, 2009 at 10:41 AM, Michael Sullivan wrote:
I generally use something like this (not exactly optimised for speed, but it’s
not bad):
/* members should have values between 0.0 and 1.0 */
typedef struct {double r, g, b, a;} rgbaf;
/constdecl/ Uint32 formatPixel(const SDL_Format* f, rgbaf c) {
return
((int) (c.r * f->Rmask) & f->Rmask) ||
((int) (c.g * f->Gmask) & f->Gmask) ||
((int) (c.b * f->Bmask) & f->Bmask) ||
((int) (c.a * f->Amask) & f->Amask);
}
/constdecl/ Uint32 pixelMask(const SDL_Format* f) {
return f->Rmask || f->Gmask || f->Bmask || f->Amask;
}
void setPixel(SDL_Surface* s, int x, int y, Uint32 p) {
SDL_Format* f = s->format;
Uint8* pixel = s->pixels + ys->pitch + xf->BytesPerPixel;
(Uint32) pixel &= ~pixelMask(f);
(Uint32) pixel |= pixelMask(f) & p;
}On Thursday 02 Apr 2009 14:33:17 mattmatteh at mac.com wrote:
remember pixel access is slow and should be avoided depending on the
application; for some applications pixel access is the only way.by the way, i believe that code on the wiki is wrong too. the correct way
is to use the mask or shift.
I just checked my spam folder, and I don’t see them: Nabble got these
emails, but I didn’t! What happened?!
Continuing with my reply…
So I need to explicity implement them? ?(Copy and paste the code on the
page into my code) ?I don’t see any #include lines on the page you sent
me.
Systems-level programming languages like C and C++ may be considered
"high level," but ultimately they are very implementation-centric:
what you write very closely resembles the machine code that is
generated. See if you can spot the difference between these two:
for (int i=0; i<max; i++) {
if (formatOf(someSurface) == someFormat) {
/* code here operates on the surface for a known pixel format *?
}
}
if (formatOf(someSurface) == someFormat) {
for (int i=0; i<max; i++) {
/* code here operates on the surface for a known pixel format *?
}
}
Unfortunately in C/C++, you often can’t count on the compiler to
optimize the flow of control for your program. Especially when calling
another function, C/C++ programs often can’t guarantee that
"formatOf(someSurface)" will always return the same value throughout
the loop, so you would have to turn your loop “inside out” to reduce
the number of checks on the surface format.
This is the reason SDL doesn’t provide a “GetPixel” or "SetPixel"
method: you’re rarely (if ever!) just going to get one pixel, you’re
going to get a lot of pixels, and set a lot of pixels, all at the same
time. It pays to write your code in a way that will be efficient, and
unfortunately in C there’s no good way to provide a pixel-access API
that is compatible with the need to code efficiently.–
http://codebad.com/
Unfortunately in C/C++, you often can’t count on the compiler to
optimize the flow of control for your program. Especially when calling
another function, C/C++ programs often can’t guarantee that
"formatOf(someSurface)" will always return the same value throughout
the loop, so you would have to turn your loop “inside out” to reduce
the number of checks on the surface format.
I ended up playing with function pointers in Tux Paint.
That is, instead of having:
for (y = 0; y < h; y++) {
for (x = 0; x < w; x++) {
if (surf->format->bpp == xxx)
…do this
else if (surf->formt->bpp == yyy)
…do that
else if (surf->format->bpp == zzz)
…do the other
}
}
I decided whether we’ll need to do ‘this’, ‘that’, or 'the other’
once, outside the loop:
if (surf->format…
doit = this;
else if (surf->format…
doit = that;
else…
doit = other;
for (y …
for (x …)
…doit(…)
Excuse brevity,On Fri, Apr 03, 2009 at 05:55:09PM -0400, Donny Viszneki wrote:
–
-bill!
Sent from my computer
function pointers involve an extra memory lookup before the function is
actually run. while it would be faster than checking several conditions
inside the loop, it’s still slower than copying the whole loop.On Friday 03 Apr 2009 19:37:44 Bill Kendrick wrote:
On Fri, Apr 03, 2009 at 05:55:09PM -0400, Donny Viszneki wrote:
Unfortunately in C/C++, you often can’t count on the compiler to
optimize the flow of control for your program. Especially when calling
another function, C/C++ programs often can’t guarantee that
"formatOf(someSurface)" will always return the same value throughout
the loop, so you would have to turn your loop “inside out” to reduce
the number of checks on the surface format.I ended up playing with function pointers in Tux Paint.
That is, instead of having:for (y = 0; y < h; y++) {
for (x = 0; x < w; x++) {
if (surf->format->bpp == xxx)
…do this
else if (surf->formt->bpp == yyy)
…do that
else if (surf->format->bpp == zzz)
…do the other
}
}I decided whether we’ll need to do ‘this’, ‘that’, or 'the other’
once, outside the loop:if (surf->format…
doit = this;
else if (surf->format…
doit = that;
else…
doit = other;for (y …
for (x …)
…doit(…)Excuse brevity,
SDL 1.3 has this (in SDL_surface.h):
DECLSPEC int SDLCALL SDL_DrawPoint (SDL_Surface *dst, int x, int y, Uint32
color);
DECLSPEC int SDLCALL SDL_BlendPoint (SDL_Surface *dst, int x, int y, int
blendMode, Uint8 r, Uint8 g, Uint8 b, Uint8 a);
There are some other primitives hiding there too.On Thursday 02 Apr 2009 10:41:30 Michael Sullivan wrote:
I want to use DrawPixel and ReadPixel in my program, but make tells me
draw.cpp:152: error: ‘ReadPixel’ was not declared in this scope
draw.cpp:152: error: ‘DrawPixel’ was not declared in this scopeDo I need to #include something (beyond SDL.h) to use these?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
? for (y …
? ? for (x …)
? ? ? …doit(…)function pointers involve an extra memory lookup before the function is
actually run. ?while it would be faster than checking several conditions
inside the loop, it’s still slower than copying the whole loop.
That’s true, but I prefer neither an extra memory lookup nor copying
the whole loop.
template
void do_the_thing(const FuncType &func) {
for (y…)
for (x…)
func(…)
}
struct MyFunctor {
void operator()(…) const {
/* your stuff */
}
};
void a_function() {
do_the_thing(MyFunctor());
}
Generated code for this is as good as if it was hand-written code.
Note that instead of passing in a functor directly, you can make types
for the different, uh, pixel types (what a concept!), and provide
methods that are defined in the declaration for accessing the pixels,
the “do_the_thing” templated function (which doesn’t need to specify
the type, the compiler works it out by itself) will be generated as
best as possible, without necessarily inlining it like a macro would
do (so not bloating the final binary as much).
C++ can be used for good or evil (to optimize or to bloat). ;-)On Fri, Apr 3, 2009 at 7:46 PM, Kenneth Bull wrote:
Pierre, you’re my hero. I’ve never gotten the hang of template
optimization. Do you know of any good online resources to learn more
about that?
Jonny DOn Fri, Apr 3, 2009 at 10:39 PM, Pierre Phaneuf wrote:
On Fri, Apr 3, 2009 at 7:46 PM, Kenneth Bull wrote:
? for (y …
? ? for (x …)
? ? ? …doit(…)function pointers involve an extra memory lookup before the function is
actually run. ?while it would be faster than checking several conditions
inside the loop, it’s still slower than copying the whole loop.That’s true, but I prefer neither an extra memory lookup nor copying
the whole loop.template
void do_the_thing(const FuncType &func) {
? ?for (y…)
? ? ? ?for (x…)
? ? ? ? ? ?func(…)
}struct MyFunctor {
? ?void operator()(…) const {
? ? ? ?/* your stuff */
? ?}
};void a_function() {
? ?do_the_thing(MyFunctor());
}Generated code for this is as good as if it was hand-written code.
Note that instead of passing in a functor directly, you can make types
for the different, uh, pixel types (what a concept!), and provide
methods that are defined in the declaration for accessing the pixels,
the “do_the_thing” templated function (which doesn’t need to specify
the type, the compiler works it out by itself) will be generated as
best as possible, without necessarily inlining it like a macro would
do (so not bloating the final binary as much).C++ can be used for good or evil (to optimize or to bloat).
–
http://pphaneuf.livejournal.com/
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I note from the code in SDL_drawpoint.c that these operate on software
surfaces only.
I am working on a video device that allows drawing to individual
points on hardware surfaces, without having to copy the entire surface
to application memory. I imagine there are others that do this as
well (I might have seen it done in opengl?).
Perhaps hardware point drawing could be useful for some applications?On Sat, Apr 4, 2009 at 12:24 AM, Kenneth Bull wrote:
SDL 1.3 has this (in SDL_surface.h):
DECLSPEC int SDLCALL SDL_DrawPoint (SDL_Surface *dst, int x, int y, Uint32
color);
DECLSPEC int SDLCALL SDL_BlendPoint (SDL_Surface *dst, int x, int y, int
blendMode, Uint8 r, Uint8 g, Uint8 b, Uint8 a);
Pierre, you’re my hero. ?I’ve never gotten the hang of template
optimization. ?Do you know of any good online resources to learn more
about that?
Not really… I got the basic ideas while reading “Modern C++ Design”,
that you could convince the C++ compiler to generate very well tuned
code, followed by a whole lot of tinkering with code, making small
test cases, calling them a million times, timing with things like
getrusage and clock_gettime(CLOCK_MONOTONIC), looking at the generated
assembly with “gcc -S foo.cc”, and so on.
With hindsight, I would recommend “C++ Templates”
(http://www.vandevoorde.com/Templates/) instead of “Modern C++
Design”. Alexandrescu’s book was nicknamed by some of my former
teammates “the crack book”, because some of the stuff in it is so
twisted and crazy, the kind of stuff that gives C++ a bad name (I
remember a friend of mine telling me he was glad when an errata for
the book came out, because he thought some of the code just didn’t
make any sense, but he was shocked to find out that the corrected
version didn’t really make much sense either!).On Fri, Apr 3, 2009 at 11:40 PM, Jonathan Dearborn wrote:
What video device are you using? If it has OpenGL drivers and this
"allows drawing individual points on hardware surfaces, without having
to copy the entire surface" is called “streaming texture access” or
"memory mapped texture access," then these functions ought to work
with the OpenGL back-end.On Sat, Apr 4, 2009 at 9:21 AM, pr wrote:
I note from the code in SDL_drawpoint.c that these operate on software
surfaces only.I am working on a video device that allows drawing to individual
points on hardware surfaces, without having to copy the entire surface
to application memory. ?I imagine there are others that do this as
well (I might have seen it done in opengl?).Perhaps hardware point drawing could be useful for some applications?
---- Donny Viszneki <donny.viszneki at gmail.com> wrote:
=============
On Sat, Apr 4, 2009 at 9:21 AM, pr wrote:
I note from the code in SDL_drawpoint.c that these operate on software
surfaces only.I am working on a video device that allows drawing to individual
points on hardware surfaces, without having to copy the entire surface
to application memory. ?I imagine there are others that do this as
well (I might have seen it done in opengl?).Perhaps hardware point drawing could be useful for some applications?
What video device are you using? If it has OpenGL drivers and this
"allows drawing individual points on hardware surfaces, without having
to copy the entire surface" is called “streaming texture access” or
"memory mapped texture access," then these functions ought to work
with the OpenGL back-end.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
OpenGL will not provide you any information on the SDL API.
What I was trying to say was that SDL_DrawPoint() should work for
the OpenGL video subsystem where so-called "streaming texture access"
is available. (Perhaps it should even work where it is not available,
however OP said it was.)On Sun, Apr 5, 2009 at 5:44 PM, wrote:
Hiyya, Great point Donny has. I would suggest you check out opengl.org
where they have tutorials on how to do this kind of thing for first
timers and vets alike.
What I was trying to say was that SDL_DrawPoint() should work for
the OpenGL video subsystem where so-called "streaming texture access"
is available. (Perhaps it should even work where it is not available,
however OP said it was.)
I think that the problem when you think of drawing a point with OpenGL
is that it asks you “how big is it”. 
(if I remember correct, what OpenGL calls a “point” is, well, a
mathematical point, which has no extend)On Mon, Apr 6, 2009 at 1:37 AM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
