Author Topic: Porting MASM5 code in Quake 2 to GAS -- Unexpected rendering results  (Read 1279 times)

maraakate

  • Regular Member
  • *
  • Posts: 12
Re: Porting MASM5 code in Quake 2 to GAS -- Unexpected rendering results
« Reply #15 on: May 20, 2019, 01:01:36 PM »
It may be easier if your GAS version supports it to use Intel rather than AT&T notation.

It's down to this one function that needs converted to GAS.  This is actually for the Q2DOS project: http://dk.toastednet.org/Q2DOS/.  This is what is remaining to be on a feature parity level with Windows.  The DOS version is compiled with DJGPP which is just GCC for DOS.  Converting the other files to MASM would probably take more time and I'm assuming whatever the problem is here it's probably something obvious and stupid that I don't know about.

maraakate

  • Regular Member
  • *
  • Posts: 12
Re: Porting MASM5 code in Quake 2 to GAS -- Unexpected rendering results
« Reply #16 on: May 20, 2019, 01:21:18 PM »
I ran both in visual studio with attached to debugger and broke to disassembly and well... here is this at the end of this function notice the add eax, ecx and how the opcodes are different.  Is this bad?



maraakate

  • Regular Member
  • *
  • Posts: 12
Re: Porting MASM5 code in Quake 2 to GAS -- Unexpected rendering results
« Reply #17 on: May 20, 2019, 01:50:28 PM »
Part of the puzzle...  i forgot that a few spots up there was a cmp eax, offset _R_PolysetDrawSpans8_Opaque I incorrectly turned this into cmpl C(R_PolyDrawSpans8_Opaque), %eax.  It needed to become cmpl $(C(R_PolyDrawSpans8_Opaque)), %eax.  This now allows the front side facing of the skins to actually work, however the backsides are still wrong and when viewed at certain angles can crash things.  But now we are getting close.

maraakate

  • Regular Member
  • *
  • Posts: 12
Re: Porting MASM5 code in Quake 2 to GAS -- Unexpected rendering results
« Reply #18 on: May 20, 2019, 02:21:50 PM »
Success!  See commit log at https://bitbucket.org/neozeed/q2dos/commits/f5bf93e3a78e112ae1f766606471a6c5e67283d4.

Thanks to everyone teaching me about disassembly and checking opcodes.  This also taught me how to read this stuff like https://www.felixcloutier.com/x86/add so I can understand this more.

One more function left to go, R_AliasTransformFinalVerts in r_alias.c (forgot about this function) and the DOS better will be feature parity with Win32.  At some point, I want to see about converting this code SSE for Pentium 3 era machines and allow separate code paths.  In the mean time I have ordered Daniel Kusswurm's x86 assembly book linked elsewhere on this forum and I look forward to reading it and asking more questions on how this can be optimized further to take advantage of SSE for the vector floats. :)

Again, thank you so much everyone on this thread!