Still looks white to me EDIT: For the record: here's my unedited post in both skins: The default font color appears perfectly readable no matter what skin you're in.
Bleh, then I dunno. You'll just have to bear with it for those posts. @Blastfrog Stop using the formatting tags, please.
aghh why are you useing that skin/light mode? I go golden/dark mode myself, it likes the darks it does.
I'll change the topic now. There's a new preview build available for Windows, Mac and Linux! You can find the downloads under "Current Preview Version" on the project homepage (Windows, Linux) and the Mac version on Sappharad's website. And here's what's changed.
Question @Eukaryot What type of type of commands/values (IDK how it's called) can you use in the "audio_replacements.json" file? Here's an example: "01": { "File": "...", "Type": "Music" }, What things can you put in between the brackets to define "01"? And what are the options for what you can put in those brackets? I'm interested in finding a way to write out a command or formula that can randomly choose a file. Here's an example, I'm mixing some Java code that won't work, but gives an idea: String[] "01": { "01_1", "01_2", "01_3" }, "01_1": { "File": "...", "Type": "Music" }, "01_2": { "File": "...", "Type": "Music" }, "01_3": { "File": "...", "Type": "Music" }, int i = (int) (Math.random() * 01.length), "01" = "01_" + i
Okay, first a full list of the properties for each audio key. I won't go too deep into the details, this will be added to the modding PDF instead. "Type" Either "Music", "Jingle" or "Sound" Determines the basic behavior of the sound, e.g. whether it loops and if it counts as music or sound effect for volume control This should not be changed from the original "File" File name of an Ogg Vorbis file to play (or as a yet undocumented feature, an SMPS file) "Source" If not using an Ogg Vorbis file as source, this can be one of the sub-types "Emulation", "EmulationContinuous" or "EmulationDirect" The game will play back original SMPS data from the ROM The sub-type determines e.g. if the sound is a continuous sound that on playback just gets a signal to continue instead of being restarted (there's more to it, like how internal caching is used differently for each sub-type, but I think that's beside the point here) "Channel" Playback channel to use - for each channel, there can be only one track playing at a time, so starting a new track will stop the old one, if one plays already Leave this out to use no channel at all, i.e. unrestricted playback independent of all other playing tracks Music and jingles automatically use channel 0 "LoopStart" Start position in samples for the looping part "Volume" Relative playback volume as a float ("1.0" means normal volume) And there's also some newly added emulation / SMPS-specific properties: "Address" For emulated playback from ROM only: Can be used to override the address of a track in ROM "ContentOffset" Actual start of SMPS data for the track inside the given SMPS file This is meant for cases when the track doesn't start at the very beginning of the file already - e.g. because there's more than one track in the same file "EmulatedID" Original sound ID associated with the track; it's needed because the sound driver makes some hard-coded differentiation inside depending on this ID But I guess that isn't all that helpful for what you're trying to accomplish. For things like a random selection of a track to play in a given situation, you can add some script code that does that. Have a look at the "Standalone.playAudio" function in "scripts/standalone/audio.lemon", it already does things like choosing the right track to play depending on the selected settings (e.g. S3 version vs. S&K version of a track and similar). If you want to make changes in there, I'd recommend to overload the "Standalone.getModdedSoundKey" function that is called inside there. This is meant to facilitate modding a bit, so you don't have to copy the whole "Standalone.playAudio" over to your script mod. I hope that helps!
Oh the information you provided is useful, and I guess it's coded using Lemon. Something I'll have to look at (and bash my head if I don't get the coding language, lol).
Sonic 3 A.I.R. did not receive an actual stable update since July 2020, only more or less experimental preview builds and mobile beta versions. So we basically took the last preview from two weeks ago, made a few additional fixes where needed, and now here we go with a new stable version for Windows, Mac and Linux! This is v21.05.08.0 and you can find it as usual on the project homepage. Here's the full changelog with all changes since the previous stable version. And these are the changes made in the last two weeks, since the recent preview update: Fixed a crash when playing an emulated music track twice in quick succession in sound test Fix for music stopping after Super Cancel while still having speed shoes Fix for a potential soft-lock when Super/Hyper transforming right when hitting the ground Added support for modded Tails' tails sprites in Time Attack ghosts Fixed that Blue Sphere game stage was not saved after entering a stage code Changed the two Soft upscalers to adapt better to the actual screen resolution
I did a let's play of this wonderful fan project and experienced four weird glitches. Those glitches can be found in the time stamps. I'm confused how I died as Hyper Sonic in Sandopolis Zone Act 2. Can all of these glitches happen in the original Sonic 3 & Knuckles?
Lava Reef and Sky Sanctuary glitches are as the original game; Knuckles is a deliberate change. I think the Sandopolis one is new though.
I'd guess the Sandopolis one can happen in the original, too. There's a small kill plane object in the wall (at the same spot in S3&K and S3AIR) that can trigger an instant kill if you manage to move into the wall too far before wall collision pushes you back. You can see that object in debug mode as reverse "GTGT" text. Actually, I wasn't able to reproduce the issue, and also haven't seen it ever before - so it probably only happens under very specific conditions, like performing a Hyper Dash in the exact right spot. Nevertheless, it shouldn't hurt if I move that object a few pixels to the right, so it definitely can't get triggered by Hyper dash any more.
I don't really know if this is the right place to mention this, but hope it's ok: I've been getting framerate stutter type issues in the Switch port, like it feels like it periodically switches to 30fps and back. Happens both docked and in handheld mode, overclocking doesn't help.
I sideloaded this onto my Onn.-brand Android TV device and it works pretty well. Granted I've only played it a few times, but so far so good. If anyone is interested, you can snag one for $30: https://www.walmart.com/ip/onn-Android-TV-UHD-Streaming-Device/636597403 Keep up the awesome work.
Hey everyone! The new stable update v21.09.12.0 is here (Windows, Mac, Linux and Switch), once again with a bunch of bug fixes and improvements. It also adds in a menu to setup keyboard & controller bindings - something I feel has been missing for a long time, but is now part of the Options. You can find the downloads and all information incl. the full changelog on the project homepage as usual.
Quick heads-up: We just released a patch (v21.09.28.0) for the latest stable update - and this time it's for desktop and mobile platforms. In other words: New mobile betas are out now! Have fun!
Now for some different-than-usual project news. The short version is: Sonic 3 A.I.R. is fully open source on Github now! And here's the details... So I've finally decided to release the full C++ source code of the project, in addition to the already previously published S3&K based game scripts. First of all, if you fear that could be the end of the S3AIR, at least from my side, be assured, it is not. I still have larger plans for the future of the project, including new game features, technical and modding improvements, and of course bug fixes. However, the thing is, the rate of development is certainly going down a bit in the future, as I've got more real-life obligations coming up. Which is part of the reason for the open source release right now. The release on Github is more or less the state of the latest update v21.09.28.0, with only a few changes made in the meantime. Don't expect any new features there, as I've spent the last weeks mainly with cleaning up the project for this release. Also, this is just a copy of the private Git repo used for development, and it will likely not get updated all too often. I hope the readme and how-to-build files included are helpful for everyone who wants to get it running. If someone is interested in building their own project on top of the S3AIR codes or re-use parts of it elsewhere, feel free to fork the repository or copy over what you need. Just respect the conditions of the GPLv3 license in case you want to make your work public. Also, if you want to release a project building on top of S3AIR with some heavy modifications, make sure to update the credits and copyright in the title screen accordingly. I very much appreciate being credited, but not being the person everyone thinks is responsible for a derivative project that I've got nothing to do with. Please note that I'm not really interested in contributions to the project in the form of pull requests or similar. Better fork the project if you want to publish your own changes, extensions or fixes. Spoiler: Why that? It's mainly because I don't want to all of a sudden find myself in the situation of having to spend my time managing and reviewing other people's work, instead of following my own ideas. That stuff can be pretty time consuming. Another reason is handling of software licenses: It's much easier to use the S3AIR or Oxygen Engine code elsewhere under a different license than GPL if I don't have to ask a larger group of contributors whether they are okay with it. That's actually a main concern for me, in case the Engine or parts of it were to be used for a different project, maybe even a commercial one. You never know, I just want to be prepared. That's all, I hope the sources are interesting and helpful for anyone interested!
Just a tiny little note, since I forgot to document it somewhere thus it isn't mentioned in Eukaryot's source release above. The file manager used for the web/iOS port has been been open source this entire time. I have a fork of react-filemanager here, which adds a BrowserFS driver: https://github.com/Sappharad/filemanager BrowserFS is what the web port for the save data folder to save files to browser storage. The /dist/ folder under _emscripten/ just contains a compiled build of that. Edit: An additional note - the Xcode project in the public repository is broken and can't find most of its files. I know exactly what happened, and will try to coordinate getting the fix in. Edit 2: Both of the problems above have been addressed in the Github repo.
Because I am an extremely evil man, I committed an act of unspeakable evil and optimised out frame pacing a bit on Windows. Before: After: Windows is the platform that sees the most improvement here; as I went out of my way to Query and adjust the Windows Timer Resolution to a more optimal value. Other platforms appear to have results from "same as before" to very slight improvement; with Sappharad being the one building & testing the other ports. This frame time graph is courtesy of RTSS. RTSS has been set to put the `Frametime calculation point` at Frame Presentation, i.e. `glxxSwapBuffers`; this is what we're trying to optimise for after all. (In S3AIR `glxxSwapBuffers` should be called by `SDL_GL_SwapWindow` if I'm not mistaken.) You can find the current version of my fork here.
Thank you for supporting the community through your open-sourcing of this project. The more fan developers follow your example, the better.
