Lift the 65535-byte .dat file-size limit - #5
Open
rremedio wants to merge 8 commits into
Open
Conversation
* chore: ignore Visual Studio build artifacts (x64/Win32 output, *.user/*.aps/etc.) * feat: lift the 65535-byte .dat file-size limit The editor capped tracks at 65535 bytes via one fixed array, GPTrack.h trackdata[65535]. Raise it to GP2_MAX_TRACKDATA = 0x50000 (320 KB) so the editor can save/open tracks as large as the GP2Lap game-side ExtraTrackFileKB max (0x10000 + 256*1024). - trackdata[] sized by the new constant; memset matches. - The load sanity check `if (fileLength < 65535)` (which rejected >=64 KB files as "not a track file") raised to `<= GP2_MAX_TRACKDATA`. - Added a `count > GP2_MAX_TRACKDATA` guard before both fread()s (ReadTrackFile + the other loader), closing the latent buffer overflow when handed an oversized .dat. Other 65535/65536 hits in the source are unrelated (angle ranges, command-arg math, image scaling) and left untouched. --------- Co-authored-by: Roberto Remedio <rremedio@gmail.com>
OnFileSaveAs passed the bare filename (CFileDialog::GetFileName) to setFileName/WriteTrackFile, so the track was written relative to the process working directory (the exe location) instead of the folder the user selected. Use the full path (GetPathName) instead, which also makes a subsequent File > Save target the correct location. Co-authored-by: Roberto Remedio <rremedio@gmail.com>
…etup (#4) Template wrapper that mirrors the source from a (case-sensitive, no-mmap) virtiofs share to a local NTFS dir in the guest and builds there, which behaves like a native Windows checkout. Copy to build.bat (now gitignored) and adjust the VS path, SDK version, and scratch dir for your VM. Co-authored-by: Roberto Remedio <rremedio@gmail.com>
Collaborator
|
It's hard to remember back but I felt the limit was imposed by the game and not just the editor have you been able to make a larger track that the game can consume? |
mydeveloperday
approved these changes
Jun 8, 2026
Contributor
Author
Yes. The GP2Lap change lifts the game limit (won't work in the stock game). TBH I only tested by inflating a track by adding repeated internal objects into it and it loaded fine in the game and worked fine in the editor. |
* Add "Show Compiled Track" view with bit-exact gp2cc module Add a toggleable editor view (View menu + toolbar "C" button) that draws GP2's exact compiled track geometry and cc-line (racing line), with no pitlane/kerbs/objects. When active it recompiles from the live track on each repaint, so it updates as cc-line sectors are edited, and mirrors the other cc-line views: a small perpendicular tick where each cc-line sector starts, plus a highlight on the selected sector. Drawing goes through a new standalone C module (gp2cc.c/.h/gp2cc_tables.c): a bit-exact port of GP2's geometry compiler + cc-line (UACalcBestLine) and its helpers, validated to the byte against GP2Lap dumps on F1CT01/02a/03/ 09/11/16: - geometry: heading, startAngle, road widths, side vectors - exact integer position warp (Bresenham gap distribution, sub_76D39) - cc-line bestLine / angle18 t_Sinus and t_ArithTab1 are embedded in gp2cc_tables.c so no GP2.EXE is needed at runtime. * Compiled view: section dividers, numbers, and start/finish line Make the existing "Track Section Numbers" and "Show Finish Line" toggles work in the Show Compiled Track view: - showFinishLine: thick line across the road at segment 0 + checkered flag. - showTrackNumbers: a perpendicular divider across the road at each track section boundary + the section index drawn mid-section. Section->segment mapping uses cumulative TrackSection::getLength() (= the geometry-command word gp2cc consumes), so the markers land bit-exactly on the compiled road. GPTrack.cpp only; no gp2cc change. --------- Co-authored-by: Roberto Remedio <rremedio@gmail.com>
* Add "Show Compiled Track" view with bit-exact gp2cc module Add a toggleable editor view (View menu + toolbar "C" button) that draws GP2's exact compiled track geometry and cc-line (racing line), with no pitlane/kerbs/objects. When active it recompiles from the live track on each repaint, so it updates as cc-line sectors are edited, and mirrors the other cc-line views: a small perpendicular tick where each cc-line sector starts, plus a highlight on the selected sector. Drawing goes through a new standalone C module (gp2cc.c/.h/gp2cc_tables.c): a bit-exact port of GP2's geometry compiler + cc-line (UACalcBestLine) and its helpers, validated to the byte against GP2Lap dumps on F1CT01/02a/03/ 09/11/16: - geometry: heading, startAngle, road widths, side vectors - exact integer position warp (Bresenham gap distribution, sub_76D39) - cc-line bestLine / angle18 t_Sinus and t_ArithTab1 are embedded in gp2cc_tables.c so no GP2.EXE is needed at runtime. * Compiled view: section dividers, numbers, and start/finish line Make the existing "Track Section Numbers" and "Show Finish Line" toggles work in the Show Compiled Track view: - showFinishLine: thick line across the road at segment 0 + checkered flag. - showTrackNumbers: a perpendicular divider across the road at each track section boundary + the section index drawn mid-section. Section->segment mapping uses cumulative TrackSection::getLength() (= the geometry-command word gp2cc consumes), so the markers land bit-exactly on the compiled road. GPTrack.cpp only; no gp2cc change. * Semantic C++ track-geometry compiler (gp2geom), wired into the compiled view Rewrites GP2's geometry compilation as the geometric process it actually is — a fixed-point "turtle" with named steps (turn, advance one fixed chord, midpoint half-step, ramp width, compute side vectors, close the loop) — instead of a transcription of the disassembly. Every fixed-point op is a named helper whose comment derives the constant (0x6488 = round(pi/2*2^14); the half-step = midpoint integration; the warp = DDA error diffusion; the chord = a fixed 128-unit step). Same exact integers: validated BYTE-IDENTICAL to the original gp2cc compiler on F1CT01/02a/03/09/11/16 (every field) and the cc-line on it is bit-exact. The cosine it uses comes from gp2cos.hpp: the table expressed as its formula (round(16384*cos(i*pi/4096)) + the one documented COS[1992]=703 quirk), generated at compile time and static_assert'd against GP2's extracted bytes. If a toolchain struggles with the constexpr generation, define GP2GEOM_EMBEDDED_COS to use the existing table (bit-identical); MSVC also gets a raised /constexpr:steps budget. New files only — the original gp2cc.c (incl. the chaotic cc-line kernel, kept as-is) is untouched. drawComputed now calls gp2geom::compileGeometry; the cc-line still runs through the existing kernel. Note: ATAN1's formula header (gp2atan.hpp) is proven but not wired in yet — it belongs with a later cc-line-kernel cleanup. CMakeLists isn't on this branch (predates the upstream CMake merge); when this lands on dev, add gp2cc.c, gp2cc_tables.c and gp2geom.cpp to its SOURCES. * Wire the cc-line solver to C++ + the formula atan table (gp2ccline) Ports GP2's racing-line kernel (UACalcBestLine + helpers: reproject, build_centre, nudge, q30 trig, the fixed-iteration integer sqrts, atan2) to C++, fed by the formula-generated tables (gp2cos.hpp cosine + gp2atan.hpp arctan). It is a faithful transcription of the chaotic fixed-point math, not a re-derivation — validated BIT-IDENTICAL to the original gp2cc_compute_ccline (bestLine, angle18, cmdStartSeg, numCmds) on F1CT01/02a/03/09/11/16. drawComputed now runs entirely on the C++/formula path: gp2geom::compileGeometry for the geometry and gp2geom::computeCcLine for the racing line. gp2cc.c/.h/_tables.c stay compiled (fallback, the shared structs, and gp2cc_gv which the view's drawing still uses) until the new files are tested in the editor. gp2atan.hpp now wired in (was sandbox-only). vcxproj builds gp2ccline.cpp (stdcpp17, NotUsing PCH, raised /constexpr:steps). View drawing unchanged. * Compiled track + cc-line as independent overlays on the normal view Scrap the standalone compiled-track view (which replaced the normal view). The two compiled features are now independent, toggleable overlays drawn on top of the normal editor view: - Compiled Track overlay (showComputed, reuses ID_VIEW_COMPILED): bit-exact road edges + per-section dividers, BLUE. - Compiled CC-Line overlay (new showComputedCCLine / ID_VIEW_COMPILED_CCLINE): bit-exact racing line + per-sector start ticks + selected-sector highlight, ORANGE / bright YELLOW. Both compile once per repaint (buildCompiledOverlay) and share the result. Fix the selected-sector off-by-one: CCLineSection[c] starts at cmdSeg[c+1] (cmdSeg[0] is the seed/start command = the editor's CCLineStart header, not a user sector), so selecting sector N now highlights N. drawComputed() is split into buildCompiledOverlay + drawCompiledTrack + drawCompiledCcLine; OnDraw's standalone branch is removed and the overlays are appended to the normal-view branch. Menu: "Show Compiled Track" -> "Compiled Track Overlay" + new "Compiled CC-Line Overlay". Toolbar: ID_VIEW_COMPILED button re-tinted blue (track-tool icon); new ID_VIEW_COMPILED_CCLINE button (ccline-tool icon, orange via repurposed palette idx 5). gp2cc.c untouched. View-only. * Nicer overlay toolbar icons + tooltips Replace the compiled-track and compiled-CC-line toolbar icons with recolored copies of the existing Show Track / Show CC Line glyphs (track in blue, CC line in orange) and add status-bar/tooltip strings for both buttons. * Register new geometry/cc-line sources in CMakeLists.txt Add gp2cc.c, gp2cc_tables.c, gp2ccline.cpp and gp2geom.cpp to the CMake SOURCES list so the CMake build matches the .vcxproj. * Restore Latin-1 copyright/credit characters in TrackEditor.rc An earlier edit had re-saved the file as UTF-8 and mangled the three non-ASCII characters (the two (c) copyright signs and the e-umlaut in 'Michael') into U+FFFD. Restore the original ISO-8859-1 bytes so those lines match upstream byte-for-byte. * Remove the legacy C track-compiler (gp2cc.c / gp2cc_tables.c) The C++ modules gp2geom (geometry) and gp2ccline (cc-line) are the live compilers now; the old C kernel was dead except for one cosine helper (gp2cc_gv) used to draw the overlay. Move that into gp2geom::gv (the interpolated GetSinusVal, bit-identical over all 65536 angles, verified against the old table) and delete both C files. gp2cc.h is trimmed to just the shared output structs (gp2cc_track / gp2cc_ccgeo). gp2geom now always uses the build-time formula cosine table (gp2cos.hpp); the GP2GEOM_EMBEDDED_COS fallback is dropped since its table source is gone. Removed from the .vcxproj and CMakeLists SOURCES. * Drop disassembly names from gp2ccline comments Replace the GP2 sub_/address/field references in the cc-line solver's comments with plain descriptions of what each step does, rename the register-named 'ebp' local to 'step', and name the 0xCBB0C constant kInvPiQ16 (round(2^16/pi)) with a derivation. Pure comment/identifier changes — the fixed-point math is unchanged (still bit-exact). * Drop the embedded GP2 reference tables and full-table guards The cosine/atan tables are generated from their formulas at compile time; gp2cos_reference.hpp and gp2atan_reference.hpp existed only to hold GP2's extracted bytes for a static_assert that proved the generated tables matched. Remove both headers and the matchesReference/atanMatchesReference guards (and their .vcxproj entries) so no extracted GP2 data ships in the editor. In their place, each table header now warns that the entries come from compile-time float rounding: a different compiler/std-lib could round a .5-boundary entry the other way, and a drifting compiled track or cc-line is the symptom to watch for. The single load-bearing boundary (cos index 1992) is still pinned by a one-line spot-check static_assert. Verified the generated tables still match GP2's bytes bit-for-bit on the current toolchain.
buildCompiledOverlay drew widthL/widthR with the perpendicular sign opposite to the normal view's getLeftSide (angle-90) / getRightSide (angle+90), so a Track Width Change Right (0xB5) command moved the on-screen LEFT edge and vice-versa. Flip the edge signs so widthL uses -pv (left) and widthR uses +pv (right), matching the normal view and the game.
phoad107185
approved these changes
Jun 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've been working on raising the maximum track filesize using GP2Lap -> rremedio/gp2lap#7
The editor capped tracks at 65535 bytes via one fixed array,
GPTrack.h`` trackdata[65535]. Raise it toGP2_MAX_TRACKDATA = 0x50000(320 KB) so the editor can save/open tracks as large as the GP2Lap game-sideExtraTrackFileKBmax (0x10000 + 256*1024).Unrelated extras included, I can separate them into different PRs if required: