nuQuake - Hardware Accelerated Modern Quake

Discussion in 'Sega Dreamcast Development and Research' started by Mrneo240, Mar 8, 2019.

  1. Mrneo240

    Mrneo240 Gutsy Member

    Joined:
    Sep 15, 2017
    Messages:
    482
    Likes Received:
    585
    thanks for being about the second person to pull the code and compile it.
     
    Anthony817 and -=FamilyGuy=- like this.
  2. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,061
    Likes Received:
    941
    Alright, so I've looked into the code a little bit I don't understand much so far; it'll take a little fiddling to get used to it.

    I have a question though. Since you use vanilla quake files, doesn't the renderer has to convert textures when loading or waste ram? Wouldn't it be better to convert the textures to .PVR format? Or is it negligible performance-wise?
     
    Last edited: Apr 8, 2019
  3. Mrneo240

    Mrneo240 Gutsy Member

    Joined:
    Sep 15, 2017
    Messages:
    482
    Likes Received:
    585
    A lot of care was taken to load textures into best format possible, EVERYTHING is paletted 8bpp. Very little memory is needed for textures.
     
    Anthony817 likes this.
  4. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,061
    Likes Received:
    941
    But does the conversion from *whatever format quake uses inside of wads* to native PVR affects performance?

    I guess my question should be: Would preprocessing the textures into .PVR files save a few FPS? Or is it all loaded in memory when loading levels, so it doesn't matter?
     
    Anthony817 likes this.
  5. Anthony817

    Anthony817 Familiar Face

    Joined:
    May 12, 2010
    Messages:
    1,104
    Likes Received:
    581
    Super happy to see FamilyGuy is helping out! This is why I love this community!

    2 Canadian masterminds getting stuff done! (At least I assume MrNeo240 is also Canadian from that Manitoba thing he had in one of his videos)
     
  6. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,061
    Likes Received:
    941
    I'm not helping out yet. It just took an interesting project to finally convince me to setup kos and fiddle with DC programming!
     
    bulletbob and jollyroger like this.
  7. jollyroger

    jollyroger Gutsy Member

    Joined:
    Oct 18, 2008
    Messages:
    458
    Likes Received:
    256
    That may make us three Canadians to look into this then? ;-)
     
    LuizNai, -=FamilyGuy=- and Mrneo240 like this.
  8. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,061
    Likes Received:
    941
  9. Mrneo240

    Mrneo240 Gutsy Member

    Joined:
    Sep 15, 2017
    Messages:
    482
    Likes Received:
    585
    fuck fabien.
     
  10. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,061
    Likes Received:
    941
    May I inquire as to why you feel that strongly about someone on the internet?
     
    Last edited: Apr 9, 2019
  11. Mrneo240

    Mrneo240 Gutsy Member

    Joined:
    Sep 15, 2017
    Messages:
    482
    Likes Received:
    585
    I can't support people who knowingly and intentionally spread false and incorrect information
     
  12. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,061
    Likes Received:
    941
    Like?
     
  13. jollyroger

    jollyroger Gutsy Member

    Joined:
    Oct 18, 2008
    Messages:
    458
    Likes Received:
    256
    Popcorn out ;-)
     
    Mrneo240 likes this.
  14. TapamN

    TapamN Active Member

    Joined:
    Sep 16, 2005
    Messages:
    30
    Likes Received:
    13
    That fixed it.

    There's still areas with single digit FPS. Hmm.

    The frame rate issues are probably caused by CPU load. If the PVR is still the bottleneck, I suspect something is way off regarding what's being fed to the PVR, like everything is being submitted as transparent or punch through or something.

    Is there some way to get the PVR's render time? Like a console command that does:
    Code:
    pvr_stats_t stats;
    pvr_get_stats(&stats);
    con_printf("Render time: %i ms\n", stats.rnd_last_time);
    If the render time is huge, then there's probably way off with how OpenGL is submitting things to the PVR. if it's not, then the problem is definitely CPU load.

    Actually, the Neon 250 card (the PC version of the DC GPU, which is, according to a ImgTec employee, slightly weaker than the Dreamcast's despite a higher clock speed) can reach above 60 FPS on Quake, so 60 FPS should be possible on the PVR's side.

    Also, the punch through polygons aren't rendering correctly on real hardware. The clouds are missing their parallax layer, and the explosion sprites have transparent boxes around them. Probably a GL bug. For punch through to work correctly, the driver must set the blend mode of punch through polygons to the equivalent of glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). I've included screenshots.
     

    Attached Files:

    Anthony817 likes this.
  15. Mrneo240

    Mrneo240 Gutsy Member

    Joined:
    Sep 15, 2017
    Messages:
    482
    Likes Received:
    585
    Check gitlab, run build with no rendering . What fps
     
  16. Mrneo240

    Mrneo240 Gutsy Member

    Joined:
    Sep 15, 2017
    Messages:
    482
    Likes Received:
    585
    Correct .Every single polygon is sent as translucent
     
  17. TapamN

    TapamN Active Member

    Joined:
    Sep 16, 2005
    Messages:
    30
    Likes Received:
    13
    I'd say about 45 FPS average. I saw 38-48.
    Oh. That's... uh... not how the PVR is designed to be used.

    One of the advantages of the PVR is it's efficient handling for opaque polygons to render them with no overdraw. When you render the screen without opaque polygons, not only is fillrate wasted on hidden surfaces, the PVR will also waste its time to slowly clear its internal color/depth buffers at a rate of one pixel per clock. It doesn't have fast color/depth buffer clearing since they normally get cleared for free during regular drawing of opaque polygons. There's basically an invisible extra fullscreen quad eating fillrate.

    More than saving fillrate, if a polygon ends up completely obsured by opaque pixels, PVR seems to only do partial triangle setup on it, so it also increases the potential polygon count of the PVR.
     
  18. kazade

    kazade Spirited Member

    Joined:
    Jul 22, 2015
    Messages:
    155
    Likes Received:
    164
    Just to clarify, we're aware of how the OP, PT, and TR lists are supposed to be used and also aware of the slowness of using the TR list. I'm assuming that mrneo has had to send stuff as blended to get the correct output?

    GLdc selects which list to use based roughly on the following logic:

    - Send everything to OP, unless...
    - It's alpha tested, in which case sent it to PT, unless...
    - Blending is enabled, then send it to TR

    Multitextured polys (so lightmaps) have to have the second texture go through TR.

    Any ideas on how to make blended polys faster?

    GLdc certainly has unoptimised codepaths, I'd be interested to know which ones these slow areas are going down.

    If you wanna chat more about this stuff, we're all on the Simulant engine discord: https://discord.gg/TRx94EV
     
  19. Mrneo240

    Mrneo240 Gutsy Member

    Joined:
    Sep 15, 2017
    Messages:
    482
    Likes Received:
    585
    Fortunately that is exactly how quake is written. Now you can finally see the problem I'm having .

    I'm glad you see the issue
     
    Anthony817 and bulletbob like this.
  20. jollyroger

    jollyroger Gutsy Member

    Joined:
    Oct 18, 2008
    Messages:
    458
    Likes Received:
    256
    The original Quake engine would pre-combine base textures and lightmaps and store them in a texture cache, which then could be displayed in a single pass. Given that hardware that supports multi-texture or extremely fast blending don't need this, GLQuake reverted to drawing multiple passes, which is generally faster.
    The tradeoff is CPU time spent software rendering textures into a cache vs. multiple identical rendering passes, one with the OP list and one the TR list. At least this is the most straightforward way... and that is what glDc does.
     

Share This Page