[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
▼ Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


๐ŸŽ‰ Happy Birthday 4chan! ๐ŸŽ‰


[Advertise on 4chan]


File: frogs.jpg (272 KB, 630x630)
272 KB JPG
Make a game engine with frogs edition

/gedg/ Wiki: https://igwiki.lyci.de/wiki//gedg/_-_Game_and_Engine_Dev_General
IRC: irc.rizon.net #/g/gedg
Progress Day: https://rentry.org/gedg-jams
/gedg/ Compendium: https://rentry.org/gedg
/agdg/: >>>/vg/agdg
Graphics Debugger: https://renderdoc.org/

Requesting Help
-Problem Description: Clearly explain your issue, providing context and relevant background information.
-Relevant Code or Content: If applicable, include relevant code, configuration, or content related to your question. Use code tags.

previous: >>109945158
>>
>>109965491
Cool, do forget everything I said, because you obviously don't need my help or explaining.
>>
maybe today...
>>
just saw the new cherno video where ai makes a whole engine, i dont want what i make to be branded as slop but its like theres a big "do everything instantly" button next to me
>>
File: 1787429118736085.png (268 KB, 478x634)
268 KB PNG
how can I start at enginedevving? making a triangle?
>>
>>109990520
what do you want in your engine? Doing one for hobby and having a bot lookup solutions to problems seems fine. Having it write everything from scratch seems senseless. Idk it depends I think what people want that button to do its not one button to solve everything and you will have to use it multiple times.
>>
>>109986135
I'm finally done with my programming language, now I can start with the engine.
>>
File: 1784572202907264.jpg (24 KB, 599x357)
24 KB JPG
>>109990520
If you are just gonna let somebody else make the slop-engine, and you are going to treat it as a black-box afterwards because you have no idea what is going on in it: why not just use an open source engine? Where are some cool options, godot (minus the gdscript part), bevy, stride, 3D0, lรถve, and more! You can get them at a press of a button, at github
>>
File: clion64_EIuMF3hxI2.png (383 KB, 1357x834)
383 KB PNG
I just finished going through the How to Vulkan 2026 tutorial.
I picked this one because it seemed the easiest to translate into C, and while that was easy, I didn't really like the tutorial itself very much.
I feel the code is poorly organized and commented, and the stuff written on the site assumes the reader already knows quite a lot about graphics APIs.
At the very least, I can use this as a working C example to reference while I go through the Khronos tutorial, I guess.
>>
>>109994534
If you don't know quite a lot about graphics APIs you have no reason to be using Vulkan
>>
>>109994745
And how am I supposed to learn about graphics APIs if not through Vulkan?
Direct3D is not cross-platform so I don't care about it. The latest OpenGL version is a decade old at this point and I'd rather not invest my time in learning something that clearly has no future.
>>
>>109994947
OpenGL
>>
>>109994745
There is no reason not use Vulkan in 2020s

>>109994954
OpenGL will teach you tons of useless legacy shit that doesn't apply to modern GPUs. That's like learning C++ by first learning how PDP-11 works.
>>
>>109995669
>OpenGL will teach you tons of useless legacy shit that doesn't apply to modern GPUs
OpenGL will teach you OpenGL which works on modern GPUs so that doesn't really make sense
>>
>>109995792
At no point anything in your post contradicted anything in my post.
>>
>>109996136
Nothing in OpenGL only applies to old GPUs
>>
>>109996199
Immediate mode, fixed function pipeline, automatic memory allocation, poor compute support etc are just legacy baggage that doesn't apply to modern GPUs. Also OpenGL API using global state machine is just much more awkward to use than Vulkan object oriented, multithreading friendly API.
>>
>>109996235
>that doesn't apply to modern GPUs.
that doesn't even make sense
the API is automatically allocating memory, it has nothing to do with old/new GPUs
and why would you use the fixed function pipeline
>>
>>109996251
>that doesn't even make sense
Well, then you should learn more about how modern GPUs work. All these things were created back when GPUs were very different from what we have now. Modern GPUs work very differently and OpenGL has to do a lot of work behind the scenes to emulate that old behavior on modern hardware. All of this is useless bloat nowadays.

>and why would you use the fixed function pipeline
You don't. That's why it's worthy yo just use API designed for modern hardware from ground up.
>>
>>109996341
>OpenGL has to do a lot of work behind the scenes to emulate that old behavior on modern hardware
It doesn't, only if you're using the fixed function piepline which got depreciated with OpenGL3 like 20 years ago
>>
>>109996355
>It doesn't
It literally does. Modern GPUs do not have fixed function pipeline. It needs to be emulated.
>>
>>109996392
try reading more than the first two words of the post
>>
File: momoi smug.jpg (109 KB, 773x802)
109 KB JPG
>>109996355
>only if you're using the fixed function piepline which got depreciated with OpenGL3 like 20 years ago
Yeah, and no one would do that. Nobody would
>put all their vertices in an array
>put the order they want them rendered in a second array
>pass both to the gpu
in the two-thousand and twenty-sixth year of our lord, Jesus Christ of Nazareth. Who WOULDN'T want to fuck about with shader autism instead of managing two arrays per model? Couldn't be me.
>>
>>109996405
the fixed function pipeline has all sorts of restrictions like one lighting model, only 8 lights
it's very old and it's disingenuous to bring it up
>>
>>109996399
I read your post fully. Can't say the same about you though
>>
>>109996467
you repeated back to me what i said while ignoring the fact that nobody uses the fixed function pipeline
>>
>>109996418
>it's disingenuous to bring it up
So write your own game engine then. It's not my problem, it's yours.
>>
>>109996418
It's disingenuous to bring up deprecated apis when discussing the amount of legacy bloat in OpenGL? That's literally what we are discussing.
>>
>>109996487
nobody uses the opengl fixed function pipeline
>>
>>109996476
>you repeated back to me what i said
You did that first. Precisely here: >>109996355
>>OpenGL has to do a lot of work behind the scenes to emulate that old behavior on modern hardware
>It doesn't, only if you're using the fixed function piepline
It's even part of the quote you've used. You've negated it and then proceeded to say the same thing the quote says.

But it doesn't matter. What matters is that we both agree that OpenGL has many useless deprecated APIs that require emulation to execute. This is exactly my point why it doesn't make sense to learn it instead of modern API for modern GPUs.
>>
>>109996496
And yet I see them all the time in OpenGL tutorials.
But it doesn't matter. If you use modern API you don't have to worry about what is modern and what is deprecated.
>>
>>109996507
nobody uses the opengl fixed function pipeline
>>
>>109996518
>And yet I see them all the time in OpenGL tutorials.
No you don't, only if they're 25 years old
Love these kids who just use the thread as a soapbox to make shit up
>>
>>109996520
And yet I see them all the time in OpenGL tutorials.
But it doesn't matter. If you use modern API you don't have to worry about what is modern and what is deprecated.
>>
>>109996581
That's a bit of a simplification. Vulkan is deprecating features on every release. The double edged sword of modern APIs is that they are "more righter" but then they change them from right under your feet as quickly as you think you know what you are doing.
>>
>>109996581
>If you use modern API you don't have to worry about what is modern and what is deprecated.
lol
>>
File: 01.jpg (358 KB, 1920x1080)
358 KB JPG
>use OpenGL
pros:
>30+ years of tutorials at your fingertips. You can access ancient and arcane wisdom from greybeards of yesteryear.
>easier to use than vulkan or DX12
>can swap pipeline stages in and out without having to precompile a whole new "pipeline" object
>you don't have to write any allocators
cons:
>need to use OpenGL 4.6 to get SPIR-V
>everything is a gluint handle, no types, easy to pass the wrong thing to the wrong function
>no native smart pointer support
>you have global program state to manage rather than passing around context objects
>API is kinda ugly to use
>have to use GLAD to load function pointers for the OpenGL API + extensions and shit
>generally less efficient than Vulkan for larger use cases than simple low poly graphics and shaders
>sucks at multi-threaded apps
>OpenGL is in legacy support mode, you will not get new features

>use Vulkan
pros:
>everything is typed properly, compiler will tell you if you pass the wrong thing to the wrong function
>state is generally not global, you pass state objects around to functions
>SPIR-V support (which gives you HLSL support because GLSL sucks dick)
>no GLAD initialization shit
>first party RAII type support with vulkan-hpp
>faster, better support for multi-threaded applications
cons:
>have to do a fucking crazy amount of initialization just to show a triangle. Literally like 1000 lines of code of selecting devices and outputs and building allocators and shit that most devs don't give a fuck about (though you can find some open source allocators)
>very verbose API, kinda ugly to use
>without extensions, pipelines are immutable. If you need to change a single shader in your pipeline, you need to create a new pipeline object entirely and bind that. This isn't a problem if you're smart with how you organize your code but gets to be a PITA for some devs

>use DirectX 12
>all the same pros/cons as Vulkan, except
pro:
>Built in smart pointer support via ComPtr
con:
you sit in the microsoft cuck chair
>>
>>109997435
an actual correct post for once
>>
File: soyboy.jpg (548 KB, 1128x1080)
548 KB JPG
>>109997435
btw if you want a simple move-only single-owner OpenGL raii class:

    template<typename Handle, void (*Deleter)(GLsizei, Handle const*)>
class GlObject {
public:

explicit GlObject(Handle handle) :
m_handle(handle)
{
}

~GlObject() {
reset();
}

GlObject(GlObject const&) = delete;
GlObject& operator=(GlObject const&) = delete;

GlObject(GlObject&& other) noexcept :
m_handle(other.release())
{
}
GlObject& operator=(GlObject&& other) noexcept {
if(this != &other) {
reset();
m_handle = other.release();
}
return *this;
}

Handle release() {
auto t = m_handle;
m_handle = 0;
return t;
}

void reset() {
Deleter(1, &m_handle);
m_handle = 0;
}

Handle get() const {
return m_handle;
}

private:
Handle m_handle;
};


use like

using GlVertexBufferObject = GlObject<GLuint, glDeleteVertexArrays>


and for shaders whose deleter only takes one arg:

inline void glObjectDeleteShader(GLsizei, GLuint const* ptr) {
glDeleteShader(*ptr);
}
using GlShaderObject = GlObject<GLuint, glObjectDeleteShader>;
>>
>>109996355
>only if you're using the fixed function piepline
Unfortunately that's not the case. Even if you're using OpenGL4.x and restricting yourself to just shader driven vertex buffer objects and such, the OpenGL API unfortunately still operates on a "stateful" model so the driver has to maintain a whole lot of GPU state between draw calls that negate a shitload of optimisation. The main reason Vulkan and D3D12 (and Metal if you swing that way) are a million times faster is because your pipelines are the entire state that YOU have to keep on top of and if you fuck up, it's on you. OpenGL sadly doesn't have the same feature. It has something that looks 99% identical, but because it still lets you mix and match your bound objects the driver has to assume you're going to and can't segregate everything into nice neat parallel workflows.
>>
>>109997600
nta, but most devs don't need the vast majority of the speed improvements provided by Vulkan or DX12. OpenGL 3+ (or 4.x really) are good enough for most hobbyist devs use cases.

What I REALLY wish we had was a Khronos-sponsored graphics API which sat between OpenGL 4 and Vulkan. Basically a cross-platform version of DX11, because DX11 is peak dev ergonomics
>>
>>109997600
thats true but thats not "a lot of work behind the scenes to emulate behaviour" its more just missing optimization opportunities
>>
>>109994947
Anyone who tells you Vulkan is a replacement for OpenGL is a moron without a clue. Vulkan can implement something like OpenGL which is why it was used to implement DirectX on linux as DXVK. If OpenGL gets "deprecated" they will just implement OpenGL in Vulkan and it will continue to work without modification. OpenGL is fine. Any tutorial you find for it today will use 3.0+ which is designed for modern GPUs. In the majority of cases where a dev switches from OpenGL to Vulkan they lose performance because they don't know what they're doing as well as the guys with 30 years of experience creating OpenGL, unsurprisingly. Just use OpenGL, start writing code, and stop reading bullshit on the internet. Most people shilling Vulkan are nocode gaymer NEETs who think they could run 2077 on their 1650 if only it was rendered with Vulkan. They want everyone to use an unwieldy timesink API because they think it will save them from getting a job to buy a new GPU. Just ignore them and they'll off themselves soon enough.
>>
>>109997755
to build on this: you cannot appreciate the value of Vulkan until you have worked with OpenGL. OpenGL is an API designed for normal programmers who want to write 3D graphics applications. Vulkan is an API designed for Graphics programmers who want to squeeze more performance out of their code by enabling features and patterns which are unavailable in OpenGL due to legacy reasons. 90% of your performance bottlenecks are going to be solvable in any Graphics API you choose (i.e, cache locality, loop unwrapping, shader branch elimination, etc).

The real skill here is not "vulkan" or "opengl", it's in getting an intuition for how graphics pipelines work, and OpenGL is still a perfectly valid model of how graphics works, albeit at a slightly higher level than Vulkan or DX11/12. Once you've got some graphics work under your belt, transitioning from OpenGL to Vulkan/DX11/12 feels refreshing, enlightening, and also easier than if you had just gone straight to Vulkan (where you would constantly be asking yourself "oh my god who the fuck cares? I just want a triangle on the screen!")
>>
>>109997635
>most devs don't need the vast majority of the speed improvements
There is no need to use old, inferior technology.
>>
>>109997755
>>109997849
>nocode gaymer NEETs
>you cannot appreciate the value of Vulkan until you have worked with OpenGL.
I used to use OpenGL in past. After I migrated to Vulkan and I see no reason to ever bother with that shit again. Vulkan API is just way nicer to work with.
>>
>>109997930
then use webgpu. it's more of a successor to opengl than vulkan is. vulkan is cool but it doesn't fill the same role as opengl. if somebody asks if they should move from opengl to vulkan the answer is webgpu nine times out of ten.
>>
>>109997435
what about wgpu
also there should be some wrapper around vulkan by now that does the hard part for you.
>>
File: terry.jpg (155 KB, 1280x1275)
155 KB JPG
>>109998109
>wgpu
idk never touched it, not really into web shit
>>
Is anyone else here developing on Defold/ with Lua?

I'm interested in collaborating via simplex chat
>>
>>109994947
Vulkan is better than opengl in mesh shader support, and DLSS/FSR/RTX stuff. And you have timeline semaphores by default which are just better than sync objects (glFenceSync) since you don't need to explicitly reset it after it signals. And also if you want to make changes to textures and buffers without making a sync point, vulkan has a copy engine thing (Nvidia has vulkan gl interop, see https://github.com/nvpro-samples/gl_vk_async_copy BUT I don't know if there is any noticable perf or stutter fixes in comparison to using an opengl async PBO using fences, the copy engine should help with a CPU bound overhead I THINK since I assume you can write to the buffer using a separate thread, but I feel like creating the memory is more expensive than uploading it, and you should look into using a compute shader if possible).
mesh shaders and timeline semaphores exist in opengl through extensions, but I wouldn't bother with supporting any GPU other than Nvidia, because nvidia just has a really good driver for GL. You kind of need an intel or AMD gpu to test with, because GL drivers can vary heavily. Vulkan is minimal enough that you don't need to worry about other GPU's (and when it happens, it likely also exists in GL).
Also Nvidia Nsight has a Vulkan shader debugger, which should cover more experimental vulkan features than renderdoc. But it requires a 30 series Nvidia GPU or newer and you need a spare PC or dual GPU/igpu setup.
Also I target webgl + Angle, for fun and portability sake. But was it worth it? Not really, everything I mentioned above does not apply to webgl, it does not even have compute / geo / tess shaders (webgpu is much more practical with compute, but I care more about my desktop Nvidia-specific build than webgl ATM, webgpu is just for rust apple devs using bevy in my opinion).
The worst part of GL is that it shares little with other API's. You can't easily add vulkan to a GL game (but maybe AI can).
>>
>>109997983
WebGPU is a Web API. It's only available in browsers. I write native programs.
>>
>>109998109
NTA, I am using wgpu in my newest project and it's pretty nice so far. It has simpler API than Vulkan but just as modern.
>also there should be some wrapper around vulkan by now that does the hard part for you
Since you are considering wgpu I assume you use Rust. Then vulkano is pretty good. It's a fairy minimal wrapper and it takes care of the most boring parts of Vulkan like image barriers and memory allocation.

>>109998131
wgpu is a native API though. You are probably thinking about WebGPU.
>>
>>109998642
it's a native API, and it seems to be more for multi-backend engines.
So you wouldn't write wgsl, you would instead prefer slang (technically there is a spirv to wgsl translator but I don't know how usable it is). But you still need to do all the API work of webgpu and vulkan/etc.
But in my opinion, every beginner starts off and they struggle with the API and shaders are an afterthought, but that quickly flips around once you start combining multiple advanced effects together, since all a sudden, your simple shaders turn into a feature matrix with exponential permutations... And who knows what's the most optimal way of batching your draw unless you benchmark? (And benchmarking is a whole new complicated set of non-obvious vendor-specific metrics which you need special tools for of what is your GPU actually wasting it's time on)
>wgpu is a native API though. You are probably thinking about WebGPU.
wgpu is the rust implementation of webgpu, dawn is the C++ implementation (used in chrome).
Last time I checked rust users still prefer using dawn for the diagnostics, but wgpu runs faster or something.
>>
>>109998888
>wgpu is the rust implementation of webgpu, dawn is the C++ implementation (used in chrome).
It's the other way around. Web GPU is implemented using wgpu. wgpu is not an implementation of WebGPU because WebGPU is a webapi, it is designed for JavaScript running inside a browser. wgpu can use WebGPU as a backend, but that's only if it is running in WASM on top of JS. If you are writing a native application and use wgpu API it will just pass the calls to Vulkan/OpenGL/metal with no WebGPU, JS or browser at any point.
>>
>>109992784
You can start engine devving right now, depending on what part of the engine you want to focus on. There are a lot of moving parts to an engine, maybe you want to work on the inputs first? Maybe you want to work on the networking side of things? Or graphic backend of the physics back end? There are a lot of ways to start engine devving.
Pick one you like the most and start from there. and slowly go building on top of it. Your first game could just have a simple gameplay loop with a while (runGame) or something like that.
>>109990520
I mean what do you want for yourself? Do you want to actually learn what goes under the hood and how everything works together and try to apply that knowledge. Or do you want something that is functional and you don't mind stressing over the details? I think we are reaching a point where LLMs should be able to do a lot as you may have seen with it decompiling every single game around. So now the questions really becomes why are you doing this? Why are you building your own game engine? Is it to learn or to build games with it. Or both?
>i dont want what i make to be branded as slop
Who cares about other people think about your work, you should do your work because you want to do it. It's not like you are earning any money from this and there is no reason why you should constrain yourself to the opinions of others. May that be for status or anything else.
>>
>>109999111
Dawn is chrome, Wgpu is firefox. There is a safari backend that you can't use for native apps (JS only).
If you are using the rust or C++ headers, dawn and wgpu are not ABI compatible (BUT I assume that the api is still able to build to wasm? so technically you CAN interchange the backend through the browser).
But if you are using the C headers, it's interchangeable across between backends on a native binary, including the JS backend which is an extra translation layer. So you can swap dawn with wgpu, and vice versa.
And this C header is called webgpu.h
>>
>>109999510
>Wgpu is firefox
Firefox uses wgpu to implement webgpu for javascript. wgpu it self is not webgpu, it's a native library that supports bunch of native graphical apis and can do way more than webgpu. webgpu on the other hand is a web api, it is bunch of javascript objects and functions. Nothing you'd use while making a native application.

>If you are using the rust or C++ headers, dawn and wgpu are not ABI compatible
wgpu is a rust crate, you can't use it with C++ unless you write some sort of wrapper.
I have never heard about anyone using dawn for anything but webgpu implementation in chrome. But maybe it can be used as a library, but what does that even matter.

>And this C header is called webgpu.h
The only thing that pops up when searching this header file is some random's project that is not part of WebGPU standard nor wgpu crate.


Not sure why are you stating all these random things or what point are you even trying to make now. It still won't change the fact that WebGPU is a web api, it is meant to be used by javascript running inside the browser while wgpu is a Rust crate for making native and wasm programs. They are not the same and use completely different languages. It makes 0 sense to recommend someone a web api like webgpu as an alternative to opengl and vulkan which are native apis. wgpu is a valid alternative though if someone is using Rust and wants a cross platform program.
>>
>>109986135
in the future everyone will have made a game.
>>
>>109998359
>The worst part of GL is that it shares little with other API's. You can't easily add vulkan to a GL game
Vulkan is very similar to OpenGL 4
>>
>Guy who has never used OpenGL says Vulkan is better than OpenGL
>Guy who tries to claim webGPU isn't a web framework
Every /agdg/ thread
>>
>>110000031
I am the one who said that Vulkan is better than OpenGL. I have been using OpenGL before in past. Vulkan is only 10 years old after all.
>>
>>110000074
Well Vulkan IS better than OpenGL performance-wise but that doesn't matter to a beginner
>>
I think it's time to come back to my vr/ar project. Rapier got a lot of updates since I last used it. Sadly it still doesn't have one feature that made me put this project on hold(motor model for joints with coupled limited angles) but now I think I can manage to workaround it.
Collisions are borked it seems, but I think it's just matter of collision groups on colliders. So I made an editor for them in the inspector. I could in theory manually tweak them and fix it, but since I want this to somehow work for any MMD model and they are not made with full ragdolls in mind, I think I need to come up with some solution to automatically generate collision groups based on how the rigid body are connected together to avoid collisions between jointed rigid bodies.
>>
>>109990520
You're never going to slop up an engine better than one that has been in development for 20 years like Godot, unless you have an ass load of time and money to burn. If you're going to use AI best to just use it to extend open-source engines that already exist. Doing it the slop way is just going to leave you with a hole in your pocket and a bunch of code you know nothing about. Like that other anon said, if your going to get AI to do it for you then you might as well just use an engine that has already been made for you and has released games.

