https://forum.supertuxkart.net/ Wed, 04 Nov 2026 19:00:43 +0000 MyBB https://forum.supertuxkart.net/thread-476.html Tue, 03 Nov 2026 16:31:10 +0000 MatiusRock]]> https://forum.supertuxkart.net/thread-476.html My name is Jorge, and I'm a software developer from Colombia. I'm excited to share an independent open-source experiment I've been working on, based on the amazing work of the SuperTuxKart team and its contributors.
First of all, I'd like to thank everyone who has contributed to SuperTuxKart over the years. The game is a fantastic example of what an open-source community can accomplish.
Introducing SourceQuest
I've recently launched SourceQuest, a personal project dedicated to showcasing open-source games and exploring new ways to make them accessible, including directly through web browsers.
Website: https://sourcequest.games/
One of my experiments is an unofficial WebAssembly port of SuperTuxKart, which allows players to experience the original game in a compatible browser without installing a desktop application.
You can explore it here:
https://sourcequest.games/games/stk/
What I've been working on
My goal was not to recreate SuperTuxKart or develop a competing game, but to adapt its original C++ engine for execution in modern web browsers.
The current experimental implementation includes:

• The original SuperTuxKart C++ engine compiled with Emscripten and WebAssembly.
  
• WebGL 2 rendering using the game's original rendering architecture.
  
• Original kart physics, tracks, characters, and AI.
  
• Single-player races against AI opponents.
  
• Browser-based storage for game data, profiles, and settings.
  
• Experimental multiplayer support using dedicated rooms hosted on my own server.
  
• WebSocket-to-UDP networking adaptations to support browser-based multiplayer.
  

The multiplayer implementation is especially interesting to me, as it allows players to join rooms through the game's existing local networking interface.
The browser version is still experimental. It has compatibility and performance limitations, and it does not connect to SuperTuxKart's official public server list.
The initial download is approximately 350 MB, with subsequent visits benefiting from browser caching.
I've primarily tested the implementation using Chrome on Windows.
Source code and technical documentation
The complete source code of my browser adaptation is publicly available:
https://github.com/MatiusRock1/stkwebassembly
The repository includes the original engine sources, WebAssembly build configuration, browser adaptations, packaging scripts, and experimental networking components.
It also documents the original upstream revision, modifications, build process, and known limitations.
I'm sharing the source because I believe other developers might find the technical exploration useful, especially those interested in bringing existing C++ games to WebAssembly.
Credits, licensing, and respect for the original project
I want to make something very clear:
SuperTuxKart was created and is maintained by the SuperTuxKart team and its community. I do not claim ownership or authorship of the original game, engine, characters, tracks, artwork, music, or other original assets.
My work focuses on adapting the existing game for browser execution, integrating it into SourceQuest, and experimenting with browser-compatible networking.
This is an independent, unofficial project. It is not affiliated with, sponsored by, or endorsed by the SuperTuxKart team.
The original GNU GPL v3-or-later licensing is preserved for the applicable code and modifications. The game's assets retain their respective licenses and attribution information.
I've also included links to the original project, its source code, and a dedicated credits and licensing page.
Credits: https://sourcequest.games/credits.html
Official SuperTuxKart website: https://supertuxkart.net/
Why I'm sharing this here
My intention is to help more people discover great open-source games while exploring what modern browser technologies can achieve.
I believe projects like SuperTuxKart deserve greater visibility, and making them accessible through browsers could introduce them to new audiences.
I'm sharing this experiment with the community because I would genuinely appreciate your thoughts, especially regarding:

• Technical feedback on the WebAssembly adaptation.
  
• Performance and browser compatibility improvements.
  
• The experimental multiplayer implementation.
  
• Proper attribution and licensing practices.
  
• Potential opportunities to share technical findings with the original project.
  

