Search Home Members Contacts
About Us
Products
Downloads
Community
Support
Pages: [1]
  Print  
Author Topic: [solved] RenderSurface.Destoy destroys wrong surface  (Read 552 times)
Lenn
Customers
Community Member
*****
Posts: 454

Ivan Miskelic


« on: January 04, 2008, 10:32:25 AM »

Hi,

I just wanted to say that I discovered that if you have many render surfaces and you desotroy one render surface twice, what will actualy happen is that this render surface will be desotryed as well as another one. Probably the one that was last created before it, or the next in the index.

I think this is a bug, so you should implement a check if a surface is already destroyed when calling RS.Destroy, and do nothing if it already is destroyed (or post an error, your choice). This would have saved me 30 minutes of debugging time, but others might find the problem more severe.

I don't think I should post sample code, as it it's fairly easy to reporduce. I tested it by printing to debug file the actual index and GetTexture integer, so I'm sure it was pointing to the wrong texture after destruction.

Thanks
« Last Edit: January 04, 2008, 05:01:25 PM by Lenn » Logged

sybixsus
Customers
Community Member
*****
Posts: 1094


WWW
« Reply #1 on: January 04, 2008, 12:58:07 PM »

Isn't this just the inevitable consequence of indexing textures and rendersurfaces with an integer index? I was under the impression that TV reissued indices which were previously used and freed, in which case there's no way for the engine to know that you didn't mean to free it.
Logged
Lenn
Customers
Community Member
*****
Posts: 454

Ivan Miskelic


« Reply #2 on: January 04, 2008, 02:10:42 PM »

Yeah. But.

Code:
RS1.Destroy
RS1.Destroy
RS1.Destroy

shouldn't do the exact same thing as:

Code:
RS1.Destroy
RS2.Destroy
RS3.Destroy

At least I think so. Tell me if I'm wrong.

Maybe it should just have a flag internally which notes if the surface has been destroyed or not. So when you call RS1.Destroy the second time (in my example), the first time the internal SurfaceDestroyed flag would be set to true so nothing would happen. They can still keep the integer index, I just feel they should put in a failsafe of that sort.
Logged

sybixsus
Customers
Community Member
*****
Posts: 1094


WWW
« Reply #3 on: January 04, 2008, 02:32:58 PM »

I'm not sure I follow. In your hypothetical example, are you saying that RS1 RS2 and RS3 all exist before you destroy RS1 three times? So in other words, the surface index of two existing rendersurfaces is changed out from under you after they've already been assigned? Because no, that certainly shouldn't happen, and I would expect TV to be crashing left, right and center if it was happening.

If, on the other hand, you create RS2 and RS3 after RS1 is destroyed, then I don't see how you can stop it happening. The index is available when RS1 is destroyed, and it gets assigned to a new surface, and you can't mark it with some do not destroy flag at this point because it's been reassigned and stopping it from being freed would create a memory leak.

But I'm really not sure which you're suggesting.
Logged
Lenn
Customers
Community Member
*****
Posts: 454

Ivan Miskelic


« Reply #4 on: January 04, 2008, 05:00:31 PM »

Hmmm ok I tested it and isolated the code. What I did was:

Create RS1, RS2, RS3
Destroy RS2
Destroy RS2

Now if you display all 3, RS2 will still be displayed, only it will look like RS1. I guess that confused me.

...

hold on, thats not what I did in my much more complicated gui code. I think that what I am doing was:

create RS1
Destroy RS2
create RS2

draw RS1, but RS2 gets drawn. ... but when i try to do this same thing in my simplified code this doesn't happen.

Oh well, i just dont have time to search for the exact cause of the bug, if there is one in the first place. Let's just asume the first part of this post is what was confusing me. Thanks sybixsus. Smiley
Logged

WEst
Community Member
*
Posts: 813

Daniel Martinek


WWW
« Reply #5 on: January 04, 2008, 05:48:42 PM »

Also be sure to set the RS to nothing (or whatever in your language) else there can be such problems too (at least I was having some).
Logged

Greetings

Daniel Martinek
Lead Programmer
Roaming Nova Studios
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.3 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks