>>100194528
I don't think rust was meant for this type of shit, languages shouldn't try to be a swiss army knife. my 5 cents on the article

>>100194528
>is the rust honeymoon phase finally over for gamedevs?
no competent person will ever consider using rust for gamedev. it literally doesn't solve any gamedev related problems and adds more of new ones.

Kek and I bet those 3yrs it was hyping rust and spamming g threads

>>100194528
>troons live in an echo chamber.
Color me surprised.

>>100194829
>>100194882
Unfortunately, the rewrite-it-in-rust crowd keep desperately trying it make into an everything language. The only outcome from this will be another ceeplusplus-style complexity tarpit.

>>100194528
Rust's whole "safety" thing is pointless for games. Safety in games is about preventing cheating and Rust doesn't help with that.
You prevent game state cheating by having either an authoritative server or desync detection, depending on your network model. And you prevent automation cheating by detecting behaviour patterns. That's it. Rust doesn't help you there.

>>100194882
There are retards trying to program the rpi pico in rust so the crowd is certainly there.

>all the retards itt
I've seen enough bugs in videogames and put right crashes to know you idiots need rust more than ever. Stick to your C# slop, you absolute amateur faggots.

>>100195122
rust doesnt prevent crashes at all.

>>100195122
>seen enough bugs in videogames
>and put right crashes
Rust doesn't prevent logic bugs and panic crashes, you absolute troon.

>>100194528
>3 years of Rust gamedev
> We built our own engine in Rust, called Comfy Engine, which we use for our games.
People who don't use premade engines spend most of their time refactoring their engine over and over. That's what always happens, it's not specific to Rust.

>>100195190
building engines is troontarded and what most people call an engine is just a renderer + game data loader which takes no skill or time to make because gpu already renders and every format already has a loader library for it.

>>100195222
T. Unity asset flip slop maker.

>>100195244
no need to sign off, I already know that you're retarded

>>100194528
apologize to jon blow

>>100195122
Rust doesn't prevent logic errors, which are 99% of video game bugs and crashes. You are a retard like all Rust users.

>>100195222
I won't disagree with that, but most people who don't use premade engines do, and instead they spend months writing and rewriting ECS systems or scene graph systems or other crap.
I'm actually reading the article now, basically it's all crying about how ECS is a shit overcomplicated system and how it's hard to use in Rust. He even mentions the solution (literally just don't use it and have big arrays for each entity type) but he still doesn't do it for some reason. (maybe it's too much pain for him to create new arrays when he adds new entities?)

>>100195297
>ECS
nobody ever used this

>>100195304
The article we're discussing is about ECS, thoughever.

>>100195313
people who have time to write retarded articles never did anything productive

>>100195297
I think the problem is generally people trying to optimize for something they wont even use
For example ECS exists because the need for cache locality but if you're going to make a fucking indie game even 1000 entities on screen are a fucking joke to any modern post 2004 computer processor.
Most engines must use those approaches because they'll run like shit if they dont but that is not the case when you're writing it from scratch which enginedevs are doing.

>>100195337
>because they'll run like shit if they dont
they run like shit always

>>100195350
But even more so, there's only so many layers of complexity you can pile before even the latest multicore PC starts dragging its feet

>>100194528
I think the Rust train is slowing down. The toxic community helped kill some of it too.

>>100195337
>1000 entities on screen
Games don't need 1000 entities, or why does Skyrim still sell gorillions of copies every year?

>>100195396
how about use simplicity? faggot
>hurr array shuffling must be complex in 2024
buy an ad for your shitty ECS

>>100194985
>C++ buffer overflow remote code execution exploits in your game
Rust stops tons of bugs that happen all the time in games

>>100195500
by making gamedev in rust so convoluted that they never get released?

>>100195500
Have you tried not trying to force multiplayer in everything?

>>100195297
The hardest part of engines is the animation system. There are out of box physics libraries that are pretty advanced.

>>100195521
You don't play games on an airgapped machine

>>100194528
>enginedev blames language instead of himself

File: smart.jpg (34 KB, 648x502)

34 KB JPG

>>100195520
Can have no bugs if there aint no program

>>100195561
You think your web browser is that safe?

>>100194528
So he is detransitioning?

>>100195500
>Rust stops tons of bugs...
Correction: it stops memory safety bugs, that's it.
It doesn't prevent logic errors which are the most common bugs in video games.
You troons should stop believing the "90% of bugs are memory bugs" propaganda from large corporations pushing Rust.

>>100195597
No, but I trust it more than a game

>>100195627
Never said it stopped logic bugs but memory safety bugs tend to be logic bugs.

You don't want your opinion changed, but I'll use any better tools I can instead of rolling around in shit that doesn't try to help me.

>>100195663
>I need help from computer in telling computer to do as I say

>>100195695
Only retards think they never make mistakes

>>100195663
>memory safety bugs tend to be logic bugs
Memory safety bugs are memory safety bugs, logic errors are logic errors.
Thanks for showing us how they derived the Rust propaganda number though, it's easy when you redefine what logic errors mean to inflate the real number of memory safety issues.

>>100195716
only retards make mistakes without noticing or learning from them, as is the case with your trauma

reminder that literally no one fucking cares about the programming language or engine you use to make your game except other losers like yourself who will never make a good game

>>100195749
How do you write a memory safety bug without having incorrect logic? I understand logic bugs are something else but the entire classification system isn't refined enough to differentiate some of these things. It's not propaganda, I want to use software that crashes less, doesn't have security issues, and that I can write easier with less debugging and more maintainability.

>>100195812
>I want to use software that crashes less
of course mindbroken tranny cannot just write software that never crashes lol

>>100195695
You program in hex?

>>100195812
Memory accesses have nothing to do with logic, you could use a word as a counter but when the program gets compiled to another architecture then word means some other size
This happens in windows and linux where int in 64bit linux is 64bits and in 64bit windows its 32bit so you have to explicitly say something u_32 or something like that

>>100195561
How would a strictly single-player game have an RCE exploit when can't make remote connections?
The original Doom never had this issue, are developers today not capable of writing quality code anymore?

