0
$\begingroup$

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?

Improve this question
$\endgroup$
1
  • $\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
    Jun 18, 2020 at 4:59

1 Answer 1

Reset to default
0
$\begingroup$

Have you considered using SDL 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 out this module here on GitHub. I do warn you though, while this implementation works, and I can easily run it at 60-120FPS, it likely does use more CPU than a fully optimised implementation. Specifically observe the initDisplay() and drawWindow() functions.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Sorry for the late answer but I just could not find the time to try your suggestion. $\endgroup$
    – LittlePilgrim
    Jul 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
    Jul 2, 2020 at 0:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.