Supermodel Forum

In the current build the polygon header hashing mechanism uses an unsigned 64bit integer to store selected header property bits. This space is however insufficient to store all the, possibly, useful data we need.

Hence I adapted a CRC32 algorithm found here (there're lots of them in the wild, maybe even faster) that calculates an hash from a stream of bytes from a given chunk of memory. The value returned should be unique for a small amount of data (all headers = 28 bytes).

I included header masks to choose what to hash, replicating the current build behavior plus some other useful bits. In the future we can unmask additional bits if required.

This fixes LeMans 24 headlights, and maybe other corner cases as well.

In addition I temporary disabled in <New3D.cpp> the "header[6] = 0" check which, as I commented in, doesn't seem to cause artifacts.

Patch for r679

Harry,
how did you get the before picture to look like that?
This is what my current build at least looks like



The header[6]=0 check is something left over from the legacy engine. But if i recall its a dirty hack to stop it running too far into junk memory. Perhaps it's not needed now, not sure without much testing.

Games like virta fighter, during the load screens between levels its simply loading data and there are no 0x88 to flush the database. And we are trying to draw the database during this .. loading period. It's one of those things i'd really like to fix.

Ian wrote:how did you get the before picture to look like that?

Wish I knew The funny thing is that I compiled the official build to make those screenshots, just to be sure to not mix something from my private one.

It was a long standing issue, at least in my situation, that's why I was in need to introduce a crc32 hashing algorithm.

Hello
Screenshot of the latest build uploaded to Emu-France
I think that you can not see the headlight



From Google Translate

model123 wrote:Hello
Screenshot of the latest build uploaded to Emu-France
I think that you can not see the headlight

Thanks model123, infact there's no headlight. Ian, maybe you've some little secret not pushed in the official tree...

r679 screenshot ^^

I had a quick look at this one.
I tried with the official build and you are right, the lights don't show. But I am pretty sure it is a transparency error, since in my working build I didn't change anything related to hashing at all.

I think (I am guessing) they are getting depth tested out because the translucent glass is being rendered before the lights. Why this would be fixed by changing the hashing ... i am not sure. Sega rally has a similar error in the svn build for the same reason I think.

Ian wrote:Why this would be fixed by changing the hashing ... i am not sure.

maybe that since I'm including some other bit in addition to those in the official one, those make for a new entry in the std::map container since the hash is different.

By the way, in my build polygon transparency is calculated like this:

Code: Select all

p.faceColour[3] = std::max(0, std::min(32, ph.Transparency()) * 8 - 1);


given that the ph.Transparency() returns an integer. But this is uninfluential in respect of the official build.

Ian wrote:I think (I am guessing) they are getting depth tested out because the translucent glass is being rendered before the lights.

Well, I tried to discard transparent polygons in fragment shader and now they show up again... so it seems to be (also?) a depth testing issue. I'm guessing with the new algorithm the headlights' header bits are set so they're not tested out (maybe a correct translucency value, I don't know since I din't have the time to check it).

Mesh splitting shouldn't make any difference to the draw order, unless the way its being split means its losing its texture alpha flag?
I checked with the superdebugger and its using texture type 7 for the head lights, which has 4 bit alpha. I also coloured the polys red based upon if texture alpha is set and it's definitely set for the head lights. So with the current code it should be drawn in the 2nd render pass, which should mean it will depth test against the glass infront of the lights.

But I am pretty sure the actual draw order should be something like

Opaque
Texture Alpha (sorted)
Translucent stencil polys (z pass)
All translucent polys