6 ms·

Maybe this site is the best place to ask. There are two major things we could use help with: - the games do not run particularly well on the raspberry pi (any

by aap_ 6y ago

Maybe this site is the best place to ask. There are two major things we could use help with: - the games do not run particularly well on the raspberry pi (any version really) and I have a feeling it's at least partially due to the OpenGL layer. We could really use someone with how to optimize OpenGL (especially on the pi). - physics have always been wonky beyond 30fps. I think someone with a good knowledge of game physics could really help us here.

sokoloff 6y ago
I did some of the physics work (but was not the lead) for Papyrus racing games in the ‘95-‘97 era. Email’s in my profile if I can help. My recollection of Vice City is that the vehicle dynamics model is not particularly realistic but optimized for “fun gameplay with a hint of realism” whereas Papyrus optimized towards “realistic gameplay with a hint of fun”. :D Our physics engine was deeply, deeply tied to a particular isochronous rate (30 Hz, then later 60Hz, IIRC) with all kinds of hackery to make that happen and divorce rendering rate from physics rate. (On the PSX, we ran physics engine tied to the VBlank.)
- aap_ 6y ago
  Yeah, i think so too. In Vice City the most surprising thing to me was that they actually modelled tire temperature. it's probably a bit crude but i found it interesting. As for the physics code, there's a big ProcessControl function all sorts of physical entities that does everything that has to happen to that entity each frame. some of it is physics, some not. My theory as to why varying timestep produces different results is that the physics calculations form some sort of differential equations whose solution depends on the timestep. That may be wrong but it makes sense to me at least. My approach to fixing it would be to log all sorts of forces applied to the physical objects each frame and log them so they can be compared. this is quite a bit of stuff to implement though so nobody has done it yet. if you or somebody is interested in that, we'd appreciate that a lot.
- rzzzt 6y ago
  The physics engine of Vice City is definitely tied to the frame rate. If you switch off vsync, you can only drive in reverse veeery slowly.
  - aap_ 6y ago
    That one i was actually able to fix :)
- mypalmike 6y ago
  Ha, back in that same era I was working at a small game company that was in discussions with Papyrus about doing some work on the Indy Car Racing game - probably a Playstation port. It never happened - I think it was determined that it wouldn't sell enough to cover the development costs. I don't remember much else except we played the PC game ("research") and it was super difficult - you needed a lot of skill not to crash at every curve. I also seem to recall that the polygon models for the cars were based on manually edited text files. Good times.
rwmj 6y ago
> physics have always been wonky beyond 30fps I suppose this is because the original developers knew exactly what hardware this would run on and the achievable framerate on the PS2 and so took lots of short-cuts in the code? Edit: Incredible project by the way.
- aap_ 6y ago
  They actually did try to make it work at all frame rates but I don't think they were actually able to test it very well because the hardware, as you said, didn't do it.
- peruvian 6y ago
  A lot of games were hardcoded for a specific FPS. Even modern-ish ones!
  - ricardobayes 6y ago
    Our local computer graphics prof hated this and set the loop rate random for the opengl idle function on our submission server. At one point it hang for 5 minutes between frames.
    - lostgame 6y ago
      Brilliant move, must have been one hell of a smart guy. I hate to say it, but fixed frame rates these days seem very 'lazy'? Obviously depending on use case and hardware.
      - dagmx 6y ago
        I wouldn't call it lazy. All development is compromise. Especially game development. If you know the game is only going to run on certain hardware, and you make the most money during the launch period of the game, it doesn't make sense to spend time, effort and money on something niche for the future.
      - Macha 6y ago