If there is anything I should improve regarding the presentation, source code, licensing, or attribution, please let me know. I'm absolutely open to feedback and willing to make adjustments.
This experiment exists because of the incredible work already done by the SuperTuxKart community, and I want to make sure that work is properly recognized.
Thank you to everyone who has made SuperTuxKart possible!
Best regards,
Jorge
SourceQuest – https://sourcequest.games/]]> My name is Jorge, and I'm a software developer from Colombia. I'm excited to share an independent open-source experiment I've been working on, based on the amazing work of the SuperTuxKart team and its contributors.
First of all, I'd like to thank everyone who has contributed to SuperTuxKart over the years. The game is a fantastic example of what an open-source community can accomplish.
Introducing SourceQuest
I've recently launched SourceQuest, a personal project dedicated to showcasing open-source games and exploring new ways to make them accessible, including directly through web browsers.
Website: https://sourcequest.games/
One of my experiments is an unofficial WebAssembly port of SuperTuxKart, which allows players to experience the original game in a compatible browser without installing a desktop application.
You can explore it here:
https://sourcequest.games/games/stk/
What I've been working on
My goal was not to recreate SuperTuxKart or develop a competing game, but to adapt its original C++ engine for execution in modern web browsers.
The current experimental implementation includes:

• The original SuperTuxKart C++ engine compiled with Emscripten and WebAssembly.
  
• WebGL 2 rendering using the game's original rendering architecture.
  
• Original kart physics, tracks, characters, and AI.
  
• Single-player races against AI opponents.
  
• Browser-based storage for game data, profiles, and settings.
  
• Experimental multiplayer support using dedicated rooms hosted on my own server.
  
• WebSocket-to-UDP networking adaptations to support browser-based multiplayer.
  

The multiplayer implementation is especially interesting to me, as it allows players to join rooms through the game's existing local networking interface.
The browser version is still experimental. It has compatibility and performance limitations, and it does not connect to SuperTuxKart's official public server list.
The initial download is approximately 350 MB, with subsequent visits benefiting from browser caching.
I've primarily tested the implementation using Chrome on Windows.
Source code and technical documentation
The complete source code of my browser adaptation is publicly available:
https://github.com/MatiusRock1/stkwebassembly
The repository includes the original engine sources, WebAssembly build configuration, browser adaptations, packaging scripts, and experimental networking components.
It also documents the original upstream revision, modifications, build process, and known limitations.
I'm sharing the source because I believe other developers might find the technical exploration useful, especially those interested in bringing existing C++ games to WebAssembly.
Credits, licensing, and respect for the original project
I want to make something very clear:
SuperTuxKart was created and is maintained by the SuperTuxKart team and its community. I do not claim ownership or authorship of the original game, engine, characters, tracks, artwork, music, or other original assets.
My work focuses on adapting the existing game for browser execution, integrating it into SourceQuest, and experimenting with browser-compatible networking.
This is an independent, unofficial project. It is not affiliated with, sponsored by, or endorsed by the SuperTuxKart team.
The original GNU GPL v3-or-later licensing is preserved for the applicable code and modifications. The game's assets retain their respective licenses and attribution information.
I've also included links to the original project, its source code, and a dedicated credits and licensing page.
Credits: https://sourcequest.games/credits.html
Official SuperTuxKart website: https://supertuxkart.net/
Why I'm sharing this here
My intention is to help more people discover great open-source games while exploring what modern browser technologies can achieve.
I believe projects like SuperTuxKart deserve greater visibility, and making them accessible through browsers could introduce them to new audiences.
I'm sharing this experiment with the community because I would genuinely appreciate your thoughts, especially regarding:

• Technical feedback on the WebAssembly adaptation.
  
• Performance and browser compatibility improvements.
  
• The experimental multiplayer implementation.
  
• Proper attribution and licensing practices.
  
• Potential opportunities to share technical findings with the original project.
  

If there is anything I should improve regarding the presentation, source code, licensing, or attribution, please let me know. I'm absolutely open to feedback and willing to make adjustments.
This experiment exists because of the incredible work already done by the SuperTuxKart community, and I want to make sure that work is properly recognized.
Thank you to everyone who has made SuperTuxKart possible!
Best regards,
Jorge
SourceQuest – https://sourcequest.games/]]> https://forum.supertuxkart.net/thread-475.html Sun, 01 Nov 2026 18:06:13 +0000 YYee]]> https://forum.supertuxkart.net/thread-475.html
The first build failed with unresolved symbols: CallX64, GetReturnedFloat and GetReturnedDouble.

With AI-assisted troubleshooting, I changed the condition for including the x64 assembly file in lib/angelscript/projects/cmake/CMakeLists.txt  to  if(MSVC AND CMAKE_GENERATOR_PLATFORM STREQUAL "x64")

After running CMake again, the build succeeded.

When launching the game, Windows reported that libc++.dll was missing. I copied the dependency DLLs into the executable’s folder, then added libc++.dll and libunwind.dll from the x86_64 runtime folder of LLVM MinGW. The game now opens successfully.

