Theme editor

  • RequestStream Movies, TV shows and anime streaming • 1 week trial
  • Donation Rewards & Vault Credit System Update
    A new important update has been posted covering the Donation Rewards bug, the reset of incorrect Donation and Platinum credits, the upcoming reclaim system for previous tracked donations, and the new Vault freeze/maintenance behavior. The goal is to remove bug-generated credits, protect real donation history, and rebuild the system in a cleaner and safer way going forward. - Jack Of Blades
    Read More

Hoping for some kind soul to help me with extracting ps2 roms...

Status
Not open for further replies.
I have all cutscenes and audio done finally still no programs to search through the files for cut stuff and can't find a program to open the art files
reply 2

There are two alternatives to going full scale "demake" in effort to uncover and rip files.

Alternative 1) Sampling
This will only allow you to sample from the finished game, or portions of the game accessible via the engine's in-game console terminal. In Sampling audio/video including images and graphic sub components, you can do this on original hardware or by use of emulator on PC. Though emulators may not be as ideally functional, running it on PC certainly makes getting samples easier especially if you want upscaled samples.

For original hardware, use a TV you can mirror/interact with via PC. Or you can do it the old fashioned way with VCR then using VCR to transfer to digital. From there you can take audio, video or images out of the digitized video. If mirror/screenshare access between TV and PC, you can ditch VCR and take sampling using PC tools.

For emulator, use of screen caps, software such as OBS and other means are conducted in sampling. In doing this you can also run an upscaler or CRT emulation layers over/with the ps2 emulator.

For images sampled, the video resolution will be low and artifactual regardless how you do it. Take this over to a vector image editor, trace the artwork/hui/gui or what ever, in vector format. Upscale it to any size you need then rasterize it, take it to a raster based image editor and save it out as PNG for less lossy and high quality formats.

For audio sampling, there are a few ways. As mentioned before there is audio recording via digital or digital voice recorder or tape deck if feeling retro, through either AUX out methods or "hotwiring" a home theater set up to AUX input of recording method.

With VCR to digital, VCR records audio data, so conversion of that to digital gives you the audio that way which can also be extracted from the digital video file +/- worked on in DAWs.

With OBS, you can record audio data from screen view either with video or separately.

With sampling, most games on ps2 include menu sections for a "sound test" portion of game which lets you "play/hear" all SFX in the game and the game's OST. For these reasons when combined with sampling, this is partly why most community doesnt bother with ripping these files. Sampling is just that much easier and can be done with most games.

Most games also feature "concept art" galleries and again the ability to sample these has over-ridden the necessity to rip them.

For in-game console, some "unsused" content within any ps2 game can be "called up" into active play or if a file accessed through menu system+console +/- file viewers. Its complex but can be done. Problem is, you have to know what the actual asset file is called and the code syntax within the game's console system to then call it up/spawn it.

alternative 2) devtoolkit research

Most games tell you in splash screens and in game credits, what tools were used to make the game. This will not tell you the specific plug-ins or addons used by each tool but by learning the engine used and all relevant devtools that made the game, you get a better expectation on what was handled with the game's coding and file/binary architecture. By looking into these engines, their relivant compilers and how they are "packaged into end user games" on engine+devtool case basis, you can "untangle" the mystery of binary file extensions that you cannot identify. This may provide insight in how to then "decompile" those binaries.

Apologies on double TLDR posting but thought you should know the options.

With sampling removing the need to decompile certain things, this plays a large factor deal into why the hacking community did not take interest in full game decompiler "demakes". This alomg with fact most OSTs can be bought/pirated and most commercial games featured a strong amount of "official presskit" media released by the developer company (concept art, mod pack assets packs for PC versions etc).

This also was hampered by fact to actually do a proper "demake" since by ps2, most games were made with an unknown assortment of plug-ins and Addons to engines, you usually have to manually build your own devtools to fully decompile a game, and those unique DIY devtools will be unique to exclusively that game.
 
I searched everywhere and there's nothing just those broken programs I mentioned
well for specifity+niche of this task, you wont get much from websearch to begin with. Wevsearch due to page rank BS n google junk will only give you top trending results from combo of keywords aka "file rip + ps2" as primary and all you're going to get is how to pirate clone ps2 DVD-ROMs to ISO for VM emulation play on 99 outa 100 results.

by looking into the game engine and devtools what made the game, you can learn more about some of the binary package architecture of the completed game. Aside from asking LLM AI, this is largely the onlyway to do this.

While some of these binaries can be unpacked if you figure out the devtool extension relation and what they are/how it is structured, not all such binaries will be this way.