>>100195640
A game is less likely to have a specific exploit than your web browser, retard. Unless you're talking about a game with a billion downloads. Some random Steam game is not going to get a specific exploit.

>>100195877
TF2 had an RCE bug 3 years ago lmao

>>100195902
Wow anon, Team Fortress 2? Is that a "random" game? Let's not kid ourselves, your game will have 1000 downloads.

>>100195902
TF2 has a built in web browser that loads in content from servers because Valve is retarded.

>>100195812
>I want to use software that crashes less
Rust doesn't prevent crashes, in fact it will likely panic more than a typical C++ codebase.
>doesn't have security issues
Literally impossible, Rust doesn't prevent all security issues. Only memory safety ones, the rest you still have to deal with yourself.

>>100195500
>MUH EXPLOITS
Are something the player does deliberately. If they break their own game that's on them. As to cheating, it's already been explained here: >>100194985

>>100195842
If you don't check that an index is inbounds, that's simultaneously a logic and a memory error

>>100195561
>airgapped
No such thing, but I do have a separate computer on a separate network and so does anybody who plays games and isn't so glacially stupid they can drown from being rained on

>>100195990
When you get an int you expect it to behave as an int would, why would you even bother with a compiler if you have to walk on eggshells?

>>100195990
I never check if index is in bounds because usecase is unknown

>>100195297
>literally just don't use it and have big arrays for each entity type
That isn't what ecs (bevy) is? Explains a lot honestly. Based article reader

>>100194528
rust political tool first and programming language second. You think that corporations that hire 3rd worlders value code quality?

>>100194829
>languages shouldn't try to be a swiss army knife.
Well, it's trying to replace C++.

>>100194528
I haven't even touched Rust but I could easily forsee all the problems the OP is having with it
Some people catch on slow

>>100195500
>C++ buffer overflow remote code execution
Unless you deliberately disabled every protection, the old school "smashing the stack" style RCE hasn't been possible on modern systems for more than a decade now.

>>100194528
>gamedev learns why games are made in C and C++

>>100196287
If you could read you would know he advocates using C# or Lisp

>>100196298
>Reading articles
Um, this isn't hackernews.

>>100196298
>C#
>Lisp
lmao this retard is going to learn why games are made in C and C++

>>100196338
He's using Unity, so it's just C# game logic.

>>100195168
Rust helps because the error messages tell you what to fix instead of just telling you how dumped the core is

>>100196357
>Unity
this retard is ngmi desu. All good games are made with either RPG Maker, Wolf RPG, or custom game engines.

>>100195168
Based on what?

>>100196374
Ctrl+Alt+Ego was pretty good, as was Void Bastards and Filcher for me.

>>100196358
>Rust devs can't step through their code in a debugger
>Filtered by a segmentation fault

>>100196376
Based on the fact that Rust programs can still crash?

File: 1365218000840.gif (1.36 MB, 320x200)

1.36 MB GIF

>>100194528
>Retard dumps 3 years of your life into making a Rust game engine without realizing it's a total productivity SUCC when writing a memory safe fizz buzz implementation requires 250k LoC and constant help from the dev 'cord
Jesus, you'd think they'd catch on sooner.

>>100194528
Veloren exists and runs on shitty hardware. Seems like a testament to rusts capabilities.

>>100195979
>Rust doesn't prevent crashes, in fact it will likely panic more than a typical C++ codebase.
redpill me on this

any sources?

someone almost convinced me to use rust for my next project rather than C++ for the low level code.

any actual sources? some guy from g00gle did a talk saying 2x productivity gainz with rust over C++ on new codebases from their internal stats

>>100196694
anti-rusters just lie and make up shit about everything. you can provide them all the proof in the world that rust works, and more companies are adopting it for business reasons which prove it. but they'll keep being buck broken by crabs

>>100196694
When you go out of bounds in C++, the optimizer miscompiles your code and makes it do random shit, but it still runs
When you go out of bounds in Rust, it crashes
What's hard to understand about this?

>>100196816
hows your cult treating you

>>100196829
you're doing what i said and know you'd do. you're incapable of independent thought, every argument you make is a predictable one you cycle through every time

File: 1711394856162413.jpg (76 KB, 500x558)

76 KB JPG

>>100196425
>Why would you want an instant solution when you could do it the tedious way?
I don't want to waste time on a solved problem

>>100196843
that was my first post in the thread

>>100194528
>Rust dev figures out why C is the industry standard for game dev til this day
Rust was fundamentally flawed to begin with yet many people didn't want to believe those flaws and push past those only to figure out its pointless and waste of time
If Rust win in this timeline then this timeline will be worse than cyberpunk timeline

>>100196694
In you use libraries that crash (panic) all the time for no good reason like B*vy, you will indeed get a lot of crashes.
If you don't, you pretty much only panic on out-of-bounds array access (which would fuck you over in any language).

>>100196888
>Rust was fundamentally flawed to begin
how so?

>>100196446
You said it doesn't prevent crashes at all. Rust programs crashing is not evidence to that claim. I ask you again, based on what?

>>100196888
>>Rust dev figures out why C is the industry standard for game dev til this day
C is not industry standard for game dev, and it hasn't really ever been.

>>100196904
>You said it doesn't prevent crashes at all
>Rust programs crashing is not evidence
Anon...

>>100196907
I think he meant C++

I don't want to debase myself by defending r*st, but every time I see a game dev blog about how <technical thing> sucks, it's always from a person or studio whose games are either obscure crap, or technical dumpster fires.
Reminds me of when Proton was still novel and some devs had such an autistic hate boner for Linux that they stated an unwillingness to even consider making/patching Windows games to make them Proton-friendly. Spoiler: all of them had games with mixed to negative reviews in general.

>>100196934
You're clearly a concern trolling idiot with no substance to your claim. I am done conversing with you. I'd tell you to retake basic Boolean logic in school, but it won't change anything.

>>100196944
His games don't look good visually, but they appear to be complete and functioning and available for purchase, which puts him above 99.99% of other Rust developers

