View Single Post
Old 09-9-2016, 06:25 AM   #78
MinaciousGrace
FFR Player
D7 Elite Keysmasher
 
MinaciousGrace's Avatar
 
Join Date: Dec 2007
Location: nima
Posts: 4,278
Default Re: hello allow me to introduce to u my Wife

cool new download links time

theme:
https://github.com/MinaciousGrace/Til-Death
build:
https://github.com/xwidghet/stepmani.../tag/0.0000003



You must be using the custom build in order for the theme to function properly.

Currently the custom build only involves modification of the stepmania executable, and not any other resources. This means no installation is required. Just download the .exe from the link and overwrite the one that exists in your stepmania5/Program. You are advised to make a backup of the original executable on the off chance the custom build doesn't work.


If you don't the wife system won't work at all, since the chartkey system has been built into c++ and is based on how the game interprets charts. This means that .ssc .dwi .sm files are all hashed rather than just .sm files. 4k/6k/8k charts should all theoretically be compatible with the system now however I have to remove some blocks I put in place to prevent the old chart key generation script from from crashing the game when trying to generate keys for non-4k charts.

Currently key generation is done both on initial song load and at the start of gameplay so you don't technically need to rebuild your cache. However you are strongly recommended to delete your song cache and rebuild it before playing.

This is done automatically and at the moment there is no way to disabled it, even if you are not using my theme. However everything is done before gameplay begins and thus has no effect on it, and the effect outside of gameplay is a marginally longer loading time.

Not using the custom build will also prevent many of the gameplay elements from functioning properly. The custom build adds parameters to the judgment messages that streamline interpretation and minimize what should be needless logical checks and hooks back into c++ objects to get information that should be disseminated by the judgment messages in the first place.


Brief changelog (only going to skim the major changes for now, a more comprehensive and in-depth changelog will follow eventually):

Build:

Performance massively increased due to a few targeted optimizations.

- Inefficient mathematical implementations in high traffic functions were replaced. The 40% of processing they were hogging during gameplay has been reduced to less than 1%.
- The game no longer calculates point in time during gameplay for every actor asking for it every frame (ie, every note on the screen). Points in time for the entire file are pre-calculated as gameplay begins and stored in a vector which is then simply read from as each actor asks for it. This however necessarily requires that an assumption can be made about whether or not the pre-calculated values will be valid by the time they are needed. I'm fairly sure that lua modding can be used to alter the timingdata of a file as you're playing it, so this system will shut off if an lua script is loaded before gameplay as a pre-caution. Values are then once again calculated on the fly. Previously calculation of point in time made up about 25-30% of what the game was doing. Pre-calculating values reduces that number to again, below 1%.
- Rendering parameters are pointerised rather than being copied and emptied every time something needs to be rendered. Copying these values rather than accessing them from a fixed memory point resulted in a fairly large degree of overhead for rending any object on the screen. The changes resulted in about another 10% performance boost after the above two were made.
- Various lazy and/or inefficient coding practices sharpened up. Static casting where appropriate. Avoiding silly situations in which floats are converted to ints in order to round them, then converted back to a float, then converted back to an int. In relativistic terms these have had a mostly negligible impact, but it's the principle of the thing.

The result is that during what most people here would consider standard kb gameplay the game just does about 20% of what it was doing before per frame, and about 95% of that is rendering objects. Essentially framerate should average more than 5x what was previously achievable on the base build. Themes that were already minimal will see less of a performance boost, and the most gain will be seen by themes employing lots of fancy stuff. For reference the old version of transcendence during gameplay with all features enabled, including the nps graph and etc. Fps averaged around 200 and often dipped below. Custom build with the new version of my theme with all the same features and more enabled, is stable at 1400 fps during gameplay.

Other stuffs

- Framelimit preferences have been added to preferences.ini. Now that the game spends the large bulk of its time rendering rather than inefficiently calculating inputs to the render engine, gpus can actually get taxed pretty hard. FrameLimitGameplay controls the maximum framerate during gameplay, and FrameLimit controls the maximum framerate for all screens aside from gameplay. They are separate entities and must both be set if you wish to cap framerates for the respective screens. My personal suggestion is to cap framerate at 300 outside of gameplay, and 1000 inside. As noted previously this will still fully utilize one of your cpu cores.
- Added preference for pitch rates, EnablePitchRates. Disabling this will make it act the same as any other Stepmania 5 install.
- Scrolling through a lot of songs on song select (like alphabetical sort on massive collections) has been improved greatly.
- Fix rates causing arrows to have motion stutter whenever the sound driver returns duplicate timestamps. This is most noticeable with DirectSound-sw.
- Judgment messages now have extra params that make sense
- A whole ton of shit that was soaking up resources when not even active have been told to stop it or been disabled entirely (lightsmanager for arcade cabinets and dancing characters fall into the latter category). I'll document all of the instances of this later (i mean they're in the commit messages in the repo, but I'll document them here later).


Theme:

- Fixed a billion bugs with songsearch. Now it should totally definitely work seamlessly. And if it doesn't who cares because I plan to rewrite the implementation into c++ anyway.
- Fixed issues with selecting waifu preventing the old scoretracking system from working properly.
- Re-enabled nps counter, nps graph, screen-filter, and lane-cover. They are now all selectable and operational as they designed to be.
- Fullprogress bar and miniprogress bar are now two separate entities that can be turned on or off independently.
- Lifebar is now just a bar that goes up and down. Not a fourth dimensional non-euclidean anti-newtonian trapeslinkyzoid.

Notes: Theme still doesn't support widescreen. I'm working on it and I intend to in the future, it's just not a higher priority than getting everything else working first. Second player support however, is still totally gutted.


You are encouraged to report bugs if you run into them. My inclination towards solving problems in most cases outweighs my adversity towards helping people with shit I think is stupid. For example, if some mod map doesn't work let me know and I'll look into it. I've already tested the megalovania mod map and it works fine, if you can call that file stepmania working fine.

There's quite a bit more to say and in a little bit of time the OP will be reorganized and restructured to become the base for the new theme (prolly the same time it gets githubbed and moved out of alpha)

One final note. Chances are you'll have to spend a little bit of time adjusting. The game is much smoother and crisper and I hit everything like 20 ms early from not being used to it.

Apart from that enjoy your performance boost, both game and player wise.

Last edited by MinaciousGrace; 09-9-2016 at 02:33 PM..
MinaciousGrace is offline   Reply With Quote