For those you cannot back-engineer a decompiling solution for, you have to go into text editor and create a custom DIY devtool to do the job.

This is simply the process that us involved in fulk decompile demake of a game.

Alternatively, you can if you're lucky, find folks with code savy-ness in communities and ask them how to work around such solutions. 99.98% of ROM-Hacking community is just there to pirate+emulate either the vanilla version of games or slight indie mods of such games. Aka they will have 0 idea as to how to do any of this. Point is, finding such tech savvy software engineers in DIY indie coding servers is highly rare.
 
I may have to I know nothing about coding
well, surprizingly enough, only coding exp I have are a couple of middle school thru highschool classes on C/C++, indie research as hobbyist on my own into HTML during Myspace age, java and php python basic fundamentals from my dad (now a 32+ year linux redhat database systems server admin) couple HS classes on linux, and BA in Game Art degree's influence into Java/python through Adobe animate + HLSL node scripting of UE 4.23 thru UE 5 (unreal engine) coupled with almost 4 years now of Stable Diffusion based "hobbyist" scripting webresearch.

plus a few Q&As, such as an interview I did with the Dev of POOM on pico 8, (just informal talking to dev), researching Kippy's Doom 1 & 2 to GBA converters, Q&A into Unity again informal from Dev of Daggan, and a few just talking with ren'py devs.

Meanwhile from 2012-2018, I "on and off" researched easy68k and Sega MDs motorola assembly 68000 in attempt to learning what it took to DIY original game ROMs for SEGA MD/Genesis. Which I did find alot about, including the full system address manuals by Rex Sabio on how the MD/Genesis system works, n while the maths, functions and system limitations make sense, I still have barely a grasp at how to code in Assembly.

I also talked with the Devs of Pixel Vision 8 in how that works vs original hardware. Along with talking to devs of GB Studio and instructors on GB Studio's web forum on how to build origibal GB/Gameboy Color roms in that fantasy console dev system suite.

I have also been monitoring and loosely learning how Unity systems work since 2011. And have been researching DOOM building since about same time, though 2011-2016 I largely back-burnered that junk because at that time you still had to build mods by directly maths coding all the sector and linedef junk. In 2018 Ultimate Doom Builder got an overhaul, supporting psuedo 3D dev software GUI environment where you could manually sculpt the level instead of pure Maths coding everything.

All just the same, I know barely surface junk when it comes to coding and programing raw through text editor/manual coding. But have learned a great deal about High Level node based scripting.

Point is, learning the coding is a very long ass process that involves simply buying the text books and learning everything you need code repository library wise.

What I do know is the following:
games that are built in engines such as Unreal, are compiled in certain uniform/stamdardized structured formats.

In the editor you group assets by level/location and function of the asset type. In compiling those to end user gane version product (playable game application file) that hierarchal structure is built out into a series of binaries.

This structure of binaries depends largely on what plugins/addons you utilize, in particular the shaders utilized and how they work with textures/texture atlasses. Then there is also "optimization" of file compression to account for in end result of the architecture which again is relative to plugins/addons used for that particular engine.

Looking up the engine+knowing the end structure of the ISO's compiled binaries and their extensions, can give you some insight to which pluggins/addons were used. If by luck, you can figure out those plugins/addons, some of these have software specifically built to extract/decompile from those binaries when used with that same game dev engine solution (Using the engine that was used to make the game, you can in some cases decompile by getting the appropriate plugins/addons, but this is only some cases).

Other than this, you have to use text editor to go through a binaries code line by line, and manually configure through production of devtool apps, how to extract that data.

TLDR super short:
aside from texture/texture atlass extraction and model extraction +/- cutscene file extract, everything else, you largely have to get through sampling. Unless you want to devote up to potentially 5-10 years to code your full demake and restoration/remaster of that game. Unless you feel like paying 5-10 ppl like 10k+/- per year to help you do it in maybe 2-4 years.
 
As the title says. I'm looking for a way to extract the roms, but in my case, I want to extract the models from these games so I can enjoy it's content via Blender. So... I need to some how change them into OBJ or FBX files.

Any help would be appreciated as me and a few others are still trying to figure this out.
Have you looked on deviant art? Many files can be found on there of models that have been extracted from games.
 
Thread owner
Have you looked on deviant art? Many files can be found on there of models that have been extracted from games.
I have not. I have an account there but never thought to look for models on that site. Thanks for the tip!
 
There are a lot of different file formats that you can find there. Files formats for .xps - daz - mmd and more. I use to have a addon for .xps for blender so that I could load those files into blender. I was mostly only ever after the outfits as I use to port them into skyrim.
 
Status
Not open for further replies.
Back
Top Bottom