>>100196944
There really aren't any rust games.

>>100196944
yeah, this dev doesn't do anything how i would do it. also they're going back to C# and unity anyway, only themselves to blame. no one forced you to write all this generic shit or get involved in anything like that. you could have written exactly like C code and gotten good results

>>100196989
You can't write Rust code exactly like C code

>>100197001
yes, you can. i do it all the time, and save on line count because i can do a lot of 3 line C code i'd write in 1 line with iterators that compiles to the same code. you don't write rust or C

>>100196989
>you could have written exactly like C code and gotten good results
Yeah. I really don't understand what's so hard about putting the whole state in a big struct and having it available at all times.

>>100197010
Rust has a thing called a borrow checker making a lot of the shit you do in C not possible

>>100196967
That's a pretty low bar in game dev, where shipping games that are either broken or embarrassingly inefficient has become the norm.

>>100196956
>Prevent (verb): keep (something) from happening or arising.
Anon, English please, prevent crashes =/= reduce crashes.

Rust can reduce crashes by preventing memory safety issues that would result in segmentation faults. However, it cannot keep all crashes from happening, obviously.

>>100197019
yes, i know how to use it. the author constantly talks about issues with the borrow checker

>I can't count the number of cases where I've accidentally caused a crash because of a double borrow on something, and not because the code was "poorly designed to begin with", but because something else in the codebase forced a refactor, and as I was refactoring I ended up needing to also restructure my use of global state, leading to unexpected crashes.
this never happens to me

>>100197019
I mean, you can still use unsafe and cast references to pointers and just write arbitrary bytes everywhere. Obviously rust is a pretty strong problem, but if you look at it hard enough you can basically do things like treat everything as untyped void ptr garbage like C.

>>100197057
So if you know how to use it you'd know that you can't do the same shit you do in C because of the borrow checker

>>100197056
>prevent crashes =/= reduce crashes.
yes, it does. you don't speak english natively or you'd know the definition

>>100197041
>That's a pretty low bar in game dev
Depends. For a regular game dev who just makes games and uses Unity or GameMaker? Sure
For somebody who programs and uses memelangs like Rust? Actually releasing games makes you a god

>>100197078
Use unsafe {}. And no, this does not just subvert the borrow checker.

>>100197078
i know how to use it, write c, and write rust. the borrow checker does not get in my way. you clearly don't know 2 of the 3 things we're talking about

>>100197057
Post your games.

>>100197109
The borrow checker exists. The borrow checker prevents you from using many programming patterns that people use in C. These are facts
You can use unsafe, but at that point why are you using Rust

>>100196690
>Veloren exists and runs on shitty hardware.
Wow, a Minecraft (2009) clone exists and runs on shitty hardware? Holy shit... Rust, I kneel...

Rust developers have never delivered anything meaningful. They live in their own echo chamber.

They constantly complain about how the world around them is full of unsafe C and C++ code.

Where is the Rust alternative to PostgreSQL? To the Linux kernel? To nginx?

>>100197145
>The borrow checker prevents you from using many programming patterns that people use in C
post them

>author says people will dismiss his problems saying “the borrow checker is not the problem, you are” and “rust doesn’t get in the way”
>literally retards in the thread doing exactly what he said
lmao rusttroons seething

>>100197057
This sums up the problem that I have with most complaints about the language. This person would be writing buggy data races causing corruption in the background in another language, they don't actually want to do the work of making sure their code is correct.

>>100197172

for (int i = 0; i < 1; i++)

>>100197355
>data races
not all code needs to be threaded

>>100197356

for i in 0i32..1 {}

>>100197380
not the same

>>100197167
>how the world around them is full of unsafe C and C++ code.
Including the Rust compiler's backend (LLVM) by the way, which has a couple million of lines of C++.

>>100197365
he's writing a threaded engine. even if he wasn't, the checker is there to prevent things like editing over a collection you're mutating which would invalidate pointers

>>100197397
who the fuck does uses threads in video games

>>100197056
You wear sunscreen to prevent skin cancer, you wear protective eyewear in a machine shop to prevent eye injury. This doesn't mean you won't be harmed, but it prevents damage. Learn English.

>>100197167
Every time someone proves you wrong, you move the goal posts. It's free for you to make up lies because you can just do it again next thread. What do you have to say about all the companies that you know are using Rust?

>>100197397
>he's writing a threaded engine
he shouldnt be, infact I think of his points is about that

>>100197432
No game developers are using Rust

>>100197356
>>100197380
Oh right, Rust doesn't even have numerical for loops. You can't run a loop without having to perform monomorphization on some generic iterator types.
There's no way this doesn't cause performance issues from the bloated machine code. It smells like instruction cache misses to me.

>>100197464
Embark Studios is, and some other indies

>>100197397
>he's writing a threaded engine
He isn't, that's one of his points.
>Global state is annoying/inconvenient for the wrong reasons, games are single threaded

>>100197485
>There's no way this doesn't cause performance issues from the bloated machine code. It smells like instruction cache misses to me.
your proof

>>100197510
yes, that's what I said, nobody

>>100197485
>There's no way this doesn't cause performance issues from the bloated machine code
All of it can be statically compiled out

>>100194528
won't the need for rust go away in a few years once we have perfect static analysis with LLMS for bad patterns, code smells, overflows etc? then just use whatever you want/whatever you're most productive in

>>100194528
>Rust
AAAAAAAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
TAKE
YOUR
TROON
LANGUAGE
AND
...
FUCK OFF!!!!!!!!!!!!!!!!!!
FUCKING JOKE! YOUR LANGUAGE WAS ENGINEERED BY MEN WEARING DRESSES, THINKING THIS MAKES THEM WOMEN!!!!!!!!!

>>100194829
Yeah! (*snickers*)
Rust was designed to be good at safety, not games or agile development!
You can't have everything with your language. Everything is a compromise.

>>100197563
>once we have perfect static analysis with LLMS for bad patterns, code smells, overflows etc
this is such an ignorant comment on so many levels

