I'm planning to write a small software rendering engine (before anyone asks, it's kind of a learning/scientific experiment for me).
Before writing any code, I'm already stuck at the very first step: how to display my framebuffer on the screen? What I'm planning to do is to render into an in-memory buffer e.g. 320x200 24-bit RGB format. Then of course I need to display the results on the screen; full-screen or in a window.
I know that similar questions already exists here:
The difference is that I'd like to update the image frequently, with a decent framerate like 50FPS.
It seems one possibility would be OpenGL framebuffer objects and/or buffer streaming. I'm not sure I should go that way or is it an overkill for this use case?I've also considered displaying a simple rectangle with a texture I would update each frame, but I'm not sure about the performance (I guess transferring a few megabytes of data each frame shouldn't be a problem though).Several years earlier I've experimented with GDI+ and WPF, but the performance was nowhere near what I wanted to achieve. Unfortunately I don't have the source code any more, but I'd admit that my approach was maybe completely wrong back then.
I'm not expecting source code or a ready solution, but rather some directions: what functionality to use, I'd be happy to read articles or a tutorial about the topic.
I was considering OpenGL first, but I'm fine with DirectX too. Other suggestions are welcome. I'm planning to use C/C++ or C#, maybe Python for the implementation.
I'm sure there must be an easy solution, but I admit I'm a complete noob when it comes to graphics programming. I guess it's just about finding an effective way to copy data from RAM to GPU memory. I was wondering how retro emulators (e.g. Vice) or fantasy consoles (e.g. Pico-8) are solving this problem?
- $\begingroup$I would suggest using an OpenGL texture and using glTexImage2D to update the contents. Then you can render it as a single full screen quad. That would be straight forward enough to implement and performance should be good. If you don't already have it covered I would recommend SDL to get up an running quickly, that will take care of window setup for you.$\endgroup$PaulHK– PaulHK2020-06-18 04:59:09 +00:00CommentedJun 18, 2020 at 4:59
1 Answer1
Have you considered usingSDL 2?
My use-case is basically identical to yours, and I've found this approach to work really well. They have a really nice C (and C++) API for drawing framebuffers to a window. It's also platform-agnostic, so you can share your implementation fairly easily between macOS, Linux and Windows.If you want to see an example, you can go check outthis module here on GitHub. I do warn you though, while this implementationworks, and I can easily run it at 60-120FPS, it likely does use more CPU than a fully optimised implementation.Specifically observe theinitDisplay() anddrawWindow() functions.
- $\begingroup$Sorry for the late answer but I just could not find the time to try your suggestion.$\endgroup$LittlePilgrim– LittlePilgrim2020-07-02 00:07:50 +00:00CommentedJul 2, 2020 at 0:07
- $\begingroup$I've never used SDL2 before, but as @PaulHK has also pointed out it's very easy to put together a prototype. With streaming textures the results were quite good. I've tried both C++ and a C# wrapper and the difference is insignificant. I could to reach 1000fps at 640x400 by generating a simple pattern pixel by pixel. Creating a complex image is slower of course, but SDL and texture streaming won't be a bottleneck for sure. Your code helped me a lot, thanks! (BTW, awesome project!)$\endgroup$LittlePilgrim– LittlePilgrim2020-07-02 00:22:03 +00:00CommentedJul 2, 2020 at 0:22
Explore related questions
See similar questions with these tags.