Got it and recompiled all, but no difference, core the same place, the same backtrace. At what place to you pull out the number of images so I can check we are getting a sane value? All I see is zeros.
There are two .iml formats.
I guess we are dealing here with newer one. In the new format, there are image headers (with names) and images are compressed in about 4KB blocks (because compressing several small images together yields better compression ratio than compressing them individually).
The problem here is most likely that number of headers does not match number of images in compression blocks (there is more headers).
placing a couple of LOGs and DUMPs there might reveal what is going on.
Actually, its just size.cx*size.cy and at 3328 pixels each, that is the right value. So assuming 3328x3328 is correct..
So +1, and +3 should be 0d00 0d00, in LE, or rather, 13x13. However, I get 3328. ($D00) Peek16le isn't flipping?
-> is 0xd00, 0x00d is much more realistical (first picture in the .iml is 13x13 pixel image).
When I rsynced the new Util.h it over-wrote my port changing, including setting of flagPPC. Sigh.
Anyway, back to where we were, looking at the image editor segv.
Called LoadIml(), which does not find IMAGE_ID and IMAGE_DATA, so it throws the exception, and loads in a more low-level loader.
Should sizes be set here? Before we call, or is it just uninitialised?
encoded_data looks correct, in that it was parsed in ok.
But it dies in RLEToAlpha.
Makes me think the size should be "somewhat smaller".
You set the size at IMAGE_END phase, I don't recall it reading IMAGE_END. Could it be our .iml file is incorrect,old ?
The image editor loads without core dumping, and displays my first icon just fine.
When I rsynced the new Util.h it over-wrote my port changing, including setting of flagPPC.
Ooops. Can you post the patch please so that I can apply it?
Based on the code, looks like problem in serialization. Will look at it asap.
Coonfirmed&fixed (well, at least I hope).
In the process, I have encountered an interesting problem - serialization of float and double.
How is the float/double format on PowerPC (or other non-x86 CPUs)? Is it the same, just needing to swap the order of bytes like integer types?
OK. It really seems like fp numbers are the same, just swapped. Altering code to this..
Only patching that is questionable is the plugin/bmp/bmphdr.h with my extra casting.
So currently, you set "flagPPC" or "flagX86" in the Build Environment variables. This will trigger code to add "-arch X" for cc and lnk times.
HasFlag("PPC") so that won't work either.
Need to be able to trigger extra linking variables (since they can not be specified in Build Environment).
then I can add linking flags in GccBuilder.cpp.
Which way to do you prefer?
Yeah I'm okay with that. I will change it to be as shown above, and we specify the build type with "-arch" in BuildEnv. Then the lnk additions will also work.
Well, I am afraid that __LITTLE_ENDIAN__ could bite us with ARM. Is not there some __power_pc__ macro?
Last one could be interesting.
Ah whoopsie.. I assumed you had previously done CPU_PPC to be powerpc, since the PocketPC cpu arch is ARM, SH3 or MIPS.
I will guess what is needed here and submit a patch.
// defines set by OsX for us.
However, can you help to find a solution as to how to be able to do Intel build on a PPC platform and vv.
The problem is, I need to set "-arch i386", which currently I set in "Build Environment". This is only use for Compile, and not use in Linking. There are no Linking options that I can see in Build Environment. So without that set, "__i386__" is not set, so the linking is done as POWERPC.
If no extra input boxes in the GUI, how can I user-optionally build for different archs?
The sources specify "linkoptions" which is Gathered from pkg.link. Not sure where that comes from.
I could take out "flagOSX11" and make two flags, but that seems uneccessary when you have a fully features build environment setup.
Can I define a new GCC32 and supply different flags?
Fetched latest sources to try out the Serialization changes (20th GMT 01:00).
Lots of issues in Installer.cpp (path not defines etc) but I assume that is just work in progress, so //'ing my way through that. It didn't like "::" in "::GetLastError()" in Socket.cpp.
That "name" and "file" are NULL probably is not good? But might be normal behavior for all I know.
Also, I'm in _awe_ of the size of your "ide" variable. I'm never doing "p ide" again.