Post not yet marked as solved
Oh, looks like the images have vanished.ahhh
Post not yet marked as solved
Hi Skohan,Out of interest, what happens if you change the code toy = bt_splat_ps(y, 128);If it doesn't make any difference I would try this#define BT_SHUFFLE(x, y, z, w) (((w) << 6 | (z) << 4 | (y) << 2 | (x))&255)Thought that would change the behaviour.It looks like the shuffle is creating the value 10880(0x80 << 6) + (0x80 <<4) + (0x80 << 2) + (0x80) = 0x2000 + 0x800 + 0x200 + 0x80 = 0x2a80 = 10,880
Hi John,This is a very old technique that people have used for ever, however your reply did hilight what was causing my problem.In the broken version of the archive class I had missed the & in my string handler. This caused all the problems as I was changing the code in a different class than the compiler was importing, and the code it should have been using was correct. That was why it was so hard to find.In your reply you point out what I was expecting.template <class CharT, class Traits, class Allocator>std::basic_ostream<CharT, Traits>& operator<<(std::basic_ostream<CharT, Traits>& os, const std::basic_string<CharT, Traits, Allocator> &str);However what I got was effectively ....template <class CharT, class Traits, class Allocator>std::basic_ostream<CharT, Traits>& operator<<(std::basic_ostream<CharT, Traits>& os, const std::basic_string<CharT, Traits, Allocator> str);Note the single very important difference. One character can really ruin your day.So what I actually received in the code was a copy of the string, not the string itself.Had I actually got what we both expected, then it wouldn't have been a major problem, though in the end I am glad I found out what was the root cause rather than just sticking a plaster on it.The bottom line is I made a mistake, but libc++ also is wrong, It should have been passing a reference to the string, instead it passed a new string, and I don't know why.CheersPaul
Well actually it does work.I eventually found the problem was that one of the games libraries, when I added it to the game project, changed include paths for the core library. This library contains all the archive handling.So some of the code was including the correct version of core, some was looking at the unconverted (win32) version.When I corrected the include path and removed the basic_string version of the serialiser, everything worked.However the bug in libc++ remains. Taking a copy of a string before serialisation is a very bad idea for lot's of reasons.I don't care now though as I have working code and can progress. I would love to know why xcode changed include paths though, that's a weird one.
John, that is not an option.The options are ..Find a solutionSpend thousands of pounds changing thousands of lines of code Drop MAc and IOS and just not support themI obviously want to go with option 1, but if it comes down to it I know which one the managers are going to pick.
After a lot of debugging I have tied down exactly what is happening.The method for a std::string is being ignored due to namespace issues in libc++.Instead it takes a copy of the std:string as a std::basic_string (actually probably std::_1::basic_string), and send that to the basic_string method.Obviously this is not what I want as I read the data into the basic_string which is then thrown away and my std::string is never modified
No,It's an old trick we have been doing for years. You override the << operator so you can use the same code to load AND save data.That way you never get out of sync.You have a single serialise function that you use for reading and writingFor example.Archive& operator <<(Archive& ar, char* val)
{
uint len = 0;
if (ar.IsWriting())
{
len = sysStrLen(val);
ar << len;
}
else
len = Arctor(ar);
ar.Serialize(val, len+1);
return ar;
}
Does anyone know how to display the stack contents in xcode?What I am thinking of doing is finding the pointer to the string I am supplying to << on the stack, and in the case of reading from disk, use this instead of the string "val"Would mean inserting some assembler, but it's the only fix I can think of.
Yes everything is correct the issue is that this code.Archive& operator<<(Archive& ar, PlayerState& s)
{
int ver = 1;
ar << ver;
ar << s.name << s.campaignState;
return ar;
}Should callArchive& operator <<(Archive& ar, std::string& val)But it doesn't. It callsArchive& operator <<(Archive &ar, std::basic_string<char,std::char_traits,std::allocator>val)This method creates a NEW std::string , loads the contents from disk, then throws it away.This code has been working fine for years on everything except mac.
Okay I have talked to my contacts at Apple, and it is not possible to get the structure of a buffer from a compiled shader.The API does not support it.So... I am screwed and have to do something completely different.
More details.I have used vertFunc.GetVertexAttributes(); to build a VertexDescriptor, but the key thing is the globals buffer at the head of each shader.When trying to get a reflection pointer to parse this I get the error.Attribute at index 0 references a buffer at index 0 that has no stride.But I need the reflection to be able to work out the stride.
