>Easy solution: If you're using Xcode, be sure to use the deployment build, and not the debug
i can confirm that this fixes most issues i described, so this splits this bug into these 3 remaining problems:
Revision 230 should at least build now. Sorry about that.
I suspect that this "deployment" build thing isn't really a legitimate fix in that it probably just masks the problem. My hunch is it's something to do with altivec's requirement for 16 byte alignment. Information appears to be scant, but from what I can gather turning "deployment" on enables -Os, that is to say optimisation for size. It's possible that this changes memory structures in such a way that the problems you are seeing are masked. Certainly the fact that it only seems to partially fix things gives credence to this theory.
Apparently the linux/ppc build (with altivec) displays similar problems. If somebody wants to buy me a Mac Mini I'm sure I could figure it out ;).
>but from what I can gather turning "deployment" on enables -Os
among turning off various debugging flags it turns on -O2 instead of -O0...
and indeed if i change the -O0 in the debugging build to either -O1, -O2 or -Os it suddenly starts working, just like the deploment build
because some of the code checks for __OPTIMIZE__ which is only defined for builds other than -O0 i tried to compile with -O0 but defining __OPTIMIZE__ manually but that didn't make it work...so it has to be related to something other, maybe alignement as you said
(In reply to comment #3)
> Revision 230 should at least build now. Sorry about that.
>
> I suspect that this "deployment" build thing isn't really a legitimate fix in
> that it probably just masks the problem. My hunch is it's something to do with
> altivec's requirement for 16 byte alignment. Information appears to be scant...
Mac OS X/Altivec related: It's almost certain that alignment is a problem, with what I think are some size issues.
Forcing int and function alignment by playing with the -falign-[thingie]=2 flags seems to cure most problems (though entering the brave new world of altering the release code produces some other problems: I went back to makefiles, as they're more familiar to me than Xcode). I had some encouraging results under gcc 4.0 using -m32 and -falign's, though I'm letting people with more talent and skill than me figure that out.
As for the com_printf overflow errors: that's seen only when running the official Id vm game, and is cured by rebuilding the qvm files. I'm pretty sure that's not an engine issue at all, but what do I know?
Distantly related, but perhaps having a bearing upon things: integer size and endian issues crop up extensively when attempting to build the bspc tool, though those seem restricted to the actual bspc code and not the common code from eleswhere. It -almost- runs, but logs some huge negative values and produces aas files almost exactly twice as large as 'real' ones and that cause the egine to barf up a crash; both symptoms of integer arrangement being bass-ackwards and too large.
Some personal opinion (though two decades outdated): I think many of the problems sorting things out are due to the preprocessor's heavy dependence upon environmental/compiler defines rather than through a project-type config header for conditionals. Many, if not most, of the recent breakage I've seen reported stems from some __thingy__ define provided by the compiler, environment or a link stub lurking in the code and by the preprocessor having to guess rather than being told what to do. But that's just me being old school.
All the Altivec-related crashes should be fixed in the latest svn revision.
You can turn altivec support on and off at the command line or at runtime by toggling the "com_altivec" cvar between 0 and 1.
We detect Altivec support at startup, and refuse to let you enable it if the system doesn't have an Altivec unit...however, the Altivec code is always built into the binary now, and takes steps to avoid running it on G3 systems.
--ryan.
Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.
--ryan.
>Easy solution: If you're using Xcode, be sure to use the deployment build, and not the debug i can confirm that this fixes most issues i described, so this splits this bug into these 3 remaining problems:>but from what I can gather turning "deployment" on enables -Os among turning off various debugging flags it turns on -O2 instead of -O0... and indeed if i change the -O0 in the debugging build to either -O1, -O2 or -Os it suddenly starts working, just like the deploment build because some of the code checks for __OPTIMIZE__ which is only defined for builds other than -O0 i tried to compile with -O0 but defining __OPTIMIZE__ manually but that didn't make it work...so it has to be related to something other, maybe alignement as you said