I meant ripping the sprites themselves.

Unbelieveable work. I remember looking into this game with VRAM and noticing how everything was just pieces, I lost hope. And now here it is again, in the flesh with fresh sunlight bestowed. Excellent work man 

Hey, how are you guys doing?

Making some progress on CV NDS games, I begin to understand how a NDS game work.

Ever since I made no progress on sprite's palette, I think maybe the palettes are shared by both map tiles and sprites. So I switched my direction from hacking sprites data to hacking map data.

Also, inspired by SNEER (Symphony of the Night Editor and Entity Recompiler) by Nyxojaele, I'm extracting the layout info to put all map*.png on the right position. It starts to look like a level editor now.



It is like a interactive VG Map, I like this! 

Now I'll need to hack sprites + object + item data to replace all the X's. And then finish up with UI elements, special effect, and other minor stuff.

Cheers,
- Rufas

EDIT: Attached 2 sample maps for you guys to play with.

Found the palettes! Just like SOTN, they hardcoded it into assembly, hence it is pretty hard to find if you don't know what you are looking for.

The whole process is like
1) Look for a monster data, like HP, EXP. From there you'll find the complete set of data including drop item, drop rate, weakness, resist for every monster/boss in the game.
2) One of the data is a function pointer, follow it.
3) You'll see some assembly instruction like this:
  loc_2271b4  r1 , Lxx_2132a30
  loc_2271b8  r2 , Lxx_22ba95c
  loc_2271c0  r3 , Lxx_22aad4c
and r3 is the pointer to the monster palette.

Since this is how it hide its palette, I'm forced to write a ARM assembly parser to locate the data:
https://github.com/rufaswan/Web2D_Games/...n_clut.php

But the problem doesn't stop there. All boss has its own overlay file, so the function and palette is located over there instead. So now you'll need monster + overlay pair data.

OOE Dracula completely breaks the rule. Unlike the rest of the boss, only its function is on its own overlay file, its palette is actually on the map overlay file. The king of the night just do whatever it wants!

In short, the palettes are all over the place, across multiple overlay files, and buried in assembly code. The whole thing is one big wild goose chase!

Since it is hardcoded, I end up patching every monster:
https://github.com/rufaswan/Web2D_Games/...s_ACBJ.txt

(NOTE: POR Loretta palette is only a set of 9 x 16 color palette, not two different .cvpal)

As for the maps, all POR and OOE maps are ripped. DOS maps have something weird going on, and wasn't able to rip correctly.

I combined the maps from multiple overlay files and made a simple grid lines for background:
1) Green line is a tile. It is 16 x 16 pixels.
2) Yellow line is a room. it is 16 x 12 tiles.
3) Cross is added to the center of a room for room symmetry guide.

The full map of Dracula Castle:
OOE :
POR :

I wonder if SOTN maps can be combined?

Cheers,
- Rufas

Wow! You're doing an amazing job.

As pointed out by SmithyGCN there were a DS Vania editor out there:
https://github.com/LagoLunatic/DSVEdit

By comparing how different we are on handling maps, I think we are two different thing, even if we are working on the very same games.

At least now I can have someone else notes for reference. Let's see how they handle the map objects. From /constants/dos_constants.rb :


OH NO!!! EVERYTHING IS IN ASSEMBLY FROM NOW ON??? REALLY !?

... seriously ...

Tell you what, I'll just put up what I got until now, and come back later. Way later.

Here are all the monsters and maps I ripped:
http://www.mediafire.com/file/9mlq425bwr...17.7z/file
http://www.mediafire.com/file/ha1sf4mcz9...35.7z/file

UPDATE : objects
http://www.mediafire.com/file/p2r4vakjkg...30.7z/file

Expect updates for DS vania to be slow from now on.

Take care,
- Rufas

It's really fascinating to watch a video that shows literally the entire game and its contents from a developer's viewpoint. Outstanding work =D

Back to rip even more Xenogears sprites.

But before that, let's go back to have a look back at those animation data. Tried to understand them with a debugger, and I realized it is not some frame-to-fps animation data, but a 128 cases virtual machine opcodes! It has jump, return, for, if, types of bytecode down there! ...I'm backing away...

Ripping NPC sprites can be pretty straight-forward, except for some odd 8 files. Going to the map that loads the data, I realized they moved the sprite data from VRAM 140,100 to 300,0 at run time, and then paired with the sprite data on the right. Couldn't figure how it happened, so I manually patch them.

Among one of them is Gaspar Uzuki, a sage from Shevat. No matter how hard I look for its pairing sprite data, I just couldn't find it. Luckily TCRF has the code to access the debug room, so I use it to jump to a map with Gaspar loaded, and mess around. This is what I got:



So yeah, Gaspar sprites are BROKEN! According to the assemble data, it should have another 256x15 sprite data, but it is removed! But then again, Gaspar only shows up during cutscene (and only 1 at that!), so nobody really notices its missing parts!. Gaspar's walking sprites are all unused.

Will be posting the sheets to the site soon.

Cheers,
- Rufas

