[Homebrew] Resident Evil: Hazardous Battle File #1

Thanks for the explanation. I'm at work, but I'll take a closer look at your example later today. As for the reference to SGL/SBL, I don't use it at all. I wrote my own open source library: https://github.com/ijacquez/libyaul/ This is the actual 3D "test" in case anyone is interested.


By the way, I didn't mean to derail your thread. Nonetheless, I'm looking forward to playing the game and learning a bit more about the engine.

 

So you have essentially a hash table (OT) where the key is the Z value in world space divided by 16. And let's say that you have a bunch of primitives roughly close together (i.e. near the same Z value) at OT[255]. Effectively, the "value" of this K-V pair is a linked list of primitives. Within that, it's sorted manually?

Is this what you mean?

 

It's really nothing more than a simple LIFO list with levels of depth. From Sony overview:

 

Getting close to a battle demo with 1.5 running inside Squeeze Bomb.


Random question: would a Hunter/Tick extra round add anything or should I keep that out and maintain the current roster of enemies?

 

honestly, adding a hunter/tick would make it alot harder seeing as how damaging and fast the tyrant is.

 

Well, that in the video is the advanced course, which is unlocked when you pick an extra outfit. I made it "harder" that usual to give some kind of variety and a bit of a challenge. My idea was to make Hunters or Ticks appear in alternate formations for other courses.

 

It's not a hash table, it's just a linked list. The position you add the primitive to the OT is obtained simply by scaling the transformed Z coordinate to the list length (or the subset of the list length you are using for 3D) and linking it in there. If you subsequently add another primitive at the same depth, then that gets linked into the same entry - but now its successor pointer is pointing to the first primitive that was added rather than the subsequent entry in the OT.

Note that you can put anything that has the correct link structure into the OT - including other OTs, and this was commonly done when the developer wanted more depth resolution over a part of the Z range without wasting memory by using the increased resolution for the entire list. Also note that the whole idea is that you don't have to sort the list - every insertion automatically happens at the right point at the time it occurs. For primitives that are at the same OT level, the direction the list was initialized in (which is under programmer control) will determine if the first of the last linked element appears in front.

 

then yes I can see that working as a way to give variety to the other courses.

 

It's not a classic linked list which starts empty, it is an array which is cleared using the DMA engine. When the list is rendered the DMA engine first reads the primitive header, which is a dword made up of the size of this primitive and the pointer to the next primitive header. The clearing puts in 0 for the size and links each dword to point to the next (the SDK has functions for clearing in both directions, but only one direction uses DMA to clear it & the other direction uses the CPU and is much slower).

If you use the library in the way the documentation says, then it is logically more like an array of linked lists. If you have all your primitives z-sorted already (or draw order isn't a problem for you) then you can just build a linked list without the array at the start and the hardware won't waste time fetching all of those zero length primitives. In most cases the time to fetch those is quicker than any other method of sorting, but it's possible. The index into the array doesn't have to be Z scaled linearly, it just usually makes sense.

The more precision you lose from Z then the smaller the array can be, but the likelihood that you'll draw two primitives in the wrong order increases. The primitives don't include the Z, so you can't write code to search through the list to find the appropriate point. You could assume that closer primitives are larger, but that isn't necessarily true and it's going to really hurt performance.