File: Untitled.png (38 KB, 1202x585)

38 KB PNG

>>100197485
The compiler isn't that dumb.

>>100197547
>>100197562
Go play with Rust for a little bit on compiler explorer, try some for loops with different types. You may notice it tends to generate more machine code than both C and C++ for basically the same functionality, mostly due to monomorphization of generic types.

>>100197617
I haven't actually used Rust but I've made a language with just one generic "loop" that works on iterators and they can get statically compiled down to the same thing as a regular loop

>>100197607
You can have everything woth Python, C and C++. The NuLangs literally can't do gui. Top fucking kek.

>>100197615
Now do it with more complex types.

>>100197456
>>100197515
then what is he doing with mutexes and getting double borrow errors

>>100194528
Yeah rust for gamedev just seems like a bad idea and mostly pointless. You typically want to write working code even if it's a messy hack and prototype fast. Rust is just not the right tool for that job.

>>100197611
not an argument

>>100197943
>In game code one ends up having to wrap things in a Mutex<T> or AtomicRefCell<T> not to "avoid issues they'd run into otherwise if they were writing C++ and forgot to synchronize access", but rather just to satisfy the compiler's all encompassing desire to make everything threadsafe, even when there isn't a single thread::spawn in the whole codebase.
There's only one mention of mutex in the article and it's a valid complaint: enforcing thread safety at the language level is pretty much useless for single-threaded applications.

>>100198285
the xor mutability rules also prevent other issues though. i understand not wanting to be subject to those constraints in single threaded code but it's not just for multithreading. like iterating over a vec while trying to insert/remove

>>100198524
>like iterating over a vec while trying to insert/remove
the "just don't do it" rule has never failed me here

>>100195297
The difficulty hobbyists, from-scratchers etc have with ECS is that they typically view it as something that should be part of the engine (ie something that should be game-agnostic) rather than something that should be part of the game. ECS as a concept is stupidly simple, it's basically just an in-memory database where fields are aligned. ECS only becomes complicated when you try to make it game-agnostic.
>literally just don't use it and have big arrays for each entity type
This basically is an ECS though. All you need to change is having big arrays for the components rather than for the entities themselves. Just as easy to code, has all the benefits of ECS, and will outperform any framework. The only downside to doing things this way is that it isn't game agnostic. Trying to make an ECS that will work just as well for a AAA FPS and a solo developed RTS is where it gets complicated, and the general-purpose frameworks that accommodate this are always less performant than just having a bunch of hard-coded arrays for your components.

>>100195337
I would say it's premature abstraction more-so than premature optimization. A complicated ECS like those used in the popular frameworks is always going to be less performant than just having a bunch of hard-coded arrays for each of your component types. The frameworks cannot make any assumptions about the kind of game you are trying to make. This focus on generality leads to poor performance, and the incomprehensible architectures are needed to reclaim some of that lost performance. If you don't over-generalize to begin with then you don't need to reclaim the performance lost in the name of abstraction and everything remains simple.

>>100198695
The problem with over-generalization is that the endgame is always just re-inventing the concept of a programming language. A programming language is already the most general tool possible. We make engines etc because it's simpler to work with than trying to program everything from scratch in C, but the entire reason that an engine is simpler to work with is because it is less general. If you demand maximum generality then the best tool you can possibly create is nothing because anything you create is going to be more domain-specific than the language you used to create it. I often wonder if these types of people would find more fulfillment in language/compiler/etc design than in game design.

>>100198524
>like iterating over a vec while trying to insert/remove
That's a logic error in single-threaded code and could have easily been just a compiler warning (or error if vec<T> was a language primitive). Sure, you may get garbage results out of your loop if you do that, but it's not a memory safety issue because you're bounds checking the vec on every access.

>>100195520
fbpp

>>100199220
it is a memory safety issue with iterators in c++ because you're holding references to invalidated pointers if the collection is moved by a resize

>>100199577
>trying to modify something you're iterating over
this is actually possible to solve by writing a custom iterator and is in fact a logic error

>>100199220
if vector reallocates you will most likely get a segmentation fault in next PAGE_SIZE bytes and then shit yourself because people who make these nonproblems into real problems don't know how to fix them, it's greay that rust exists and so we don't have to deal with those low IQs

>>100199632
>this is actually possible to solve by writing a custom iterator and is in fact a logic error
>>100195842
>Memory accesses have nothing to do with logic

This is exactly what I mean

>>100198707
writing game code in C is as simple as it gets, in the end you quite literally do not need more abstraction than

float positions[PHYSICS_ENTITIES * 3];

And anyone who will try to argue with that is incredibly retarded, API's like OpenGL and Vulkan do not work very well even with a struct of 3 floats in C++, it's only C that has 0 aliasing rules because it is the sped of programming languages that does not care about anything besides hurr it's just like bytes of this alignment bro.

>>100199698
I'll argue with it, SoA data layout is very unergonomic

>>100199847
There's a reason we use C++, but if you use C for a moment it makes you realize that in C++ your data should look exactly like this, if you cannot build an abstraction over it, you're not going to make it, it's really not that hard to stop being a midwit and replace a struct of 3 floats with a class pointing to 3 floats internally and having whatever interface you want, if you really need this

>>100199894
>your data should look exactly like this
No it shouldn't because it's a pain in the ass to work with
Also likely to be worse for performance in most cases

>>100199909
it has optimal performance and memory layout for sending it directly to gpu, midwit

>>100199945
You send transform matrices to the GPU, midwit

what kind of retard started using Rust for games 3 years ago and kept banging his head in a wall for 3 years??
if you want to make a "fun and interesting" games then you pick up a mature game engine and use the language you are already familiar with, then you can actually dedicate your time to make a fucking game!

>>100200047
I'd like to see how you would create transform matrices better than from a flat array of positions

>>100200089
Data for entities on the CPU is best stored in structures, not component arrays, because it better matches how you actually work with data

>>100194528
isn't gamedev all about using a stable LTS base until you release your game?
Rust is not like that at all.

>>100200157
you don't work with data, computer does, kill yourself

>>100200162
no it's about getting shit done and rust is not good for that

>>100200166
What is this hilarious cope
Learn to program

>>100200183
yeah I can program and think in very abstract terms, that's why I don't need to make everything an object like a low IQ subhumans would

>>100200195
Even though making them an object is better for performance because it matches your access patterns

>>100200237
you're a low IQ subhuman who never made a game and don't know what computer's* access patterns are because you don't peogram

>>100200178
yes that's why I said LTS stuff.
Don't forget up until a while ago the linux kernel was still using C99(or was it 89?) even though C11 had a spec out for over a decade.

Productive developers can deal with working on old ass java if they need to.

>>100200258
When you're working with game entities, you aren't dealing with just the position in one operation. You're dealing with the position, the rotation, the color, your health, your physics body, whoever knows what else
That's why you put them in a data structure so they're next to each other in cache
If you put all your entity components in some SoA mess you're going to have more cache misses as you pull in from multiple different arrays just to get the data you need for an operation

>>100200281
>what is icache and dcache

>>100200292
something irrelevant to this conversation
we're talking about the data cache, which is 100 times slower than the instruction cache and you're going to be doing the same operations regardless of your data layout anyway

Rust exposed. Meanwhile I'm eating good with C# monogame. It just werks and no a 5ms pause after 60 seconds of garbage literally doesn't matter for 99.98% of games.

>>100200316
that's one way to out yourself as a fizzbuzzer who never wrote a game complex enough where icache pressure is a real problem

>>100200371
>icache pressure is a real problem
This is the biggest larp I've ever heard, lmao

@100200387
maybe you should go to a doctor if you heard anything, then you might stop hearing your own larps such as saying that dcache is irrelevant but then talking about data cache as if that's not what dcache is

>>100200403
I said instruction cache was irrelevant, are you having trouble reading?

@100200425
maybe for your fizzbuzzer programs it is, but when retards like you start making games in their oopsie code, suddenly icache starts thrashing and your game runs at least x100 slower than if it was made by someone with a brain

>>100200451
Nope, instruction cache is barely worth talking into consideration, maybe if you're doing something extremely stupid like super deep virtual method hierarchies for trival operations
Data cache is what you should care about for performance (Although even that has been way overblown)

@100200477
>like super deep virtual method hierarchies for trival operations
yes that's exactly what you do since you're too mindbroken to just use a flat array of data

>>100200491
No that's not what I do retard

@100200515
yes, not yet, you're just a fizzbuzzer that never did anything, but if you ever get to actually programming that's exactly what you will do since you're too braindead to not be a contrarian, quite ironic that optimal game programming patterns didn't change since N64 and yet you still can't comprehend them.

>>100200539
Optimal game programming patterns have changed since the N64
The whole "storing components in a SoA structure" meme is new, because data cache speeds are now relatively much slower and computers have SIMD processors which can take advantage of this

@100200561
sorry, you're right, that's why this new thing runs x6 better on actual N64 than what midwits like you do, ironic, isn't it? https://www.youtube.com/watch?v=t_rzYnXEQlE

>>100200568
Give me a timestamp to what you're talking about

@100200584
I'm talking about the entire video of course, zoom zoom

File: file.png (30 KB, 591x383)

30 KB PNG

gaydevs seething at this post

>>100200595
at 9:55 he talks about data cache, he's saying exactly what I'm saying, put your variables next to each other in a structure, don't put them in disparate arrays
Also doesn't show any benches for this, like I said, data cache being slow is a recent issue so he's cargo culting modern best practices without testing it here

>>100200608
>Fixed a crash that occurred when trying to attack a neutral faction village or caravan party while being a mercenary.
what are the odds that this was nullptr dereference because they used the soulless OOPsie code for everything? LMAO
@100200626
Ah of course, I was weary of posting this video because a midwit like you wouldn't understand that N64 isn't a modern computer.

>>100200630
>you wouldn't understand that N64 isn't a modern computer.
That's exactly what I'm saying
Putting shit in arrays to optimize for data cache and SIMD is a modern computer thing, not an N64 thing, so him doing it on an N64 isn't going to make much of a difference

File: rust.png (3.71 MB, 1920x1080)

3.71 MB PNG

>>100194528
skill issue

>>100200608
This guy is a dumbfuck. Bannerlord is written by Turkish uni students and I'm pretty sure a good portion of the game logic is C#.

>the video is fake and it made no difference
I still don't understand what's the point of larping about knowing things while being an obvious fizzbuzzer who never wrote a program more complex than fizzbuzz.

>>100200668
>>the video is fake
Did I say that?
He didn't benchmark him rearranging data members, he just said that he did it
He showed benchmarks for a lot of other things, not that

>>100200608
>The Cnile's Prayer
That bug didn't happen.
And if it did, it wasn't that bad.
And if it was, that's not a big deal.
And if it is, that's not my fault.
And if it was, Rust couldn't have prevented it.
And if it could have, I wouldn't use it anyway because you're a tranny.

>>100200683
for the kind of problems that exist in videogame programming, rustrannies would replace pointers/references with indices into arrays and then they would risk getting a segfault because now nothing is checked at compile time.

>>100200693
no, they'd be bounds checked because it's idiomatic to use get() and handle the None case

>>100200714
>it is idiomatic to have bounds check on every memory access
no wonder there's no relevant games in rust, even those that exist run like absolute shit

>>100200721
bounds checking is cheap

>>100200721
knew that'd be your next inane reply lol >>100196843

there are legitimate criticisms of game dev in rust. but its moot because all the other game engines are worse

>>100200725
in languages like C++ where you do the sane thing of iterating over dumb arrays and then the bound check is actually just your for loop exit condition and not only just cheap, but free

>>100200754
which is what rust does too. you'd iterate over collections. you can't even keep your points straight because otherwise you're storing pointers to random shit that's out of cache which is a bad access pattern anyway (same as indices)

>>100194985
Rust for games is not about safety, it's about the way it makes certain kinds of optimizations really easy to do, especially compared to C++, where if you want shit to be optimized you have to be prepared to write the STL from the ground up, because the ABIs are so fucked it's not even really funny at this point.

Oh, and the best part is they will never fix any of it because they are dying on the hill of backwards compatibility.

>>100200789
>it's about the way it makes certain kinds of optimizations really easy to do, especially compared to C++
Give examples of this

>>100200768
you cannot iterate over collections, midwit

>>100200806
found the end of your argument chain lmao

>>100200819
yes it's an efficient circular buffer and you somehow overstepped into beginning that was already read yet not overwrtten yet since you're a nocoder who can't program

>>100194528
>NOOOO WE DONT WANT TO WRITE CODE
Ok, back to C++.
>NOOOOOOO ITS BUGGY
Ok, back to C#.
>NOOOOOOOO IT HAS A GC
Ok, C with embedded Lua.
>NOOOOOOOOO WE NEED HOT RELOADING, FAST ITERATION, FAST COMPILE TIMES, LOAD 100 GB TEXTURES EVERY 5 SECONDS
>WE WANT THE SPEED OF C, THE SEMANTICS OF JAVASCRIPT, AND THE DEBUGGABILITY OF COMMON LISP
Just execute all gamedevs with extreme prejudice.

>>100200281
Ah yes, of course, the physics engine needs to know about the HP and inventory of each entity, lol
Do you really believe what you say?
How do you even use AVX instructions when everything is a heterogeneous struct, and your access pattern is doing a bunch of logic for each entity separately? Do you even use vectorization at all?

>>100200872
>WE WANT THE SPEED OF C, THE SEMANTICS OF JAVASCRIPT, AND THE DEBUGGABILITY OF COMMON LISP
Thank God for C++ offering all that.

>>100200836
>you can't iterate over collections
is meaningless nonsense

>>100200608
does this nocoder really think most crashes and bugs are cause by memory unsafety?
fucking midwits on HN man

>>100200918
yes everything you posted ITT is meaningless nonsense, kill yourself fizzbuzzer

>>100200896
but C++ is actually faster than C when you aren't a nocoder so saying "speed of C" is sort of insulting

>>100194528
Why the fuck would you need reflection? You don't need that shit for game dev at all (as a Mercedes-Benz S-Class owner)

>>100195627
It absolutely does prevent logic bugs. The borrow checker simply isn't what you think it is.

>>100200796
Compared to something like C++, there are a lot of referencing nuances that just don't show up in Rust because of the way value sharing is handled. For instance in C++ you have to be constantly aware of the way you pass things around, not only because of RVO fuckery, but also because of copy / move constructor wrangling, etc. In rust you have the Copy and Clone traits, and they are impossible to misuse. In addition to this lifetimes make it so certain optimizations based on references are 1. trivial, and 2. can never be misused. Whereas in C++ you are unlikely to have more than a few layers of pointers because of how hard it is in practice to handle such a hierarchy, those hierarchies are trivial in Rust.

On the other hand, most of the people who complain about Rust not being good for prototyping are trying to set up all these lifetime constructs etc from the get go, and then getting fucked in the ass by a problem they created themselves. Or alternatively they're trying to write unsafe code using safe constructs and then hitting a wall instead of just writing unsafe code in the first place.

Rust is really good at mindbreaking people over the "safety" shit, when for me, the moment someone brings up safety as the number one reason they use rust I mentally flag them as people who haven't used the language for more than a few months, or for whom the borrow checker never clicked, and they actually think the borrow checker is actually something you consciously think about and have to actively work around.

It is what it is.

File: 8wq3cwtnxpj11.png (212 KB, 1200x1335)

212 KB PNG

>>100200806
>you cannot iterate over collections
What did he mean by this?

>>100200955
he's been long out of arguments and just calling everyone fizzbuzzers lmao >>100200927

>>100200955
you will understand when you write something more complex than fizzbuzz and understand how computers work, and that they are in fact not just a faster PDP11

>>100200935
True, but stop giving our HPC Chads secrets to the plebs.

>>100200962
when your talking points are so dumb and repetitive, it's impossible to tell if there's a human typing the post or a bot

>>100200940
Interesting. So your approach is "unsafe everything, rewrite it later"? I'm interested to hear about how that works out in practice.

>>100200962
But I can iterate over collections, I do it all the time.

>>100200975
yes I have a mirror at home too, you can stop acting like an NPC anytime

>>100200996
>my fizzbuzz has collections
impressive, anon, truly

>>100200883
An entity is a collection of sub objects that include things like health, physics, rendering, logic, AI. If your health goes to 0 you might want to change you renderering object to a corpse and change your physics object to a body on the ground. Games have a large intermingling of concerns, the article in the OP talks about this
>How do you even use AVX instructions when everything is a heterogeneous struct
For most code you don't, there's only a few areas of a game where you can get significant gains from vectorization

>>100200940
These "optimizations" you're talking about are extremely trivial

>>100197356
Rust is an abortion

>>100201006
If I can do it, you can do it too. Believe in yourself.

>>100201009
>if your health goes to 0
you will change one integer and renderer will handle it

>>100201039
What's your point?

>>100201046
renderer will sort all available model id's which are just integers and then render them in batches separately from your irrelevant health code, idiot

>>100201058
Yes, what's your point? Are you even following this discussion?

>>100201009
>If your health goes to 0 you might want to change you renderering object to a corpse and change your physics object to a body on the ground.
lmao, instantly, in the same fucking loop? Do you understand how crap that would even look, performance nonwithstanding? What is this amateur hour shit?
>For most code you don't, there's only a few areas of a game where you can get significant gains from vectorization
Yeah, like all the areas where performance matters, as in any code that touches spatial information.

>>100201063
my point is that it isn't heavily intertwined like you want us to believe, fizzbuzzer

>>100201063
Not him but I think you're the lost one, buddy.

