Requesting Help -Problem Description: Clearly explain your issue, providing context and relevant background information. -Relevant Code or Content: If applicable, include relevant code, configuration, or content related to your question. Use code tags.
Why is 3D so much harder than 2D! I can a shitty version of any 2D game in a couple days. But 3D? There just aint no fucking way! 2D puzzle games - EASY! 2D playformers - NO PROBLEM! 2D Top Down Zelda Stuff - PIECE OF CAKE! Then you go literally just 1 console generation into 3D - Mario 64, Golden Eye, Spyro, Crash Bandicoot? JUST FUCKING IMPOSSIBLE! You need a million fucking 3D assets for the most simple level, enemy AI is retarded compared to how fast you can put together a half decent 2D ai, hit collision is brutal, nothing fucking works, everything is glitching through everything else, the lighting is awful, the worldbox looks like trash, and some how your 20 poly character animations lag and break the armature or weight painting or something. It's all just a cluster fuck!
00
Anonymous06/10/26(Wed)18:23:28
>>109024223 It’s just how it is. 3D adds another dimension, that means more shit.
00
Anonymous06/10/26(Wed)18:25:18
>>109024223 just use godot and be done with it nigga
>>109025568 I actually happen to be somewhat of an expert in this topic. But your question is very vague and what you mean drastically changes your answer
>1. Make an X or Wayland window and draw into it in software. This is perfectly reasonable, but software rendering really struggles with modern resolutions and refresh rates, at least when we're talking about something highly interactive like a game. >2. Make an X or Wayland window and draw into it in hardware, without using the userspace drivers. This is fucking insane, and an unbelievable waste of time and effort, unless you get a kick out of trying to implement GPU drivers yourself. It is also hardware specific. >3. Not use a display server at all, and drive the screen yourself Don't do this. Unless you're actually writing a display server, you have no business touching these interfaces. I actually find the DRM/KMS system quite interesting, but you clearly come off as someone going at it for the wrong reasons. You're not going to unlock some kind of supreme hidden performance or whatever you're expecting to find. Nobody is going to run your program if it works like this.
Then you have the same thing as above where software is slow, and no OpenGL or Vulkan is fucking insane. Wayland compositors still use OpenGL (usually ES) or Vulkan here.
>>109032161 are we talking before or after hardware t&l
00
Anonymous06/11/26(Thu)20:11:38
>>109032161 Just write the most basic passthrough shader you can imagine and congrats, you have the same visual style as DX1-8 without the jank or compatibility issues.
00
Anonymous06/11/26(Thu)20:19:29
>>109029705 ok gotcha i was hoping X/Wayland could provide me with fast enough buffers by themselves but if they don't, drawing on a gpu texture it is
00
Anonymous06/11/26(Thu)20:48:38
>>109032422 use sdl. it doesn't go through the gtk or qt gui frameworks. it jockeys its own resources in the display manager and provides its own image buffer types that you can draw on with the cpu if you really want to go that way. this is what all the doom sourceports do for their software rendering.
New feature! You no longer need to rename your created tracks to take the place of existing tracks. >Creates TRACKS folder in same directory as binary if it doesn't exist >Accessible with space/cup switch button in track select menu >Always available no matter what cups the user has unlocked >Not available in championship mode, only single race/time trial >Arrows from replay loading file menu re-used >Lap records saved to TRACKS/RECORDS.REC and based on track CRC >Network play works if all players have track file with matching CRC, if not TRACK NOT AVAILABLE text will display and prevent readying
00
Anonymous06/11/26(Thu)20:51:56
>>109032624 this is like nascar 1999 x need for speed born out of some kind of fever dream.
00
Anonymous06/11/26(Thu)20:52:35
>>109032422 With both Wayland and X (if you use the appropriate extensions rather than the ancient shit), you use normal shared memory for software buffers, so the protocol itself doesn't really get in the way when it comes to efficiency. XWayland can pass it through with no extra copies too, so isn't an extra source of inefficiency, at least in terms of pixels over the wire. GPU buffers are similar, but instead are a dma-buf, which is just a handle to some GPU memory instead of some normal memory, plus some extra shit about tiling layouts, because GPU buffers aren't as simple.
When I say software rendering is slow, it's simply that the CPU is nowhere near as good at punching pixels into a buffer as a GPU is, but is definitely doable, and could be SIMD optimized if you're into that shit.
00
Anonymous06/11/26(Thu)21:23:01
Do you guys use public / private encapsulation for your projects or do you just make everything public?