phire 6y ago
It's a bit of an underpowered GPU, but I would have thought it would be powerful enough to run an early PS2 era game like this. It might just be really unhappy with the number of draw calls that you are doing. Looks like you are currently doing a drawcall per mesh; You might need to pack multiple meshes into a single drawcall. Do you have any idea how many drawcalls per frame you are currently doing?
- aap_ 6y ago
  Using renderdoc with normal opengl i count 660 draw calls on a hopefully representative frame. Multiple meshes per drawcall are hard due to the architecture of renderware. I have considered sharing vertex and index buffers though. Do you think that will make a big difference?
  - phire 6y ago
    I suspect that sharing vertex/index buffers won't really help (alone). Last time I profiled something graphically intensive on the pi 4, I found that touching any of the draw state or uniforms between draw calls would trigger an expensive re-validation on the whole pipeline. 50% of my cpu time was spent in the driver. Of course, the app I was profiling was pushing quite a lot of uniforms per draw call. Your workload might be different, so profile before doing anything drastic. I recommend building a version of mesa with symbols so you can see exactly where CPU time is spent. BTW, try prepending `mesa_glthread=true` to your command to see if that gives you a free speed boost.
    - aap_ 6y ago
      hm, state changes between draw calls are hard to get rid of...after all that's why they're separate calls in the first place. profiling the driver is probably indeed something i should look into.
      - garaetjjte 6y ago
        You should be able to batch CPU-side drawcalls by packing multiple meshes into bigger vertex buffer, then generating draw parameters for every object into SSBO/UBO, and then utilizing ARB_multi_draw_indirect to draw everything at once. To change textures inside these batched drawcalls you might need ARB_bindless_texture. This talk is helpful: https://www.gdcvault.com/play/1020791/Approaching-Zero-Driver-Overhead-in https://www.gdcvault.com/play/1020791/Approaching-Zero-Drive... I don't know if these extensions are available on Pi driver, though.
Const-me 6y ago
> We could really use someone with how to optimize OpenGL (especially on the pi). Not sure that gonna help much. I think what you should do instead, port your OpenGL code to OpenGL ES. Specifically, Raspberry Pi 1-3 support GLES 2.0, Pi 4 supports GLES 3.1. As a nice side effect, renderer will become portable to smartphones. This may or may not be a lot of work, depending how exactly you use OpenGL. Pi 4 introduced Vulkan as well, but unlike GLES I have not tested it and not sure how good is the support.
- aap_ 6y ago
  I have in fact tested everything with GLES 2.0, 3.1, and desktop GL 2.1 and 3.3 and they should all work. If it's as efficient as it could be is another question. I find OpenGL rather messy as an API compared to d3d9.
  - Const-me 6y ago
    I don’t have GTA3 but I do have VC on Steam. Compiled 32-bit Windows build of VC with GL2. Here’s a renderdoc capture from my PC: http://const.me/tmp/vc-win10-gl.zip http://const.me/tmp/vc-win10-gl.zip 1. On the main rendering pass, your code renders stuff mostly back to front. Consider sorting opaque objects by Z and render then front to back. If you do that, early Z rejection gonna save tons of pixel shaders and fill rate. The sorting doesn’t need to be perfect, an approximate will do as well, but with these ~5k draw calls I’m pretty sure even C qsort gonna be adequate on Pi4. Translucent objects need to be rendered back to front like you’re currently doing. 2. In your pixel shader you often have this code: if( a < u_alphaRef.x || a >= u_alphaRef.y ) discard; Where u_alphaRef is [ -1000; +1000 ] i.e. very large interval. Don’t do that. Write another pixel shader for cases when you don’t need alpha tests. GPUs disable some optimizations (early Z rejection is one of them) when you calling discard in GLSL/HLSL. 3. Up to EID 5328, the game rendered the next frame. Starting from EID 5377, the game was finishing rendering of the previous one. That’s a good idea by itself, the problem with that, the temporary texture has size 4096*4096 pixels. Only top-center 3840*2160 portion was actually used. My desktop PC is fast enough to deliver 60 FPS, but on RPi you should not use textures much larger than necessary. All modern GPUs support non-power-of-2 textures, Pi4 included. 4. You are using 2x MSAA for the main pass. At least for my test cases on Pi4 (see e.g. this project https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac ), even 2x MSAA ruined performance, if you use the same setting on Pi4, I think that contributed the most to the performance issue. Try to disable MSAA and see what gonna happen. If you’ll find out it helps with the performance but the quality is too bad now, try to implement a cheaper substitute somehow, search the web for FXAA and SMAA keywords.
zamalek 6y ago
Time corrected vertlet integration[1] is really approachable and I'd strongly recommend trying it out. [1]: https://www.gamedev.net/articles/programming/math-and-physics/a-simple-time-corrected-verlet-integration-method-r2200/ https://www.gamedev.net/articles/programming/math-and-physic... Edit: http://archive.gamedev.net/archive/reference/articles/article2200.html http://archive.gamedev.net/archive/reference/articles/articl...
zennit 6y ago
Could box86 help here? https://github.com/ptitSeb/box86 https://github.com/ptitSeb/box86
- terramex 6y ago
  No, according to README.md re3 works natively on arm64.