I was reading all the process and explanation that Rufas brings and i am impressed, he must be the best ripper with lots of knowledge in all the story of "rippers", before it was ripping screenshot by screenshot, but this guy now came with a totally new way of ripping stuff, something that very few of us is able to understand or work with... this guy deserves all my respect

Let's talk about special effects sprites.

I know the game can change its palette on-the-fly and allows the sprites go "rainbow" for visual spectacle. So it also means I'll have to examine frame-by-frame to get the palette.

But with over 100+ folders of special effect, I just don't have the time or patient to do it. So I'll put the files here for anyone interested. I recognize it is a hard work, so you can just submit them to TSR directly.

http://www.mediafire.com/file/5y8b7qedc2...6.zip/file

Take care,
- Rufas

P.S. I also update the first post with overworld sprites (they are already submitted).

(10-24-2020, 06:23 PM)rufaswan Wrote: Let's talk about special effects sprites.

I know the game can change its palette on-the-fly and allows the sprites go "rainbow" for visual spectacle. So it also means I'll have to examine frame-by-frame to get the palette.

But with over 100+ folders of special effect, I just don't have the time or patient to do it. So I'll put the files here for anyone interested. I recognize it is a hard work, so you can just submit them to TSR directly.

http://www.mediafire.com/file/5y8b7qedc2...6.zip/file

Take care,
- Rufas

P.S. I also update the first post with overworld sprites (they are already submitted).

Thanks a lot buddy, but i think those animations are animated with a 3D program, i dont have a single clue on how to use them to make the effects frame by frame and use them, i can make something out of them, but would take lots of time and work...
I am sure, however, that someone will use them in a good way.

Amazing!
I was just wondering if my goal is just to "upscale" the sprites.
How do I go about it?
How do I make beetle HW detect my upscaled sprites?

(04-16-2022, 09:55 AM)Topheryu Wrote: Amazing!
I was just wondering if my goal is just to "upscale" the sprites.
How do I go about it?
How do I make beetle HW detect my upscaled sprites?

Hi! The guys from Xenogears Perfect Works Build asked this question before, so I'll just quote it here:

Quote:Ordinarily, the normal emulator internally have 1x resolution and 1 MB of VRAM. It will then upscale to 3x (along with filters and such) when render to the screen.

These enhanced emulators however, internally use 3x resolution. Every texture loaded is upscaled 3x first then put on the VRAM (and used 3x VRAM space, hence it is now 9MB VRAM (3x width and 3x height)). Because they already have the texture, they can calculate its hash and load the HD ones instead. That's how HD texture replacement works.

So no, unfortunately. You can't just replace the TIM files (within the BIN/CUE) with HD ones. It is pretty much an emulator-only feature.

If you want to release a HD texture pack, you can do it with PNG, no need to convert to TIM.

So, to use upscale texture, according to this guide:
https://www.libretro.com/index.php/beetl...available/

1) Turn ON texture dump option, and play through the whole game to get all texture in the game (texture dump works only for loaded assets).

2) Use a tool to upscale all texture files within the dump. You can any filter, including machine-learning, to enhance whatever you want. But remember, DO NOT rename the file names, as that's how the emulator find the HD textures.

3) Turn ON texture replacement option, and change the internal resolution higher than 1x.

I would recommend try to replace the character portrait first to get a feel on how the whole thing works, like this mod:
https://www.reddit.com/r/XenoGears/comme...y_release/

From there you can try upscale manually.

Good luck!
- Rufas

OK thanks I have already done these things.

Not the texture dump necessarily but rather the texture replacement bit.

The Xenogear subreddit has already released texture pack for background and portraits.

My personal project would be to upscale the character sprites instead.

I know that it would look weird but I just wanna try it out.

My only problem is the file names associated with it because Beetle emulator renames these files different compared to once you've made.

For example.
Your fileanme for this portrait is:
https://imgur.com/f0MPjKM
While Beetle HW would rename this similar portrait is:
https://imgur.com/fK0EdIn

Will it work if I just put it in as is?

Thanks for your efforts btw.

You'll need to follow Beetle filename for the emulator to find the texture. So in your example, 000492.tim will need to be rename and replace 46c8e27-bc2f6e29 file from Beetle.

000492.tim is auto-generated filename when ripping game files from BIN/CUE.

46c8e27-bc2f6e29 is hash generated by Beetle when loading the texture. When Beetle find a filename same as the hash on replacement folder, it will load that file instead the original texture. Hence, "texture replaced".

Beetle detect character sprites just like any other textures, backgrounds and portraits. The character sprites dumped from Beetle is a bunch of unassembled parts, which is correct behavior, since the game still need to loop through the data/texture atlas before actually rendering to the screen.

My assembled sprites are the result of looping through all the data/texture atlas with the pairing sprite textures. So no, you can't upscale my assembled sprites to use with Beetle, unfortunately.

Also, Playstation has only 1MB VRAM, and Xenogears managed to use nearly all them and end up having very little space for main party sprites. So the devs load them to RAM instead and go load-on-demand to VRAM when needed. You might find Fei's parts is dumped as a bunch of very small textures, instead of usual NPC/monster at 256x256 texture.

Hope this helps!
- Rufas