Vulkan > whatever shitter garbage your doing

>>106440531
Rdr2 was made with Vulkan. Not a bad renderer at all.

>>106440381
Video sauce?

File: 5fa27b2cb1c7e3043c155c8d.jpg (34 KB, 544x495)

34 KB JPG

>>106440531
what if I was using GNMX?
>>106440615
its in the OP
>picrel sauce : https://x.com/cinnadev_/status/1959665536100340163

>>106440381
>just make it exist first
Shit advice, absolute midwit drivel. I wish people stopped parroting this dumb idea.

How many games have died due to technical debt caused by this retarded idea?

>>106440754
>Shit advice
it is a shit advice for game dev that solely relies on a game engine like a midwit is supposed to.
But its a good advice for game engine dev because we'll do better in the next iteration once we got shit to work during the first run.

>>106440381
soul/soulless

>>106440774
No, it's just shit advice and how projects die. It's like "just work around the bug if its not critical bro". Why do you think it will take less effort to fix something in a year when you've forgotten most of what you knew about it instead of now when you've been actively working on it? This advice only works for art, because you can dump in some placeholder and then replace it later. For your engine? You can, but you're increasing your own workload tenfold and making it more likely you abandon the project due to technical debt.

Ironically, engine dev is more like classic painting or sculpting: you can undo mistakes, but it's orders of magnitude harder than just taking the time to at least avoid the worst of them.

i iterate on engines features all the time. it's impossible cover all possible problems and corner cases of the system until you encounter them first. for this you need something working fast.

>>106441352
>it's just shit advice and how projects die
you seem to be one of those retards that believes writing perfect, well-optimized, produciton-ready code right from the start is what everybody should be doing. Have fun with your premature optimizations.
But typically, software development is a constant cycle of adding new features and refactoring your code, which in other words means "make it exist first, make it good later".
>just work around the bug if its not critical bro
how?
the text goes "make it exist first ... make it good later" not "make it exist first and leave it as it is"

https://registry.khronos.org/vulkan/specs/latest/man/html/VK_EXT_device_generated_commands.html
Use-case? Seems like Valve had a big hand in it.

>>106441352
obsessing about perfect architecture is how you turn into a jonathan blow or casey muratori taking 900 years to make a basic game.

"just make it exist" doesn't say "write unmaintainable slop that is impossible to refactor and runs at 5fps. You are kidding yourself if you think anyone writes software in 1 perfect draft

>>106441522
You keep harping on about it like it's some reasonable middle ground, but the reality is nobody who parrots that comes back to it to improve the sloppy work, it just becomes an excuse to be lazy and write bad code.
>>106442768
>jonathan blow
You mean the guy who has made 2 games which have both been extremely successful, both easily in the top 0.0001 percentile of indie games? Sure he's only made 2, but the vast majority of indie developers don't even release 1 in their whole lifetime that gets close to the success of Braid or the Witness.
>"just make it exist" doesn't say "write unmaintainable slop that is impossible to refactor and runs at 5fps. You are kidding yourself if you think anyone writes software in 1 perfect draft
See above, it's always used as an excuse for laziness. Nobody writers perfect code on the first try (or ever for that matter), but you should try to write as good a code as you reasonably can on the first try.

File: img_68b07909883f72.59832132.jpg (35 KB, 255x487)

35 KB JPG

>>106443070
>the reality is nobody who parrots that comes back to it to improve the sloppy work
yeah, I get that your reality is the one where you wrote a vulkan renderer within your first try and went all the way to implementing PBR and GI within the first try because you knew very well about how to code all that right from the start before you even began writing a vulkan renderer for the first time. That way you never had to come back to improve your sloppy work because all your work was like that of a pro since the start.
But my reality is that I had to gave up several times, pick up where I left off, feel lost, start from scratch and keep at it till I get there.
You don't get to project your elitist reality onto my midwit reality. At least, I got a peace of mind.
Keep your bs to yourself.

>>106443198
>higher standards than the bottom of the barrel means unattainable perfection
Lazy and stupid people instinctually feel threatened by standards and lash out with hyperbole and strawmanning.

>>106443198
Holy mother of reddit. When will you fuck off and kill yourself already? It's bad enough everyone had to migrate to /vg/s amateur development thread some time ago. You dont need to kill this dead horse.

Nobody wants to hear how you think slapping the words "GI" and "PBR" next to your engine makes it this impossible to architect thing. No, you spastic desperate to spam nu-graphics-dev content every single day, these aren't stunning achievements that need 50 rewrites and 3 years of tinkering. All this is ironic coming from you, the nigger who is admittingly a master of sweet fuck all and yet somehow musters the ego to assert what other people should be doing. I'm sorry your rewrite of <muh learnopengl> took so long, I guess?

Sincerely, kill yourself

>>106443546
>>106443610
lmao. I was being sarcastic and looks like I did a fantastic job.
Anyway, contrary to what you believe, a lot of folks do come back to improve their sloppy work and they either improve it or start from scratch instead, all of which is in regards to "make it exist, make it good".
Keep on coping
>Nobody wants to hear how you think slapping the words "GI" and "PBR" next to your engine makes it this impossible to architect thing
I know. That is exactly how you made it sound like with your "it just becomes an excuse to be lazy and write bad code" take. Of course, you will dodge all that and pin it on me and I don't mind so go ahead and cope.

>>106440381
Is it wise to make a game using C and not C++. I enjoy the former's simplicity and don't enjoy how bloaty the latter is.

>>106440381
>op pic
kino

>>106443070
Jonathan Blow got absolutely BTFO by not one, but two indie games made in fucking game maker (Hotline Miami and Undertale).

>>106443070
Braid only made $6 million. For an indie success, that's mild these days.

If John Blowjob was working on some advanced 3d PBR shit or whatever that’d be fine but he’s literally making top down indie slop. I don’t know why he’s so autistic. Devving to nodev is insane.

>>106443765
>Is it wise
that's like asking is it wiser to take a bus or a taxi to reach your destination.
A definite answer can't be given. Just like how you'll need to experience traveling by a bus and by taxi at least once to figure out what you feel most comfortable with for reaching your destination(you sometimes might feel like taking a bus and a taxi the other times, depending on your destination and what travel experience you'd prefer to reach there), you'll need to have a serious experience with both of those languages to actually figure out what is the best tool out of those two for the job you are about to take over.
Keeping if it is wise or not aside, if you enjoy C then maybe just stick to C++11 and don't go any modern than that. You'll get to enjoy the best of both worlds. C with virtual method tables is a real comfy and every version after C++11 gained exponential complexity along with huge compile times, making those modern version not so worth it.

File: 1744814532722.png (991 KB, 1439x1570)

991 KB PNG

>>106440381
Is game dev hard or is it merely time consuming?

>>106444031
it is time consuming because it is vast.
is it hard?
not really.
Its just like developing a new skill. Be it driving, diving, cooking or game dev, it might be hard at first but once you get the gist of how you should do things and get comfortable with what you are doing, it won't feel hard at all.

>>106443810
And both of those got BTFO by Lethal Company, hope you're using LC as your blueprint then.

>>106441352
if your engine is composed correctly it shouldn't matter if you're rewriting entire functions or even classes... post your project, anon

>>106444031
It's really fun too.
BASIC was the best game on my MSX.

File: ZuluEfo.jpg (71 KB, 700x483)

71 KB JPG

>>106444137
>if your engine is composed correctly it shouldn't matter
exactly. This reminds me of semantic compression by Mr. Muratori
https://caseymuratori.com/blog_0015
sometimes, the language of choice also makes it an absolute nightmare to make any changes later on, especially when clean code shit like abstraction and inheritance are heavily practiced.

>>106444031
Depends

>>106442358
nvidia have had this since 2015
https://registry.khronos.org/OpenGL/extensions/NV/NV_command_list.txt

just imagine what the future would be like without crappy amdjeet hardware.

>>106444031
Time consuming. But if you're doing something hard then it can be hard.

>>106440381
>>106440754
>make it "exist first"
>now I'm paralyzed because anything that I would have to touch would break it and require major rewrites

>>106444449
Don't worry bro instead of doing it right the first time just half ass it until it works then come back to it in a year when you remember absolutely fuck all about the topic and what you did, while also having 100k lines of code that depend on it and will cause domino effects.

It's a problem for future you anyway.

>>106444379
4 cores, 2 threads, IGPU a bit better, rinse and repeat

>>106440381
Both of those look like shit though?

>>106444560
That's fine. Even shit games will sell

>>106440381
But those both look bad.

>>106444611
>look bad
That's fine. Graphics aren't everything.

>>106444478
Arm processors would have become mainstream far faster because companies would have been trying to get out from Intel's cartel. Arm supposedly has 10-20% of the cloud provider marketshare already. Makes sense considering the big 3 have been making their own Arm server SoCs to get out from under Intel and AMD, and Nvidia's superchips are all Arm based now. Now imagine if intel was price gouging without AMD to act as a release valve. x86 would be dead.

>>106444856
Was just alluding to intel before the ryzen.
As soon there's no one else trying, stagnation is immediate.

File: ygg-1756661709.webm (672 KB, 1920x1200)

672 KB WEBM

Progress:
- Did some interface work recently, mostly bank, stats/bonuses. And how I prioritize some inputs, eg escape will close open interface(s) with some preference
- Fixed multi-part animations so the travel and hit animation frames get proper frame duration times from the definition on each spell phase
Also I added the params to ffmpeg for webkit bros

I really want to get into graphics programming, I want to do this kind of programming. I want to get low level and avoid the webdev jew.
Except, I do have a dayjob, although unrelated to programming. Fortunately, although some days we have a lot of work, I also have some days with a lot of free time and my boss (my dad) usually lets me just be on my computer.
I was thinking on following learnopengl dot com, except apparently it'll be hard from a mac. And I don't want to work exclusively on my desktop back at home.

What workflow do you guys suggest if I want to work both on LInux (or maybe Windows, I guess) in my home and also on my mac? Should I just replace the thing for a thinkpad?
Maybe I should just focus on building a small game with something like raylib or something, for now.

>>106444956
SDL + Open GL
SDL is the ultimate "werks on everything", at a point you can do stuff like dreamcast with it.

>>106444986
Do you still need OpenGL? I thought SDL3 added a lot of GPU support.

Thats it, I'm starting over. Again.

>>106444986
Thanks I'll check it out. I think I actually did some small hello world kind of example with SDL before.
Isn't OpenGL a pain to use in macos though? That was part of my point.

>>106445078
SDL2 already do it with the engine, but he wants specifically to learn OpenGL

>>106445115
If i'm not mistaken, SDL makes OpenGL trivial on OSX as it does with all other platforms.
All the initialization bullshit is handled by the SDL itself.

Anyone know any good game dev IRC channels, specifically people focused on engine dev

File: 1756400770575549.png (43 KB, 370x320)

43 KB PNG

>>106445115
>Isn't OpenGL a pain to use in macos though? That was part of my point.
>>106445133
>If i'm not mistaken, SDL makes OpenGL trivial on OSX

The issue is that apple deprecated OpenGL and doesn't support it anymore. Opengl will still work on mac for now, but it could break in the future and apple will not fix it. They want you to use their dumbfuck API, Metal

>>106445235
Metal is actually nice but you shouldn't support it on general principle of avoiding vendor lock in.

>>106444956
apple doesn't like C++ or opengl.
you might find it easier to develop in windows in a VM like parallels.
stick to unity / godot if you want sanity.
Otherwise if you insist, I would suggest sticking with opengl if you want shaders (for 3d games), simply because of webgl (if your game is going to be free, your #1 priority should be trying to get as many people playing as possible, the web is easy and portable, but it going to run slower/browser compatibility so having a native copy is nice to have). If you want things to be more simple (for 2d games), I think SDL's built in rendering / raylib is fine.
To get around the opengl depreciation, there is a tool called Angle that runs opengl ontop of Metal, Vulkan, directX, and etc.
But I believe the abstraction could interfere with GL profilers / debuggers like RenderDoc / native tools (if you had a Nvidia / AMD gpu, there are some extra tools like Nsight and some AMD profiling thing with works with OpenGL).
OpenGL has a lot of weeds that won't be covered in learnopengl, and arguably more weeds just to get C++ running on Apple in a portable way (sharing / distributing is nightmarish compared to Windows, linux is also not great but steam can run windows binaries on linux).

>>106444986
Works on everything but Windows (who plays video games on Windows anyway) where you can't even move the window without freezing the program.
>if it was finally fixed in sdl3 I don't give a fuck, kys faggot

Guys, do you know resources where I can learn about building multiplayer games?

>>106445235
If apple ever actually removes ogl, then there will be a project to add a shim layer from gl to metal. You're in the exact same boat today if you use anything besides metal or opengl, because everything else requires a shim layer already.

>>106445384
I never experienced that with SDL2 at least.
I have a few projects i run on linux, windows and all that and i can drag the window around with no issues.

>>106445384
>if it was finally fixed in sdl3
I don't think so.
win32api doesn't let you poll for messages unless you let go of mouse pointer after a window enters the move or resize event. That's how it is designed. I write my apps such that the renderer calls update when windows moves and resizes as well. Another solution is to render on different thread, won't be perfect but will do a very good job.
>>106445430
I just went through unreal engine's source code. Fuck HTTP. RPC FTW

>>106445384
Ah wait, not i did read your complaint correctly.
Yes, game will freeze when dragging windows on windows, but i don't see the use case to keep the game running while dragging the window, unless you're making some very specific software.

>>106445481
1. you're making any other software than a game
2. you're game has lockstep multiplayer
3. you're simply smart enough to realize a program gui program shouldn't pause when you click the title bar

>>106445760
>1. you're making any other software than a game
The only case where this is a problem is if the software has a processing portion like it renders pictures or process data etc.. but you should be running on another thread
>2. you're game has lockstep multiplayer
You should be running the multiplayer portion in another thread, as the OS will fuck with you either way
>3. you're simply smart enough to realize a program gui program shouldn't pause when you click the title bar
There are many cases where this is desirable, like single player games

Of course, that is a windows problem mostly.

>>106445235
I really am starting to lean towards replacing my laptop

>>106445356
Thanks for the detailed explanation, anon.

>>106445115
You can learn OpenGL on Mac. It's stuck at version 4.1 basically. So most features in tutorials will be there. You can go through the entire LearnOpenGL tutorial.

The feature you want that's unavailable is compute shaders. At that point you'll have to:

- use some kind of API translation layer (MGL, Zink)
- switch to sdlgpu or bgfx (wrappers around lower level apis)
- use something like webgpu which is another wrapper around lower level apis
Just learn the lower level api

Honestly learning metal if you're stuck on Mac is not the worst idea. You're just writing toy applications to learn graphics right now you don't have to think about longevity or supporting every platform

Someone told me you're not supposed to tie your physics to the framerate so what do I tie it to?

>>106440725
>she/her
Are dudes still pretending to be women to get indie dev brownie points

File: 1331320450214.gif (616 KB, 159x137)

616 KB GIF

>Just make it exist first
Then realize you essentially vibe coded everything and have to redo literally everything from scratch if you want to go forward in a productive manner?
Bad advice.
>no, just do it properly from the start!
So, make it good from the start rather than making it exist first?

>>106445955
Time

>>106446056
So I calculate how much time has elapsed since the last frame and advance the physics but that amount?

>>106446071
Yes, it's called delta time.
Alternatively, you can use a timer callback to run your physics in a fixed timestep independent from the video.
It is more stable than delta stuff, but you limit the physics frame rate, and may have to use dead reckoning to smooth out the output to the video.

>>106446071
You count up time and your physics engine "consumes" fixed time steps by subtracting from the available time, each time there is enough time available.

>>106446098
>>106446116
Thanks. I'm not entirely new to programming (I do some web stuff) but I have very little idea of how to program games. I'm trying to get into it, though.

>>106440774
>engine dev, aka: how to make a small 4 months project last 5 years
this advice is on the same level of the "dream game" slop

https://gafferongames.com/post/fix_your_timestep/

Mandatory reading. Technically it introduces a frame of delay but it's imperceptible at > 60 fps. And it allows you to update physics at a slower rate and just interpolate. Which will make it easier to get high fps. This is the only same way to handle delta time in games in a way that supports every framerate. Never lock the fps like fucking Konami or other "AAA" games

File: combat.webm (1.12 MB, 640x424)

1.12 MB WEBM

>>106446164
Depends on what you consider "enginedev".
If you consider downloading SDL2, box2D, lz and 30 other libraries, and just mushing em together and making the engine be able to read TilED data, it's not much slower than just using godot or something, and the game ends up a bit smaller and faster.

However, what i'm personally doing is pretty "engine dev slop", given the only code that is not mine running is the diskROM.

>>106446190
That is a step above of what i knew in this

>>106446190
no, 16.7 ms of latency is not imperceptible. also, judder feels and looks like absolute shit, and interpolation (to mask judder) feels floaty when applied to the camera.
variable timestep is best for the player. don't bother whining about nondeterminism if you're already using a nondeterministic physics lib.

>>106446369
You can disable interpolation for things like mouse movement of a first person cam, but keep it on for everything else. I'm all ears if you have a solution that works for 30fps to 240fps without a big delay or judder.

>>106446410
Oh and is specifically deterministic. My game has physics in it and I don't want weird shit game speed specific issues cropping up. Running the physics at a lower rate and interpolating has workee great for me

>>106446410
i just told you: variable timestep

>>106445851
>I really am starting to lean towards replacing my laptop
You could try asahi linux dualboot (assuming you have 8gb of ram and enough space / portable SSD).
I am the other anon, and I should warn you that apple is "harder", but windows and linux are still hard, and it really comes down to cmake / whatever (other anons will tell you that it's "soo much easier if you don't use cmake", it's the same level suffering when you get into the weeds of it and try to get things working on all the platforms, if needed).
The reason why unity / godot is so popular is because it works on the web, apple, windows, android, with an NDA + pay for engine license on the switch / consoles, and it's as simple as clicking export, and you still get all the engine dev features, like shaders and drawing raw vertices (but it's harder to wrap your head around it because of all the layers of abstraction).
It's actually a harder mental game to figure out what you CANT do on an off the shelf engine, compared to writing the engine yourself (most people here are bloat/micro-optimization-schizos, they are not wrong that unity / godot devs are lazy but if you could put a fraction of the level of effort engine devs put into a game engine, you would get the same, if not a better game finished, 10x quicker).

>>106446369
I am not using a nondeterministic physics lib.

>>106446508
Cmake is really required if you're doing cross platform engine dev

>>106440381
Odin is slow isn't it.
Yes, it is slow because it doesn't use LLVM.
Sure, but you don't have to be LLVM to be fast? What about GCC?
Yes, but GCC is made by a large team of experienced developers working on it for decades. Odin is made by one, admittedly experienced, developer. But still, he is alone.
What about the features?
You might as well use C# because it is going to be faster than Odin and has more features.

Don't use Odin.

Anyone here using SDL3gpu with metal or d3d12 successfully?

>>106446634
>SDL3
It is not out yet. Don't use that experimental shit.

>>106446655
https://github.com/libsdl-org/SDL/releases/tag/release-3.2.0

Are you stupid? It's stable. I'm just wondering if anyone's run into hard issues with it. For example you can't pick an explicit GPU. Which is fine for most people. But scenarios where someone has multiple discrete gpus might be a problem.

>>106446584
what about its simplicity? What about "having fun"?

>>106440381
Daily reminder to use libresprite/aseprite for drawing game art.
See this tutorial for reference: https://www.youtube.com/watch?v=iQFvjAJ5gIo

>>106446699
>53% complete
stupid tranny, can't you read?

>>106446734
>girl voice
alright im sold

>>106446734
goyware

>>106446190
>>106446369
16.7ms of latency is imperceptible.

16.7ms of latency added on top of the rest is absolutely not imperceptible. 35ms of latency is playable (but not great or even good), 50ms of latency is unplayable, experienced that first hand in that new Robocop game.

>>106446436
Truth nuke. Interpolating in single player games is retarded.

>>106446753
>Tranny
Opinion discarded take it to one of the troll threads

>>106446799
How does 16.7ms randomly become triple that. The "variable time step or die" reeks of contrarianism

>>106447170
Because you don't just have 16ms of latency anon. It's 16ms added on top of everything else.

>>106446799
>>>>>>16.7ms of latency is imperceptible.

>>106447170
there you have it. if you don't mindlessly follow a blogpost that gets linked fifty times a day on reddit and hackernews, you're a contrarian. you can't possibly have a preference considering the drawbacks of each approach.

>>106445430
rs private server resources https://www.rsps.dev/documentation

>>106446436
not anon, but you generally need interpolation if you don't want your fps to be bottlenecked by one part of your code, like physics.
when the jolt physics API says that it's stable at 60hz, that means below 60 steps per second, there will be issues.
JoltPhysics examples calculates the tick like this:
// When running below 55 Hz, do 2 steps instead of 1
numSteps = deltaTime > 1.0 / 55.0 ? 2 : 1;
And in the loop, it checks if the FPS is below 30hz, and it caps it (so it starts going in slow motion).
The physics is happy to run at 200hz if you could handle it (fps is limited by the physics in those examples) since usually high step counts help with stability, and there is no point in implementing physics interpolation if your game can easily handle 200hz physics, and your rendering / other bottleneck reaches a maximum of 120hz.
But if you can't, and your physics takes 100x more time that your rendering, you should interpolate it (if you want an optimal experience at a high hz / futureproof it). And physics interpolation should also help with fps stability (since fps is not tied to the step speed, instead it's your draw calls / etc).
https://jrouwe.github.io/JoltPhysics.js/

>>106446508
I avoided Asahi Linux for a while. But fuck it, I just installed it. I just want Emacs that works flawlessly (it's slowish on macos) and being able to study, for example, OpenGL in the same way on both machines. I'll try this for a while, if I don't get used to it, I'll switch to Windows or follow some of the other recommendations of the other anons.
Thanks again.

>>106447188
16.6ms includes frame render time.

File: img_68b3a0e1baaed0.93159619.jpg (25 KB, 320x213)

25 KB JPG

>>106445975
its possible
>>106446164
>how to make a small 4 months project last 5 years
yes. That's how it becomes more addicting than drugs. Game engien dev is bad for health.
>>106446584
>Odin is slow isn't it.
>You might as well use C# because it is going to be faster than Odin and has more features.
if you are talking after seeing some benchmarks on the internet then you need to take a closer look. The Odin code used to test was shit(maybe intentional). It wouldn't make sense why Odin outperformed c# by a huge margin in a few test cases and c# outperformed Odin in other test cases until you take a look at the code. The guy who wrote Odin code did a very poor job.
>Yes, it is slow because it doesn't use LLVM.
Odin uses and always will use LLVM. It might use anything else in the future but it'll always use LLVM
>you don't have to be LLVM to be fast? What about GCC?
true.
What you have to be is a heavily funded corporation. There is a reason why Zig is struggling to not have to be LLVM and Go is chilling not relying on LLVM.
>What about the features?
what about it?
Odin got plenty of them. Its compiler is just over a GB when compiled from source, unlike C# that takes a lot of disk space and doesn't come with "batteries included" library packages that makes you feel like you have no need for a package manager, all of which are included within just over 1 GB source code, by the way.
>Don't use Odin.
and?
You don't. Have fun with C#.
Manual memory management and high performance is not for everyone, especially for those who decide from looking at benchmarks written in shittier code.
>>106446734
nah. They are good but only for raster shit.
Imma spin up my own vector graphics editor and a vector graphics renderer for my game. With compute shaders, there won't be a performance issue at all.

>>106447629
>vector graphics editor
I know you said something about svg graphics before, but now I'm curious. Are you making something in a similar vein to adobe flash? Sounds pretty awesome.

>>106447631
>>106444947
Cool spells. These animations are awesome to watch.

>>106447332
the 16.7ms we were talking about is the minimum bound on how outdated a physics frame can be in an interpolated fixed-timestep system

>>106447705
>in a similar vein to adobe flash?
kind of. But these is no virtual machine here. Apart from triangulation, all vector geometry is generated by compute shader so it won't be slow.
Yes, it is the SVG graphics thing I mentioned before. The problem with vector graphics is that its always sharp af but some or most of the time, art style needs to be smooth and non-uniform.
The only solution I have for creating soulful art with vector graphics that doesn't pixelate upon zoom is to create a vector graphic painter as well that is capable of replicating raster drawing app's brush strokes and storing those strokes as vector data instead of updating a bunch pixels on the frame buffer. This is gonna make operations like masking multiple layers very annoying to implement. Gotta see.

>>106445997
Do thing properly, but don't strive for perfection. Realize that your game will be unpolished and bad at first and set that as your goal

File: img_68b3da4638cc85.22892302.jpg (53 KB, 767x784)

53 KB JPG

>>106445997
>So, make it good from the start rather than making it exist first?
how can you make it good from the start when you have no idea what "good" is?
That is why you make it exist first and understand it thoroughly so that you can always improvise upon it or recreate a better version.
Remember saar, "premature optimization is the root of all evil!"

>>106447878
Interesting. I once thought about creating an image editor that displayed the image using a signed distance field shader. With the power of SDFs, you'd be able to create images that wouldn't pixelate (too badly) upon zooming in. Making an image editor is awesome anyway, good luck with that. Are you a good artist?

>>106447714
Thanks anon. Should be more fun ones soon, I want to do rock and sand spells that also travel

>>106444031
Yes it's hard, it's one of the hardest things you can do, anyone who tells you otherwise is a moron

>>106448066
Cool, these are prolly the most impressive part of your game right now.

https://gameprogrammingpatterns.com/game-loop.html

Another time step article. A fast time step of like 5-10ms is good.

>>106448336
Your time step is the frame rate the monitor is running at, you don't get to choose

>>106448361
There are VRR monitors anon. Realistically you can assume your display supports at least 60hz. The only time I've seen anything less than is using shitty cables on a 4k monitor

>>106448411
and that means your timestep is 16.66ms

>>106448245
I'm short on the gameplay mechanics just yet, but I'm about to start printing those soon! Luckily that effort pales in comparison to everything done to get here

>>106448428
you can pick whatever update rate you want and interpolate, not sure why you keep saying this. For example: Console games can run at 30fps or 60fps. TVs are usually 60hz minimum. Would you say a console game running at 30fps connected to a 60hz has a 16.6ms timestep? no because that's fucking stupid

>>106448466
Running your update multiple times a frame is wasteful

>>106448479
Anon read the article. You're not updating multiple times per frame. In the "Fixed update time step, variable rendering" scenario. The idea is that you update the state of your world every N ms. You still produce 60 frames per second (or 90, 120, 144) etc depending on the refresh rate. But the renderer is simply recording a snapshot between the frames. The higher the refresh rate, the more snapshots between frames, and the smoother motion will appear. Lag because you're rendering inbetween frames is unnoticeable if this technique is implemented correctly

>>106448527
that's what I mean by updating multiple times a frame
For every frame you render you update your game state several times
That's wasteful, ideally you should update things once per rendered frame

>>106448548
You can add an option in the settings to lock the framerate but keep this system. So people with high refresh rate monitors can get max use out of them, but people on mobile or battery can cap if they want. Rendering multiple times per update is required for high refresh.

>>106448570
That has nothing to do with what I'm saying

The ideal loop is update > render > update > render > update > render
If it's update > update > update >render > updare > update > update > render you're being wasteful

I hate saying this but, more timesteps per frame makes the physics engine more precise, because you're effectively running everything slower and have less precision errors and wobbly systems and all that.
I hate it because it quickly gets into the "JUST ADD MORE TIMESTEPS BRO" logic, instead of actually solving the problems in a less dumbass fashion.

>>106448599
It does fix your timestep problems yes, but it's inefficient, there are better ways to do things especially if you're making your own physics system

>>106448613
Yep, but if the system can handle it, running at 120 FPS or something, it's just less shit to fix.

>>106448019
>image using a signed distance field shader
I remember seeing something similar at https://www.youtube.com/watch?v=BkOsE63bGuA
by BYP and SkyTrias called SDF Atlas. You can skip right to it with timestamp, its the first entry. Though such a thing has its limitations, its always a more intuitive alternative than any 2D procedural painting app out there.
there are some relevant work in the following year https://handmade.network/jam/2023
Shapeup by Danile Hooper. There is also a relevant lux editor, its not SDF based but its cool.
>Are you a good artist?
no.
I tried art seriously for 6 months. I improved but got nowhere never good and naturally stopped practicing as I was planning to learn music as well. Maybe I'll pick it up again and continue seriously so that I can git gud.
>>106448245
I second this. Shit looks very good.

>>106448019
>>106448843
more about SDF atlas : https://handmade.network/p/274/sdf-atlas/

>>106448583
>If it's update > update > update >render > updare > update > update > render you're being wasteful
Not if you want stable physics.

>>106448967
There's better ways to do stable physics

>>106448995
Such as?

>>106449010
Depends on what you need

>>106448967
Players really don't care about how accurate the physics or simulation is behind the scenes. Do not waste your efforts. If it works, it's enough.

>>106449036
Players definitely care if your physics are unstable.
And what happens if you get a laggy frame for whatever reason (could be shit out of your control like an OS or driver thing)? You're going to step your physics with a delta of a second? Anything that's moving is going to disappear.

>>106448843
This is great. Very interesting.

>>106449058
The thing with physics is there's physics that are relevant to gameplay which benefits from being stable, but also isn't usually particularly complex or realistic
And then there's physics used for graphical effect, tumbling bodies and debris in explosions, which is more realistic but doesn't need to be stable

File: Screenshot 2025-08-31 225138.png (1.15 MB, 1060x619)

1.15 MB PNG

Making my first foliage system has been fun
literally just used leaves brush in krita, and a shader to have have eyecandy transparency + vertex displacement for wind

>>106440381
Just wait for ai. It will read your mind later.

>>106449757
Will it be able to correctly answer my personal question "Am I gay?" after reading my mind?

>>106448583
that's a 2D game loop
most 3D games have a frontend/backend for graphics (graphics command assembly on the frontend, graphics command execution on the backend), and the physics should be on it's own thread if the frontend takes up a lot of time.
physics (locations) -> read by frontend (interpolate between old and new state) -> execute by backend
This adds latency, but it all depends on the delicate balance of minimizing bottlenecks.
So you might be 2 extra frames behind, the physics (only 1 extra frame for camera motion) but if you could reduce your frame time in half, that could be a minor latency hit, in exchange for 2x more FPS, but of course at 30->60hz, 2 extra frames would feel like sludge, and at 200->400hz, it probably feels good, but 400hz displays have no become mainstream yet.

>>106449863
That's called pipelining, and it really doesn't have anything to do with 2D / 3D or graphics frontends and backends

>>106447629
>ts compiler is just over a GB when compiled from source, unlike C# that takes a lot of disk space
dotnet sdk is ~400MB...

>>106450932
I see.
how large will the directory be when you build .net runtime, including the all the third party dependencies along with workloads, all from source in that directory?
Turns out, all that for Odin is less than 550 MB. A little over 1 GB on my disk space was due to .git metadata I failed to ignore.
The actual source code of the language itself is less than 35 MB. Rest is LLVM and vendor packages. And if the vendor packages that are unrelated to the development of language are ignored, it comes close to 350MB(on linux).
This size of 550 MB is inclusive of the source code, all the dependencies and several third libraries and the final build files.

>>106449740
sovlful

DX11 chads, I need some help:
A separate instance buffer for every property? or a single instance buffer for a fat struct that contains all the properties?

>>106451774
you typically have a per instance struct, and you upload an array of such struct into buffer every frame. that's just easier. there is no reason to pute every attribute into separate buffer.

>>106444031
One of the most retarded thing you can do. A gigantic waste of time, it doesn't make any money, socially you're seen as the autist who didn't mature enough to leave his gaymes. And that if you actually *do* something. Just look at the same procrastinating schizos here trying to get some parasocial juice instead of doing anything worthwhile.

>>106441352
Traditional painting has plenty of mistakes, you just don't see them because you start with line work and then fill in the details layer by layer... It is analogous to game engine development yes but you're misunderstanding the process of art itself... Deeply concerning, anon.

>>106451997
I, too, love going back to fix my underdrawing after I've given it the underpainting pass.

File: file.png (379 KB, 1825x909)

379 KB PNG

Been making a game where visibility is linked to audio. Each positional audio node has an intensity value calculated in real-time which is sent directly into the shader.

>>106446369
>>106446410
AHHHH! I wasn't sure if I was insane or something; my game uses interpolation and feels very subtly shitty when jumping and turning... and I did change the camera to be directly controlled. Your camera motion makes a circle, but your body's motion makes a polygon.

Maybe a bit of simple calculus could fix it, or double-interpolating a faked-up variable-timestep kinematic. I definitely don't want to switch to variable timestep.

File: img_68b3d62a4a2127.06039532.jpg (26 KB, 581x536)

26 KB JPG

>>106452030
So apart of calculating lighting with normals, an additional position parameter(push constant or uniform buffer) needs to be introduced as well and that's it. That's a very neat way of implementing that.
Noice!

>>106444449
rewriting means you have something to compare to, or to revert to, along with experience of any encountered issues to get it working at all
when writing "perfectly" from the beginning you have to just dream up a solution with no flaws (you'll most likely end up not implementing anything and just fiddle with non-issues without getting anywhere)

>>106452058
Thanks. Yes exactly, and the colour is keyed to sound frequency (another uniform).

>>106444449
There are tiers of making it "exist first". And you can't skip any tier.
1. Make the outcome exist first
2. Make different subsystem exist first
3. Isolate a single system, make it good and the other subsystem will allow you to test the current one. If you see a janky coupling now is the time to fix them.
4. Isolate the next subsystem, make it good and use the other to test it.

You should always have a working game at every major "make it good" pass.

>>106452343
>You should always have a working game at every major "make it good" pass.
If you're writing a game from scratch there's gonna be a lot of shit to do before you have a working game

>>106452362
>there's gonna be a lot of shit before you have a working game
And the important point is to not waste time on the boiler code before you have your game running. Personal example: I perform 0 error checking in the platform code, until I have my entire game running.
Same phenomenon happens inside the game:
I don't polish different engine components until the actual gameplay code is running. When I am happy with the gameplay then I start massaging the engine components. Stuff like DirectX, shaders, etc is the last thing to become "good".

>>106452508
I don't think you've made a game from scratch because it doesn't work out like that in reality, it's like building a house with a foundation made of cardboard

>>106443198
Escape from Tarkov.

That is all.

>>106452532
>foundation made of cardboard
And you replace that with just enough concrete to allow more progression on the actual house. And building software != house. You can't iterate on a house as you build it, you plan the entire thing upfront and then build the whole thing. Software is dynamic, video games are doubly dynamic the only shit you can plan upfront is the stuff you have already done before which is fine. I know what I want my logging subsystem to look like and I can build the "good" version upfront. But how would you know what's a good logging system if you haven't build one before?
You build a placeholder logging system that just dumps everything into a single file. And then develop your game, when you require more classification you add just enough to that logging system to match the current use case and move on, repeat.

>>106452557
>Escape from Tarkov.
true.
The devs had proprietary license from Unity corp that they took full advantage of for creating their awesome procedural animations.
Its not a custom engine but even then updating unity version was a huge nightmare to the studio.
Tech debt will be a serious issue only if the wrong tool is chosen for the job or if the people available for the job are not proficient enough to get the job done with the right tool.
In other words, the fate is already decided even before the actual work gets started. We just need a good eye to spot the troubles early on and adapt ASAP to minimize the damage but there is no crystal ball functional enough to help with that.

>>106452631
You can't replace the foundation without rebuilding what's on top of it, that's the point of the analogy
If you don't have enough experience to know what's required of your game engine you're just gonna end up restarting the project until you do, the ship of theseus approach won't work

>>106452657
>You can't replace the foundation without rebuilding what's on top of it
I don't have time to do a full write up.

>>106452713
No matter what you'd write you'd still be wrong, you clearly haven't made a game or you'd know that

>>106449740
Cool, post a webm next time

File: cool.webm (1.59 MB, 800x600)

1.59 MB WEBM

>>106448843
I tried bringing back this old idea into my current passion project, a texture editor. Here, I simply plastered an SDF shader on it. This is actually really interesting, but I don't know how feasible it will be since drawing sprites like this is not fast.

Here's a short description how it works:
The textures in my game store grayscale images in the R, G, B and A channels of the png file individually. This allows a single image to have act as if it had 4 layers (more if you divide the image into compartments). These grayscale images are blended inside the shader. This should be fast but the blending process is not very fast, but it's very convenient for me. The cool thing about this is that the grayscale images can change their colors in real time, so it basically acts like a NES-era sprite palette.

Maybe I can make that old ambition work somehow.

wicked engine looks like good autism

Please excuse the typos, I'm a bit busy with some other things right now.

File: img_68b3bd56d32827.09395748.jpg (125 KB, 530x809)

125 KB JPG

>>106453245
>but I don't know how feasible it will be since drawing sprites like this is not fast
I had the same though about rendering vector graphics for a 2D game instead of relying on raster textures.
Relying on SDF felt like a very convenient solution. In fact, I'm using signed distance to render fonts accurately over a quad directly from the contour data, not from a texture atlas and I'm very happy with it but it really is not as performant as rendering text from an already generated texture atlas so I restricted this approach to retained mode UI only.
The issue with SDF is that there is no standardized file format to share SDF work from one software to another. This is very frustrating and also the primary reason why I chose to rely on SVG format. By having vector brush strokes, linear and radial gradient coloring along with masking features as per SVG specs, there is a huge room for interoperability. With the help of compute shaders, rendering the vector shapes won't be an issue at all so it seemed like a more flexible and practical approach that offers good performance and quality
I like how you are layering multiple channels and generating an SDF version of the raster image. All the generated image are so full of soul.
>but I don't know how feasible it will be since drawing sprites like this is not fast
me neither but after looking at https://www.youtube.com/watch?v=s5NGeUV2EyU I can't help but believe that SDF are very capable and its the draw calls that'll become the bottleneck. Since there is no depth calculations, maybe merging all R, G, B, A channels into one layer might give more performance during the game play and it might be good enough for your game.
I'm still unsure on what primitives the vector editor should be using(currently its just four of them. Circle, rect, quadratic & cubic bezier cuvers and the rest of the shapes are just variations of them, need to test if those four are enough) so it'll take a few more days before I post my progress

>>106453554
>a few more days before I post my progress
Cool, I'm eager to see how it looks. Good to see that someone else shares the pains of trying to make scaled 2D images look good.

>>106453554
>I'm using signed distance to render fonts accurately over a quad directly from the contour data, not from a texture atlas
That's nifty, I just copied the atlas method from the internet for fonts. Unfortunately, as a general rule, unless you're going to take advantage of it, you should always use static textures instead of real-time.

>>106446240
I remember seeing this in the /v/ threads. It looks really smooth.

>>106453245
I had similar idea in the past and I prefer to import most ui elements in gray scale (or usually white) so I can have full control on the exact colors.

I assume you can go crazy with gradient mapping to get more colors per layer at the cost of more careful shading on the midtones

But what is this program you are using?

for anyone using sdl3_gpu: read SDL_CreateGPUShader#remarks 30 times. You have to use TEXCOORD0-N for vertex attributes in order to keep the API crossplatform. Very weird but its cool now that I got it working.

>>106453896
The smoothness is one of the reasons why i'm doing it.
MSX2/2+ can do some pretty impressive 60 FPS scrolls, but barely any game do it on the platform.
There's this psycho world that does it, and 2 other games, but nothing that is even MSX2 exclusive.

File: 2025-09-01 13-09-09.webm (840 KB, 800x600)

840 KB WEBM

>>106453999
I do that for non-SDF fonts too. One of the main reasons I went into engine devving was because SFML didn't even have a color parameter for texture drawing.

The program is a part of the engine. I made a simple window system and then kept adding features to it. I'll warn you now, the code underneath is pretty terrible, but it works. Remember that old post about a fatal error due to too many nested loops? That was me.

What's your favorite realtime gi solution ? For me it's cascade grids and virtual point lights. And forward+ to render. I think I'm basically doing ddgi

>>106454189
>nested loops
*nested blocks

>>106449058
for 1..n {update(dt/n)}

now think about what happens when your fixed-timestep loop suffers a frame hitch. you're probably going to subdivide the physics update as above.

File: spellcaster_pepe.png (3.2 MB, 1024x1536)

3.2 MB PNG

Has anyone here ever released a game?

>>106455083
I did

>>106455083
I've released a few one-level demos. No money.

How the hell do you pass per draw data with indirectdraw

>>106440381
what's the consensus here on Godot. I'm a nocode tranny btw, I only know some python data analysis tool but want to fuck around with game dev on my spare time

>>106455538
fine for noobs, most people are going to tell you don't bother and just do GLFW / SDL3. If you're new its not a terrible choice there are a wealth of tutorials. Or just use Unity.

>>106455372
What are you confused about. Typically with indirect draw you're generating the parameters for the draw pass in a compute shader. So you can just write the per draw data you need in an adjacent buffer and index it inside the indirectdraw call

There's no good pixel fonts that support every modern language huh
The only thing i found is Silver and it's trash that not only has different height, spacing and when switching cyrillic, latin, kanji etc but it even fucks up symbols in the same goddamn alphabet. And the dev unironically wants licensing money for this.
Guess i'll just go with noto sans.

File: Unifont_sample_v13.0.06.png (402 KB, 496x207)

402 KB PNG

>>106455724
Have you heard about our lord and savior GNU Unifont?
https://unifoundry.com/unifont/index.html

File: 1577595577140.jpg (18 KB, 313x286)

18 KB JPG

>>106455083
a-a game?

>>106455748
That actually looks pretty great, thanks.

>>106455083
I released two self-contained demos, about an hour's playtime apiece. It was good for feedback and learning about the process. Someone even donated $3 to one of my games kek

>>106455586
thanks

float scale;
glfwGetWindowContentScale(window, &scale, nullptr);
ImGui::GetStyle().FontScaleDpi = scale;
ImGui::GetStyle().ScaleAllSizes(scale);

Is this what I'm supposed to be doing.

Okay I’m getting the hang of indirect draw. It’s a little awkward because I’ve completely replaced vertex buffers with vertex pulling. I still have to figure out how to batch everything given my current implementation. With sponza it’s easy because that’s one mesh and everything is a primitive. For the chess scene everything is its own mesh with one primitive so indirect draw basically becomes a regular indexed draw. This can be changed with a mega index buffer but that’s something I don’t think I’m ready to do you. Although I guess indirect draw is still useful in the context of compute culling. I’ll have to research.

File: vin_diesel_drinker.webm (3.46 MB, 1280x720)

3.46 MB WEBM

>>106440381
Dudes, how hard would it be to make a turn based strategy MMO? I have 8 years of programming experience, but null experience as a game dev. What engine do you recommend for that? Can AI generate consistent sprite sheets? (i just want these as placeholders so i can focus on the coding). I dont want to make the next wow, i just want to canalize my autism in a constructive way. Thanks in advanced.

>>106457442
>[...] MMO [...]
Very difficult.

>>106455083
I released some free games on Steam that I made in college as student projects, nothing independently yet though

>>106455083
yeah, its no big deal.
>>106455538
>I only know some python data analysis tool
that's enough to make GDScript easy to learn. Godot is a very good choice for you.
>>106457442
>turn based strategy MMO
8 years programming what?
unless its low level system programming that includes concurrency/parallelism and socket programming, it won't be of much help.
the term "MMO" makes it almost impossible to make because its not about just creating some MMO shit, it costs a lot to setup and maintain an MMO service, which is why only AAA studios usually take on such a genres.

File: output_trimmed.webm (2.83 MB, 1744x944)

2.83 MB WEBM

>>106452888
Ok

How do you guys render the map?
Only method I've been doing is tile-based, where I have a 2D array and just loop through and render each tile for every frame.
I'm sure there are far better ways to do this, but I've never ran into any trouble with speed.

>>106458011
Very good.

>>106458015
Drawing a tilemap is not very heavy at all.
But if it's always the same, you might check if you have render to texture somewhere, and render to a texture, then do dirty texture updates when the map change.

>>106458110
pointless premature optimization that would be slower than just redrawing the tilemap

>>106458110
I thought of that, but it felt like way too much work.
On a side note: I can't think of 2D games as anything BUT tile-based. It just seems like the only good way to represent maps in an orderly fashion.
I suppose you can have it be represented as a list of objects (trees, ground, houses, etc) as a graphic and pixel coordinates, but that just sounds messy.

>>106458306
Tiles constrain you to a grid, use a space partition if you want the freedom to put objects anywhere

a video game where your gameplay is being live streamed and anybody can just fuck with you. wow, much genius?!?!?

>>106458349
Why not both?

File: br.jpg (40 KB, 554x554)

40 KB JPG

>>106458363
Old but Gold.

>>106458241
>>106458306
It's probably too much work, and the way it is is fine.

File: aa.png (105 KB, 2345x727)

105 KB PNG

trying to implement cpu backface culling and failing miserably, will try again tommorow

>>106459007
>trying to implement cpu backface culling
why

>>106458015
Use a vertex and fragment shader. You draw a quad for each tile, the fragment shader looks up the appropriate texture for this tile type and draws it. This will run at 60 fps even on a eee pc from 2007

>>106459014
for fun

>>106442358
With indirect drawing you can make a list of indexed draws to send to a compute shader to undergo whatever (ie frustum culling) and the compute shader will send the modified list back to the cpu to be executed. DGC extends this functionality beyond an indexed draw. You can do other commands, vertex and index buffer bindings, pipeline* bindings, push constants. Additionally you don’t need to send the list back to the CPU, the shader can execute the commands on its own.

>>106440381
gonna keep shilling that retarded woman "meme" here?

File: img_68af71f4412aa0.79867030.jpg (82 KB, 279x497)

82 KB JPG

>>106459434
I am shilling the "meme".
Where its from a woman or if she's retarded is (You)r concern.

>>106458015
Instanced drawing is better suited for tile-based maps, otherwise you oversaturate your call buffer. It's a matter of binding an array buffer, loading your data into the array buffer, and running one drawInstancedArrays. The attribute binding is a bit finnicky to figure out the first time though.
If any more optimization is needed after that (it usually isn't unless your tiles are really small) you can concatenate tiles to reduce the amount of quads.
I'm able to get ~10,000 dynamic sprites running in WebGL with instanced rendering before the overdraw kills the integrated GPU on my laptop which is pretty good all things considered.

>>106459597
If the perspective is always the same you can also pre-render large chunks into a texture and then just position/draw those, but like I said it's usually negligible when the throughput is as good as it is these days.

>>106459597
It literally doesn't matter, you can draw 10,000 sprites no matter what technique you use

>>106459645
>It literally doesn't matter
only if all 10,000 sprite are literally the same thing, as in all of them are using the same texture but that is almost never the case during the game play. When game logic, physics and AI come into the picture, a significantly noticeable lag pops up if you simply draw 10,000 sprites.
There is a reason why techniques like batch rendering, instancing, treating sprites as particles instead and computing them in compute shader and much more exist, each of them with their own pros and cons.

>>106459885
No, you can draw 10,000 sprites all with different textures and different draw calls at 60 FPS easily

>>106459645
For a target like WebGL and phone arch then it can matter. Though I agree with you, for a dedicated GPU on a desktop it probably wont matter any time soon.

>>106460029
I'll just highlight my previous post
>When game logic, physics and AI come into the picture, a significantly noticeable lag pops up if you simply draw 10,000 sprites.

>>106460140
Also not true

>>106460147
>Also not true
you would have mentioned why if that were the case though.
It might not be true for a flappy bird clone but not all games are flappy bird clone slop.

>>106460154
What other explaination is there that you're wrong and you don't understand how cheap drawing 10,000 sprites is? You can do it on 20 year old hardware no problem

>>106460160
its not my fault if you are too retarded to read past the first couple of words and ignore to notice or perceive the words "game play", "physics" and "AI" completely.
Games like Terraria wouldn't have succumbed to tiled rendering if what you said is actually the case.
>You can do it on 20 year old hardware no problem
for a flappy bird clone? yes

>>106460191
Yeah I read what you said and it's still wrong, real games I was making 20 years ago were pushing 10,000 sprites with all the particle effects on screen

>>106460202
>real games
yeah, must have been real slop games. No wonder it worker out well for you saar

>>106460214
Quality of the game doesn't have anything to do with it

>>106460221
>Quality of the game doesn't have anything to do with it
ah, no wonder you kept on prattling that I am wrong when it was you who was completely ignorant about all of the stuff that make a video game out of a simulation and pushed your opinion that since it worked for your simulation in the past, it'll work for any kind of video game.
Truly ironic.

>>106460239
Can you repost this in English

>>106460239
>>106460245
why? its not like you can do anything other than pick up on my grammar at this point. Anyway...
>ignorant about all of the stuff that make a video game
ignorant about all of the stuff that goes into making a video game

>>106460257
I know everything that goes into making a video game and I'm telling you when you put all that stuff in a game you can still easily draw 10,000 sprites (or even more)

>>106460264
wait?
are you the windows xp guy trying to get back at me?
whatever, better luck next time.
Doesn't matter what you say, facts remain that when game play logic and other things are not simple, rendering needs to get efficient for good performance. What you are saying does not hold for a fairly complex game play that does lighting and depth calculations.
Yes, in case you didn't know, even pixel art games use normals maps these days and drawing 10,000 sprites with several drawcalls for such an art style will cause a drop in FPS.
I won't buy your BS that has been full of ignorance since the start.

>>106460294
>facts remain
Bro this is me who has made a game and you who has not repeating what you think is common wisdom like ChatGPT
I have no idea why you're talking about normal maps, you don't need to do multiple passes for normal maps either, does adding more misinformation to your position make it stronger?

>>106460308
>I have no idea why you're talking about normal maps
exactly the reason why I was calling you ignorant.
A video game is not just simply simulating something and presenting on the screen. Its much more than that. Good lighting, unique art style, detailed environment and characters all do matter not just for defining the quality of the game but for defining the game itself.
For someone who thinks that quality of game is not important and focuses solely on present a texture onto the screen, you wouldn't understand why I'm talking about it.
>does adding more misinformation to your position make it stronger?
what misinformation?
You are the one forcing your ignorant opinion on me with your "sauce: trust me bro!".
I never said old hardware is incapable of drawing 10,000 sprites. I said over and over that its not a practical approach when game play is not dead simple.

>>106457761
>that's enough to make GDScript easy to learn. Godot is a very good choice for you.
thanks for the advice. I think as first step I'll try to pick up pico-8 as I've already got a license and it should be easy to learn and make quick games or prototypes. Maybe when I know more about game dev I'll go bigger with Godot and whatnot

>>106460390
Quality of the game has nothing to do with the performance of the game
Normal mapping has nothing to do with being bottlenecked by drawcalls (normal mapping is done on the GPU, drawcalls are a CPU bottleneck)

>>106460682
thank you for showing your ignorance.
Feels reassuring.

>>106460688
You have not made a game
You have not benchmarked any of the things you're talking about

>>106460698
yeah, sure. For someone who couldn't point out what misinformation they called me out on, you lost your credibility.This ain't new and I know exactly where this will end(at insulting my ethnicity, that is) if I push you further.
Apart form those two, it will help you a lot if you mention a few more thing I didn't do for deeming me as "wrong". You haven't made any point till now other than the "trust me bro, you don't know shit!!" bs since the start so nothing will change anyway.
If you want to make me "wrong", at least make the bait attractive enough for me to willingly me bite it.

>>106460759
you said you can't draw 10,000 sprites while having a decent game running
you can, you just made that up, you've never tested it

>>106461160
>you said you can't draw 10,000 sprites while having a decent game running
that's kind of what I said. As someone who things the quality of the game is not important at all, you lowered the bar for the definition for "decent" and kept crying on me pointlessly lmao.
A decent game in 2025 is not the same as a decent game from 2013 like flappy bird. The standards have changes since the time you tests your bland game with hardly any lighting, vibrance and gameplay. Jon Blow's top down puzzle game is a good example of a decent game of this ear. Even for 2D, when you have dynamic environment and lots of vfs, it doesn't even have to reach 10,000 for the game to lag, even on old hardware. That is actually where you need to rely on several techniques for efficiently rendering.
>you can, you just made that up, you've never tested it
all you've tested is just plain textures on a quad. No wonder you don't see anything wrong. Let's say I made that up. Creators of noita and terraria should have been absolute retards for rendering their game the way they are doing instead of drawing 10,000 and much more sprites without a care about the draw calls count. I've given plenty of examples till now and you've been sticking to your "trust me bro, you are wrong, just admit it" bs, befitting your ignorant self.

>>106461309
I have made an actual game that pushed sprite counts of over 10,000 a long time ago, it's completely possible
You arguments are very confused and don't really have anything to do with the topic

>>106461343
>pushed sprite counts of over 10,000 a long time ago, it's completely possible
when did I ever say its impossible?
It becomes impossible if you make a decent game that is not simple like flappy bird.
>You arguments are very confused and don't really have anything to do with the topic
and that completely gave away what kind of game you actually made, that it was just a bland one.
FYI, particles in VFX and environment in a 2D games are all sprites. Is it still confusing?
All the dynamic lighting around the player and the environment in a 2D game is just a composition of the environment and the light source gradient. still irrelevant?
Maybe if you did any of that, you'd have understood where I'm coming from instead of relating to your past experience that simply displayed sprites on the screen all the time.

>>106461410
Yeah I'm not talking about flappy bird I'm talking about a real game
Dynamic lighting is done on the GPU so that has nothing to do with the amount of draw calls you're issuing which is basically a CPU bottleneck

File: img_68b0b0c6ac4d59.59041089.jpg (22 KB, 720x571)

22 KB JPG

>>106461425
ah, whatever >>106459645 and >>106460029 bs was on about, nvm.
You are gonna seriously suffer with doing anything on 4K resolution with those bs of your.

>>106461450
Resolution also has nothing to do with draw calls
You seriously have no clue what you're talking about, stop fucking embarassing yourself and filling this thread with low quality misinformation

>>106461459
>Resolution also has nothing to do with draw calls
when did I say they did though?
feel free to point it out.
It has to lot of do with causing a significant delay when you attempt to draw over 10k quads.
>You seriously have no clue what you're talking about
you where the one that's showed ignorance with no credibility till now though
>stop fucking embarassing yourself
are you sure its not the other way around?
>filling this thread with low quality misinformation
again, what misinformation? Your statements about your experience on developing a real game are as legit as me stating that you are gay.
It was you that kept of saying irrelevantly that quality of the game, resolution, game logic, AI and physics have nothing to do with draw calls when I was pointing out that they are the factors that would cause a delay when drawing lot of quads mindlessly, as you suggested.

>>106461510
>It has to lot of do with causing a significant delay when you attempt to draw over 10k quads.
No, a higher resolution just means more pixels to draw, 10k quads is fucking nothing, GPUs can handle millions and millions of triangles, the issue is the amount of draw calls
10,000 is something computers are comfortable with, 100,000 draw calls would be too high though

>>106461525
>a higher resolution just means more pixels to draw, 10k quads is fucking nothing
ah, what about your previous post >>106461459 that said "Resolution also has nothing to do with draw calls"
also, why are you stating the obvious, as if you got noting left to pin on me?
Your have been completely neglecting the gameplay aspects of a video game and suggested to draw thousands of quads without anyway and that is only fine if there is hardly any gamplay content present, like games that have bland sprites with no lighting calculations or physics.
Literally what I've been saying since the start.

>>106461578
10,000 draw calls for sprites takes barely any time and leaves plenty of time to run your gameplay code

>>106461594
again, you are completely ignorant about the possibility of the textures being of very high resolution, demanding lighting calculations with normal maps and a few more scenarios you are completely oblivious about.
Let me enlighten you that RPG maker would struggle just to render 10k sprites. With 10k draw calls, it'll probably just crash. Though you might be thinking that its nothing, the overhead of gameplay and language does really play a huge part when it comes to the final game.
I won't respond further if you keep up with this pointless bs with your baseless statements.

>>106461696
All that stuff is done on the GPU so it's not related to the draw call count at all
You cannot just draw sprites in RPG Maker, everything is some sort of game object which has overhead

>>106461767
I'm not the one who said >>106459645, spare me your bs and tell that to yourself.

File: bush.png (178 KB, 582x279)

178 KB PNG

Bugged shader.

>>106459429
Yeah but why would you do that

>>106462709
Generally the more you do on the GPU the better. There is a latency penalty and synchronization penalty that occurs when you do a GPU to CPU to GPU roundtrip

>>106457442
>turn based strategy MMO
so something like Dofus?

File: 1726671475136731.jpg (66 KB, 736x540)

66 KB JPG

>>106462777

>>106462839
Yeah, i sincerely don't think there are enough turn based strategical MMOs out there.

>>106458011
Sick

>>106462709
The GPU is good at that task, and the only purpose of performing that task is to speed later GPU tasks up.
Overall it’ll be the same or faster, whilst giving your more room to do things on the CPU.

>>106462896
You already got a concrete example in this thread. For example

- compute shader runs and culls every object in the game
- for each object you record how many triangles are visible vs not visible into a buffer
- you also use atomicints to generate the indirect draw buffer
- then when you render instead of the CPU having to read back the culling buffer in order to generate the next command, it's already encoded in a buffer the GPU can access. So you just call render with the indirect buffer bound

Google frustum culling GPU indirect draw for a basic tutorial.

>>106462969
doing per-triangle culling is a waste of time, cull per object

20 fov is more efficient than 90 fov with object culling. hope this helps.

yeah I'll just use unity

>>106462969
indirect drawing by itself is not very useful, without bindless buffers and textures.
you can hack it together by storing all vertices in the same buffers and using texture arrays, but it's not scalable.

>>106463035
and using bindless introduces too much complexity into the engine, like manual texture residency management, texture streaming etc.

>>106463047
GPU driven rendering is generally just pointless masturbation unless you're working on something cutting edge

>>106462984
Depends on your engine. It works well for me without bindless but don't have thousands of textures.

>>106463056
It's really easy to implement basic gpu driven techniques anon. Hardly technical masturbation. In my (non-game but still 3D) engine we support users uploading arbitrary models into it, so adding a GPU driven per triangle culling system meant some of our users went from seeing 20fps to 100fps. Should they have used a less subdivided model? Probably, but we can't control for that always.

>>106463047
>bindless introduces too much complexity
even without bindless, it can get complex.
If we do things like the way the post you are replying to suggested, depending on how vkCmdDrawIndirect() proceeds, we will have to manually apply memory barriers to avoid data corruption on the write buffer.
Its only actually useful in a scenario where the data your are dealing with can't be put into a structure and you wish to avoid the overhead of repeating the same draw calls several times from the CPU.

>>106463116
I can't see culling triangles being faster than culling objects

>>106463118
barriers are cheaper than copying data across the PCIE bus on most hardware (although on unified memory platforms like mac it might be a negligible difference). As always benchmark and profile

>>106463131
>barriers are cheaper than copying data across
absolutely true, no denying it.
Its a tad bit complex as well and that's what I was conveying.

>>106463127
It's probably faster in un-optimized dense scenes where having object culling would mean still rendering highly dense objects that you can barely see. Ala nanite/unreal.

>>106463151
nanite is a culling and LOD system that takes care of all that stuff for you

>>106463127
we do both. Culling triangles is relevant when you have large objects that fill the entire fov. You can dispatch a thread to look at 1-5 triangles in a model simultaneously, if they're not in the fov then you avoid submitting them to the rasterizer at all. It speeds things up because now you're not wasting bandwidth / cache on triangles that will ultimately be clipped.

If you have a normal LOD system and control the max polycount of all models in your game you can probably skip culling per triangles.

The logical conclusion to this is meshlet rendering / culling, so we do kind of a basic version of that and the long term solution would be to use meshoptimizer to dynamically generate meshlets for a given object, then emulate mesh shaders via compute for portability, but I've never tried that.

>>106463163
I've never heard of a game that culls per triangle because everything is grouped into convienently sized objects anyway

>>106452532
I'm not enginedevving, but can't you just use interfaces to abstract the implementation and delay some decisions?

>>106463217
In reality no because you don't even know what your requirements are and even the API will inevitably change

File: meshlet.png (175 KB, 376x435)

175 KB PNG

>>106463198
Alan Wake 2 doesn't cull per triangle but I think they were one of the first commercial games to require mesh shader support. A mesh shader is a group of triangles that you can cull, but instead of having to do a compute shader -> barrier() -> vertex -> fragment you can go mesh shader -> fragment directly. The splotches on this bunny represent the "meshlets" that your shader would process and do occlusion / frustum testing on .

>>106463228
There must be a way to apply some kind of architecture to help with that, but I have still no idea about programming engines (for now). So basically I guess you're right

>>106463259
The bottom line is you can't create a game and an game engine without knowing what you're doing and the only way you will know is by trying and failing until you find out what works

>>106463273
Well that's normal, things are usually made in iterations. The problem is when you iterate on something like yanderedev's code but that's easily avoidable kek

>>106463259
>some kind of architecture to help with that
there can never be on, like the other anon mentioned.
Games engines are complex. You need to implement things one way if you want good performance with racing games and implement things another way if you want good performance with a 3rd person RPG.
The first step to knowing the right solution to apply for the problem is to first be aware of the existence of the solution itself. No architecture can help with that. Only prior first hand experience can, attaining which has always(according to me and everyone I came to know) been a constant iteration of continuously building several things over and over again.

>>106463198
I feel like he's full of shit. You can't cull individual triangles efficiently in modern APIs. It's the whole reason mesh shading was invented.

>>106464573
mesh shading is just a replacement for obsolete fixed function input assembler -> vertex shader pipeline, which is now software emulated anyway.

>>106464573
You can. Do it in a compute shader and then draw with indirect drawing. And you're right mesh shading is the superior version of that.

File: 2025-09-02 15-19-00.webm (1.99 MB, 800x600)

1.99 MB WEBM

Testing palette animation on tiles. The performance is not as bad as I thought it would be. The resolution matters a lot, it can reach around 400 FPS if I scale down to half window size, but it drops to nearly 130 if I set it to full screen. I'm going to try redrawing the textures to be smaller.

>>106465085
this will be slower than culling individual triangles on cpu

>>106464665
mesh shader is basically a compute shader that can submit triangles to the rasterizer

>>106465375
why would it be slower than culling triangles on the CPU? You already have them submitted to the GPU for rendering. GPU triangle culling for a model with 100,000 triangles takes < 1ms on my 3060, when using a local_size_x of 32 and making each thread responsible for culling ~5 triangles. It also makes more sense to do it on the GPU, as you have to cull when the camera changes.

>>106465393
Exactly. It's possible to emulate mesh shader support on GPUs or APIs that don't support it via compute. In theory it will be slower because you have to do compute -> vertex pulling -> fragment, but this person claims they got better performance: https://tellusim.com/mesh-shader-emulation/

>>106465511
Nigger babble
>hello yes i cull triangles * within a model *
>see my $600 graphics card can do 1,000,000,000 iterations of a dot(x, y)-offset plane check per second
>noo what do you mean this is slow, retarded, and overengineered
We're so proud of you. You managed to run dispatch one instance of a compute shader with one relatively small dataset and one draw.

Keep believing this is real world engine dev and not just you being a fucking mong desperate to link the first article you found on goole every chance you get - the height of zoomer knowledge.

>>106465593
>slow, retarded, and overengineered
>real world engine dev
Those things are not mutually exclusive.

>>106465593
The 3060 is a mid tier gpu, and this technique works well even on igpus, we do multiple draws, it works well for our use case. Why are you so mad anon? non-devs always jump straight to ad hominem. I'm going to keep doing the thing backed by evidence instead of changing my entire pipeline because someone on /g/ said I should. Culling groups of triangles is literally an established thing, google meshlet I can't spoonfeed you any harder.

>>106465784
>Why are you so mad anon? non-devs always jump straight to ad hominem
Why are tranoids like this? At least I will admit to my ad hominems and strawmans. This is just sad. "<no-devs> <nooo you cant just ad hominem>"

>I'm going to keep doing the thing backed by evidence
"IM WITH SOIENCE" good goy. Keep spamming the first link you found on google because you cant be fucked to do any research yourself

>>106465804
also
>our
There is no "our". Do you have a bunch of pocket trannys in your pocket that you're speaking on behalf of? Fuck your foe censusism