DNHAPM: Profiling and Game Monitoring for Touhou Danmakufu ph3 [20180723: v1.0]

~Hakurei Shrine~ > Rika and Nitori's Garage Experiments

<< < (2/3) > >>

Sparen:
Version 0.3 has been released

What's new in 0.3:
- Bomb and Death Monitoring
- Clarifications on buffer time required post-event call to ensure that the report is written before the script is terminated

I wanted to provide an example of the Bomb & Death monitoring system but I realized literally at the end of a run of DNH Troll Stars that I had forgotten to add the event to actually write the files and generate the report, so no images for now.

not ZUNs wife:
this is an incredibly useful tool for bullet hell scripters, mind you.. :3 helps with resource hogging and game balance type issues that are notorious for being time-consuming in game development

Sparen:
Version 0.4 has been released.

What's new in 0.4:
- Step Logging and colored graph overlays + Spellcard event listening
- Bullet and Text size configuration settings for Death & Bomb Monitoring

Download the new release here: https://github.com/Sparen/Sparen-DNH-APM/releases/tag/v0.4

Please report all bugs on GitHub Issues. Please keep in mind that this project is a work in progress - although it probably works fine for smaller projects, some additional things need to be worked out before it can be used conveniently in a full game or a system with significant player or difficulty based changes.

Sparen:
Version 0.5 has been released.

What's new in 0.5:
- User-defined Logging
- Custom file paths
- Reading only runs of the specified script during aggregation

Download the new release here: https://github.com/Sparen/Sparen-DNH-APM/releases/tag/v0.5

Please report all bugs on GitHub Issues.

This is expected to be the last version before 1.0, and contains the needed adjustments for the APM to work conveniently in a full game environment as well as in more complex Single scripts with multiple players and difficulties.

As usual, I welcome feature requests and comments on how to improve the APM, as it is a tool for the Danmakufu community to use.

Drake:
I've sent a pull request, here are some additions:

I changed the FPS monitor to track FPS based on time passed rather than using DNH's function. This means you have much greater control over the tick. I haven't tested it a whole lot but this is how I tend to do it myself. One caveat is that for a reason I can't quite pin down this method consistently reports slightly less FPS than GetCurrentFps (likely somehow because it's all calculated from script rather than by the program itself), so there's a manual constant factor to fix it to be more or less consistent with what GetCurrentFps reports on average.

I've added a line to mark 60FPS on the graph as this will generally be what people want to target. I've also set 60 FPS to be the minimum value of the top of the graph for the same reason (if your program is somehow always running under 60FPS).

I've changed the line drawings so it moves the beginning of the graph to the first coordinate rather than at the static (0, 0) spot, mainly because having the 0 FPS at the beginning of every graph was annoying me and it's technically incorrect. The other things start at 0 so it didn't affect those, but it would affect FPS along with other user-defined stuff.

Here are pictures of 10-frame update and 2-frame update:

There's also an oversight affecting at least the FPS graph where the previously aggregated graphs all stay exactly where they were previously drawn even if the y-axis scale is changed due to there being a higher maximum value. This is made very clearly apparent if you play a normal run and then frameskip a bit on the next. This basically means the aggregates can't be compared (i.e. the whole point) if the maximum value changes.

Navigation

 Message Index

Go to full version