Sure thing- but I think there were some global index inconsistencies in the ones I posted so here: https://u.teknik.io/28mXkk.zip Double checked the Global Index numbers to make sure they matched up and all work properly. But yeah- absolutely include them.
The video wasn't offering 720p60 as an option when you posted it, but it appears to offer it now. You can see the difference when watching directly on Youtube in 60fps. (Not sure if the embedded one supports 60fps) I recorded a crappy video from my own version. Interestingly, his version 1.1 appears to behave differently than my 1.0 port of the code: https://youtu.be/W6HrVbOMElM In his video, when the game drops below 60fps, it skips frames. On mine, the entire game slows down. Not sure if this is because part of the code isn't working in my port due to different offsets, or if the two versions behave differently. I'm guessing it's the latter, since the game-clock itself slows down. Also, the demos don't sync, which you can see in my video.
That might be his emulator doing that? I looked into those two locations in RAM to see which functions were accessing it. In my copy of Sonic Adventure (V1.0005 NTSC-U 10/5/99), this is the subroutine of interest: Code (ASM): ROM:8C051760 set_framerate: ; CODE XREF: sub_8C049298+12p ROM:8C051760 ; sub_8C049560+10p ... ROM:8C051760 mov.l #unk_8C754EC8, r0 ; Move Immediate Long Data ROM:8C051762 mov r4, r3 ; Move Data ROM:8C051764 mov.l #unk_8C754EC0, r2 ; Move Immediate Long Data ROM:8C051766 mov #0, r3 ; Move Immediate Byte Data ROM:8C051768 mov.l #RAM_Framerate, r6 ; Move Immediate Long Data ROM:8C05176A mov.l #RAM_Framelock, r1 ; Move Immediate Long Data ROM:8C05176C sts.l pr, @-r15 ; Store System Register Long ROM:8C05176E mov.l r4, @r6 ; Move Long Data ROM:8C051770 mov.l r4, @r2 ; Move Long Data ROM:8C051772 mov.l #sub_8C051810, r4 ; Move Immediate Long Data ROM:8C051774 mov.l r5, @r1 ; Move Long Data ROM:8C051776 mov.l r3, @r0 ; Move Long Data ROM:8C051778 mov.l #sub_8C605234, r3 ; Move Immediate Long Data ROM:8C05177A jsr @r3 ; sub_8C605234 ; Jump to Subroutine ROM:8C05177C nop ; No Operation ROM:8C05177E mov.l #sub_8C055C44, r2 ; Move Immediate Long Data ROM:8C051780 jmp @r2 ; sub_8C055C44 ; Jump ROM:8C051782 lds.l @r15+, pr ; Load to System Register Long ROM:8C051782 ; End of function set_framerate ROM:8C051782 ROM:8C051784 ; --------------------------------------------------------------------------- ROM:8C051784 mov.l #RAM_Framerate, r5 ; Move Immediate Long Data ROM:8C051786 mov r4, r3 ; Move Data ROM:8C051788 mov.l #unk_8C754EC0, r2 ; Move Immediate Long Data ROM:8C05178A mov.l r4, @r5 ; Move Long Data ROM:8C05178C rts ; Return from Subroutine ROM:8C05178E mov.l r4, @r2 ; Move Long Data I'm a little unclear at the moment as to what it does exactly, but it seems that this subroutine takes 2 parameters (stored in r5 and r4) which are stored before this subroutine is called. r4 contains the Framerate parameter and r5 contains the Framelock (or 'Speed' in JmTsHaW's case). Both are usually 2 when called, with the rare exception with what I imagine is the menu screen. There are 6 locations in 1ST_READ.bin where the values for the parameters are loaded into the registers before this function is called. Here are the locations along with the two bytes that must be changed in 1ST_READ.bin (or in track03.bin if you want to modify it that way) in order for the game to run at 60 FPS completely: 000392AC -> 01 E4 (change in track03.bin @ 0x4635F46C) 0003956E -> 01 E5 (change in track03.bin @ 0x4635F72E) 0003E662 -> 01 E5 (change in track03.bin @ 0x46365402) 00044736 -> 01 E5 (change in track03.bin @ 0x4636C316) 00072AAE -> 01 E5 (change in track03.bin @ 0x463A14FE) 0008A1D2 -> 01 E5 (change in track03.bin @ 0x463BC3F2) Of course, one of these changes also causes the cutscenes to run at a ridiculous speed (the animations and choreography I imagine are timed to 30 frames). Other than that, under the latest version of Demul at least, it plays and works like a dream. I don't get any slow down at all that isn't caused by the emulator itself. Anyways, here's my video.
So I'm curious. What files contain the hud, menu, and any other on screen graphics like the tails race bar and the treasure hunting and the mission graphics? I was thinking of working on a reimagining of those graphics since they were severely over looked when the game was ported.
Various PVM archives and PVR files in the system folder contain all the textures in the game (assuming you mean PC version). There's a partial list at SCHG:Sonic Adventure/Textures. Also CheatFreak I've added your textures to the Goal Ring Mod.
Excellent, thanks! I'm too assed to make new graphics though so hope ya'll like the Generations textures because I plan on putting in modified versions of those graphics (That may include a mod that updates character and level textures to similar textures from Generations). Mainly I want to update the title screen, menus, the HUD, and any graphics like item icons, results screens, font choices, what have you. Speaking of Generations, has anyone made a mod that replaces the characters with their respective Generations models? And failing that, anyone made a mod replacing the characters with their original Dreamcast models? Kinda want to go all or nothing here, anything to replace the SADX models though.
I found a batch of Generations model swaps a few years ago on some site that doesn't exist anymore. I can't get them to work with my version of SADX but perhaps they could be of some use. https://www.mediafire.com/?23042fqchxbatdz
We're in the process of updating the new modding system to work with character models. The old character models don't work (I think) because of conflicting memory addresses in the dll files. Also, most of the old character models were made using a hex editor and a really just dreadful workflow, so when the new system is complete it should all be much nicer. The current model viewer supports animation previewing, and we'd like to one day maybe include animation editing. Major problems holding back progress is the current model editing transform handles don't show in the right places or orientations, and for some reason trying to build a DLL mod (chrmodels, advmodels, etc) produces invalid results. I don't know if it's been fixed but there are also some mod-loader problems with loading a non-compiled model file. Work is ongoing...
Ugh, I just realized that most of the menu things are stored in PVR instead of PVM, so my project is kind of useless right now Eh, maybe I'll play around with some textures in levels, see what I can replace using modified Generations and 06 textures.
Have you tried using PVRViewer? I've seen videos of hacks before that completely redid the menu graphics.
Oh yea I have seen that, but with the SADX Mod app they added the feature to use higher res PNG files to replace the PVM textures. If I'm still restricted to the PVR's original dimensions that'd defeat some of the purpose. To be fair though the menu textures aren't as shitty looking as the in game textures and backgrounds so that may still work. I'll look into it again.
PVR texture replacement using the texture pack system will be available in the next mod loader update. It's in and working right now, but it just hasn't been released yet because reasons.
That being the case, I'll briefly describe how to use it. It works the same way PVMs replacements do, except that the texture index (index.txt) and all the images go in the root of your mod's textures folder. There's a caveat though: Custom texture filenames must match their PVR counterpart in everything but extension. They can be in subfolders, though. The index format is the same (gbix,filename) except that the order doesn't matter. That being said, here's a list of every PVR and their global index in the correct format. Just copy and paste the entries as you need them and replace the file extension with whatever you're working with (DDS, PNG, etc). You can use Puyo Tools or PVRViewer to convert the PVRs to PNG. I'll write a guide for the whole shebang in the next couple days.
Awesome, fun times. Final question. What's the best way to split up the PVM files into separate PNG files in folders? Almost done with the boring legwork part with downloading and converting the textures, then I can start making stuff.
I don't know how much of the cutscenes are hard-coded and how much is rendered in-engine with in-game assets that can be altered, but someone on another forum I frequent recently pointed out that Chao have a dark coloration and poorer quality model in cutscenes compared to how they look in the Chao Gardens. Presumably, this inconsistency is to prevent more important details in cutscenes from lagging on the Dreamcast and was left uncorrected in ports. Question is, is it feasible with current tools to make cutscene chao have a consistent look with Garden Chao?
The cutscenes are both hard-coded and rendered with in-game assets that can be altered. One would merely have to find the object used to display Chao in cutscenes, and then find the model used by that object. This may be easier said than done however, because the coding for cutscenes is poorly understood. Your other problem then is getting a Chao model in a format the game can use.
Since I don't understand clearly how to use this new method of texture editing, this is in a PVM archive. This small texture edit changes Amy's dress to be more like her Dreamcast dress, and has a resized and smoothed Ring texture. Grab that here. Coffee the Mug. After someone asked if I could make a "Hot Coffee" mod, I made a "Hot Coffee" mod. Download custom model here And mod here