But anyway, I wouldn't trust anything that cherno faggot presents in his videos. He's always looked like a scumbag to me. He's more skilled than you though so what he can get AI to do you're not going to achieve. If you don't want to create slop then don't, it's that simple. Have some integrity lil nigga.
>>
>>110000820
how to sex migu???
>>
>>109997435
>muhhhh smart pointers
Grow a brain, retard.
>>
>>110000074
Being better than OpenGL doesn't means it's raising the bar that high.
>>
>>109997435
>>OpenGL is in legacy support mode, you will not get new features
except every couple years KHRONOS still updates it to add new features.
>>
>>110000826
>He's always looked like a scumbag to me.
His C++ tutorials are directly responsible for me passing an interview for my first real job out of university. He looks like a scumbag because he's Dutch they just look like that. He was also really young when he made those videos he's an impressive goy
>>
>>110000826
>He's always looked like a scumbag to me
He seems like a completely chill guy
>>
Why is it so hard to make an Unreal game that doesn't feel like pure slop?
>>
Claude ass over here whipping up straight shit wasting my tokens. I prolly could have done it myself. Fuck no.
>>
I'm going to embark on a solo autist mission to program a small game in C++. I was previously an application level / webshitter programmer so no real experience to speak of. I'll want to use a graphics API, math library etc, but the rest I want to write myself to the extent possible. Since I work alone I figured I could have an LLM do PR reviews for me. Which one do you find the best for this type of work? Codex vs Claude vs Cursor vs Deepseek basically. I don't really want it to generate any code for me, just be a kind of sounding board for my ideas and to review and catch mistakes.
>>
>>109993829
You know there is a middle way here. It doesn't have to be black box ai slop vs hand coded.
>>
Check out my gayme, is open sourche fa****s:

