Conversation

Notices

1. Embed this notice
   tromino (snug edition!) :nkopeek: (tromino@snug.moe)'s status on Thursday, 14-Sep-2023 05:41:01 JST tromino (snug edition!) :nkopeek:

   it uses over a third of a core lol, idk how to do fast software rendering

   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Thursday, 14-Sep-2023 05:41:00 JST :blobcathug:

     in reply to
     @tromino on nowday hardware i guess i would take shaders... on older hardware, i have no idea
   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Thursday, 14-Sep-2023 05:47:26 JST :blobcathug:

     in reply to
     @tromino well im not sure how the pipeline works correctly... but like shadertoy supports it so i guess it should be possible tho... and no, that way you wouldnt use the draw method to render stuff, you would use shaders to do it or in other words, you provide your gpu some code which then gets executed for every pixel on the screen running fully on the gpu in parallel all the way
     https://www.shadertoy.com/
   • Embed this notice
     tromino (snug edition!) :nkopeek: (tromino@snug.moe)'s status on Thursday, 14-Sep-2023 05:47:28 JST tromino (snug edition!) :nkopeek:

     in reply to

     • :blobcathug:

     @Jain@blob.cat or at least there wouldn't be as much benefit I think when the draw routine can only draw one row of pixels at a time

   • Embed this notice
     tromino (snug edition!) :nkopeek: (tromino@snug.moe)'s status on Thursday, 14-Sep-2023 05:47:29 JST tromino (snug edition!) :nkopeek:

     in reply to

     • :blobcathug:

     @Jain@blob.cat would be kinda hard to do rendering on the gpu when I want to be able to execute user code in the middle of drawing

   • Embed this notice
     tromino (snug edition!) :nkopeek: (tromino@snug.moe)'s status on Thursday, 14-Sep-2023 05:54:10 JST tromino (snug edition!) :nkopeek:

     in reply to

     • :blobcathug:

     @Jain@blob.cat I mean like, I have a row callback pointer that can be accessed from the library consumer side that lets you make arbitrary modifications to the ppu state every scanline, which take effect immediately when the next line is drawn

     :blobcathug: likes this.
   • Embed this notice
     tromino (snug edition!) :nkopeek: (tromino@snug.moe)'s status on Thursday, 14-Sep-2023 05:54:15 JST tromino (snug edition!) :nkopeek:

     in reply to

     • :blobcathug:

     @Jain@blob.cat so it's c code on the cpu that needs to be executed in between lines

     :blobcathug: likes this.
   • Embed this notice
     tromino (snug edition!) :nkopeek: (tromino@snug.moe)'s status on Thursday, 14-Sep-2023 05:56:31 JST tromino (snug edition!) :nkopeek:

     in reply to

     • :blobcathug:

     @Jain@blob.cat if I didn't have anything like that then I could probably do rendering using shaders fine, but I think scanline effects are fun and they're what make the cool distortion and gradient effects in that demo possible

     :blobcathug: likes this.
   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Thursday, 14-Sep-2023 06:09:38 JST :blobcathug:

     in reply to
     @tromino im pretty sure that this is not an issue for shaders... but (and there is a big but), shaders are build on math while moving pixels within c on a cpu is much much easier tho... (i bet any demoscener who used shaders would disagree :blobcatgooglynotlikethis:)