So a while back, I added mipmap support to the PVM editor, and I've added a new feature to SADXLVL2: if you add a modpath property to sadxlvl.ini pointing to a mod's folder (eg mods/mymod), SET and CAM files will be loaded from the system folder in that folder first, and saved there. Eventually, all modified data will be stored in the mod folder, so that running split again doesn't erase your changes, and you can work on multiple mods at the same time without duplicating the entire system folder.
I have a few questions. The palette light table data is contained in those PL_??B.BIN files. Do we know anything about the file format or what stages use these? Also, do we know what the SL_??B.BIN files are? I was thinking these were for the sky box, but the game doesn't seem to load these files based on the FileMon output from the SADX Preview. I think I see some X/Y/Z data in them though. The game always seems to give the "SKY SETTIN'" X/Y/Z parameters <1.0, 1.0, 1.0>. I was going through the file directory in the AutoDemo again and noticed these files, which is why I ask. EDIT: I just realized these files don't exist in the 2004 PC version anymore. They still exist in the GC/DC versions though...
I was never able to figure this format out, mainly because the data is compiled into sonic.exe, and I could never find it in there. Also, I was finally able to figure out view frustum culling, and added it to salvl and sadxlvl2. Both programs are significantly faster now. Also fixed a bug with the skyboxes not rendering. Enjoy.
Yes, if you look on my website now, I have marked that one as obsolete. Basically, the old patch Dude made that my patcher program is based on just disables the first-person view, which can still lead to camera spinning under certain conditions. This mod disables the right analog stick's horizontal movement entirely. In the future it might be possible to determine exactly why SADX behaves the way it does and correct it with an update to the mod, but don't hold your breath.
Just out of curiosity, I've tried to use the SADX mod loader to apply the goal ring patch but capsules still appear at the end of a level. I must be doing something wrong.
I got it working: clicking "Install loader" seems to have made it work properly. Out of curiosity, can I use this to make a sound mod without overwriting the original files?
Yes, all you need is a folder with a mod.ini file with Name, Author and Description entries, and a system folder with the files you want to replace in it (system\sounddata\bgm\wma for music, system\sounddata\voice_us\wma for english voices, system\sounddata\se for sound effects).
You might remember how long ago, Crystallize made a texture pack for SADX with mipmaps. It turns out, the old version of Puyo Tools at the time wasn't so good at properly formatting PVMs, so I hacked PVMEditSharp a bit to make it loop through every PVM and give mipmaps to all non-paletted square textures. Before: After: You can download a mod for the mod loader here.
MainMemory and I have been trying to work towards 2 goals: - Optimize SADX model output significantly (it is pretty bad right now) - Be able to generate SA2 meshes at all Now this requires a Triangle Strip Generator, and I had limited success implementing one of my own (it garbled the mesh in some places, but worked in others) but unfortunately being a noob at git, I destroyed my only copy. Anyways, we're both pretty bad at C, and this program called STRIPE generates excellent triangle strips - but it also completely screws up the rest of the mesh data sent to it. We both tried looking into fixing it, but this program is above our level. What we need is someone who can either fix all of the problems with the program (you'll need to add vertex normal, uv and vcolor support). OR, someone (or a group of someones) to port it to C# so we can directly integrate it into SA Tools (this is probably the better option). Another solution would be for someone to write their own triangle strip generator into SA Tools (if you think you know how to do this and don't want to port STRIPE, contact me) Once this is done, you should be able to import models with double or triple the polycount you can now. And not to mention this will make it so we can even *do* custom models in sa2. You know you want to!
Here's abit more of a demonstration as to why STRIP isn't quite up to snuff. Before proceeding it might be a good idea to brush up on Alias-Wavefront format. We've got some minor custom extensions going on in our files, but for the most part it's the same. Here's our base model. It has no UVs, no Vertex Normals, and no Vertex Colors. It looks like this: Un-stripified OBJ file stripified version This, predictably, works just fine with our current importer. However, when we move onto something a little more complicated, like this model with UV coordinates (aka texture verts) and Vertex Normals: Un-stripified OBJ file stripified version STRIPE makes a fatal assumption. The number of UVs in a model is not guaranteed to be the same as the number of verts in a model. In fact, for that to happen is very rare. Each vertex can have an infinite number of UV coordinates, since the number of uv coordinates should be faces * 3 (before stripifying). I think I know why they made this assumption though, and that is so that they could keep their strip vertex references as a single value, unlike how wavefront's face vertex references can have multiple values (one for each kind of vertex - you'll see them separated by slashes like so: v/vt/vn). Because of this improper handling of UV coordinates, textured models don't work properly. STRIPE even went so far as to include the vertex normals (although, it never references them properly to do the issue mentioned previously) The solution to this would be to add the ability to add the slashes for extra references into the strip and strip continuation entries (t and q respectively). There's one more case: A model with faces, vertex normals, UV coordinates, and vertex colors. This requires uses of our format extension (we added vc indeces right after the vn indeces in the face definition). However, when we move onto something a little more complicated, like this model with UV coordinates (aka texture verts): Un-stripified OBJ file stripified version STRIPE tries with this model and doesn't crash. I'm not sure if it imports into sadxlvl2 without crashing the program, but either way, it ignored our vcolors (obviously), and didn't reference the included data properly.
I have a question. The Xbox 360 and PS3 versions of Sonic Adventure have the base game and DX DLC, but the PC version from 2010 is just the DX version. Is there a way to put the regular Sonic Adventure branding into the PC version (title screen, etc) in the same manner as the No Battle mod for SA2B (changes branding to SA2 but keeps SA2B features) on the PC? Would it just be easier to somehow turn the "DX DLC" off for the PC version cause it's a port of the PS3 and Xbox 360 versions? I just love the regular Sonic Adventure title screen with the ripple effect.
The short answer: yes, but you won't be able to play it like that. The long answer: it could be possible with some in-depth hacking like I did for the SA2 No Battle mod, but I'm not willing to do any in-depth hacking on the Steam version.
New mods: The Gravity Control mod allows you to change the angle of gravity using the D-Pad in 512 increments. Press L+R to reset gravity to normal. The Simple Gravity Control mod allows you to change gravity to one of six directions with the D-Pad and Y button.
You know I want to! :D Wow man this sounds tight, so if you guys breakthrough with this what kind of models can we import?