Is this an appropriate solution for this setup, or is there a recommended way to avoid these issues?

Thanksss  ]]>
The first build failed with unresolved symbols: CallX64, GetReturnedFloat and GetReturnedDouble.

With AI-assisted troubleshooting, I changed the condition for including the x64 assembly file in lib/angelscript/projects/cmake/CMakeLists.txt  to  if(MSVC AND CMAKE_GENERATOR_PLATFORM STREQUAL "x64")

After running CMake again, the build succeeded.

When launching the game, Windows reported that libc++.dll was missing. I copied the dependency DLLs into the executable’s folder, then added libc++.dll and libunwind.dll from the x86_64 runtime folder of LLVM MinGW. The game now opens successfully.

Is this an appropriate solution for this setup, or is there a recommended way to avoid these issues?

Thanksss  ]]> https://forum.supertuxkart.net/thread-457.html Sat, 10 Oct 2026 22:31:33 +0000 Chungusse]]> https://forum.supertuxkart.net/thread-457.html https://forum.supertuxkart.net/thread-456.html Sat, 10 Oct 2026 21:33:21 +0000 Gusta]]> https://forum.supertuxkart.net/thread-456.html
But, how it works in STK? And this will be revelant for STK Evo?]]>
But, how it works in STK? And this will be revelant for STK Evo?]]> https://forum.supertuxkart.net/thread-454.html Sat, 10 Oct 2026 03:29:59 +0000 Christopher]]> https://forum.supertuxkart.net/thread-454.html
Right now, Pepper races solo, but it would be amazing if Carrot the cat could be included on her kart, not as a separate playable character, but maybe curled up sleeping on the back or just sitting down with small animations.
Since we already have Godette with GDBot on the front of the kart, having Carrot on Pepper's kart would be Great.

Would or be able to add him in?]]>
Right now, Pepper races solo, but it would be amazing if Carrot the cat could be included on her kart, not as a separate playable character, but maybe curled up sleeping on the back or just sitting down with small animations.
Since we already have Godette with GDBot on the front of the kart, having Carrot on Pepper's kart would be Great.

Would or be able to add him in?]]> https://forum.supertuxkart.net/thread-452.html Fri, 09 Oct 2026 10:37:01 +0000 Mish7913]]> https://forum.supertuxkart.net/thread-452.html , I was walking on site, and find a page where is shows STK World Map:



And when I first saw this, I was like: "Wait ... what happened to Africa?", and then I realize that this is not a map or real world, it's a remaked to fantasy map , and then I was thinking: "What if make a map not too simillar to our world?", and so ... I drew a sketch of a map how I imagined:



If you like this idea, I can draw final version of that.
So ... What do y'all thknk?

  Stkflag_worldMap_a.jpg (Size: 109.81 KB / Downloads: 94)

  stk_newmap.jpg (Size: 186.94 KB / Downloads: 94) ]]> , I was walking on site, and find a page where is shows STK World Map:



And when I first saw this, I was like: "Wait ... what happened to Africa?", and then I realize that this is not a map or real world, it's a remaked to fantasy map , and then I was thinking: "What if make a map not too simillar to our world?", and so ... I drew a sketch of a map how I imagined:



If you like this idea, I can draw final version of that.
So ... What do y'all thknk?

  Stkflag_worldMap_a.jpg (Size: 109.81 KB / Downloads: 94)

  stk_newmap.jpg (Size: 186.94 KB / Downloads: 94) ]]> https://forum.supertuxkart.net/thread-450.html Thu, 08 Oct 2026 18:47:02 +0000 Gusta]]> https://forum.supertuxkart.net/thread-450.html https://github.com/supertuxkart/stk-code/issues/5892

(Too lazy to talk more lol)]]> https://github.com/supertuxkart/stk-code/issues/5892

(Too lazy to talk more lol)]]> https://forum.supertuxkart.net/thread-441.html Wed, 23 Sep 2026 10:38:55 +0000 Kubrix]]> https://forum.supertuxkart.net/thread-441.html https://supertuxkart.net on Steam? Might be able to donate 100 usd if you have PayPal]]> https://supertuxkart.net on Steam? Might be able to donate 100 usd if you have PayPal]]> https://forum.supertuxkart.net/thread-434.html Fri, 18 Sep 2026 15:00:36 +0000 stbdev]]> https://forum.supertuxkart.net/thread-434.html
I am in the process of implementing a speed lines shader to the stk-codebase. With this post I'm hoping to discuss the possibility of adding it to the game.