>>100201066
>lmao, instantly, in the same fucking loop? Do you understand how crap that would even look, performance nonwithstanding? What is this amateur hour shit?
I don't even know how to respond to this, you don't know what you're talking about
>Yeah, like all the areas where performance matters, as in any code that touches spatial information.
Animation, AI, some spatial stuff like broadphase queries
95% of the code you're writing in a game isn't even run enough to bother vectorizing, or can't be vectorized well

>>100201066
>lmao, instantly, in the same fucking loop? Do you understand how crap that would even look, performance nonwithstanding? What is this amateur hour shit?
yes they all really unironically believe this, they cannot comprehend that using slightly more memory for indirection and then doing one operation in a loop that does not thrash icache will always be faster

>>100201071
A "entity" is something that ties all your disparate subsystems like physics, rendering, animation, audio together. An entity touches all of these systems

>>100201079
>95% of the code you're writing in a game isn't even run enough to bother vectorizing
Since it's also not the bottleneck, it is completely and utterly irrelevant to this conversation.

>>100201089
only in fizzbuzzer mind, real games don't have such thing, they only have netcode subsystem, audio subsystem, rendering subsystem, physics subsystem and a bunch of data that needs to go through the pipeline

>>100201091
What's your point?

>>100194917
this

>>100199945
I'd call you a midwit but in typical C user fashion you're actually too stupid to even merit that title. The data structure you want to send to the GPU is going to be horribly unfriendly for how the GPU actually handles data. AND it's not even a better layout for sending it to the GPU! All that matters for sending data to the GPU is that you do it in bulk.

C users should kill themselves. It would be eugenic for the rest of humanity.

>>100201096
>a bunch of data that needs to go through the pipeline
Yes that's the "entity" I was talking about

>>100200981
How do you think people rewrite C++ and C projects in C? The first drafts are usually filled with unsafes.

You don't need unsafe everything. What they are likely trying to do is having two mutable references to the same resource (which can be done with inner mutability by the way, but it's annoying). You can simply use a pointer for that. More often than not there's also a really easy way to do these things with regular references, except you don't see them because we are so used to C and C++.

>>100201111
health quite literally never interacts with physics and depending on the game and layout those things can run on separate threads without any synchronization, retarded fizzbuzzer

>>100201118
>health quite literally never interacts with physics
health = 0, change physics body to one resembling a corpse
everything in a game interacts, that's the point

>>100201122
>change one integer for next frame
yeah that totally requires your oopsie brainrot

>>100201127
Who the fuck said anything about OOP?
I hope you're in therapy, you need it

>>100201079
>don't even know how to respond to this, you don't know what you're talking about

for (auto &monster : monsters) {
  monster.update_pos();
  if(monster.health <= 0) {
    monster.texture = get_corpse_tex(monster);
  }
  monster.render()
}

Niggers will stand there and pretend this is a sane architecture.

>>100201141
What are you complaining precisely?

File: xxcH2hH.jpg (42 KB, 753x960)

42 KB JPG

>>100201100
>What's your point?

>>100201141
>update position even if monster is dead
>texture ID is thrashing same cache lines meant for health calculations
>render monster right after instead of waiting to collect all monsters of same type that are dead and need to be rendered
lmao, they really do believe this is how games must be written
>>100201149
you're braindead

>>100201165
>thrashing same cache lines
Holy larp

>>100201122
>it is the responsibility of your physics loop to swap textures and implement death logic
Braindead negro

>>100201179
No, it's the responsibility of the superstructure that ties them together. Read the posts you're replying to

>>100201184
no it isn't, all game logic should be implemented as queues of commands to subsystems to process things, not whatever you imagine, retard
>>100201174
>game has to load x10 more data into cache just to calculate health and there's absolutely nothing wrong with that

>>100201193
>all game logic should be implemented as queues of commands to subsystems to process things
That would be the superstructure that ties them together, yes
Also a terribly cumbersome architecture to work with

>>100201199
>terribly cumbersome
I recommend a different hobby, like knitting.

>>100196376
panic() crashes the program.

>>100201205
Who said anything about hobbies? I'm not the hobbyist Rust developer pretending he knows how video games are made larping about cache thrashing

>>100201218
yes you're a fizzbuzzer instead, which is worse, at least I could have a conversation with a rust dev
t. C++ programmer

>>100201184
LMAO WHAT THE FUCK ARE YOU TALKING ABOUT NIGGER
A minute ago you were saying you should send HP information to your fucking GPU because your physics logic somehow needs to know about monster hit points.
You're clearly winging it at this point

>>100201223
You're calling everyone who tries to correct your lack of understanding about anything a fizzbuzzer
Your opinions are straight from the ECS larpers handbook

>>100201231
I never said anything close to that

>fizzbuzzer trying to correct me
what did he mean by this

>>100201141
noooooooooooo you can't just iterate over a collection, that's nonsense!!!

>>100194528
I am really curious what issues they ran into with global state, considering you can do global state in the exact same way you can with any other language in the world.

>3 years
>doubt
Or maybe just trash programmer.

>>100201247
in Rust, to have global variable, you're basically forced to have a Mutex because um, because WHAT IF another thread accessed this?

>>100201254
you're not

>>100201254
What the fuck are you talking about? Pointers exist in Rust. Why do you try criticizing something you know nothing about?

Also how is having a Mutex hard? Lmao

>um actually, if you bypass all rust features and do C type programming then it's not that bad
I can already do this in C++

>>100194917
100%
this whole language is fueled by blog posts and shitposts

>>100201277
You're retarded, and unsafe doesn't do what you think it does. Even if it did your argument is still retarded, but I don't expect you to ever understand why.

Again, you don't know the language you're trying to criticize. Actual Rust derragement syndrome at play.

Instead of trying to discuss shit you don't know anything about, go email the C++ commitee and tell them to fix the STL. That would be about 10 times more productive.

>>100201307
I'll have you know we take professional pride in not having strided iterators after 30 years of STL

>>100201307
How about you slam dunk a wad up your ass, you raging faggot?

The issue we have with rust is the same as the issue with trannies, namely

SHUT UP
SHUT UP
SHUT THE FUCK UP
SHUT UP AND GO AWAY
STOP TRYING TO GROOM KIDS
SHUT THE FUCK UP

