Alignement will have to be discussed here (but I'm tired, now).
Maybe I'm totally wrong here but doesn't work gcc2 in this way, too? You know, 32bit alignments unless you specify -mshort option. This my "guess" supports also the fact gcc2 compiled quake never produces such warning (about non-32-bit-aligned stack). But I'll leave the word to more experiences people ;) Btw that means gcc4 now aligns integers and structures on 16bit boundary?
Yes, it hopefully produces "Bad surface extents" at runtime. The code is
really wrong, because it does not consider the potential floor problem.
It would be interesting to investigate deeper that approximation
Can you give me some clue what to look for? Every floor()/ceil() function? Isn't possible that different behaviour with different optimization options are because different FPU precision is used? (single vs double floats, fmul vs fsglmul etc..). I'll look at this asap.
behavior. Maybe some differences in the FPU and soft-float implementations.
I can't imagine how could be this possible, -m68020-60 uses FPU, too.
And I finally found it ! It is a bug in GCC 4.2.2. I posted a detailed
bug report on the GCC Bugzilla.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34947
Vincent, you rule! ;-) Now just wait when the guys decide to fix this.. I don't expect someone here is able to make a patch.. I'd like to be wrong ;)
So I'll disable CAN_DEBUG_WITHOUT_FP it in my next patch, and we will
have to decide if it should be enabled again when GCC is fixed.
Wise idea. Please make that patch asap ;) So general rule, with your new patch, will be *not* to use -fomit-frame-pointer in both debug and release version, right? This probably apply to c++ code as well?
another function. Definitely: the current GCC 4.2.2 is unusable with
-m68020-60 and -O
damn it. btw if you'll have some time, try to look at gcc4 compilation with make CFLAGS=-m68060 against gcc4 (in normal -m680000) -- it produces error, too, however, totally different. That's the reason why I'm waiting for that patch so much since I want to try this, too.
Quake console messages are displayed in the TosWin console. I was very
amused when I first saw "You got the shells"... in the bash window !
;-))
Anyway, is it possible to play the real Quake (not the Unreal :-) ) on
ARAnyM, with OpenGL ?
possible yes but no one did this. maybe it's not that much work, since there is that natfeature opengl in aranym (I've seen some screenshots from Francois or Olivier with OpenGL apps running).. maybe it's just a matter of Mesa lib compatibility with the OpenGL quake requires. But honestly, I see no point in this -- everyone can play quake in native environment. And there could be some hardware problems -- for example, as far as I know, there's no way to detect when the key is released and when pushed in the other way than directly reading ikbd hardware. As I remember, aranym's support for ikbd isn't 100%.
Anyway, thanks again for your great work!