Thread 106974912

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

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

Previous:
>>106939581

>>106974912 (OP)
Comfy as fucc

Cool tee on Carmack.

>>106974912 (OP)
What tools would a modern gang of Johns and Carmacks be using today? They more or less invented Windows gaming while using a Unix flavor to make their own engine and other tools.

Remember:
just make cool shit. If your shit isn't cool stop and make something cool.

>>106975358
So you're telling me that I just need to mek gaem?

>>106974912 (OP)
Did /gedg/ die?

>>106975324
>while using a Unix flavor
Doom was written on a NeXTSTEP, which was created by Steve Jobs and has a more or less direct successor today in macos
today's Carmacks are no doubt also using macs, they just work

>>106975992
And they went with Windows after Quake because the price to performance was better alongside support for other parts of the system. Today's gang is probably using Windows while eyeballing Linux really hard. The NeXSTEP was a wonder but it's time was short.

>>106976123
>it's
it is time really was short

>>106975955
people are afraid of making the op

>>106976123
>I use WinNT, Win98, MacOS 8.x, and linux on a regular basis. I also spend some time with MacOS X and irix.
>NT is definitely going to be the primary development platform for our next project, but I will be evaluating alternatives for a possible transition after that. The contenders will be linux and MacOS X.
>Linux has progressed a lot in usability in the time since I made the last platform decision. Sure, the guts have always been good, but the user environments were very weak compared to windows or the mac. Some people may think six xterms and a few athena apps are all the UI that anyone should need, but I disagree.
- Carmack, 1999 (https://games.slashdot.org/story/99/10/15/1012230/john-carmack-answers)

yeah, pretty much. Funny how absolutely nothing has changed since the past millennium.

>>106976346
windows became so bloated that you get more performance while through wine
it will only get worse, unless they fire the jeet CEO

>>106976422
The problems and various schemes are much older than Sitrep Nutellaman.

How should I start my own video game development company? What do I need to do to put together a team?
>>106976141
Nahh, we're just too lazy.

I got sidetracked going through factorio devlogs, I guess inheritance and virtual calls didn't matter for them performance wise.

>>106976346
Seems kinda obvious to develop a game on windows since that's where your players gonna be. The same way that if you write server software you ought to be on linux. I did game dev for a bit with mingw to compile and a vm to test but if you were doing it professionally you'd want to clean up the workflow.

Trying to decide if this is correct for undamped distance constraints or if there's a bug still.
Looks sorta glitchy to me.
This physics shit is gonna be a pain in the ass to debug...

>"Go deliberately randomizes the order of keys when iterating through a map"

guess who had the bug that only happens when it 1/100 starts with index '0'

here's how:
>unit structs are stored in map
>remember their index in the map
>when moving units around, we're actually just moving their indexes.
>BUG: When instantiating our team units, we accidently fill up the entire grid with default index 0.
>this normally doesn't matter. When we try to fetch an index that doesn't exist from the map we'd probably just silently fail or something (idk why it was like this)
>but when adding a new unit, while iterating through the unit map trying to find an open index, if it happened to check index 0 first, the real unit would have its index shared across all grid slots on the map.

>so during my animation, it would check all those index '0' slots on the map, and apply animations to the unit with that index.
>my unit goes flying across the screen at 5x speed

thanks for listening.

You DO need an ECS.

>>106978130
abstraction is a dev consideration, anon.

>>106976130
Oh, you fag

>>106978130
You can make anything run fast. Discussion about OOP or ECS or whatever flavor du jour is a subjective/stylistic matter. What is necessary is smart programmers who can get the job done with whatever tools or paradigms they prefer.

You can optimize OOP code to be very performant when needed. Granted the optimized code will often end up looking like SoA/flat arrays by the end of it as that's what runs fast on modern CPUs, but at that point it will be an optimization, not a stylistic/organizational decision.

>>106974912 (OP)
Hey guys.
I want to make an 2D RTS game, have it a bit laid out.
Where do I start with learning Godot?

>>106976130
turbofaggot

>>106982584
Learn Python first

>>106978842
I guess it looks right? A bit deceptive cause the constraint is also pushing if it's too close.
Pretty cool how this is not hard at all to do with XPBD and chat gippity.
And it's embarrasingly parallel so I can just put this in a compute shader an get mega physics perf.

>>106981375
yea they're pretty great. In fact, I think you should have 2 at least.

Go! Buttox!

...I screwed up the ear scaling.

>>106982664
let him have his time to feel smart

>>106979649
Sounds like you have a map from int to unit, and a flag in the unit struct to say whether it's currently in use? At least that's what it sounds like based on you talking about iterating over the map in hashtable iteration order trying to find an unused index. If that's the case, why not use an array instead of a map?


Anyway, here's mine:
>testing out multiplayer
>with 3-4 players connected, the server segfaults roughly once every 30 minutes on average
>seems to only happen when a player is either connecting or disconnecting
>build a little stress tester that connects and then disconnects hundreds of times in parallel
>server reliably segfaults in 5 seconds or less
>backtrace points to the destructor for my custom channel type
>specifically the part where it destroys any leftover messages
>add some debug prints
>"ringbuffer size = 16, offset = 14, 4 messages to discard"
>"discarding idx 14"
>"discarding idx 15"
>"discarding idx 16"
>segfault
>check the index calculation
>instead of doing idx % size, it checks if idx > size and subtracts size if so (division is slow lmao, and idx is always < 2 * size)
>change > to >=
>no more segfault
I honestly have no idea how this ever worked at all. Some code paths would correctly wrap at 16, while others went through this broken function that wraps at 17 instead, so I feel like messages should have been constantly getting lost in that gap, causing major problems even outside the stress test.

I feel like im going insane trying to understand the most basic concepts, can anyone help me out, why is it saying the eye is at (0,0,-1) relative to the projection pane? By their definition of camera space the z axis is going from positive to negative, so the eye should be at (0,0,1) given this definition of camera space, unless all is thrown out the window when talking about relative positions

>>106984803
meant to say (0,0,1) relative to the projection pane that is

>>106984803
Would have helped if you had provided the link:
https://nicolbolas.github.io/oldtut/Positioning/Tut04%20Perspective%20Projection.html
It seems like this tutorial is explaining things in a particularly convoluted way. But piecing together their definitions from the "Mathematical Perspective" section, Figure 4.6, and a bit about the projection plane under Camera Perspective:
>the eye is at 0,0,0
>the eye is looking in the -Z direction
>the projection plane is at Z = -1
And the space where these hold is called "camera space", I think to distinguish it from "world space", where the eye could be anywhere and looking in any direction.

Looking at the part you highlighted, I think you are correct: the eye's location relative to the projection plane is actually (0, 0, +1). But it looks like they're then deriving important things from the incorrect -1 version. I don't know this material well enough to say how they managed to get (I assume) correct results out of this incorrect derivation.

>>106985011
someone even raised the issue like 12 years ago, from the authors reply I still dont understand it
https://github.com/paroj/gltut/issues/76

>>106984803
>>106985011
Basically I think you should try to find a better tutorial. But here's the short version AIUI in case it helps:

The way you do perspective in general is by dividing X and Y by Z (or maybe -Z, depending on how you set up your coordinates). Things that are farther away have larger Z (or at least larger abs(Z)), so this division makes things smaller when they're further away. In graphics programming, you actually don't want to do this division yourself—it's better to set W = Z (e.g. gl_Position = vec4(x, y, z, z)) and let the automatic division by W take care of it for you. The reason to do it this way (AIUI) is the GPU uses the W value to do perspective-correct interpolation on your varying values (e.g. texture coordinates). If you divide it yourself, you don't get this, and things will look wrong.

You'll see some stuff online about near planes / far planes / viewing frustum and such. These are specifically to do with the depth buffer, not perspective as such. The only limitation in the perspective math itself is that you can't have objects at Z = 0, since you'd have to divide by zero. However, when you're using a depth buffer, the depth buffer has a finite amount of precision. Basically you're picking a minimum (near) distance and maximum (far) distance and stretching out your 2^16 possible depth values to cover that range. The further you stretch it, the more space there is between any two consecutive depth values. Everything you render has its depth rounded to one of those 2^16 values, and if you ever have two objects whose depths round to the same value, the depth buffer can no longer distinguish which one is in front, and you get Z-fighting. So you have to set near/far planes to avoid stretching out the depth buffer too much.

>>106985167
funnily enough this book is recommended by the khronos group, https://docs.vulkan.org/tutorial/latest/00_Introduction.html

im gonna stop trying to make sense of it and just move on, its been helpful so far anyways

>>106985111
actually meant to link this issue, https://github.com/paroj/gltut/issues/70

it doesnt matter anyways he doesnt address the actual question

>>106978037
>What do I need to do to put together a team?
money

>>106978130
"OOP / inheritance / virtual calls are bad for performance" is misdirection for brainlets

I'm too lazy to refactor, so I invented member aliases compatible with non modern c++. Works with nested members too.
// War crimes
template<typename Type, typename Parent, Type& (*Getter)(Parent&)>
struct MemberAlias {
typedef Type AliasType;

inline static size_t ptrOffset;

MemberAlias(Parent* parent) {
ptrOffset = (char*)this - (char*)parent;
}

MemberAlias& operator=(const Type& color) {
Getter(*getParentPtr()) = color;
return *this;
}

Parent* getParentPtr() {
return (Parent*)((char*)this - ptrOffset);
}

operator Type& () {
return Getter(*getParentPtr());
}

operator const Type& () const {
return Getter(*getParentPtr());
}
};

>>106986041
Don't clever too close to the sun.

birb
Added more options to the shaders to help keep the noise down and morph instanced sphere shapes.

>start working in Vulkan
>5000 extensions deprecating integral chunks of the API
>but it's all a janky mess because muh 1 guy on a Linux distro from 2005 might not have compatibility
Say what you want about Apple but at least they don't do this shit and actually get rid of deprecated stuff.

>>106988106
In a hindsight apple is not even that bad when it comes to that. Android on the other hand
>have to update the android app to keep it public
>manage to avoid full scale update of every single component by some miracle yet again
>literally day later another notification comes about the 16kb update

>>106986605
depth of field looks like shit on pixel art

>>106988106
why do you care about guys on 2005 distros? are you retarded?

>>106988106
Targeting old hardware is fine.
Targeting old software is retarded.

Of all of the "deprecations" (they're actually not) and major changes to some of the fundamental parts of the API, most of them (dynamic rendering, synchronization2, etc.) had compatibility layers on top of the older APIs, so there really is no reason not to use them.

>>106990422
agreed

i would be so much further along with my engine if i wasnt so autistic

I dont care what carmack did fuck you

>>106993163
He made some outstanding games.

Got the basis for Cook-Torrence working. Although specular is appearing much smaller than it should be. At roughness 0.1 it’s appearing as a cm sized instead of the well known inch sized dot. I think something’s wrong with the normal distribution function.

The basis for PBR is now here. There's a lot of variables you need to keep track of and ensure are correct. Roughness is clamped to 0.05. Now I need some form of reflection capture to get proper looking metals. I also want to experiment with some of Disney's methods, also Unreal and Destiny 2.

>>106994801
>PBR
All that extra work just to make things look more soulless.

>>106995096
PBR is just glorified Blinn-Phong. The real soullessness comes from all those wanna be digital camera effects. Exposure, Bloom, Grain, Chromatic Aberration.

>>106995334
>PBR is just glorified Blinn-Phong
no its not

>>106995362
YES it is

>>106988106
Some of the extensions can be provided by layers that emulate them for implementations that don.t support them. I never tried it so maybe it's all fake and gay.

ZERO PROGRESS from anyone in here what the fuck man

My to-do list:
>cascaded shadow maps (for directional light)
>point light shadows (cubemap array)
>screen space shadows
>screen space ambient occlusion
>screen space reflections
>bloom
>proper tonemapping (handling the finalized hdr buffer in its own pass)
And then finally I can get into the game dev stuff. And that doesn’t include optimizations like vertex compression, frustum culling, light culling, etc. There’s a depth prepass but that’s only because ssao needs it in a forward rendering context.

>>106997656
i went from a pic of a pepe to this if it counts

>>106997733
These are all multiple-week rabbitholes, maybe consider doing all the game dev first?

>>106997656
>ZERO PROGRESS from anyone in here what the fuck man
Because I haven't even started! Like I don't even know what to ask man!

>>106997656
I fixed a bunch of bugs just this morning

>>106997656
Why would you come here if you're making progress

>>106997921
The only thing here that might take more than an hour is SSR. The foundation for everything is already setup.

>>106997948
(you)s

>>106997957
Godspeed. I'll check in next month to see how your implementation of CSM is going.

>>106997989
Wow you’re retarded

>>106997656
>ZERO PROGRESS
Story of my life.

>>106997957
I don't think you can do any of those in an hour except for bloom and tone mapping

Kind of weird how bitsets are 4 bytes at the very least. Just made my own template that swaps aliases between regular bitset and smaller versions.

>>106978037
>we're just too lazy
This board's bump limit is too low.

>Speaking of which...

Been listening to Romero's Apple Time Warp podcast interview with Nasir Gebelli. Pretty insane how he coded his Apple // games, typed commands into Woz's mini-assembler like anyone else would program in BASIC; keeping track of locations and things in his head. And seems things didn't change much when he worked on the Famicon.
https://www.youtube.com/@appletimewarppodcast1264/

>>106999850
you're literally me, but im so autistic that im not even including any std includes and write everything i need myself
#autism

>>107002109
I do that. I don't think I'm autistic. I just want fast compile times.

>>107002121
you're right, it is very fast

>>107002109
I am using std library but every now and then it turns out it's subpar. Unlike the other guy I want runtime performance.
std::set? Straight to the trash where it belongs. std::map and std::unordered_map? Completely replaced. std::vector? That's a static variable or custom pmr allocator.

any imgui wizards here?
i have a table with lots of entries for which i use clipper
how to focus and scroll a certain row into view?

>>107002567
ImGui::SetScrollHereY(); // Centered
ImGui::SetKeyboardFocusHere();

Well now that C# scripting basically died with Mono what's the best scripting method that ISN'T lua

I guess just writing native code is the least painless solution, but C# with mono felt like a really nice middleground where it could be embeded like scripting language but didn't have any scripting language retardation like lua's esoteric table system

>>107004583
*least painful

>>107004583
python

does anyone have any experience with kaplay? was looking into ways i could play around with javascript to further my understanding and saw some people recommending this. what are your thoughts? how is it vs phaser?

>>107004583
>Well now that C# scripting basically died with Mono what's the best scripting method that ISN'T lua
why did it die? If you like c# scripting maybe try embedding haxe via hashlink.

>>107005762
Because Mono was the only method of embedding C# that was easy to use and the last version of .net that it supports was released in 2018, in case you've lost track of time that's 7 years ago now

>>107005262
Not suitable for such performance sensitive applications like games, plus i'll be honest i don't really like python.

>but it's only game code
It's still a very big part of the project

>but new computer fast
Webdev cope

Thoughts on programming languages without implicit type conversions?

>>107006273
People actually use languages with it for anything but shitty websites that take 5 seconds to load a line of text?

>>107006408
C and C++ have implicit type conversions

>>107006273
you need to at least to do zero-extension/sign-extension unless you are designing a language for masochists.

>>107006542
how often are you actually converting between numeric types though?

>>107006273
Zig is pretty strict here and it works quite well, IMO.

>>107005762
>embedding haxe via hashlink
>Use HL/JIT for daily development (fast compilation time)
>Use HL/C for final release (best performance)
>HL/C and HL/JIT share same runtime and semantics
Never heard of this before but it sounds pretty great. How hard is it to set up as an embedded scripting language? Seems like the docs are mostly aimed at standalone Haxe programs. There are wiki pages on embedding and the Hashlink C API, but they're pretty sparse. In particular, I'm not sure how you're supposed to expose host-language data and functions so that Haxe scripts can call them.

>>107006875
docs are pretty shit last time I checked you mostly have to check out other projects that use haxe for scripting. I think armory3d uses it not sure.
Haxe is nice but it always assumes that you know what you want and that you go and read the code.

>>107006571
very often?

if i can't do
uint32_t x = 2;
int64_t y = x;
in your language then it's a bad language.

>>107007166
why are you very often using different sized numeric types

vump