rsdlink and tmdsort for windows 64

Graphic based area of development (Graphics Processing Unit), including the Geometry Transform Engine (GTE), TIM, STR (MDEC), etc.
Post Reply
Mills
Curious PSXDEV User
Curious PSXDEV User
Posts: 14
Joined: May 3rd, 2016, 11:21 pm

rsdlink and tmdsort for windows 64

Post by Mills » March 3rd, 2020, 4:28 am

I know this has been asked a lot in the past years... is there any way to get 32 bit versions of these programs?.
I guess not... So is there another method of creating the TMD files?.

I could create a TMD, following the file structure (I think). But I don't know what tmdsort is doing to the file, so that I can reproduce it.

User avatar
Someone
Curious PSXDEV User
Curious PSXDEV User
Posts: 20
Joined: August 7th, 2016, 11:40 pm
I am a: ROM hacker hobbyist
Want to Find: Interesting info about PS1

Re: rsdlink and tmdsort for windows 64

Post by Someone » March 3rd, 2020, 5:00 am

You can always compare files before and after sorting. But readme explicitly says that polygons are sorted by their type. You should know that PS1 can render different types of primitives, but before rendering they must be transformed and library has separate routines for each type, chaotic jumping between these routines will kill performance so it is much efficient to transform polygons in batches by their type.

Mills
Curious PSXDEV User
Curious PSXDEV User
Posts: 14
Joined: May 3rd, 2016, 11:21 pm

Re: rsdlink and tmdsort for windows 64

Post by Mills » March 3rd, 2020, 8:51 am

Someone wrote:
March 3rd, 2020, 5:00 am
You can always compare files before and after sorting.
I tested several models, they are exactly the same, even a big planet I created with lots of triangles (1680) was unchanged after sorting it (performance is very good).

So I can forget about tmdsort.

By the way, this is a bit off topic, but I was testing xmplay lib, and I realized we can also ignore another 16 bit util called VABSPLIT, because vh header is always 3104 bytes in size, so:

Code: Select all

//this is the function to load an XM
int XM_VABInit(u_char* VHData,u_char* VBData);
If we load or include the whole VAB file as "vabfile", VHData is at &vabfile[0], and VBData at &vabfile[3104].

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest