I looked and didn't see a search button anywhere so if I missed it someone please point it out for me.

I was reading about the intent of this project and how it will be developed and was really interested in it. The biggest point for me was that no external graphics libraries will be loaded in to display game graphics. All that coding will be done in the project. In the past I have looked around a bit for books or other references to help me to learn more of how this is done, but I haven't had luck with any good resources. I do use a couple of lightweight 2d libraries for graphics display of what I like to play around with, but they always have shortcomings(not as many for myself) for people that use them. Generally when a programmer gets further along in ability these libraries fall short and lack facilities for advanced techniques and rendering so more powerful full game engines have to be used. I, however, would much prefer to have the know how to write just what I need, then, if necessary, add functionality as it becomes needed.

This is much more of a low level knowledge that is not as widely available as general knowledge so far as I can tell. I was wondering if the project lead for Handmadehero would have any references he could list somewhere on site that would give some of this lower level knowledge for graphics display.

I know the project is written primarily in C, but in a form so that it is compiled with a C++ compiler. With C++17 there is a posibility of a low level graphics being added to the standard library so this may become a moot point for C++ before long(not a fan of the idea myself), but still such knowledge would be nice to have.

Are you asking about software rendering? I can suggest Michael Abrash's Graphics Programming Black Book (here's it in single-page html format). It's a very old book, so a lot of code and optimizations there are irrelevant today. And it is a book more about optimization than graphics. But you can find some explanation about general graphics concepts - lines, polygons and triangles, etc..

For a bit modern optimizations you can find interesting information in Fabian Giesen (from RAD Tools) blog:
https://fgiesen.wordpress.com/201...iangle-rasterization-in-practice/
https://fgiesen.wordpress.com/201.../optimizing-the-basic-rasterizer/
https://fgiesen.wordpress.com/201...the-graphics-pipeline-2011-index/
Blog entries and comments include a lot of useful links.

But if you are asking about what API to use, then it depends on what API you want to use. 2D? GDI? Direct2D? Cairo? 3D? OpenGL? Direct3D?

Here's a nice tutorial about modern OpenGL: http://www.arcsynthesis.org/gltut/index.html Although it is unfinished.
Here is another one that looks ok: http://learnopengl.com/

Sorry I wasn't clear enough. I wasn't asking about which API to use as it was stated in the project design goals that no current library would be used. All display coding would be done in house. In essence a custom API would be developed for visual display of the game with CPU optimised routines being used at first to allow for more easily ported code for cross platform use. This is the kind of reference I am after.

Finding books or blogs/tutorials on using current library APIs is easy provided the library in question has been used in general enough to be talked about. I know OPENGL is available on all platforms and information on it is widely available, but project design goals stated that it would not be used. I am very interested in code that would operate on this low level for graphics display. I know it would be slower that required for use on release of any real project, but getting initial information on how it is done would lead to more information down the development line to improve it and move the work it does from the CPU to the GPU for optimal performance.

So what I am looking for is not any information on any current library or API used for graphics display, but information on building your own display routines without the aid of such API or libraries.

I will look into some of what was linked and see where that takes me, so thank you.

So you are asking about how OpenGL and Direct3D interacts with GPU and how to implement that part yourself?

That is a very complex process. Because almost each GPU has different architecture. And accessing GPU directly can not be done from user application. Only kernel drivers can do that (for stability and security purposes). So if you will want to do that, you'll need to write OS kernel driver, or your own OS :)

Anyway here are documentation made public by some GPU vendors. These docs are used, for example, to implement Linux open-source graphics drivers.
Intel - https://01.org/linuxgraphics/documentation
AMD - http://developer.amd.com/resource...eveloper-guides-manuals/#open_gpu
Broadcom VideoCore IV (used in Raspberry Pi) - https://github.com/hermanhermitage/videocoreiv (I'm guessing Casey will use this later in stream)
http://www.broadcom.com/docs/supp...videocore/VideoCoreIV-AG100-R.pdf

Not sure if there is anything public available from Nvidia.

I'm looking forward to reading the VideoCore documentation as I intend to work on a little OS for my Raspberry Pi. So happy that Broadcom released the doc last year. =D

mmozeiko
So you are asking about how OpenGL and Direct3D interacts with GPU and how to implement that part yourself?

Actually lower level than that. Not sure how I can be more clear, but even opengl and direct3d/directx build on something. Yes I know windows has graphics capabilities as part of it as it is the OS direct3d and directx are built for, but for cross platform there are methods that(from what I know) can work universaly with a bit of tweaking for the compilation process to add/remove certain aspects that differ from platform to platform.

Current states of direct3d and directx rely on the gpu for texture transforms and other intensive processes to free up cpu usage for things it does better. Reading the reference as to what this project will be doing it specificly stated that cpu rendering will be hand coded first to just get things working and testable. Later, those graphics routines will be redone and optimized using GPU processing instead of CPU processing for speed and performance across platforms. My interest is in the low level CPU usage to get a graphics display independant of platform. I have yet to have time to look at the links you provided, but I am sure that those will have some reference in them.

I do know that any OS in general provides uniform inteactivity through API layers to hardware so that software running on the OS doesn't interfere with it, but instead safely coexists. In order for say Apple or Microsoft to get dedicated GPU binary libraries from hardware manufacturers they have to shell out a lot of money. Linux simply doesn't do that. Instead they use some primitive level communication, investigate it and optimize it as best they can surmise since they don't pay manufacturers for spec specifics.

This is all fine. I'm just trying to get to the very basics. Just as an example, SLD is now on version 2. SDL2 uses GPU acceleration to display graphics and it coexists with the opengl api. Before SDL2 was SDL1.2 which used the CPU for all rendering, although it did coexist with opengl in that iteration as well. I suppose I could go bug the SDL forums to death on this subject, but since what I am asking about(and doing a poor job it seems) is mentioned in the mission statement of this project, I was hoping to get more information here more easily.

Spirro
My interest is in the low level CPU usage to get a graphics display independant of platform.

In such case you typically don't go lower than OpenGL and Direct3D. Because every platform has different driver model for interacting with GPU. You won't be able to write kernel driver for every single OS, and even if you can, then nobody will be able to use because that will require admin rights to play your game.

In order for say Apple or Microsoft to get dedicated GPU binary libraries from hardware manufacturers they have to shell out a lot of money.

That's not very accurate. Microsoft depends on GPU vendors to write drivers. They don't write drivers themselves for modern GPU's for a long time already. They simply let Intel, AMD and Nvidia do that.

Linux simply doesn't do that. Instead they use some primitive level communication, investigate it and optimize it as best they can surmise since they don't pay manufacturers for spec specifics.

Also not true. AMD and Nvidia write and provide binary drivers themselves for Linux. There's no need to pay anybody. But there exists projects that reimplement them as open-source based on specs available - and no need to pay for them, those links I posted above include all information needed to implement such drivers.

SDL2 simply uses OpenGL for GPU acceleration (or D3D, and people are porting it to different platforms like Metal). If you use OpenGL yourself there is nothing else you'll gain from SDL2 GPU accelearation.

Sorry for turning this into a bit of a semantics battle, but..

mmozeiko
Because every platform has different driver model for interacting with GPU. You won't be able to write kernel driver for every single OS, and even if you can, then nobody will be able to use because that will require admin rights to play your game.

I completely agree to this point.

Microsoft depends on GPU vendors to write drivers. They don't write drivers themselves for modern GPU's for a long time already. They simply let Intel, AMD and Nvidia do that.

My mistake in oversimplifying my arguement here. Yes I know the GPU manufacturers provide drivers, but money does change hands to ensure that said drivers are optimized to support APIs on Microsofts end(directx) and will moreso in the future for Apple as they are going to abandon OpenGL soon in favor of an in house API.

Also not true. AMD and Nvidia write and provide binary drivers themselves for Linux.

Here I agree and disagree. AMD and Nvidia DO provide Linux drivers...to a point. GPU drivers are a big sore spot for Linux distribution creators and maintainers, but that's another issue I won't open.

There's no need to pay anybody. But there exists projects that reimplement them as open-source based on specs available - and no need to pay for them, those links I posted above include all information needed to implement such drivers.

And for these I thank you. I've barely been able to review them, but am looking forward to them.

SDL2 simply uses OpenGL for GPU acceleration (or D3D, and people are porting it to different platforms like Metal). If you use OpenGL yourself there is nothing else you'll gain from SDL2 GPU accelearation.

SDL I used as an example and merely pointed out the difference in optimisation between 1.2 and 2.0 to try and help put my point across. Basicly that at some point more primitive methods were used(bad example I guess?)

At any rate, thank you for the links you provided above. I will need a good deal of time to look them over and see what I can gather from them.

I think money (directly or indirectly) more exchanges hands of AMD/Nvidia and big game development studios rather than MS. MS really doesn't have competition in AAA game market (if you look at PC games, not console ones). Because GPU vendors and game developers want to sell more their stuff than competitors, GPU vendors sell professional services to go to game companies to optimize their game for their product (and that's why you get "The Way it's meant to be played Nvidia" loading screens). And also they optimize drivers specifically for latest/greatest game. 10 or so years ago it was well known fact that Doom3 which uses OpenGL run very well only because GPU vendors optimized GL drivers for specific sequence/path of GL calls of Doom3. If you wanted to do something else, you could easily hit software fallback path. That's why GPU vendors writing drivers is a bad thing in my opinion (nobody can control what shenanigans they are doing in closed source). Linux open-source drivers is the way it should be.

Here I agree and disagree. AMD and Nvidia DO provide Linux drivers...to a point. GPU drivers are a big sore spot for Linux distribution creators and maintainers, but that's another issue I won't open.

Well, yeah. But packaging doesn't matter here. Whoever wrote drivers (AMD/NVidia) has the most knowledge about how to write or optimize them, so they don't need to pay or communicate with anybody.

Really, supporting GL or D3D and writing OS driver requires very little information from MS or Apple. Most of knowledge and skills are required how to effectively support GPU architecture.

SDL2 still includes software renderer in latest source. You can easily examine it, but it is CPU based: http://hg.libsdl.org/SDL/file/e29fec41a2c6/src/render/software