Arwill

You mean like #define + #ifdef?

The problem with GUI settings is that the result is not apparent, and there might be side effects. I do not find spending half day on trying out setting combinations as productive work.

I have looked into SRP and i do still consider that as an option, and also replacing the shaders. But i have doubts regarding the SRP, for example i have looked at the code that sorts lights in Forward+. The individual light calculations are not much, but its still done trough the job system. I imagine if there are hundreds of lights, then that would make sense, but for 2-5 lights, it seems like a waste. So it might be optimised to scale, but not for my case.

Is the effort of replacing the SRP worth it, and is the performance comparable to putting together/reusing an engine in C++? It is also a bigger commitment, as it needs to be coded on a different level and in a way very specific to the engine. Better than having to reverse asset file formats, but still very specific to the engine.

>On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea.

I would say its the exact opposite to that. For that genre, its best to roll your own engine, or pick something open-source. The list of problems that i firsthand experienced:

There are lots of features and options in the engines, but they are not all usable at the same time. One feature disables the other. You look at the list of all the nice things the engine can do, but then at some point you figure it can't do (or can't efficiently do) what you absolutely need. All those awesome looking graphics are not practically usable, simply not performant or not compatible to be usable.

There are features that only work in "baked" mode. You "bake" it in the engine editor, and there is no way of changing that at game run time. Unreal is the most limited in this, but Unity is not much better. Some game developers reverse-engineer Unity internal asset formats with a hex-editor, so that they can change feature behavior at runtime. At that point, rolling your own engine makes more sense. One example i saw was a developer reverse engineering the light probe group asset file, so that he could add a new light probe group at runtime.

Engine API's change drastically from version to version. All the code and scripts need refactoring, all the time. You run into a breaking bug, and the only solution is upgrading, but upgrading means breaking your whole codebase.

You need to go trough the engine's abstractions, and bad luck if that can't be done efficiently. An example of this: Unity HDRP applies screen-space ambient occlusion (among other effects). It applies the effect over the whole screen. If there is a third-person view of the character from close or first-person hands/weapons rendered, then even over that. That results in a white halo around the first-person hands/weapon, looks bad. In a custom engine, the solution is simple, apply the full-screen effect before the first-person hands are rendered, then render the hands without the effect. Its a matter of switching the order of a couple of lines of code.

The solution is github and the BSD/MIT/Apache licensed game engines and libraries.

Its not about transparency, it about what the interviewer assumes about you, first hand. Just like you assuming that whoever is looking up things must be doing it in secret, with the intention of cheating.

Interviewing has also become harder too. You try to search the net during the interview, because you forgot the name of a thing, and the interviewer will assume you are running with an AI chat, and are cheating the interview.

Project managers and consultants do actually write those documents/specifications justifying the work before the programmers get to do it.

Using UTF8 internally and converting strings for W API calls is a way to gain some performance.

No, those domains are completely fine, they are just marked as untrustworthy on some obscure google list.

Stigmatised would be when it commonly/publicly has a bad rep.

I remember transferring all my dads files from his Spectrum to a new PC with a serial cable, and then getting to have the Spectrum for myself. The serial cable worked surprisingly well, on the first try.

Light/material calculation in shaders requires exponentiation, which is a costly operation. If a clever lookup table can get around that, it sure can be faster.

If anything, then events like this makes decision makers rethink if they really should run Windows everywhere. Why does a flight schedule display has to run Windows, for example? It might not be their fuckup, but they will lose users too, for sure.

Sometimes this kind of error handling is the cause of program slowdowns. So the API fails, but the program retries anyway, and so fails again endlessly. The user doesn't see anything from this happening, only that "the app is slow". Windows is plagued by this kind of behaviour. Its both what the article suggests can cause this, but throwing and ignoring exceptions can have this effect too.

The goal, IMO, would be to force the app not to try (or not to try once it failed) something that is bound to fail.

Each level of abstraction has its own caching and buffering routines because the underlying layers are slow, and without the ability to make them better, you can only put your own cache on top of it. This helps initially, but in the end, the time goes wasted managing all those caches and buffers at every given layer.

The hypothesis is that these black holes were not created from stars, but exists from right after the big bang.

https://en.wikipedia.org/wiki/Primordial_black_hole

The principle is that you should be using the underlying API if something is already solved on a lower level, and not replicate the functionality on a higher level, because it will perform poorly. There was a reason why the lower level API exists in the first place.

This applies to graphics programming very well, its not a question that you wouldn't be making your own pixel rasterizer instead of using DX, OpenGL or Vulkan, for example.

The big recognition is that when doing business apps, SQL database functionality is the underlying API, and you should prefer using that.

The way i understood it, they wanted to track their competitors users.

Its not called "hooking into", building your own UI's is the expected and proper way of working with SAP now. SAP even provides the tools for building your own HTML based (simplified functionality) GUIs. There will always be power users who will fix data in the backend directly, but working with custom GUIs is the way to work with SAP.

I don't think photons are absorbed and re-emitted by electrons. At least that argument does not hold when discussing light slowing down in glass or water. Light is affected by the electromagnetic field of the material it is going trough, is slowed down, or absorbed based on some of its property, but photons that go trough are going trough without collision. Photons that get absorbed and re-emitted are scattered in all directions, and are mostly lost. You would not see a consistent image trough a polarising sunglass, if the photons you were seeing were re-emitted photons.

The geometric description of the universe is a high-level description of the universe, but its just a description, its not what fundamentally is. The large-scale universe emerges from the low-level behaviours of its smallest parts, the particles and the vacuum.

Causality is not a product of the universe, but the other way around.

Its technically not a single header, but almost. I was thinking about litehtml.

Specifically this recipe: https://twitter.com/ocornut/status/890210588600565762

I am already using ImGUI, and its a bonus if i don't have to include another font engine.

I am a big fan of single header libraries. And libraries that i not just link to, but which i am allowed to reuse and compile myself. Then i gut that library and remove everything i don't need. Less code, less space, less runtime and less potential bugs hopefully.

For example there is a single header library HTML renderer and its fast, but does not run JavaScript.

And there is for example Chromium, which is the complete browser experience, but its 10GB source code, no sense in trying simplifying any of that.

SIMD vectorization is like quantum mechanics, it becomes classical if you look.

I am actually excited when seeing a historical movie without epic exaggeration. Recently this TV series was my favorite: https://www.imdb.com/title/tt10405220/

It presents a primitive material reality, but also the culture and supernatural beliefs.

It doesn't have to be without monsters, it just have to portray them according to beliefs of people of that time, and not according to our modern interpretation, or modern appeal. It could be an opportunity to also document ancient societies, culture, mythical beliefs too.

An addition. Also make a survival mode, where you are not just sightseeing safely, but also have to survive whatever is happening.

A serious time travel game.

Think of MS Flight Simulator or Google Street View as documenting the current world. Then take the same approach to thoroughly document the past. The locations, the events, all in 3D VR with realistic graphics, and simulated actors that react to events and react to the players.

Take the current knowledge and physical/archaeological remains of the past, and digitise them, digitally renovate them. Do this rigorously and professionally. Not Hollywood-style approximation, but the work of real historians and archaeologists. Let historians use it and debate the details how it should really look, or how the events really unfolded and adjust it accordingly. Organise the database of content and simulations. AI is possibly already there to automate processing and conversion to 3D of old videos, photos and paintings, even perhaps writings to animation scripts. If not yet, some AI researcher is surely working on that.

Make a VR meta world, where players can travel to certain locations and certain time and interactively take part in the events.

I would pay a monthly subscription for such a thing, to see the past getting recreated digitally. It would be the next best thing we actually could do, compared to real time travel.

Its not trivial, but it is widely understood that fonts baked into GPU texture is the way to go for fast text rendering. The decision, if they care about performance, should have been trivial, their listed excuses are not valid.

Dear ImGUI also does this, and while font baking is not trivial, integrating ImGUI is almost.

Search for Quake 3 Arena networking, it is what defined how multiplayer networking is done. The source is on github, and there are explanations on the net. With a quick google i found these:

https://fabiensanglard.net/quake3/network.php

https://www.jfedor.org/quake3/

I agree, someone speaking multiple languages will not suddenly become good at programming.

But there is a study that showed, that talent for languages matters more for programming skills than talent for mathematics.

Read somewhere that neutrino particles are interesting in this regard, as they travel straight trough the earth.

>if they picked an off-the-shelf engine

I would add an anti-pattern in contrary to that: engine duct-taping.

There might be a specific solution in the engine for a problem, or in the underlying library/graphics API, which a developer could make use of/could unlock. But the level/game designers chose to build solutions on top of high-level engine features, which leads to poor performance, bugs, glitches and unwanted side effects.