60 lines
3.4 KiB
Plaintext
60 lines
3.4 KiB
Plaintext
What's Fixed (Good Work)
|
||
|
||
- float height added to the master target_data_structure — now consistent with the SSBO and database.
|
||
- Thread count corrected to "five threads."
|
||
- Stale target rule fixed: "timestamp is older than 1 hour" — that's the right semantic.
|
||
- Database numbering gap (missing 5) is closed.
|
||
- int32_t police_boat properly typed in the database table.
|
||
- Database/dynamic state separation clarified — the note that the database holds only physical characteristics
|
||
is important and was missing before.
|
||
- patrol_route.json removed cleanly; simulator owns that logic now.
|
||
- Timing change resolves the A-scope problem I flagged — targets no longer have to wait for north crossing.
|
||
|
||
---
|
||
One Significant New Issue
|
||
|
||
float elapsed_seconds will lose precision at current epoch.
|
||
|
||
float has roughly 7 significant decimal digits. The current Unix timestamp is about 1,748,000,000 seconds. At
|
||
that magnitude, a float can only distinguish values that are about 128 seconds apart — it cannot tell the
|
||
difference between two timestamps that are minutes or even an hour apart. Your 1-hour stale check would break
|
||
silently.
|
||
|
||
This should be int64_t elapsed_seconds (or simply keep the original time_t, which is int64_t on 64-bit Linux).
|
||
In the PostgreSQL column, this maps to BIGINT.
|
||
|
||
---
|
||
Still Unresolved from Before
|
||
|
||
The SSBO struct (target_data_to_shader_structure, the block starting around line 142) still has the same
|
||
pseudo-types that were flagged earlier — enum material, binary police_boat, and time_t timestamp. The database
|
||
table was updated to proper types but the SSBO struct wasn't touched. Those three fields in the SSBO struct need
|
||
the same treatment:
|
||
|
||
- enum material; → int32_t material;
|
||
- binary police_boat → int32_t police_boat;
|
||
- time_t timestamp; → int64_t timestamp; — and note that std430 will align this to 8-byte boundaries, which may
|
||
pad the struct unexpectedly. Worth documenting.
|
||
|
||
Also: may_need_update in the database table still says "binary" rather than a typed value.
|
||
|
||
---
|
||
One Question on the New Timing
|
||
|
||
With targets now dispatched "as they arrive," Thread 1 could receive a new target batch at any point during a
|
||
sweep — including mid-frame while the GPU is rendering. The mutex protects the write side, but you'll need to
|
||
decide when Thread 1 actually uploads the new data to the SSBO: at the start of each render frame (safest), or
|
||
immediately on receipt. "Immediately" is fine but should be stated, so the code is written with that in mind.
|
||
Recommend adding one sentence to the Thread 1 description about when it drains the incoming target buffer and
|
||
calls glBufferSubData.
|
||
|
||
✻ Sautéed for 1m 1s
|
||
|
||
※ recap: Museum radar simulator in C++/OpenGL. We're specifying the target data pipeline in CLAUDE.md. Next: fix
|
||
the SSBO struct types — change enum material, binary police_boat, and time_t timestamp to proper int32_t and
|
||
int64_t types. (disable recaps in /config)
|
||
|
||
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
|
||
❯
|
||
───────────────────────────────────────────────────
|