[Bobboau]

so, what exactly is boost/shared_ptr.hpp ?

[Kazan]

one of the boost:: and soon to be std:: (and already is std::tr1 in compliant compilers like vs2008 with the appropriate update) smart pointers

auto_ptr is deprecated in the next language standard


now what shared_ptr actually is - it is a reference counting pointer that automatically deletes the pointer when the last instance goes out of scope - use it for things like "new ClassInstance"

use shared_array for "new object[1000]" instead

here is the c++0x spec http://en.wikipedia.org/wiki/C%2B%2B0x

get boost from

http://www.boost.org/

im also going to be moving the includes out of the project definition and just have everyone put them into their visual studio additional headers settings

[Bobboau]

on that last point that would be a good idea, I am right now trying to get a MSVC2008 solution working (without disrupting the existing stuff).

you say this is std in vs2008? is there some way we could include the native version on compilers that have it installed already?
oh, and are you using an outdated version of wxWidgets? I'm getting a bunch of odd errors (I'm using 2.8.9)

[Kazan]

trunk, if it compiles right now, crashes due to some alterations to the multithreading im making and trying to debug... something is crashing inside wxWidgets i think... and i am compiling against 2.8.9 though i might have changed something partially in code that requires me to finish cleaning it up

i just upgraded to vs2008 at home.. just haven't opened PCS2 yet

if you get the appropriate update to vs2008 then include the appropriate header and it's in std::tr1 namespace for shared_ptr and shared_array, etc etc ... the big thing here is they're EXCEPTION SAFE pointers

if i haven't already in code im going to be deprecating usage of wxThread objects and using boost threads and boost mutexes as these are becoming std:: in C++0x

[Bobboau]

I figured out what the errors were from, we need to include wx\msw\winundef.h after every inclue of windows.h, it undefines the common symbols, most importantly Yield.

do the boost thread things behave roughly the same as the WX stuff?
it'll be nice if STL gets some better threading capabilities.

[Kazan]

I figured out what the errors were from, we need to include wx\msw\winundef.h after every inclue of windows.h, it undefines the common symbols, most importantly Yield.

do the boost thread things behave roughly the same as the WX stuff?
it'll be nice if STL gets some better threading capabilities.

they're better than the wx ones.. boost library pretty much kicks the **** out of everything, it's basically the "test bed" std:: ... their API is a little different obviously.. but soon as our compilers get C++0x compliance next year probably we switch "using boost::thread" to "using std::thread"

other changes to the language in C++0x is better memory model that is multithread aware, a version of the "static" keyword called "thread_local" (self explainatory)

[Bobboau]

"thread_local"
****N SWEET!

I need to look into this.
I really think they aught to make mutexes and semiphores standard types (like in't and floats.)

[Kazan]

read the C++0x wiki page.. the thread library includes all the synchronization functions you would want

conditions variables, mutexes, etc

for more detail here is Boost::thread which is becoming std::thread

http://www.boost.org/doc/libs/1_38_0/doc/html/thread.html

[edit]
is your "latest PCS2 build" link in your signature up to date to 2.0.3?

[Bobboau]

it was the last build I made, so no, not yet anyway, it probably will be soon though.

[Kazan]

if you're going to post dev builds in your signature please post "Latest Stable (2.0.3)" and "Bob's Latest Development Build"

currently trunk builds are ALPHA quality and are pretty much gauranteed to crash

[Bobboau]

while I'm waiting for XP to compress this laptop's 30GB hard drive so I can squeeze an extra GB or two out of it to install the update, because you still have SCP internal access, I think I left the POF file upgrade specs in there, could you repost those somewhere public.

I did just order a 320GB HD from newegg btw.

[Bobboau]

are we actually using boost anywhere yet?
I was going to make a new compatibility file that would use the tr1 implementation when possible and boost otherwise, but when I wen't to see what classes we were useing it didn't seem like we were using any.

also have you considered loading the different textures in different threads?

and does anyone else experience texture corruption like what I have attached or is it just me?

[attachment deleted by admin]

[Kazan]

are we actually using boost anywhere yet?
I was going to make a new compatibility file that would use the tr1 implementation when possible and boost otherwise, but when I wen't to see what classes we were useing it didn't seem like we were using any.

also have you considered loading the different textures in different threads?

and does anyone else experience texture corruption like what I have attached or is it just me?

a) yes im using boost::shared_ptr (aka std::tr1::shared_ptr) and boost::regex
b) openGL is not thread aware.. all opengl commands (including texture load) must come from the same thread
c) never seen that.. video card/driver combo?

[Bobboau]

well, I guess I have to wait untill you commit that because I got rid of the includes and everything compiled fine.

couldn't we put the reading part into desperate threads at least? I have a feeling it would increase performance eminencely.

possibly, it seems to be related with texture loading though (investigating it is what peaked my curiosity about loading textures in threads) if I hit the reload textures button it clears it right up.

[Kazan]

well, I guess I have to wait untill you commit that because I got rid of the includes and everything compiled fine.

couldn't we put the reading part into desperate threads at least? I have a feeling it would increase performance eminencely.

possibly, it seems to be related with texture loading though (investigating it is what peaked my curiosity about loading textures in threads) if I hit the reload textures button it clears it right up.

weird.. i could have sworn i used regex and shared_ptr ... you should download boost and install it.

i could put the reading of the textures from disk into a different thread, but the main UI would still have to wait for that thread.. in the end it would make little difference in perceived performance

[Bobboau]

can you commit whatever you have right now, I was trying to work on changing the way turret importation worked to address VA's bug, but it seems that chunk importation is broken because I assume the loading thread is deleteing it's self, and that seemed like something that your changes might have effected or fixed.

[Kazan]

they havent fixed it yet.. and i cannot get it to compile since i updated to VS2008... it thinks wxGLCanvas is not defined but it's enabled in wx/setup.h and was when i compiled wxwidgets

i've made a spattering of changes (added casts) all over to shut up warnings about converting size_t to int

[Bobboau]

why not change those ints to unsigned ints, that usually does it.

I've got it compiling under VS2008, but I have that library specialization thing half set up (the boost-tr1 thing).

[Kazan]

why not change those ints to unsigned ints, that usually does it.

I've got it compiling under VS2008, but I have that library specialization thing half set up (the boost-tr1 thing).

because that doesn't fix the 64-bit portability warnings

64bit windows
unsigned int = 4 bytes
size_t = 8 bytes

[Bobboau]

oh, well I guess that's an ok reason then, though it might still be a good idea to actually use the size_t when applicable.

anyway, was bored and seeing as I can't really fix most bugs due to the current changes to the threading model makeing the code base super unstable. I just improved POF compilation time by 50-100% for objects in the 10000 poly range. more complex objects will benefit more.