If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/game1024/OpenSpeedy shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Solo project — review before adopting

• Last commit 1w ago
• GPL-3.0 licensed
• CI configured
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live game1024/OpenSpeedy repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/game1024/OpenSpeedy.

What it runs against: a local clone of game1024/OpenSpeedy — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in game1024/OpenSpeedy | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 38 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of game1024/OpenSpeedy. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/game1024/OpenSpeedy.git
#   cd OpenSpeedy
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of game1024/OpenSpeedy and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "game1024/OpenSpeedy(\\.git)?\\b" \\
  && ok "origin remote is game1024/OpenSpeedy" \\
  || miss "origin remote is not game1024/OpenSpeedy (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 38 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~8d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/game1024/OpenSpeedy"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenSpeedy is a Windows-only game speed modifier that manipulates frame rate timers and game speed parameters in real-time by hooking into DirectX/game processes and patching memory regions. It breaks artificial frame rate caps and provides variable-speed acceleration (0.1x to 10x) without modifying game files, using C++ hooking and memory patching techniques via the mainwindow and cpuutils/memutils modules. Monolithic Qt5 GUI application: mainwindow.cpp/h is the central UI controller connected to mainwindow.ui (Qt Designer XML), with two utility modules (cpuutils.cpp/h for CPU/speed manipulation, memutils.cpp/h for memory operations). bridge/ contains a separate CLI entry point. Configuration handled via config.h header. Multi-language support via .ts translation files. Installer and CI automation decoupled into installer/ and .github/ directories.

PC gamers who want to bypass frame rate limiters or play retro/slower games at accelerated speeds, and potential contributors interested in reverse engineering, memory manipulation, game modding, or Windows API hooking. Users value the open-source approach over closed-source cheat engines.

Actively developed with CI/CD pipelines (.github/workflows/ci.yml and package.yml), multi-language support (English, Simplified Chinese, Traditional Chinese via .ts files), and installer automation (WiX Toolset in installer/). GitHub stars and forks indicate community adoption, though the codebase shows C++ patterns typical of mid-2000s Windows development rather than modern practices, suggesting it's production-ready but not aggressively refactored.

Single-language (C++) with heavy Windows API coupling (cpuutils/memutils directly manipulate process memory and CPU state), making it fragile across Windows versions. No visible unit test suite in the file list, relying on CI workflows for validation. Potential runtime stability risk: hooking game processes can cause crashes or instability if games update their memory layout or anti-cheat mechanisms. Maintainer activity appears active but could benefit from a test suite and more modular design.

Project is under active maintenance with CI checks (ci.yml), automated packaging (package.yml), and Windows installer generation (WiX .wxs config). The presence of CMakePresets.json and CMakeLists.txt suggests recent modernization toward CMake-based builds. Latest commits likely include Windows version compatibility fixes and UI refinements given the translation files and icon assets being versioned.

git clone https://github.com/game1024/OpenSpeedy.git
cd OpenSpeedy
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release
./build/OpenSpeedy.exe

Requires: CMake 3.16+, Qt5, MSVC/Clang toolchain, Windows 7+ (inferred from WiX installer targets). See .github/workflows/ci.yml for exact build matrix.

Daily commands: After build, launch: ./build/Release/OpenSpeedy.exe (GUI) or ./build/bridge/OpenSpeedy-cli.exe (CLI mode). GUI mode requires X11/Wayland equivalent absent; Windows native windowing only. Debug builds via: cmake --build build --config Debug.

• mainwindow.cpp: Central UI event loop and main application controller; orchestrates speed modification triggers and user input handling
• cpuutils.cpp: Core speed manipulation logic: CPU frequency scaling, sleep timer hijacking, and game speed acceleration math
• memutils.cpp: Low-level process memory read/write operations; essential for hooking game memory regions and patching frame rate caps
• config.h: Configuration constants (speed multipliers, timer thresholds, polling intervals) for the speed modifier behavior
• CMakeLists.txt: Defines build targets, Qt integration, Windows resource inclusion, and cross-platform CMake configuration
• .github/workflows/ci.yml: CI pipeline defining build matrix, test execution, and artifact generation; reveals supported toolchains and validation gates
• bridge/main.cpp: CLI interface entry point; shows alternative usage patterns and headless operation mode

UI changes: Edit mainwindow.ui in Qt Designer or modify mainwindow.cpp directly. Speed/memory logic: See cpuutils.cpp (CPU frequency scaling, timer manipulation) and memutils.cpp (game memory read/write). Preferences: Edit preferencedialog.cpp and related .ui file. CLI bridge: Modify bridge/main.cpp for command-line interface. Build system: Update CMakeLists.txt. Translations: Run lupdate on .ts files and edit via Qt Linguist. Config defaults: Adjust config.h constants.

