This is a very rare situation to reproduce. I am getting an error in SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the problem is that SDL application has no focus, but is in foreground and the system comes out of display turned off by power saving and also having a screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia card. I have found no problem using software renderer so far.
if you use SDL_gfx, but initialize/close SDL in your application, characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn character. This list is initialized on-the-go whenever a character is first used : first usage will do a slow draw to a surface, which is then stored as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures, but SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will destroy all the temporary textures.
Thanks
ArmandoOn Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse <jeroen.clarysse at telenet.be wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures, but
SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will destroy all
the temporary textures.
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny DOn Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures, but
SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will destroy
all the temporary textures.
Dear Jonny.
Is this related with the problem I described at the start of this thread ?
Is it possible that SDL quits? I was supposing that the texture was freed
or discarded without my knowledge but not the entire SLD.
ThanksOn Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza <@Armando_Alaminos_Bou wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures, but
SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will destroy
all the temporary textures.
I’m not sure which problem you refer to. Can you link to it? The problem
in this particular thread is when you explicitly call SDL_Quit() and then
use SDL_gfx later. If you don’t use SDL_gfx, this does not apply to you.
Jonny DOn Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza wrote:
Dear Jonny.
Is this related with the problem I described at the start of this thread ?
Is it possible that SDL quits? I was supposing that the texture was freed
or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn <@Jonathan_Dearborn> wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures, but
SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will destroy
all the temporary textures.
It is at the very beginning of the thread, but this is the quote-----------------------------------------------
This is a very rare situation to reproduce. I am getting an error in
SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with
SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the
problem is that SDL application has no focus, but is in foreground and the
system comes out of display turned off by power saving and also having a
screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia
card. I have found no problem using software renderer so far.
Any on how to recover from that condition ?
On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn wrote:
I’m not sure which problem you refer to. Can you link to it? The problem
in this particular thread is when you explicitly call SDL_Quit() and then
use SDL_gfx later. If you don’t use SDL_gfx, this does not apply to you.
Jonny D
On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza <@Armando_Alaminos_Bou wrote:
Dear Jonny.
Is this related with the problem I described at the start of this thread
? Is it possible that SDL quits? I was supposing that the texture was
freed or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < @Armando_Alaminos_Bou> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures, but
SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will destroy
all the temporary textures.
Jonny DOn Tue, Oct 6, 2015 at 12:33 PM, Armando Alaminos Bouza wrote:
It is at the very beginning of the thread, but this is the quote
This is a very rare situation to reproduce. I am getting an error in
SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with
SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the
problem is that SDL application has no focus, but is in foreground and the
system comes out of display turned off by power saving and also having a
screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia
card. I have found no problem using software renderer so far.
Any on how to recover from that condition ?
On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn <@Jonathan_Dearborn> wrote:
I’m not sure which problem you refer to. Can you link to it? The
problem in this particular thread is when you explicitly call SDL_Quit()
and then use SDL_gfx later. If you don’t use SDL_gfx, this does not apply
to you.
Jonny D
On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jonny.
Is this related with the problem I described at the start of this thread
? Is it possible that SDL quits? I was supposing that the texture was
freed or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn <@Jonathan_Dearborn> wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures,
but SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will
destroy all the temporary textures.
Jeroen’s mail with the subject “a short warning about SDL_gfx” was sent
as a reply to Armando’s mail with the subject “Problem with
SDL_UpdateTexture when coming form screen saver” (according to the mail
headers). Thus any “correctly” behaving email client will believe that
Jeroen’s mail was intended as a direct reply to Armando’s question.
So yes, you could say that these threads got mixed up somehow.
eirik>
On Tue, Oct 6, 2015 at 12:33 PM, Armando Alaminos Bouza wrote:
It is at the very beginning of the thread, but this is the quote
This is a very rare situation to reproduce. I am getting an error in
SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with
SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the
problem is that SDL application has no focus, but is in foreground and the
system comes out of display turned off by power saving and also having a
screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia
card. I have found no problem using software renderer so far.
Any on how to recover from that condition ?
On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn wrote:
I’m not sure which problem you refer to. Can you link to it? The
problem in this particular thread is when you explicitly call SDL_Quit()
and then use SDL_gfx later. If you don’t use SDL_gfx, this does not apply
to you.
Jonny D
On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jonny.
Is this related with the problem I described at the start of this thread
? Is it possible that SDL quits? I was supposing that the texture was
freed or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures,
but SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will
destroy all the temporary textures.
There we go. Well then Gmail is (probably intentionally) misbehaving
because it groups by subject line.
Jonny DOn Tue, Oct 6, 2015 at 1:23 PM, Eirik Byrkjeflot Anonsen wrote:
Jonathan Dearborn <@Jonathan_Dearborn> writes:
Then this thread got mixed up somehow with yours.
Jonny D
Jeroen’s mail with the subject “a short warning about SDL_gfx” was sent
as a reply to Armando’s mail with the subject “Problem with
SDL_UpdateTexture when coming form screen saver” (according to the mail
headers). Thus any “correctly” behaving email client will believe that
Jeroen’s mail was intended as a direct reply to Armando’s question.
So yes, you could say that these threads got mixed up somehow.
eirik
On Tue, Oct 6, 2015 at 12:33 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
It is at the very beginning of the thread, but this is the quote
This is a very rare situation to reproduce. I am getting an error in
SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with
SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the
problem is that SDL application has no focus, but is in foreground and
the
system comes out of display turned off by power saving and also having a
screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a
NVidia
card. I have found no problem using software renderer so far.
Any on how to recover from that condition ?
On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn <@Jonathan_Dearborn> wrote:
I’m not sure which problem you refer to. Can you link to it? The
problem in this particular thread is when you explicitly call
SDL_Quit()
and then use SDL_gfx later. If you don’t use SDL_gfx, this does not
apply
to you.
Jonny D
On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jonny.
Is this related with the problem I described at the start of this
thread
? Is it possible that SDL quits? I was supposing that the texture was
freed or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn < @Jonathan_Dearborn> wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check
WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character
is first
used : first usage will do a slow draw to a surface, which is then
stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures,
but SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will
destroy all the temporary textures.
well, it was my fault : I just replied, but changed the mail title to start a new thread. I didn?t realize that a mail could have some sort of hidden ?thread identifier? and thought only the mail title was used
my apologies :-(> hen Gmail is (probably intentionally) misbehaving because it groups by subject line.
Jonny D
On Tue, Oct 6, 2015 at 1:23 PM, Eirik Byrkjeflot Anonsen wrote:
Jonathan Dearborn writes:
Then this thread got mixed up somehow with yours.
Jonny D
Jeroen’s mail with the subject “a short warning about SDL_gfx” was sent
as a reply to Armando’s mail with the subject “Problem with
SDL_UpdateTexture when coming form screen saver” (according to the mail
headers). Thus any “correctly” behaving email client will believe that
Jeroen’s mail was intended as a direct reply to Armando’s question.
So yes, you could say that these threads got mixed up somehow.
eirik
On Tue, Oct 6, 2015 at 12:33 PM, Armando Alaminos Bouza wrote:
It is at the very beginning of the thread, but this is the quote
This is a very rare situation to reproduce. I am getting an error in
SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with
SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the
problem is that SDL application has no focus, but is in foreground and the
system comes out of display turned off by power saving and also having a
screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia
card. I have found no problem using software renderer so far.
Any on how to recover from that condition ?
On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn wrote:
I’m not sure which problem you refer to. Can you link to it? The
problem in this particular thread is when you explicitly call SDL_Quit()
and then use SDL_gfx later. If you don’t use SDL_gfx, this does not apply
to you.
Jonny D
On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jonny.
Is this related with the problem I described at the start of this thread
? Is it possible that SDL quits? I was supposing that the texture was
freed or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < @Jeroen_Clarysse> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures,
but SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will
destroy all the temporary textures.
But if any one has some inside into my problem I will greatly appreciate.
Fortunately, I have tested several times and there is no problem if using the software renderer.
On the other hand, the hardware rendered is also creating problems with some Windows XP, specially if inside a virtual machine.
So, I will be using the software renderer as default and the user can change that in a configuration file.
jeroen clarysse <jeroen.clarysse at telenet.be> writes:
well, it was my fault : I just replied, but changed the mail title to start a new thread. I didn?t realize that a mail could have some sort of hidden ?thread identifier? and thought only the mail title was used
my apologies
It’s a fairly common mistake these days. Sufficiently common that:
hen Gmail is (probably intentionally) misbehaving because it groups by subject line.
Jonny D
Yes, that probably is intentional.
I think the problem is really that many of these systems were made by
"logical" people (by which I mean people who would never press a "reply"
button unless they actually intended to reply to something). But most
people are not that “logical” (by which I mean that they don’t consider
the meaning behind what they do as long as the end result “looks
right”).
I’m afraid we “logical” people are on the losing side here and will just
have to adjust. So don’t worry too much about it
Still, just knowing why things end up the way they do might be useful
occasionally. Or at least a little bit interesting. And that’s really
why I sent my explanation.
eirik>> On Tue, Oct 6, 2015 at 1:23 PM, Eirik Byrkjeflot Anonsen <@Eirik_Byrkjeflot_Ano> wrote:
Jonathan Dearborn writes:
Then this thread got mixed up somehow with yours.
Jonny D
Jeroen’s mail with the subject “a short warning about SDL_gfx” was sent
as a reply to Armando’s mail with the subject “Problem with
SDL_UpdateTexture when coming form screen saver” (according to the mail
headers). Thus any “correctly” behaving email client will believe that
Jeroen’s mail was intended as a direct reply to Armando’s question.
So yes, you could say that these threads got mixed up somehow.
eirik
On Tue, Oct 6, 2015 at 12:33 PM, Armando Alaminos Bouza wrote:
It is at the very beginning of the thread, but this is the quote
This is a very rare situation to reproduce. I am getting an error in
SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with
SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the
problem is that SDL application has no focus, but is in foreground and the
system comes out of display turned off by power saving and also having a
screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia
card. I have found no problem using software renderer so far.
Any on how to recover from that condition ?
On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn wrote:
I’m not sure which problem you refer to. Can you link to it? The
problem in this particular thread is when you explicitly call SDL_Quit()
and then use SDL_gfx later. If you don’t use SDL_gfx, this does not apply
to you.
Jonny D
On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jonny.
Is this related with the problem I described at the start of this thread
? Is it possible that SDL quits? I was supposing that the texture was
freed or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each drawn
character. This list is initialized on-the-go whenever a character is first
used : first usage will do a slow draw to a surface, which is then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated textures,
but SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will
destroy all the temporary textures.
Most likely this is because D3D is dumping your textures. This can happen
on certain mode switches, which might be what you’re seeing when you come
back from the screen saver.
To resolve this, you have to handle the SDL_RENDER_DEVICE_RESET event by
reloading your textures (from memory or disk). I think that event was only
implemented as of SDL 2.0.4.
Have you tried the OpenGL renderer to see if that works better for your
needs?
Jonny DOn Tue, Oct 6, 2015 at 2:28 PM, alabouza wrote:
No problem !
But if any one has some inside into my problem I will greatly appreciate.
Fortunately, I have tested several times and there is no problem if using
the software renderer.
On the other hand, the hardware rendered is also creating problems with
some Windows XP, specially if inside a virtual machine.
So, I will be using the software renderer as default and the user can
change that in a configuration file.
Yeah, (off topic at this point) but I would actually say it’s a failing of
the client UI.
The client may not present the necessary information to the user for him to
know which thread the new message will be a part of. If the client
organizes incoming mail by subject line, then shouldn’t it also do the same
for outgoing mail (by adjusting the hidden data accordingly)?
UX speaking, when you want to change the subject of a discussion with the
same target email address, should you be expected to leave the discussion,
create a new message, and input the email address again?
Jonny DOn Tue, Oct 6, 2015 at 2:50 PM, Eirik Byrkjeflot Anonsen wrote:
jeroen clarysse <jeroen.clarysse at telenet.be> writes:
well, it was my fault : I just replied, but changed the mail title to
start a new thread. I didn?t realize that a mail could have some sort of
hidden ?thread identifier? and thought only the mail title was used
my apologies
It’s a fairly common mistake these days. Sufficiently common that:
hen Gmail is (probably intentionally) misbehaving because it groups by
subject line.
Jonny D
Yes, that probably is intentional.
I think the problem is really that many of these systems were made by
"logical" people (by which I mean people who would never press a "reply"
button unless they actually intended to reply to something). But most
people are not that “logical” (by which I mean that they don’t consider
the meaning behind what they do as long as the end result “looks
right”).
I’m afraid we “logical” people are on the losing side here and will just
have to adjust. So don’t worry too much about it
Still, just knowing why things end up the way they do might be useful
occasionally. Or at least a little bit interesting. And that’s really
why I sent my explanation.
eirik
On Tue, Oct 6, 2015 at 1:23 PM, Eirik Byrkjeflot Anonsen < eirik at eirikba.org> wrote:
Jonathan Dearborn <@Jonathan_Dearborn> writes:
Then this thread got mixed up somehow with yours.
Jonny D
Jeroen’s mail with the subject “a short warning about SDL_gfx” was sent
as a reply to Armando’s mail with the subject “Problem with
SDL_UpdateTexture when coming form screen saver” (according to the mail
headers). Thus any “correctly” behaving email client will believe that
Jeroen’s mail was intended as a direct reply to Armando’s question.
So yes, you could say that these threads got mixed up somehow.
eirik
On Tue, Oct 6, 2015 at 12:33 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
It is at the very beginning of the thread, but this is the quote
This is a very rare situation to reproduce. I am getting an error in
SDL_UpdateTexture. The call to SDL_GetError() returns :
LockRect(): INVALIDCALL
I only found the condition if SDL_CreaterRenderer is called with
SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the
problem is that SDL application has no focus, but is in foreground
and the
system comes out of display turned off by power saving and also
having a
screen saver.
The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a
NVidia
card. I have found no problem using software renderer so far.
Any on how to recover from that condition ?
On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn < @Jonathan_Dearborn> wrote:
I’m not sure which problem you refer to. Can you link to it? The
problem in this particular thread is when you explicitly call
SDL_Quit()
and then use SDL_gfx later. If you don’t use SDL_gfx, this does
not apply
to you.
Jonny D
On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jonny.
Is this related with the problem I described at the start of this
thread
? Is it possible that SDL quits? I was supposing that the texture
was
freed or discarded without my knowledge but not the entire SLD.
Thanks
On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn < @Jonathan_Dearborn> wrote:
I wonder if it would help add-on library developers to have an
event/callback that signals that SDL has quit? Or one could
check WasInit
all the time… :-/
Jonny D
On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza < aabouza at gmail.com> wrote:
Dear Jeroen,
I do not use SDL_gfx .
Thanks
Armando
On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse < jeroen.clarysse at telenet.be> wrote:
if you use SDL_gfx, but initialize/close SDL in your
application,
characters drawn with sdl_gfx will be garbled.
basically, the gfx library keeps a list of textures for each
drawn
character. This list is initialized on-the-go whenever a
character is first
used : first usage will do a slow draw to a surface, which is
then stored
as a texture for subsequent, much faster drawing.
closing SDL will destroy the renderer and all associated
textures,
but SDL_gfx doesn?t know this !
I recommend calling
gfxPrimitivesSetFont(NULL,0,0);
right before you destroy your renderer or close SDL. This will
destroy all the temporary textures.
Hi Jonny. Thanks for sharing your ideas. I will explore your solution using SDL_RENDER_DEVICE_RESET. The content of my textures is all stored in memory.
Armando----------------------------
Most likely this is because D3D is dumping your textures. This can happen on certain mode switches, which might be what you’re seeing when you come back from the screen saver.
To resolve this, you have to handle the SDL_RENDER_DEVICE_RESET event by reloading your textures (from memory or disk). I think that event was only implemented as of SDL 2.0.4.
Have you tried the OpenGL renderer to see if that works better for your needs?