Intro
Speed lines (aka wind streaks) (see the videos below for more info) are quite a common feature in kart racing games, as the name suggests they come on screen when the player experiences a speed boost of some sorts, usually through an upgrade. I personally noticed them first in Mario Kart, but I've since gone and checked a few other kart racers (Sonic, Crash Team Racing etc.) and they all feature them in some capacity. The main purpose is to provide an extra sense of speed to the player, by mimicking wind rushing past at high speeds.

Shader
I initially started writing the effect purely in GLSL, but pivoted to using Godot's visual shader graph for quicker iteration. Before delving into more specifics here's what it looks like in isolation:
https://youtu.be/_1LBMsESjSQ

(or see next post for embedded view)

There are quite a few tweakable parameters for the shader. Ranging from: 

• Density of particles
  
• Softness of the particles
  
• Amount of wisps (i.e. how many subdivisions of the UV space to sample the noise texture from)
  
• Wind speed (very useful as we can tie the intensity of the boost to this)
  
• Radial stretch (how blobly should the wisps be, effectively stretches the uv.x coordinate)
  
• Radial mask size (how much of the screen should be ensure is always free of the effect - for gameplay purposes)
  
• etc.
  

At the moment I have implemented a primary control to the shader (value ranging from 0-1 as a scalar float) BoostIntensity. That value is driving:

• the wind speed
  
• size of the radial mask (make the mask a bit tighter at higher intensities to really bring home the sense of speed)
  
• color saturation (make the effect pop more at higher intensities, makes the wind feel more intense)
  

While I still need to profile on some weaker hardware, the shader should be really cheap to run on most hardware. On my machine it was close to 30us (7900xt). The effect works with sampling a noise texture at 2 samples per pixel, which is really modest in my experience.

Preview
Hooking up the shader and it's driving value -> BoostIntensity. We get something like the following:

(note the effect does look somewhat choppy due to the video quality, but is smooth during actual gameplay)


Implementation
I am still trialing the proper CPU side implementation, mainly on the 'how exactly' the effect should come in, how strong and how long should it last etc.

I've been experimenting with a few different options for the question 'how exactly'. Ranging from:

• Should it come in mainly based on current velocity ratio with maximum velocity?
  
• Should it be on impulse/activation of a SpeedIncrease?
  

I believe at the moment I'm going with a bit of a hybrid solution of the both, this looks roughly like the following:

• Use the trigger of any SpeedIncrease modifier as the impulse 
  
  (as long as there's no active SpeedDecrease or Attachment like the anchor/parachute etc.).
  
  
• Then shortly driving up the value and overshooting slightly to a target value.
  
  (make the impulse of the effect a tad stronger than it's sustained intensity).
  
  
• Then settle down the intensity value and base it on the ratio between the current speed and the maximum speed.
  The last step here effectively helps tie the effect to match with the current speed regardless of difficulty setting.
  
  
• Then I use the already pre-existing unique duration(s) of the SpeedIncrease to keep the effect active.
  
  
• Once the SpeedIncrease runs out we linearly interpolate back down to 0 to gently ease out.
  
  
• There are also some provisions for correctly latching whether we've crashed into something, drastically lost speed or got hit with a SpeedDecrease to then directly ease down to 0 (rather than waiting for the effect to run out naturally).
  
  

I am still needing to properly clean up and dial in the logic, but I personally think it's getting closer to the final solution. A couple of notes from my side:

• The effect does still ramp up to 1.0f quite fast at the moment, dialing this down is something I'm working on, it should only really be at 1.0f if we've stacked 2-3 speed increases and going fast (i.e. coming out of red skid + zipper + nitro should be 1).
  
  
• Once we crash the effect can come down just a tad faster in my book, at the moment it uses the same linear ease down to 0 as when the effect normally runs out.
  
  
• Certain SpeedIncrease items we can maybe experiment with not having it contribute to the intensity (i.e. turn it off for skids etc.?)
  

Closing Remarks
If this feature/effect looks of interest to you and would be a good fit for the game, let me know and I can clean up my code and start the PR. From there we can discuss further and iterate on feedback/suggestions.

PS: I did only notice at the posting of this post that there might be a related thread to another implementation of speed lines, my apologies there, but I do think we can work out a way to combine our efforts. https://forum.supertuxkart.net/thread-200.html

Thanks and kind regards,
stbdev]]>
I am in the process of implementing a speed lines shader to the stk-codebase. With this post I'm hoping to discuss the possibility of adding it to the game.

