1
Graphics / Re: Maybe found a bug on the r-pi, or doing something stupid
« on: August 30, 2023, 11:32:41 pm »
Thanks for the help
The thing is that I have two primary constraints.
1) The Pi has limited bandwidth on its internal memory bus, and the GPU shares the bus with the CPU, it doesn't have separate memory. I can't go copying HD-sized textures around so manually double-buffering doesn't sound workable due to the copying requirement. I can get one (1) of these copies per frame and still keep a 60fps frame rate, so that has to be the "update the display from the frame-buffer" pass.
2) I want to try and stick with the same paradigm that the GEM routines were designed for - ideally I'd like to link this up to an emulator later on, and having things work "like they should" will make it easier. GEM didn't double-buffer the screen, it just sent a list of dirty-rects to the application and expected drawing to happen in the primary frame-buffer.
I was drawn to SFML because it has a lot of the low-level graphic API calls with options already built in (eg: draw a rectangle, in a colour, with a fill and a specific line-thickness). It doesn't do dash-patterned lines, but I think I could probably do that in a shader - it may just be that this isn't a good match, and that's ok too, that's sort of what I'm trying to find out...
![Smiley :)](https://www.sfml-dev.org/forums/Smileys/default/smiley.gif)
1) The Pi has limited bandwidth on its internal memory bus, and the GPU shares the bus with the CPU, it doesn't have separate memory. I can't go copying HD-sized textures around so manually double-buffering doesn't sound workable due to the copying requirement. I can get one (1) of these copies per frame and still keep a 60fps frame rate, so that has to be the "update the display from the frame-buffer" pass.
2) I want to try and stick with the same paradigm that the GEM routines were designed for - ideally I'd like to link this up to an emulator later on, and having things work "like they should" will make it easier. GEM didn't double-buffer the screen, it just sent a list of dirty-rects to the application and expected drawing to happen in the primary frame-buffer.
I was drawn to SFML because it has a lot of the low-level graphic API calls with options already built in (eg: draw a rectangle, in a colour, with a fill and a specific line-thickness). It doesn't do dash-patterned lines, but I think I could probably do that in a shader - it may just be that this isn't a good match, and that's ok too, that's sort of what I'm trying to find out...