I'm currently working on a game engine, and I have the software side entirely done and it's sitting at 500 frames per second on loading a frame for the screen, but right now I don't know what I should use to load it onto the screen

I had tried direct3d and after I had implemented it everything is using a vertex/triangle group and I want to load everything as a 2d image (already rasterized) and I can't seem to find anything on direct3d that doesn't have to do with triangles...

I can't write to the screen fast enough without the GPU (to keep up with the loading time) and using triangles really makes me feel like I'm getting scammed with what I already have (in the end it's still just sending a coordinate and color to the screen (pixel))

I can't write to the screen fast enough without the GPU (to keep up with the loading time) and using triangles really makes me feel like I'm getting scammed on what I already have

Also does anyone know what I should use if I want to include a video player as well?

What?

lol, iow, we do not understand what you're asking.

Let me ask back: have you built a software renderer which produces images of +/-screen resolution and you have these images written to memory. Now you are looking for a way to present them on screen as fast as your renderer produces them.

Have i echoed that correctly ?

1 hour ago, Green_Baron said:

lol, iow, we do not understand what you're asking.

 

Let me ask back: have you built a software renderer which produces images of +/-screen resolution and you have these images written to memory. Now you are looking for a way to present them on screen as fast as your renderer produces them.

Have i echoed that correctly ?

Nice deduction, but wouldn't you assume somebody knows how to draw an image on screen before writing some kind of rasterizer? We'll see where this goes 

Sure, i would. That's why i didn't exhaust myself right away with a sermon about the graphics pipeline.

But i can imagine that someone built something on the CPU alone ignoring graphics apis. But this is just idle speculation as long as we don't know what's already there and what is wanted.

We'll see where it goes ? If it goes ...

16 hours ago, Green_Baron said:

lol, iow, we do not understand what you're asking.

 

Let me ask back: have you built a software renderer which produces images of +/-screen resolution and you have these images written to memory. Now you are looking for a way to present them on screen as fast as your renderer produces them.

Have i echoed that correctly ?

Sort of, I want full control over the pixels on the screen instead of doing some triangle or 3d shape on the screen and then doing a texture over it. (I have a much better method at doing depth) Yesterday I was going through a couple of things and the only thing I've found so far is someone loading a texture and keeping the z coordinate 0 

14 hours ago, Green_Baron said:

Sure, i would. That's why i didn't exhaust myself right away with a sermon about the graphics pipeline.

But i can imagine that someone built something on the CPU alone ignoring graphics apis. But this is just idle speculation as long as we don't know what's already there and what is wanted.

We'll see where it goes ? If it goes ...

 

I wouldn't mine anything you could give that would help, right now i'm pretty much at i'm going to have to do some sort of engine on my own and get into working with DLLs and some system language (after going through things like vulkan/direct3d/opengl)

Also I don't really need too much of the GPU processing that those provide, maybe a shader and a +- for depth (mainly) rendering is all I'd benefit from that besides the screen writing

Sounds awesome.

I doubt you can avoid to build a simple pipeline (like rendering your scene to a renderbuffer texture) and using a passthrough shader to present it to screen, projecting it to a quad (so 2 triangles may be the bullet you must bite). That'll only be a few lines of code in OpenGL or equivalent. Well, a few 10s of lines maybe ?

Maybe somebody else has a better answer for you ...

Edit: keep in mind that drawing usually occurs to one buffer (back buffer) while the other (front buffer) is being displayed. After drawing has finished (or a certain time has expired), buffers are swapped, and drawing commences on the front buffer that is now the back buffer (or vice versa). I'd happily accept a library that does this for me, on Windows, Linux, or whatever ...

31 minutes ago, Green_Baron said:

Sounds awesome.

I doubt you can avoid to build a simple pipeline (like rendering your scene to a renderbuffer texture) and using a passthrough shader to present it to screen, projecting it to a quad (so 2 triangles may be the bullet you must bite). That'll only be a few lines of code in OpenGL or equivalent. Well, a few 10s of lines maybe ?

Maybe somebody else has a better answer for you ...

Edit: keep in mind that drawing usually occurs to one buffer (back buffer) while the other (front buffer) is being displayed. After drawing has finished (or a certain time has expired), buffers are swapped, and drawing commences on the front buffer that is now the back buffer (or vice versa). I'd happily accept a library that does this for me, on Windows, Linux, or whatever ...

 

I had done some looking into how a monitor is displayed (what is sent to a monitor) and there's a scan line and a frame rate associated with that

I'm pretty efficient on what I need to display the graphics, positioning the screen takes 2 milliseconds, after that all I have to do is + or - a few things for depth or shade, one loop through

None of the graphic engines have anything direct, use geometrical shapes and it'll convert (rasterize) it to pixel coordinates. which I have mine already rasterized

Hi @tolazytbh, it's perfectly possible to do what you want (I think), there's nothing to preclude you from generating the GPU memory on the CPU and then copying it up to the GPU for display purposes. However, by doing so, you will be throwing away almost all of the capabilities of the GPU and probably backing yourself into a corner (hence why people above are recommending not doing so).

To simplify the 2D graphics, depending on what you're using, there will be a load of libraries which can simplify things. Personally, because we're using DX, I use the DirectX toolkit which provides things like 'spritebatch' and' spritefont' which simplify the writing of the game and then we can focus on the game play rather than boiler plate code.

Do you have any specific questions with which you need assistance?