Intro
Speed lines (aka wind streaks) (see the videos below for more info) are quite a common feature in kart racing games, as the name suggests they come on screen when the player experiences a speed boost of some sorts, usually through an upgrade. I personally noticed them first in Mario Kart, but I've since gone and checked a few other kart racers (Sonic, Crash Team Racing etc.) and they all feature them in some capacity. The main purpose is to provide an extra sense of speed to the player, by mimicking wind rushing past at high speeds.

Shader
I initially started writing the effect purely in GLSL, but pivoted to using Godot's visual shader graph for quicker iteration. Before delving into more specifics here's what it looks like in isolation:
https://youtu.be/_1LBMsESjSQ

(or see next post for embedded view)

There are quite a few tweakable parameters for the shader. Ranging from: 

• Density of particles
  
• Softness of the particles
  
• Amount of wisps (i.e. how many subdivisions of the UV space to sample the noise texture from)
  
• Wind speed (very useful as we can tie the intensity of the boost to this)
  
• Radial stretch (how blobly should the wisps be, effectively stretches the uv.x coordinate)
  
• Radial mask size (how much of the screen should be ensure is always free of the effect - for gameplay purposes)
  
• etc.
  

At the moment I have implemented a primary control to the shader (value ranging from 0-1 as a scalar float) BoostIntensity. That value is driving:

• the wind speed
  
• size of the radial mask (make the mask a bit tighter at higher intensities to really bring home the sense of speed)
  
• color saturation (make the effect pop more at higher intensities, makes the wind feel more intense)
  

While I still need to profile on some weaker hardware, the shader should be really cheap to run on most hardware. On my machine it was close to 30us (7900xt). The effect works with sampling a noise texture at 2 samples per pixel, which is really modest in my experience.

Preview
Hooking up the shader and it's driving value -> BoostIntensity. We get something like the following:

(note the effect does look somewhat choppy due to the video quality, but is smooth during actual gameplay)


Implementation
I am still trialing the proper CPU side implementation, mainly on the 'how exactly' the effect should come in, how strong and how long should it last etc.

I've been experimenting with a few different options for the question 'how exactly'. Ranging from:

• Should it come in mainly based on current velocity ratio with maximum velocity?
  
• Should it be on impulse/activation of a SpeedIncrease?
  

I believe at the moment I'm going with a bit of a hybrid solution of the both, this looks roughly like the following:

• Use the trigger of any SpeedIncrease modifier as the impulse 
  
  (as long as there's no active SpeedDecrease or Attachment like the anchor/parachute etc.).
  
  
• Then shortly driving up the value and overshooting slightly to a target value.
  
  (make the impulse of the effect a tad stronger than it's sustained intensity).
  
  
• Then settle down the intensity value and base it on the ratio between the current speed and the maximum speed.
  The last step here effectively helps tie the effect to match with the current speed regardless of difficulty setting.
  
  
• Then I use the already pre-existing unique duration(s) of the SpeedIncrease to keep the effect active.
  
  
• Once the SpeedIncrease runs out we linearly interpolate back down to 0 to gently ease out.
  
  
• There are also some provisions for correctly latching whether we've crashed into something, drastically lost speed or got hit with a SpeedDecrease to then directly ease down to 0 (rather than waiting for the effect to run out naturally).
  
  

I am still needing to properly clean up and dial in the logic, but I personally think it's getting closer to the final solution. A couple of notes from my side:

• The effect does still ramp up to 1.0f quite fast at the moment, dialing this down is something I'm working on, it should only really be at 1.0f if we've stacked 2-3 speed increases and going fast (i.e. coming out of red skid + zipper + nitro should be 1).
  
  
• Once we crash the effect can come down just a tad faster in my book, at the moment it uses the same linear ease down to 0 as when the effect normally runs out.
  
  
• Certain SpeedIncrease items we can maybe experiment with not having it contribute to the intensity (i.e. turn it off for skids etc.?)
  

Closing Remarks
If this feature/effect looks of interest to you and would be a good fit for the game, let me know and I can clean up my code and start the PR. From there we can discuss further and iterate on feedback/suggestions.

PS: I did only notice at the posting of this post that there might be a related thread to another implementation of speed lines, my apologies there, but I do think we can work out a way to combine our efforts. https://forum.supertuxkart.net/thread-200.html

Thanks and kind regards,
stbdev]]> https://forum.supertuxkart.net/thread-421.html Tue, 25 Aug 2026 20:08:19 +0000 Gusta]]> https://forum.supertuxkart.net/thread-421.html
I have some ideas that I can talk later.]]>
I have some ideas that I can talk later.]]> https://forum.supertuxkart.net/thread-412.html Wed, 19 Aug 2026 15:50:32 +0000 schrowd]]> https://forum.supertuxkart.net/thread-412.html Issue #5197 mentions adding the ability to pause, seek, move back and forth by individual frames and change
the speed of playback when watching replays. To this, Alayan responded "Pause, rewind and speed change are
all things I would like to have as well. This won't be in 1.5 and maybe not in 2.0, but it's definitely on the roadmap."

