Rice Video Community version

[death--droid]

Hmmmmm a very interesting idea you have there, but I can imagine this becoming a labrynth of different folders. Probably wouldnt be the hardest thing to implement. Mind sending me the files your using as an example so i know exactly what your talking about.

 

[microdev]

There are at least two currently undefined name that could be used to define a texture, or a group of related textures.

Those two "currently undefined" names are checksums: The first is the DRAM (texture data) CRC (=Cyclic Redundancy Code) and the second is the palette CRC. So you would group textures with identical checksums.

Further details about how the cryptic texture names are composed can be found in this post.

Not sure how this would help you. Do you want to group identical textures?

 

[NES_player4LIFE]

Hmmmmm a very interesting idea you have there, but I can imagine this becoming a labyrinth of different folders. Probably wouldn't be the hardest thing to implement. Mind sending me the files your using as an example so i know exactly what your talking about.

At least a labyrinth has boundaries. The current method dumps everything into a bucket and we have to fish for what we are looking for.
Files and more information also added to the post.
As it happens 822B3E9D refers to a few more files then originally stated however these files are associated within the game as action textures, such as roll overs and kart crashes.

Those two "currently undefined" names are checksums: The first is the DRAM (texture data) CRC (=Cyclic Redundancy Code) and the second is the palette CRC. So you would group textures with identical checksums.

Further details about how the cryptic texture names are composed can be found in this post.

Not sure how this would help you. Do you want to group identical textures?

I had forgotten about that thread.
Thanks for explaining the code again.
I hope to group associated textures within a folder named for the common denominator.

 

[Guru64]

What's 'spirit mapping'?

 

[NES_player4LIFE]

What's 'spirit mapping'?

It refers to collecting the 2D slices of a 3D object and arranging them into a orderly output.
Imagine, if you will, slicing an apple into 50 slices so that you can unfold it into thin chips. These are the files in question.
Now imagine that you wanted to paint a fruit basket but you just cut the last apple.
Now have a pile of apple slices without any order that you're trying to arrange.
You decided to go for a walk and take your mind off of your problem, however your girlfriend makes a fruit salad by throwing a sliced pear into the mix.

You wish that you had a way of identifying the apple slices from the pear slices because you need to fold these seemingly identical objects back into their original form.
What you need to map them so that you are able to place them correctly. You know what the fruit looks like but arranging it is impossible.
I'm suggesting a knife that will cut the fruit and mark each slice with an identifying number. Thus giving you a scientific way to recreate a 3D apple from 2D chips.

 

[Fanatic 64]

It's actually a bigger 2D object, the tiling is done to get around the N64's 4KB texture cache.

"Spirit Mapping" would refer to grouping all the tiles that make up the larger 2D image.

 

[microdev]

At least a labyrinth has boundaries. The current method dumps everything into a bucket and we have to fish for what we are looking for.
Files and more information also added to the post.
As it happens 822B3E9D refers to a few more files then originally stated however these files are associated within the game as action textures, such as roll overs and kart crashes.

Ok, I see. So the filtering would mean group by identical

• DRAM CRC = identical textures (with a different palette - most probably duplicates can be omitted as palette is changed by the game(?))
• Palette CRC = different textures however with identical palette (chances are high that those textures belong to an animation frame of the same cart)
• DRAM & Palette CRC = such a texture should only exist once thus does not make sense

So grouping by identical palette CRC seems to make the most sense.

Now the issue of aligning the right textures would have to be addressed. A possible approach might be to check the texture location coordinates when dumping:
A cart seems to always consist of two textures with identical size (64x32) and the same palette. Thus both must have the same x-coordinate and the second has to be located 32pix underneath the first (given there is no overlapping).

This circumstance might allow the plugin to automatically identify corresponding textures and either group them in a sub-folder or add to both the DRAM CRC of the upper one as a prefix (probably better).

 

[NES_player4LIFE]

The plugin should process both options:

• DRAM CRC
• Palette CRC

DRAM CRC for most of the textures.
Palette CRC for other less common textures.

The plugin should be able detect these patterns and adjust the output to place textures into folders according to their respected address.

 

[death--droid]

Hmmm i see what your trying to do, wouldnt be the hardest thing to implement i guess. Not really a priority option though.
New Version, fixes PAL CRC generation, and change up how where dumping textures.

Download Version 0.4.2: http://adf.ly/vcUZC

 

[NES_player4LIFE]

Thanks for taking the consideration.
What is the dump directory, I can't seem to find any new data at texture_dump.

EDIT:
It seems that the plugin only uses preexisting folders.
ci_bmp
ci_bmp_with_pal_crc
png_all
png_by_rgb_a

 

[death--droid]

Slight mistake in my part, accidently removed a reference to the function that generates the folder names.
Theres a few bugs ive introduced in recent version that I need to deal with XD Quickly though ill fix the folders problem.


Download Version 0.4.3: http://adf.ly/vdGVd

 

[death--droid]

Fixed a few more problems to do with texture dumping and texture loading i accidently had introduced.
One was related to using D3DX function to save textures as it seemed to be saving textures incorrectly, the other was to do with the config calling some of the highres functions when they shouldnt of been, causing the plugin to crash out.

Download version 0.4.4: http://adf.ly/vdbd1

 

[death--droid]

Ok code is under a bit of heavy work now, hopefully be able to provide a faster, cleaner and more accurate Video plugin by the next release.

 

[weinerschnitzel]

Narann's MK64 disco color fix is a nice commit there. Thanks for taking care of this plugin and keeping it current with all of the upstream Daedalus Graphics work and Narann's improvements to the OGL version. The project has changed alot -and for the better- since it's move to Github. :thumbsup:

Was the point lighting issue with Conker's BFD ever resolved?

 

[death--droid]

No problem Weinerschnitzel! I'm just glad the plugin still gets a bit of use and attention from others And yeah Narann is making great progress as well working out odd quirks of Rice Video.

Hmm sadly I still haven't managed to work out whats happening with it yet :\

 

[aiyoros]

Hi people. I´m not new in here, I forgot my old mail and username

btw, I'm trying to use the plugin in PJ64 1.6 but doesn´t load giving an error "error to load plug in"
In PJ64 2.1 doesnt appear either.

EDIT: Windows 7 x64

 

[NES_player4LIFE]

btw, I'm trying to use the plugin in PJ64 1.6 but doesn´t load giving an error "error to load plug in"
In PJ64 2.1 doesnt appear either.

Did you prep your system?
"Requirements: MS C++ 2013 x86 Re-distributable Package (Link here http://www.microsoft.com/en-au/downl....aspx?id=40784)"
I had the same problem but once I updated it runs fine.

 

[aiyoros]

hmmm I´ve downloaded the x64 version before reporting my problem, will try the x86 one!

 

[Fanatic 64]

You need x86 for x86 programs (Project64).

 

[aiyoros]

Fixed =)