1. Windows privilege escalation: cpuutils/memutils likely require admin privileges to hook processes and modify CPU state; missing elevation will fail silently or crash. 2. Anti-cheat interference: Modern games (EAC, BattlEye) may detect or block the hooking mechanism; no fallback or detection logic visible. 3. Qt platform plugin: GUI requires QT_PLUGIN_PATH set correctly; static builds may be necessary for distribution. 4. Process handle lifetime: No visible cleanup in memutils for opened process handles; potential handle leaks if exceptions occur. 5. CMake presets: CMakeUserPresets.json may override defaults; ensure local config doesn't conflict with CI expectations. 6. Translation files (.ts): Must be compiled to .qm binary format before runtime; missing lupdate step breaks multi-language support.

• Process Memory Hooking — Core technique in OpenSpeedy: injecting code into a running game process to intercept and modify behavior (frame timers, speed calculations) without modifying game files; essential to understand ReadProcessMemory/WriteProcessMemory and DLL injection patterns.
• Windows Timer Resolution Manipulation — cpuutils.cpp likely uses timeBeginPeriod/timeEndPeriod or QueryPerformanceCounter hooks to alter the game's perception of elapsed time; fundamental to speed acceleration without breaking game physics.
• CPU Frequency Scaling (DVFS) — cpuutils references CPU speed control; understanding dynamic voltage/frequency scaling helps explain how OpenSpeedy can affect game performance without modifying game code directly.
• Reverse Engineering & Binary Patching — Implicit to memutils memory read/write: contributors must identify target memory regions (frame rate counters, speed multipliers) by reverse engineering game binaries and applying runtime patches.
• Qt Signal-Slot Architecture — mainwindow.ui and mainwindow.cpp use Qt's event-driven model; understanding signal/slot connections is essential for modifying UI behavior and adding new controls.
• Windows Process API & Handle Management — memutils relies on OpenProcess/CloseHandle; proper handle cleanup and access rights (PROCESS_VM_READ/PROCESS_VM_WRITE) are critical to avoid leaks and privilege errors.
• Translation & Localization (Qt Linguist) — Repository includes .ts files (OpenSpeedy_zh_CN.ts, OpenSpeedy_en_US.ts); understanding Qt's translation workflow is necessary for maintaining multi-language support.

• cheat-engine/cheat-engine — Mature closed-source game cheating engine; similar memory-scanning and process-hooking techniques but broader feature set (Lua scripting, GUI debugger)
• x64dbg/x64dbg — Open-source Windows debugger for reverse engineering; complementary tool for analyzing game binaries and understanding memory layouts that OpenSpeedy targets
• UnknownCheats/Unknowncheats-org-Wiki — Community knowledge base for game modding and memory manipulation techniques; educational resource for understanding the hooking patterns used in OpenSpeedy
• api0cradle/APIUnfuck — Windows API modernization library; relevant for updating OpenSpeedy's deprecated Win32 calls to contemporary equivalents
• winproportional/winproportional — Alternative speed/timing modifier for Windows games; direct competitor with different UI/architecture approach

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for speedpatch core functionality

The speedpatch module (speedpatch/speedpatch.cpp, speedpatch/speedpatch.h) is critical for the core speed modification feature but has no visible test files. Adding unit tests would catch regressions, improve code reliability, and serve as documentation for the patching logic. This is especially important for a tool that modifies game memory.

• [ ] Create speedpatch/tests/ directory with CMake test configuration
• [ ] Write tests for speedpatch initialization and cleanup functions
• [ ] Write tests for frame rate modification logic in speedpatch.cpp
• [ ] Add test execution to CI workflow (.github/workflows/ci.yml) for both 32-bit and 64-bit builds
• [ ] Document test coverage expectations in CONTRIBUTING guide

Add comprehensive GitHub Action for multi-platform builds and release artifacts

The repo has build scripts (script/build32.bat, script/build64.bat) and an installer (installer/OpenSpeedy.wxs) but the package.yml workflow appears minimal. A complete CI/CD pipeline should validate builds on both 32-bit and 64-bit architectures, run installer creation, and automatically attach compiled binaries and installers to releases. This reduces manual build overhead and improves release reliability.

• [ ] Extend .github/workflows/package.yml to build both 32-bit and 64-bit executables using the existing batch scripts
• [ ] Add step to generate Windows installer (OpenSpeedy.wxs) for each release
• [ ] Configure workflow to upload .exe and .msi artifacts to GitHub Releases automatically
• [ ] Add code signing step if signing certificates are available (reference installer/create_installer.bat)
• [ ] Test workflow with a pre-release tag to validate artifact generation

Add missing documentation for memory and CPU utilities modules

The repo contains utility modules (memutils.cpp/h, cpuutils.cpp/h, taskscheduler.cpp/h) that are core to the speed modification mechanism, but there is no developer documentation explaining their APIs or usage patterns. New contributors cannot easily understand how to extend or debug these modules. Adding API documentation in docs/ would lower the contribution barrier.