I have built the engine side of this and in accordance with the "Communicating with the team" section of the
contributing code guidelines I am making a forum post about it.

I have implemented this by means of a ReplayControl class that owns the replay clock. It can pause (setPlaying), move 
the head of the playback to a desired time (seek) and change the rate of playback (setRate). The ability to move back and 
forth by individual frames naturally falls out of this; you would just seek by a frame-sized delta (or move to an adjacent time
via m_all_times, both can work). This functionality is currently enabled via a --replay-control flag and without it it is inert.
This doesn't change the normal race clock: everything outside of watch replay mode remains untouched.

I have deliberately NOT added the UI. I've built the mechanism, however as it stands there is no user interface that allows
the user to control it. This is on purpose and has been done for two main reasons.

   1. Building UI blind without knowing if it is wanted or how the structure should be set out puts my time and effort at risk of being wasted.

   2. Where the UI lives, how it looks, where the buttons are, etc. are design decisions that are not my call to make.

This feature has a dependency on the fix outlined in pull request #5837 - without it, seeking backwards would cause the ghost
to freeze in place, which is far from ideal.

The diff can be found here: https://github.com/schrowd/stk-code/compare/fix-ghost-controller-seekable...feature-replay-control

(Note to reviewer: the three "removed" lines in world_status.cpp are still there, they're just indented one level deeper and so
 GitHub shows them as red. None of the original behaviour has been changed or deleted. You can see that exact same code in
 lines 479-481.)

To wrap this up, I'd like to ask a few questions:

• Is this something you'd want in the main game?
  
• Should I build the UI or is that something you would be doing?
  
• Is driving the world clock the correct approach?
  
• Where should this live? It currently lives in src/replay: does it belong somewhere else?
  
• Whose job should it be to handle frame-stepping - ReplayControl's or the UI's?
  

Those are the main questions I'd like answers for however if you have any other questions or concerns I'd be happy to answer them.]]> Issue #5197 mentions adding the ability to pause, seek, move back and forth by individual frames and change
the speed of playback when watching replays. To this, Alayan responded "Pause, rewind and speed change are
all things I would like to have as well. This won't be in 1.5 and maybe not in 2.0, but it's definitely on the roadmap."

I have built the engine side of this and in accordance with the "Communicating with the team" section of the
contributing code guidelines I am making a forum post about it.

I have implemented this by means of a ReplayControl class that owns the replay clock. It can pause (setPlaying), move 
the head of the playback to a desired time (seek) and change the rate of playback (setRate). The ability to move back and 
forth by individual frames naturally falls out of this; you would just seek by a frame-sized delta (or move to an adjacent time
via m_all_times, both can work). This functionality is currently enabled via a --replay-control flag and without it it is inert.
This doesn't change the normal race clock: everything outside of watch replay mode remains untouched.

I have deliberately NOT added the UI. I've built the mechanism, however as it stands there is no user interface that allows
the user to control it. This is on purpose and has been done for two main reasons.

   1. Building UI blind without knowing if it is wanted or how the structure should be set out puts my time and effort at risk of being wasted.

   2. Where the UI lives, how it looks, where the buttons are, etc. are design decisions that are not my call to make.

This feature has a dependency on the fix outlined in pull request #5837 - without it, seeking backwards would cause the ghost
to freeze in place, which is far from ideal.

The diff can be found here: https://github.com/schrowd/stk-code/compare/fix-ghost-controller-seekable...feature-replay-control

(Note to reviewer: the three "removed" lines in world_status.cpp are still there, they're just indented one level deeper and so
 GitHub shows them as red. None of the original behaviour has been changed or deleted. You can see that exact same code in
 lines 479-481.)

