Thing is, i believe this argument specifically is a gatcha for people that actually want a more powerful and open engine. I do also want a way more open and powerful engine but throwing the argument that low end devices are the minority is just giving roblox (and other high enough people within roblox) a very easy counter point, that being the fact that low end devices aren’t quite the minority. Hey, personally i believe this to an even higher extent. Specifically personally i dislike how games which seemingly don’t seem to do much actually magically take tons of system resources for whatever reason.
The better argument is well, how about roblox letting US do the optimization part and not them? “Oh well roblox believes in a automatic one click solution engine” yea they do, except that’s still not going to get them far and clearly haven’t gotten them very far in the actual game innovation department. Can’t say game’s inner workings have changed much since like 10 years ago. Has developer skill, knowledge and whatever else relating to developers and how they design these games? Yea sure, though the engine is nearly the same in terms of actual power and performance since like a decade ago. The automatic one click solution has never and will never lead to anything. Wish for a future in which roblox gives US the power.
exactly. let us do the optimizations and not roblox
if a game isnt performant for mobile that’s the creator’s fault, and the game probably sucks anyway
I believe a scenario would be EditableMesh/Image instances being either delayed or straight up not showing up. I believe these delays to even failures could result in overall game failures that would require multiple retries from the developer just to make that specific piece/pieces of the game actually function. Maybe sometimes it could straight up just never function. Can’t say roblox is being very specific about that.
And i’m just saying, if it gets to a point in which the engine needs to micro manage the memory usage of fresh EditableMesh/Image instances then there’s proooooooooobably a very high chance that if its not the EditableMesh/Images crashing the game, then it’ll be something else. No point in forcing the engine to micro manage these things for the sake of avoiding a inevitable crash.
Hey, roblox maybe should actually debloat the client/engine and give us the power, tools and systems to actually more effectively optimize our games so that way magically roblox would no longer need to micro manage the memory usage of random features for the sake of preventing realistically nothing.
What format does the pixels buffer use? The code sample makes a suggestion that it’s an array of u32s but it’d be nice to get proper specification on it. Which byte components of the u32 map to which color and the alpha channel?
I’m also going to ask if we’ll get the ability to have multiple texture sources reference the same EditableImage rather than requiring it to be cloned across each one. Maybe a temporary ID system using a hash or GUID?
FWIW 2GB Android devices are a bigger percentage of the player base than you would expect.
We have to design these APIs such that it’s possible to use these APIs without crashing on those devices. This is important to a lot of developers.
We do also want to support you doing more complex and expensive things if the user’s device can handle this.
Keep in mind that each 1024x1024 EditableImage is a 4MB buffer. These are probably more expensive (in memory cost) than anything you’re used to working with in Roblox.
Indeed, we can’t fully “optimize for you” here. We are going to expose you to that reality that what is possible to allocate safely may differ per client.
If you’ve ever worked a mobile game outside of Roblox you’ll have some sympathy that dealing with memory on mobile is incredibly hard. Mobile OSes are extremely fickle and inconsistent and there’s no guaranteed safe rules for memory allocation patterns. Allocating reasonable and achievable amounts too quickly can get you killed. Patterns that work one day might kill you the next because the OS wants to run some background job more than it wants to keep you alive. Sometimes you’ll get memory pressure signals, but even those aren’t consistent.
We’re going to try to abstract and rationalize this a bit so you don’t have to deal with the full extent of that sadistic reality that we have to deal with as an engine team, but once you’re now dealing with multi-megabyte objects we’re in this together now.
The system initially will be very cautious and conservative, but over time we’ll make it more dynamic. It will require a lot of experimentation over time to refine, though.
We’re prioritizing getting the essentials perfected first.
The extended mesh attributes APIs in this update are an example of one of the reasons we didn’t add batch APIs already. That would have invalidated those batch APIs. More stuff we’d have to remove and rewrite.
We really want batch APIs. We’ll add them eventually. Likely sometime after the first public release.
Kind of a small thing but it’d be wonderful if we could use the CSG APIs in some point with meshes. I understand converting them into mesh parts is coming later, but if you can’t turn them back into meshes you can’t CSG with them
Try playing a game like Criminality or something on an iPhone 6, hell even a last gen Xbox like a One S. Runs like absolute crap, disabling every option and putting in on lowest graphics may get you an unstable 40-50 fps on the Xbox, as for the phone…
If Roblox wants to be a respectable engine it needs more options for DEVELOPERS to create the games they need for the platforms they want, instead of kneeling before whatever 9 year old technology Roblox still supports. Don’t fool yourself into thinking Roblox is doing any good for these platforms, unless a game is insanely low end or specifically optimized for these platforms it’s gonna suck playing any game on them anyways.
How am I being selfish? I just suggested (disproven by stuff, apparently i was wrong) that <=2GB Android “low-end” users were a minority Roblox should stop catering to so much (note that I don’t have data to back this up for Roblox in specific; i’m going on the general trend in the tech space as of lately which is “phones have been powerful for a very long time”. Android too, even Google and Samsung’s cheapest phones are great with performance. I’m not sucking up for apple here lmao).
A statement like “i wish the engine had more advanced features and rendering” isn’t being selfish or “going against the entire playerbase” it’s just a basic wish considering the majority of players either run on competent computers, midrange/flagship phones (or even “low end” but not by an extreme standard like “2GB memory”), or other devices capable of running Roblox better than what the engine pushes in its current state. My original post was mostly a misinterpretation of this feature not being added due to memory management concerns - an issue for the most part nonexistient on desktop platforms and some higher end phones (S24 Ultra has 12GB and iPhone 16 Pro Max has 8 I believe?)
If the goal is “as least memory as possible on Android” then there is some room for improvement but generally things are all OK right now. On Sober (the android apk on Linux), the client sits on a baseplate at 600MB of memory, 53ms ping, and is chilling at the FPS cap. Assuming Android is idling at 400MB that leaves Roblox a gig to do whatever. This issue will become nonexistent in the coming years as memory becomes cheaper and even “ultra-budget” phones seen in 3rd world countries will get more sensible amounts like 4GB and even 6.
This is fairly immature. Once again, you’re misreading my post. I said I think it should be the game developer’s responsibility to optimize their games, not “Roblox should optimize their engine and feature priorities over me and people with RTX 4090s and 32GB of memory!!” but if Roblox is looking to a feature where professional studios consider them over going with Steam and Unreal/Godot/Unity then a change needs to happen.
I am not going to get into another debate over that because I just had one last week over here:
It would be more optimal for SetFaceColors, SetFaceNormals, SetFaceUVs, SetFaceVertices to have 3 separate vertex arguments instead of an array of vertices.
It is incredibly inefficient to create a table each time you want to change the face color (or any other attribute). Especially considering that meshes can have hundreds of faces, therefore the overhead of creating a table for every attribute across every face adds up quick.
When I was converting my EditableMesh terrain system to use these new APIs I saw a .2 degradation in speed.
You must also remember that even with a 4gb device most Android mobiles use a significant percentage of that RAM for the Android platform, and background apps. This can mean a 4gb phone can easily have less than 2gb free for Roblox.
Bro, you can’t even run a baseplate game on an iPhone 6s (that has the most optimized software to spare for Roblox). I think your corporate leader should give up on even trying to hold us back from progression.
Or…they can make the features but make it exclusive to mid-range+ devices and allow developers to lock the game to certain device. (And it’s the developer’s choice to)
(And it’s the developer’s choice to)