• [ ] Create docs/ARCHITECTURE.md explaining the role of memutils, cpuutils, and taskscheduler in the speed patching pipeline
• [ ] Add inline code documentation headers to memutils.h and cpuutils.h explaining each public function's purpose and parameters
• [ ] Document the memory patching strategy used in speedpatch/speedpatch.h with examples of supported game types
• [ ] Add troubleshooting section in docs/ for common issues when modifying speed (e.g., process detection failures, patch application timing)
• [ ] Link new docs from README.md or create DEVELOPMENT.md for contributor guidance

• Add unit tests for cpuutils.cpp and memutils.cpp: Currently no visible test/ directory; contributors could create a basic test suite using Google Test (gtest) to validate memory read/write operations and CPU speed calculations without requiring a running game process.
• Document the exact Windows API calls in memory hooking: Add inline code comments and a docs/HOOKING.md explaining ReadProcessMemory/WriteProcessMemory patterns, target memory regions, and how to identify game-specific timer locations; this would help contributors extend support to new game engines.
• Create a GitHub Actions workflow to test Windows version compatibility: ci.yml exists but could be extended with a matrix testing Windows 7, 10, 11 builds; add diagnostics for OS API availability (e.g., checking for deprecated Win32 calls).

OpenSpeedy has significant security concerns

• High · Use of Game Speed Modification - Potential Anti-Cheat Violations — Main application purpose (mainwindow.cpp, speedpatch/speedpatch.cpp). The application is explicitly designed to modify game speed and bypass frame rate limitations. This functionality could violate terms of service of online games and trigger anti-cheat detection systems, potentially leading to account bans or legal issues. Fix: Add clear warnings to users about potential anti-cheat violations. Include legal disclaimers and recommend use only in single-player or offline games.
• High · Third-party Hook Library (MinHook) - DLL Injection Risk — third_party/minhook/. The codebase uses MinHook (third_party/minhook) for function hooking. While MinHook itself is legitimate, function hooking is a sensitive operation that can be exploited for privilege escalation or used to modify game behavior in ways that violate game policies. Fix: Ensure MinHook is kept up-to-date. Implement code signing for the DLL to prevent tampering. Document the hooking behavior clearly and ensure users understand the risks.
• Medium · Potential Unsafe Memory Operations — memutils.cpp, memutils.h. Files like memutils.cpp and memutils.h suggest direct memory manipulation capabilities. Unsafe memory operations (buffer overflows, use-after-free) could lead to crashes or code execution vulnerabilities. Fix: Conduct thorough code review of memory manipulation functions. Use safe memory APIs and bounds checking. Consider using AddressSanitizer during testing.
• Medium · Referral Link in README - Potential Phishing Vector — README.md. The README contains a referral link (https://ref.365tz87989.com/?r=RWQVZD) which could be compromised or used for phishing attacks. The domain appears suspicious with numeric prefix. Fix: Remove or verify the legitimacy of the referral link. Use official domain links only. Consider removing affiliate/referral links from public repositories.
• Medium · Missing Dependency Lock File — speedpatch/vcpkg.json (no corresponding lock file detected). No lock file (vcpkg.lock, package-lock.json, etc.) is visible in the repository structure. This could lead to supply chain vulnerabilities if dependencies are updated to malicious versions. Fix: Commit dependency lock files (vcpkg.lock.json) to version control. Use exact version pinning for all dependencies.
• Medium · Unsigned Executable Risk — installer/OpenSpeedy.wxs, main.cpp. No evidence of code signing for executables. Unsigned binaries can be modified by attackers and users cannot verify authenticity. Fix: Implement code signing with an EV certificate. Include signed installers and DLLs. Provide checksum verification for download integrity.
• Low · Unclear Open Source License Compliance — third_party/minhook/LICENSE.txt, LICENSE (root). MinHook is included as a third-party dependency. While it has a BSD license, ensure all third-party licenses are compatible and properly documented. Fix: Create a THIRD_PARTY_LICENSES.txt or similar document listing all dependencies and their licenses. Ensure license compatibility.
• Low · CI/CD Pipeline Security - No Visible Signing or Notarization — .github/workflows/ci.yml, .github/workflows/package.yml. GitHub Actions workflow files exist but security controls like artifact signing, notarization (for macOS), or SLSA provenance are not evident. Fix: Implement artifact signing in CI/CD pipeline. Add SLSA provenance generation. For Windows builds, implement authenticode signing.
• Low · Missing Security.md or Responsible Disclosure Policy — .github/ directory. No security policy file (.github/SECURITY.md) is present for reporting security vulnerabilities responsibly. Fix: Create a SECURITY.md file with clear instructions for reporting security issues privately. Consider using GitHub Security Advisory.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.