https://files.catbox.moe/eq8nxm.apk
>>
If you want the imagepack, I extracted them also

https://files.catbox.moe/gcj6lp.zip
>>
Which games you've made this week f****s?

I've made "Angry Terrorists"(Original Angry Birds idea), "Flou"(Pou, but with Floyd n* face), Flacid Bird(Flappy bird with flacid hanging balls(harder to pass through the obstacles)) and Adolf Bros
>>
File: 1791212818209348.jpg (38 KB, 290x390)
38 KB JPG
>>110005116
>theres a big "do everything instantly" button next to me
That button is the github-button. Thats where claude also gets their shit. Do you really want to use a shitty decompiled version of stride or flax or bevy, from mr jew-stein, or do you want to go to the source, and get the ORIGINAL. Think about it for a second
>>
>>110006732
Oh, you're still in the "all they can do is copy code they saw from github" cope
>>
>>110006792
Refute the "cope". Are you in the, "im working to shill for mr jew-stein, but people dont bend for my lies, better pretend that im bussy and productive, so i can go home earlier, or get a raise" cope?
>>
Why is OpenGL documentation so shit?
>official documentation
explains nearly nothing
>online tutorials
actually explain nothing
>books
fine but not great
I'm not a vibeshitter but I told a model to output a program using OpenGL and I feel like I've understood more reading through it than I understood trying to wriggle myself through this API, I think gatekeeping is good but only when I do it. Am I genuinely an idiot or does anyone else have the same problem?
>>
>>110007200
I feel like a lot of stuff really does a horrible job of building a mental model of how things actually work.
The whole GPU pipeline, the OpenGL state machine, API conventions etc.
You really do just have to stumble around until it finally clicks.
>>
>>110006044
> f****s
Why are you censoring?