Not trying to stop you, just don't care and don't want to fucking hear about it.

>>100201348
>fizzbuzzing tranny larping as professional
>cannot write his own specific strided iterator for his specific problem
it's like you aren't even trying

>>100194528
>rapid prototyping and iteration
Just get Gamemaker. It's still a lot of work even with most retard-friendly engine.

>>100194528
So basically if you're writing anything more complicated than a grep clone, stay away from tranny and use C++ instead?

>>100194528
>is the rust honeymoon phase finally over for gamedevs?
What the fuck are you talking about? Have you ever seen any game made in Rust?

No one ever recommends using Rust for games. Just because you ""can"" doesn't mean it's the best tool for given task. If you want to actually make a game just use a premade game engine with C# or something on top.

>>100201599
even then you might as well use Go
honestly every cli app I've used that was written in Go has been a better experience with more features than anything that was written in rust. most Rust programs have barely any features. their big feature is "memory safety" which means jack shit for the user when the program can still panic like any other program

>>100201721
fzf is cool and all but it's fzy for me

>>100194933
Show me one(1) case of a game being rewritten in Rust.
You have no idea what you are talking about.

>>100196956
>>100197056
It doesn't even reduce crashes. Rust always proritizes to crash instead of entering an invalid state. It is much more prone to crashing than other systems languages, which often can continue working into an undefined state.

>>100197057
>this never happens to me
This(large refactors) happens to me and I am long time Rust developer. However double borrows is a sign of code being poorly designed, and so are frequent refactors.
Rust does require you to make a lot of important decisions out front, and if you don't fully understand what you are doing, it's easy to end up like that.

>>100201741
the large refactors happens to me occasionally, it was all the other stank design smells that i saw kept appearing in the writeup

>>100201599
No, if you can't comprehend what makes different languages suitable for different task, you should stay away from C++ as well.

Go was designed with people like you in mind.

>>100201768
Rust isn't suitable for any task. It cannot even compile itself and has to beg C++ to do it for xer.

>>100201399
Do you realize that this thread was made by someone who dislikes Rust, right?

Majority of Rust discussion on /g/ is started by seething ciniles. You rarely see a Rust thread made actually by a Rust developer.
If you do not want to hear about Rust, just stop talking about it. It really is that simple. But for some reason Rust lives rent free in every cinile and zigger head for some reason.

>>100201782
Yes yes. Now go use Go or some other toy while the grown ups are talking.

>>100201798
Sorry but I am C++ programmer and several commits in LLVM are under my name and you can go eat a dick you retarded nigger tranny, Rust will never be a real programming language.

>>100201813
Yeah, you sure are. You sure are.

>>100201930
2 more weeks until Rust can compile itself after over a decade of programming by incompetent mentally ill men who can't even program actually

>>100201935
It sure is it sure is.

File: file.png (10 KB, 394x198)

10 KB PNG

>>100196976
Veloren which is also FOSS

>>100195500
there would actually need to exist a finished game in rust for that to be true, which will never happen

>>100202355
>shitty cubeworld clone that's more irrelevant than cubeworld

>>100202781
>doesn't count...because...IT JUST DOESN'T OKAY?

>>100202792
at least if I ask a normie about cubeworld they will remember it, lol

>>100194528
Yes and it'll die a faster death when Jonathan Blow's Jai comes out. I heard that its to Odin what C++ is to C.

i think rust is definitely not ideal for prototyping and gamedevs would be better off just using a sane subset of c++.
the only rust game on steam that ive found looks good (by any reasonable metric, including just popularity) is Tiny Glade, which was made by professionals who have worked in the industry for a long time. even embark studios who are very vocal proponents of rust don't actually use a game engine written in rust for their games.

>>100201741
>Show me one(1) case of a game being rewritten in Rust.
>You have no idea what you are talking about.
nta but I think he's talking about the people who open issues on github asking to redo everything in rust. most people refuse to do so for obvious reasons

File: 1689407235495612.jpg (579 KB, 2048x1536)

579 KB JPG

>>100197657
>lying on /g/
well that's not new
Python has terrible performance
C is not suitable for writing more complex applications if you value your time
Cpp just sucks, don't think I've hated a lang as much as cpp. I respect js more than this shit

File: 1691288126418935.png (475 KB, 570x660)

475 KB PNG

>>100195222
cool story now make an engine to rival unreal
if you can't better stfu

>the same rajeet still seething 24 hours later
Rust lost
Cniles won

>>100201465
Exactly the sepples pride I was talking about. It doesn't even make sense
>yes of course the STL has functions for trivial stuff such as std::max, std::plus or std::next, because muh portability. THIS IS VERY IMPORTANT AND YOU SHOULD ALWAYS USE THEM
>strided iterators? Do it yourself lmao

>>100204568
I never used any of these in my entire life

>>100204596
And yet you say you use the STL, curious

>>100204606
yes only the useful parts

>>100204611
>The STL is perfect, Stepanov did nothing wrong
>actually I don't use 2/3rds of it because it's broken
I accept your concession.

>>100204638
I'm not part of any cult so I can do whatever I want and I'm not sure what's your problem, but your buyer's remorse is not my problem tranny.

>>100204663
You're still talking?

>>100204680
the voice you hear isn't me

>>100203875
Games are very rarely hosted on GitHub.

>>100204638
>I accept your concession.
why do intellectually bankrupt frauds keep using this term? is this something you discovered on reddit?

>>100205036
it means he ran out of cope to reply with.

>>100196287
>>100196338
why do you automatically associate c# with unity? it's a powerful alternative to c++ for engine development unless you don't want your stuff getting decompiled.

>>100202355
this game redpilled me on rust. its buggier than the literal scam game it's based on which was made in 2 months.

>>100205470
>C# cannot be decompiled
based retard

>>100205036
Actually it originated here, tourist.
Don't put yourself in such a state of emotional distress because I made a simple joke at the expense of your sacred STL.

>>100205670
I assume you meant c++ and I mean decompiled to a point where you can rebuild the game from scratch