by aap_ 6y ago

sokoloff 6y ago

I did some of the physics work (but was not the lead) for Papyrus racing games in the ‘95-‘97 era. Email’s in my profile if I can help. My recollection of Vice City is that the vehicle dynamics model is not particularly realistic but optimized for “fun gameplay with a hint of realism” whereas Papyrus optimized towards “realistic gameplay with a hint of fun”. :D Our physics engine was deeply, deeply tied to a particular isochronous rate (30 Hz, then later 60Hz, IIRC) with all kinds of hackery to make that happen and divorce rendering rate from physics rate. (On the PSX, we ran physics engine tied to the VBlank.)

aap_ 6y ago
Yeah, i think so too. In Vice City the most surprising thing to me was that they actually modelled tire temperature. it's probably a bit crude but i found it interesting. As for the physics code, there's a big ProcessControl function all sorts of physical entities that does everything that has to happen to that entity each frame. some of it is physics, some not. My theory as to why varying timestep produces different results is that the physics calculations form some sort of differential equations whose solution depends on the timestep. That may be wrong but it makes sense to me at least. My approach to fixing it would be to log all sorts of forces applied to the physical objects each frame and log them so they can be compared. this is quite a bit of stuff to implement though so nobody has done it yet. if you or somebody is interested in that, we'd appreciate that a lot.
rzzzt 6y ago
The physics engine of Vice City is definitely tied to the frame rate. If you switch off vsync, you can only drive in reverse veeery slowly.
- aap_ 6y ago
  That one i was actually able to fix :)
mypalmike 6y ago
Ha, back in that same era I was working at a small game company that was in discussions with Papyrus about doing some work on the Indy Car Racing game - probably a Playstation port. It never happened - I think it was determined that it wouldn't sell enough to cover the development costs. I don't remember much else except we played the PC game ("research") and it was super difficult - you needed a lot of skill not to crash at every curve. I also seem to recall that the polygon models for the cars were based on manually edited text files. Good times.

rwmj 6y ago

> physics have always been wonky beyond 30fps I suppose this is because the original developers knew exactly what hardware this would run on and the achievable framerate on the PS2 and so took lots of short-cuts in the code? Edit: Incredible project by the way.

aap_ 6y ago
They actually did try to make it work at all frame rates but I don't think they were actually able to test it very well because the hardware, as you said, didn't do it.
peruvian 6y ago
A lot of games were hardcoded for a specific FPS. Even modern-ish ones!
- ricardobayes 6y ago
  Our local computer graphics prof hated this and set the loop rate random for the opengl idle function on our submission server. At one point it hang for 5 minutes between frames.
  - lostgame 6y ago
    Brilliant move, must have been one hell of a smart guy. I hate to say it, but fixed frame rates these days seem very 'lazy'? Obviously depending on use case and hardware.
    - dagmx 6y ago
      I wouldn't call it lazy. All development is compromise. Especially game development. If you know the game is only going to run on certain hardware, and you make the most money during the launch period of the game, it doesn't make sense to spend time, effort and money on something niche for the future.
    - Macha 6y ago

phire 6y ago

It's a bit of an underpowered GPU, but I would have thought it would be powerful enough to run an early PS2 era game like this. It might just be really unhappy with the number of draw calls that you are doing. Looks like you are currently doing a drawcall per mesh; You might need to pack multiple meshes into a single drawcall. Do you have any idea how many drawcalls per frame you are currently doing?