>>110007200
>Why is OpenGL documentation so shit?
learnopengl.com is probably the best there is
>>
>>110007200
If you find openGL tutorials difficult you might be an idiot
>>
>>110005095
>catch mistakes.
just compile and run your game why the fuck do you need an AI?
>>
>>109992784
I hate this ugly tranny so fucking much lol
>>
>>110009627
>why the fuck do you need an AI?
He explained why he wants to use AI. Learn to read.
>>
>>110010803
yes and i quoted it and told him the compiler does it
>>
>>110010818
>I need something to do code review for me
>compiler does it
Retard or pretending.
>>
>>110010848
ok why do you want a "code review" from a chatbot who will just tell you what you want to hear
>>
>>110010860
>why do you want a "code review" from a chatbot who will just tell you what you want to hear
Probably because he wants to hear if his code is well written. That's the point of code review.
>>
>>110010880
That's one of the things AI can't do
>>
>>110010889
It can to a degree.
>>
>>110010899
Trusting an AI with something very subjective that you have no way to verify is very stupid, you'd be better off just vibecoding, at least that gets you results
>>
>>110010916
I disagree. I think he will be better off writing stuff himself and asking AI for reviews than vibe coding. Even if the reviews will not be as in-depth or precise as human made, he will still be engaging with actual documentation and writing code himself which teaches you way more than asking AI to write things for you.
I can't recommend him which models would be good for reviews since I never needed them. But I have been using deepseek while learning Japanese and it does a great job figuring out nuances and analyzing grammar. I'm sure it would work fine for beginner level programming.
>>
>>110010943
Documentation is objective, it tells you what the code does
A review is subjective, if you ask an AI to review your code it's going to give you garbage (because most of the stuff it learnt from is garbage) and you would have no way to know any better
>>
>>110000128
>to a beginner
or to a pro. there are engines and games made with OpenGL that are well beyond anything anyone in /gedg/ could ever make. claiming OpenGL somehow limits anyone is pure cope and skill issue.
>>
>>110010956
>if you ask an AI to review your code it's going to give you garbage
Well, instead of doing a guess work, let's try it. I wrote a badly written Rust code that you'd expected from a newbie, and deepseek preciselypinpointed all mistakes.
So yea, I think AI is viable for beginner's code review.
>>
>>110011132
He's not a beginner
Ask if it can correct gamedev mistakes
I doubt it could
>>
>>110011132
why do all AI trannies use rust?
>>
>>110011147
I have been using Rust years before contemporary LLMs and I do not use AI for programming. Like I've said, I mostly use it for learning Japanese. I can write my own code myself.

>>110011141
He said he is a webshitter with no experience. He will be fine.
>>
>>110011163
If you're a webshitter you have experience
Your example is Rust pedantry not real programming advice
>>
Anyone got some SDL3 tutorials that define a basic game structure?
All the stuff I find is like "we'll make some shit decisions to explain some functions easily", but I want the opposite, I know coding and can read the docs, I want details on input handling (polling or events?), splitting rendering from the cpu thread, reasource management, etc



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.