To wrap this up, I'd like to ask a few questions:

• Is this something you'd want in the main game?
  
• Should I build the UI or is that something you would be doing?
  
• Is driving the world clock the correct approach?
  
• Where should this live? It currently lives in src/replay: does it belong somewhere else?
  
• Whose job should it be to handle frame-stepping - ReplayControl's or the UI's?
  

Those are the main questions I'd like answers for however if you have any other questions or concerns I'd be happy to answer them.]]> https://forum.supertuxkart.net/thread-401.html Mon, 03 Aug 2026 22:39:14 +0000 nastynate664]]> https://forum.supertuxkart.net/thread-401.html https://forum.supertuxkart.net/thread-400.html Sun, 02 Aug 2026 16:53:03 +0000 Mish7913]]> https://forum.supertuxkart.net/thread-400.html

Few days ago, I learned that you can make several animation for assets, and game will choose randomly what to play in current race, you need just put markers on timeline "start" and "end" several times to separate animations, like this.



So ... that gives me an idea, what if add this method to the karts as well?
When you repeat same markers of animation, for example "winning animation", and when you will win the race - game will randomly choose one of winning animations, that can be also for "loosing" animation, for "hit", for "jump", etc ...

Like this:


So ... what do you think about this idea?

  2026-08-02 19-33-15.jpg (Size: 16.06 KB / Downloads: 100)

  2026-08-02 19-34-07.jpg (Size: 8.23 KB / Downloads: 96) ]]>

Few days ago, I learned that you can make several animation for assets, and game will choose randomly what to play in current race, you need just put markers on timeline "start" and "end" several times to separate animations, like this.



So ... that gives me an idea, what if add this method to the karts as well?
When you repeat same markers of animation, for example "winning animation", and when you will win the race - game will randomly choose one of winning animations, that can be also for "loosing" animation, for "hit", for "jump", etc ...

Like this:


So ... what do you think about this idea?

  2026-08-02 19-33-15.jpg (Size: 16.06 KB / Downloads: 100)

  2026-08-02 19-34-07.jpg (Size: 8.23 KB / Downloads: 96) ]]> https://forum.supertuxkart.net/thread-399.html Sun, 02 Aug 2026 13:35:20 +0000 Gusta]]> https://forum.supertuxkart.net/thread-399.html
Someone with experience with Vulkan coding can help me (and DON'T DARE TO USE LLM IN THIS, DAMN).

Things to finish:

 - Post processing (stk-code/src/graphics/post_processing.xpp)
 - Shadows 
 - Maybe new shaders? 
 - More things to see in video settings.

Maybe, I will create a repository to make easier the co-working.]]>
Someone with experience with Vulkan coding can help me (and DON'T DARE TO USE LLM IN THIS, DAMN).

Things to finish:

 - Post processing (stk-code/src/graphics/post_processing.xpp)
 - Shadows 
 - Maybe new shaders? 
 - More things to see in video settings.

Maybe, I will create a repository to make easier the co-working.]]> https://forum.supertuxkart.net/thread-398.html Sat, 01 Aug 2026 17:58:55 +0000 Stellar Horse]]> https://forum.supertuxkart.net/thread-398.html They are not fit to the sizes of the characters on the karts. When I drive along the tracks i always think - Why everything is so big here? All tracks are so beautifully made, but there is no feeling of awareness that these tracks are created for the characters. Right now it feels as if they are just some strangers who accidentally drove into a places that not belongs to them. 

And because everything is so big, I can't enjoy the beauty of the tracks on the fullest because everything is too high, so i have to drive back to get better look at some objects.

I just thought maybe you would consider this question and maybe adjust the sizes? 

In any case, i just sharing with you my thoughts  I love this game, it's very enjoyable to play ]]> They are not fit to the sizes of the characters on the karts. When I drive along the tracks i always think - Why everything is so big here? All tracks are so beautifully made, but there is no feeling of awareness that these tracks are created for the characters. Right now it feels as if they are just some strangers who accidentally drove into a places that not belongs to them. 

And because everything is so big, I can't enjoy the beauty of the tracks on the fullest because everything is too high, so i have to drive back to get better look at some objects.

I just thought maybe you would consider this question and maybe adjust the sizes? 

In any case, i just sharing with you my thoughts  I love this game, it's very enjoyable to play ]]>