aap_ 6y ago
Using renderdoc with normal opengl i count 660 draw calls on a hopefully representative frame. Multiple meshes per drawcall are hard due to the architecture of renderware. I have considered sharing vertex and index buffers though. Do you think that will make a big difference?
- phire 6y ago
  I suspect that sharing vertex/index buffers won't really help (alone). Last time I profiled something graphically intensive on the pi 4, I found that touching any of the draw state or uniforms between draw calls would trigger an expensive re-validation on the whole pipeline. 50% of my cpu time was spent in the driver. Of course, the app I was profiling was pushing quite a lot of uniforms per draw call. Your workload might be different, so profile before doing anything drastic. I recommend building a version of mesa with symbols so you can see exactly where CPU time is spent. BTW, try prepending `mesa_glthread=true` to your command to see if that gives you a free speed boost.
  - aap_ 6y ago
    hm, state changes between draw calls are hard to get rid of...after all that's why they're separate calls in the first place. profiling the driver is probably indeed something i should look into.
    - garaetjjte 6y ago
      You should be able to batch CPU-side drawcalls by packing multiple meshes into bigger vertex buffer, then generating draw parameters for every object into SSBO/UBO, and then utilizing ARB_multi_draw_indirect to draw everything at once. To change textures inside these batched drawcalls you might need ARB_bindless_texture. This talk is helpful: https://www.gdcvault.com/play/1020791/Approaching-Zero-Driver-Overhead-in https://www.gdcvault.com/play/1020791/Approaching-Zero-Drive... I don't know if these extensions are available on Pi driver, though.

Const-me 6y ago

> We could really use someone with how to optimize OpenGL (especially on the pi). Not sure that gonna help much. I think what you should do instead, port your OpenGL code to OpenGL ES. Specifically, Raspberry Pi 1-3 support GLES 2.0, Pi 4 supports GLES 3.1. As a nice side effect, renderer will become portable to smartphones. This may or may not be a lot of work, depending how exactly you use OpenGL. Pi 4 introduced Vulkan as well, but unlike GLES I have not tested it and not sure how good is the support.

aap_ 6y ago
I have in fact tested everything with GLES 2.0, 3.1, and desktop GL 2.1 and 3.3 and they should all work. If it's as efficient as it could be is another question. I find OpenGL rather messy as an API compared to d3d9.
- Const-me 6y ago
  I don’t have GTA3 but I do have VC on Steam. Compiled 32-bit Windows build of VC with GL2. Here’s a renderdoc capture from my PC: http://const.me/tmp/vc-win10-gl.zip http://const.me/tmp/vc-win10-gl.zip 1. On the main rendering pass, your code renders stuff mostly back to front. Consider sorting opaque objects by Z and render then front to back. If you do that, early Z rejection gonna save tons of pixel shaders and fill rate. The sorting doesn’t need to be perfect, an approximate will do as well, but with these ~5k draw calls I’m pretty sure even C qsort gonna be adequate on Pi4. Translucent objects need to be rendered back to front like you’re currently doing. 2. In your pixel shader you often have this code: if( a < u_alphaRef.x || a >= u_alphaRef.y ) discard; Where u_alphaRef is [ -1000; +1000 ] i.e. very large interval. Don’t do that. Write another pixel shader for cases when you don’t need alpha tests. GPUs disable some optimizations (early Z rejection is one of them) when you calling discard in GLSL/HLSL. 3. Up to EID 5328, the game rendered the next frame. Starting from EID 5377, the game was finishing rendering of the previous one. That’s a good idea by itself, the problem with that, the temporary texture has size 4096*4096 pixels. Only top-center 3840*2160 portion was actually used. My desktop PC is fast enough to deliver 60 FPS, but on RPi you should not use textures much larger than necessary. All modern GPUs support non-power-of-2 textures, Pi4 included. 4. You are using 2x MSAA for the main pass. At least for my test cases on Pi4 (see e.g. this project https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac ), even 2x MSAA ruined performance, if you use the same setting on Pi4, I think that contributed the most to the performance issue. Try to disable MSAA and see what gonna happen. If you’ll find out it helps with the performance but the quality is too bad now, try to implement a cheaper substitute somehow, search the web for FXAA and SMAA keywords.

zamalek 6y ago

Time corrected vertlet integration[1] is really approachable and I'd strongly recommend trying it out. [1]: https://www.gamedev.net/articles/programming/math-and-physics/a-simple-time-corrected-verlet-integration-method-r2200/ https://www.gamedev.net/articles/programming/math-and-physic... Edit: http://archive.gamedev.net/archive/reference/articles/article2200.html http://archive.gamedev.net/archive/reference/articles/articl...

zennit 6y ago

Could box86 help here? https://github.com/ptitSeb/box86 https://github.com/ptitSeb/box86

terramex 6y ago
No, according to README.md re3 works natively on arm64.