From 35e52958f9d5b55fc7f581010db8dbfd5082fd12 Mon Sep 17 00:00:00 2001 From: Miloslav Ciz Date: Tue, 20 May 2025 20:00:52 +0200 Subject: [PATCH] Fix small bugs --- TODO.txt | 29 +++++++++++++++++++++-------- data | 2 +- media/manual.txt | 26 ++++++++++++++++++++++---- renderer.h | 15 ++++++++------- 4 files changed, 52 insertions(+), 20 deletions(-) diff --git a/TODO.txt b/TODO.txt index d876327..099f4c5 100644 --- a/TODO.txt +++ b/TODO.txt @@ -3,16 +3,23 @@ fuck issue trackers :D =========== GENERAL ============== - hitting ramps at higher speed still often bugs, try to fiddle with physics - again (reshape iterations, tension, ...) -- shift the car texture a bit to align the wheels? KINDA DOESN'T GETT BETTER NOW -- make car turned on its back behave nicer + again (reshape iterations, tension, ...); seem acceptable now maybe? +- frontends: + - auto test frontend, with no I/O, that will just internally run a series of + inputs and check if the output is as expected + - X11 + - ncurses? yes or no? + - try Pokitto + - Nibble, should hopefully be powerful enough. + - ESPboy? + - linux framebuffer? +- make car turned on its back behave nicer? but how? - press forward map??? :-D only when physics is frozen -- make some kinda repo for world record runs? +- make some kinda repo for world record runs? how will they submit it? - Try doing the bouncy car body? Just keep a point and its velocity, change its velocity by a proportion of car's velocity change (this minus prev. frame), then offset car body by this. However we'll also have to transform inbetween world space and model space. -- replay validation? - final tests: - very long replay - different resolutions @@ -23,8 +30,9 @@ fuck issue trackers :D - error handling (bad map format, bad replay format, items in data file, ...) - valgrind, cppcheck, different compilers, optimization levels, ... - play replay from one platform on another + - profiling - play all maps a lot - - correct saving or replays etc + - correct saving of replays etc. - empty and large data file - FPS on each platform - try to use the racing module by itself @@ -32,14 +40,19 @@ fuck issue trackers :D =========== BUGS ================= -- at high resolution (like 1920) buggy triangles sometimes appeard, tried to - fix this in S3L now but needs to be tested - immediately after starting the map countdown seems to be lower (seems to perhaps be caused by nextPhysicsFrameTime, look into it) =========== HANDLED ============== - should drifting make a sound? NO NEED +- in tiny resolution the sky jumps when rotating +- car particles seem too big in low res +- replay validation? MAYBE NOT, make a separate tool if needed, shouldn't likely + be part of the game +- at high resolution (like 1920) buggy triangles sometimes appeard, tried to + fix this in S3L now but needs to be tested +- shift the car texture a bit to align the wheels? KINDA DOESN'T GETT BETTER NOW - c99 may impose limit 4095 chars on str literal, gives warning on internal data file, try to somehow hack around it (maybe just convert it to an array in the end?) Maybe this: make a standalone C file with the string in it that diff --git a/data b/data index a5189eb..82d1cd0 100644 --- a/data +++ b/data @@ -89,7 +89,7 @@ details :~vcd2 :f212 :uzba| :uBba :AybcJ :ABbeL :'yap :^yaqI- :+Aca :!ybq :nw0k| -#Mdevtest;4321 0 +#Mdevtest;4321 2 :*313 :\a13L :m111 :=000 :fE15 :f41& :f3c1 :f771 diff --git a/media/manual.txt b/media/manual.txt index a3f7e7f..c6d021c 100644 --- a/media/manual.txt +++ b/media/manual.txt @@ -297,13 +297,31 @@ much. Q: Why is the physics so buggy? -A: You are right in the observation that Licar physics is not perfect. This is +A: You are correct in the observation that Licar physics is not perfect. This is firstly because of the game's aim for simplicity (e.g. avoiding use of floating point) combined with the fact that even without such constraints it's one of the -most difficult tasks to create a flawless physics engine. We apologize for any +most difficult tasks to create a flawless physics engine. I apologize for any frustration but unless you want to fix this yourself, you'll have to just accept -it, the game is meant to be a simple entertainment. In other words this is a -feature :) +it, the game is meant to be a simple entertainment, not physically realistic +simulator. After the release of the game it's also difficult to make any changes +to physics because all previous replays will get invalidated by the change, so +changing anything about physics will be done very, very rarely. + +Q: The graphics looks weird, stuff near camera seems to kind of warp weirdly. + +A: It's a feature, this is the software renderer's simplification of handling +near plane culling, it's how it was done back in the era of PS1 and similar +consoles, it has its charm. It should be possible to turn on the "correct", +non-warping way somewhere in the code (S3L_NEAR_CROSS_STRATEGY) if you really +want to, but it will cost some FPS. + +Q: I see glitching triangles suddenly flashing over the screen. + +A: This may be happening in higher resolutions, it's because of overflows in +integer math. Effort was made to minimize this but it can probably still happen +at times. Lowering the resolution should generally help, also increasing +S3L_NEAR in renderer.h should prevent this (but it will have some consequences). +If it seems real significant, you can report this to me. Q: I found a bug or have some other important comment. A: Send me an email (found on top of this file). diff --git a/renderer.h b/renderer.h index c35e212..8628425 100644 --- a/renderer.h +++ b/renderer.h @@ -1511,13 +1511,13 @@ void LCR_rendererDrawSky(int sky, S3L_Unit offsetH, S3L_Unit offsetV) sky = 8 + 4 * sky; LCR_loadImage(sky); - topColor = LCR_sampleImage(0,0); + topColor = LCR_sampleImage(0,0); // top strip color is the first sky pixel - LCR_loadImage(sky + 3); + LCR_loadImage(sky + 3); // load the last part of the sky (3) bottomColor = LCR_sampleImage(LCR_IMAGE_SIZE - 1,LCR_IMAGE_SIZE - 1); - anchorPoint[0] = ((LCR_EFFECTIVE_RESOLUTION_X * offsetH) / S3L_F) % - (2 * LCR_IMAGE_SIZE * LCR_SETTING_SKY_SIZE); + anchorPoint[0] = ((LCR_IMAGE_SIZE * 2 * LCR_SETTING_SKY_SIZE * offsetH) + / S3L_F) % (2 * LCR_IMAGE_SIZE * LCR_SETTING_SKY_SIZE); if (anchorPoint[0] < 0) anchorPoint[0] += 2 * LCR_IMAGE_SIZE * LCR_SETTING_SKY_SIZE; @@ -1541,7 +1541,7 @@ void LCR_rendererDrawSky(int sky, S3L_Unit offsetH, S3L_Unit offsetV) } anchorPoint[1] += 2 * LCR_IMAGE_SIZE * LCR_SETTING_SKY_SIZE; - + int linesLeft = 0; int skyPart = 0; @@ -1759,7 +1759,7 @@ void LCR_rendererDrawLOD(void) { variability = variability < 14 ? variability + 1 : 0; bx = j * 8 + 4; - _LCR_rendererDrawLODBlock(bx,by,bz,2000, + _LCR_rendererDrawLODBlock(bx,by,bz,4 * S3L_F, LCR_SETTING_LOD_COLOR,variability); } @@ -2204,7 +2204,8 @@ void LCR_rendererDraw3D(void) S3L_rotationToDirections(LCR_renderer.carModel->transform.rotation, LCR_RENDERER_UNIT / 2,&p,&r,0); -#define LCR_PARTICLE_SIZE (16 << (LCR_EFFECTIVE_RESOLUTION_X / 640)) +#define LCR_PARTICLE_SIZE \ + ((16 << (LCR_EFFECTIVE_RESOLUTION_X / 640)) >> LCR_ANT_RESOLUTION) p.w = LCR_PARTICLE_SIZE;