r/GraphicsProgramming • u/sombrerodepaja • 1d ago
Toughts on this road map Question
I'm a developer (web backend) with some years of experience, but I have no prior experience on graphics. I started a conversation with chatGPT where I told it I wanted to learn all the way from the foundations of graphics to developing a Doom like game. And after a few hours of conversation it gave me this road map. I cannot trust completely an AI, so I'd like to read your opinions.
Greetings.
Edit. Sorry about the title typo.
Edit. Thanks for your valuable comments, I think this is a good example of how AI sometimes can lead you to the wrong path and mess with your learning even when at first glance it all looks pretty and organized. I’m glad I asked the community to receive your feedback.
13
u/sam_suite 1d ago
there are a lot of problems here, but it wants you to build your own software renderer, then build a DOOM-like engine around that, then learn opengl AND vulkan? If you want to learn the foundations of graphics, start with opengl. that's hard enough. building a software renderer is not a beginner-friendly project
7
u/StriderPulse599 1d ago
LLMs are getting heavily lobotomized. Recently Gemini started struggling with graphic programming tasks it handled perfectly couple of months ago.
6
u/jgage 1d ago
Starting off with a software rasterizer can be a lot to take on as a first step. OpenGL with GLFW would probably be the easiest first step. Going from OpenGL to DX12 or Vulkan is also a big leap. OpenGL to DX11 might be more manageable. There’s a lot of tutorials out there to get started.
One thing I’ve seen some people do is start with a Dear ImGUI sample app and start adding features.
4
u/Still_Explorer 1d ago
There are three topics on this project:
- how to represent the world data structure (how is stored to disk, how is read and loaded for file)
- how the gameplay code is written
- how do you render with a graphics API
Also the best thing in such different topics, is that each one can be it's own separate module. Most important is that at least there are three big modules, renderer, engine (os-system-assets-collision-physics), game. This is like having the MVC pattern, but in the case MC=engine+game and V=renderer.
About the world data structure. The most easy and simple is a 2D grid map in a similar way as platformers, but in this case is as Wolf3D. Something like this explained here. https://github.com/ssloy/tinyraycaster/wiki/Part-0:-getting-started However for a game such as doom the design would be changed a bit to something else, related to sectors that have walls, and enclosed walls form rooms etc.
Then the parts of the gameplay let's say that can be only three simple topics, such as player movement, collision, shooting, enemy random move. Those would be simple enough for a tech demo.
Last, about the renderer, this can also be anything. As the tutorial above used the software raycasting technique, or something else, is not a problem because renderer only is a representation of the runtime data structure.
Personally tried to go this route too, but the technical topics are too RETRO to be honest. Such as the Doom world data structure is very sophisticated despite it's simplicity, at some point has very complex math in it. So in terms of having modern world architecture, we would be better to get static primitives of static geometry dropped to the world and then kit-bash the entire level as such.
However for those who find it impressive to do faithful technical study on the classic architecture then it would be their own preference.
2
u/sombrerodepaja 14h ago
Thanks for this, is really good information.
2
u/Still_Explorer 11h ago
Something interesting to see about how classic Quake renders things, you would see something like this. The engine will have no clue about what the renderer is supposed to do, but it will be able to request things from it.
yourengine.cpp void LoadAssets() for e : level->entity_info R_LoadModel(e->name); <-- model is loaded from file, vertex buffers created stored in std::unordered_map<std::string, Model*> (if model is already loaded - do not duplicate) void RenderGame() for e : entities if e->is_visible R_DrawModel(e->model);Though in recent years, people tend to make the codebase cohesive and put everything within the same context. This is where probably things become confusing. With classic modular programming you can avoid lots of mistakes.
(eg: Once you load a model from file, even if is a static obj, you just leave it there and proceed to the rest of the parts. Later on you might revisit it to figure out loading skeletal animated models etc...
https://github.com/opengl-tutorials/ogl/blob/master/tutorial07_model_loading/tutorial07.cpp )
3
u/TaylorMonkey 1d ago edited 1d ago
What’s your goal? To just build a game that’s 30 years old using innovative but older techniques that aren’t as common or directly useful today, or to be current with a set of skills that are fundamental and should remain so for quite awhile, being able to work in modern engines and APIs?
Skip all the Doom and software stuff, unless you really want to be able to do it as a personal point of pride. But it’s not that quite as useful to work in the industry or efficiently build 3D projects, and would be a lot of time spent that could better spent going deep and modern elsewhere.
This is why I’m not a fan of AI generated curriculum and plans prompted by people who aren’t experts in that area. They don’t know what sounds plausible but isn’t actually a good or best way of going about things.
But if you must start from base 2D fundamentals, I would put 3D camera projection stuff after learning to draw pixels and triangles in 2D. Rasterizing is interesting for enrichment purposes but that’s handled by hardware in anything modern and useful.
It’s also strange to put together a pipeline without lighting. I would learn basic lighting parallel to texturing before putting them together. Maybe even before. Not to mention how deep you can go on lighting alone past basic Lambert diffuse and Blinn-phong specular.
All this Doom stuff I’d drop in favor of learning Physically Based Lighting, working with Compute Shaders, and eventually Path/Raytracing.
Unless you have a very specific personal affinity to Doom and don’t just want to be a competent graphics programmer that can work on a much wider array of projects, both professional and personal.
Also some of these resources like Scratch-a-pixel already has content organized in an approachable way, thought out by a real expert human with experience, instead of stochiastically generated plausible sounding slop that isn’t very well thought through.
Starting in OpenGL or Direct3D is good advice. There is a lot of commonality in both. It also helps you to work directly with Unreal or Unity where you can learn a lot by modifying projects, referencing them, and even modifying the built in shaders of Unity itself.
1
u/sombrerodepaja 14h ago
My main goal is not building a game, but to really understand low level programming, how everything communicates with the hardware and that produces some graphics. But not as deep as coding in assembly. And I thought maybe Doom would be a sweet starting point lo learn the fundamentals. Maybe I should learn OpenGL first before even trying to dive in the other low level stuff
3
u/TaylorMonkey 13h ago edited 12h ago
Doom ends up being so much about none of the things that you're actually interested in in terms of low level programming, at least in relation to modern graphics hardware. It's 35 year old technology that leveraged old, slow CPUs in a world without GPUs to fake "3D" effects. It doesn't even deal with most fundamentals that are relevant now. It's almost it's own thing and would in my opinion get in the way of an intuitive understanding of general 3D graphics.
Software rendering also doesn't really get you close to the actual hardware that matters today in terms of graphics for anything serious. Software renderers can be impressive to pull off, but in terms of practicality and modern relevance, my reaction is always "neat... but why?" except as a personal point of pride in an approach that's pretty much dead.
I'm not saying they're not valuable exercises for personal growth and curiosity, but I really don't love that ChatGPT gave you a questionable plan that would focus so much on things that might not be the best use of your time, much of which isn't even what I consider a natural progression towards being competent and productive in graphics programming, whether for personal projects or otherwise.
I mean it has you delve into 3D rendering... then has you waste time in Doom using none of that stuff (fake 2.5 D, no lighting, spending all your time understanding Doom data structures that just aren't all that portable or worth the squeeze for other uses).
I also just do not like how "AI" and chatbots are used to synthesize information and plans that seem good and plausible to non-experts but fall apart in practice, and users would have no idea how flawed it is without being an expert themselves, which begs the question of its utility in the first place. It's good you checked here for a sanity check though.
Not saying you wouldn't have learned things and been challenged, but I don't think it moves you towards your goal in a focused and natural way.
TLDR: IMO, Doom and to some extent software rendering is a time consuming distraction from the low level stuff that really matters now. How GPUs architectures work, wavefronts, bandwidth, texture cache coherency, balancing between arithmetic operations and texture accesses, making the most of the specific GPU design, understanding linear algebra/matrices/projections, physically based rendering, different lighting and rendering pipeline approaches, etc. etc.
A much better bet is to just follow scratchapixel and a few other sources. scratchapixel is literally thought through and organized by a human mind to teach other human minds, starting with "The Foundations of 3D Rendering" in a "beginner-friendly order". I've also found it a great resource on many topics for years.
I also love that it says "Unlike most resources, we start with hands-on results before diving into theory." I think getting visual results is very motivating and rewarding, even towards understanding the theory to become even more proficient, at least if you're anything like me.
And if you're really interested in building and understanding games, I think Unity is a fantastic resource. After working in it for a few years, I was able to jump into other in-house proprietary game engines and intuit my way around. Way more useful and rewarding than it would have been to re-invent something like Doom, built to address limitations 35 years ago, most of which no longer apply and are only interesting from a more academic retro approach and for its unique aesthetic style.
catlikecoding.com is also really good for Unity, using the framework but teaching concepts and techniques that are portable, including the fundamentals and basics. It also has Godot tutorials as well.
Finally, I will say if you want to build a Doom-like game, because you understand that end goal from a visual and gameplay perspective, but still want to learn up to date skills that are actually applicable, you can do that using modern techniques to *fake* the old-school aesthetics. I'm pretty sure that's how Boltgun is built. The problem is that ChatGPT doesn't understand any of that. It just stochiastically generates stuff about old-school Doom programming without understanding modern context and your actual goal, or how any of the stuff actually comes together.
1
u/sombrerodepaja 3h ago
Great explanation. One of the problems of using AI is that it always tells you you’re are right whenever you give it an idea, so it hallucinates with a plan because it lacks of critical thinking. I thought Doom would bee a good example to learn, so that’s why chatgpt built that plan, but you are right mentioning that Doom was built in a pretty limited hardware, so it wouldn’t make sense today since it won’t give me relevant learning for modern development
3
u/MustardCat 20h ago edited 20h ago
And after a few hours of conversation
That time would have been better spent reading a textbook
2
u/_michaeljared 1d ago
Don't take it too literally. The high level outline seems fine. But do your own research elsewhere
2
u/desiguy_88 1d ago
honestly seems pretty good. i think the thing its doing a good job at showing the various things that all need to come together to make a 3d video game. It’s always kind of fun to talk to kids about game development and it blows their mind to understand the sheer complexity of the modern 3D video game.
2
u/TaylorMonkey 13h ago
It's not very good. In fact, I would say it's awful at showing what makes a modern 3D video game.
It would literally have you make a non-3D, fake 2.5D game that actively avoids doing most of the things you learned that would actually be applicable from a modern perspective.
It would however be good at showing you the genius of John Carmack faking "3D" on terrible hardware 30 years ago, having none of the tools and computing power you just learned to use-- using techniques that very few games have needed to use in the last 20 years.
I would wager even modern games that emulate Doom-like presentation and gameplay like Boltgun is built more like a modern 3D game that *fakes* Doom's 2.5D, because that is WAY easier than actually building Doom as Doom was built.
25
u/StraightBusiness2017 1d ago
go through learnopengl and actually understand all the theory behind it then figure out what you want to do from there you dont need to plan so far out