t8y

IMO the article is better advice than the parent comment.

Learning from Unreal or even Godot to write a basic renderer is pretty wild. It would be like telling someone who wants to make a model rocket that they should study the Falcon Heavy.

Making a basic renderer in c++ is orders of magnitude simpler then trying to deconstruct a game engine that(according to google search) has over 2million lines of code.

The book RayTracingInOneWeekend[1] is a good starting point for people looking to write a raytracer.

[1]https://raytracing.github.io/books/RayTracingInOneWeekend.ht...

I didn't know that constraint propagation existed. Having a quick look it does look the same.

In the in the original WFC(wave function collapse)[0] versions it always used an example of a completed output and generated all valid tile combinations from that. For a game this means that the developer can use hand made maps as examples for it to create new plausible maps. In the common vernacular WFC doesn't use this step and just directly either generates what combinations work or the devs manually decide what tiles can be next to others. Perhaps only the combination of both steps should be considered WFC.

Just to guess I think this is probably a case of it being developed independently in different fields. It's good to have another name for it as I always hated it being called "wave function collapse" when that is a physics thing.

[0]https://github.com/mxgmn/WaveFunctionCollapse

This uses the "wave function collapse" algorithm. Oskar Stalberg also made a great demo of how it works[0], but it might not make sense just from that. Martin Donald made a really nice youtube video on how it works[1]. The name "wave function collapse" can be off putting but it's pretty straightforward, and an algorithm that can come in handy for many uses both in game development and just general software development.

I'm actually procrastinating on HN from working on a GPU parallelised version that can generate millions of positions every frame. In Townscaper you can actually see that the algorithm runs quite slow and lags behind the players input, there's just a bunch of animation to hide it. I'm hoping to eventually get a version that can run in log2(mapsize) time.

[0]http://oskarstalberg.com/game/wave/wave.html [1]https://www.youtube.com/watch?v=2SuvO4Gi7uY

This is only possible in WebGL 2. There's a texture fetch in the vertex shader for the particles. The water demo is so impressive because it runs in WebGL 1 (Though it needs partial derivatives)

Someone writing a photo or video editing program could use this technique to process images fast. Instagram used to do filters on the CPU then changed to a shader version for a huge speedup. I use JFA in a game to generate outlines of 2D characters that are procedurally generated in the app. Also the JFA is a way of generating voronoi diagrams in log2(textureSize) steps and could be used for anything that uses voronoi diagrams. Generating a distance field is just one use.

I think there's lots of good things about GB Studio I just didn't want to write some kind of HN manifesto on Game Boy game development. For example I'm sure with GB Studio it's possible to run into hardware limitations like sprites per line, music causing lag etc.

I worry about things like this trivialising the difficulty of the past. Something like this is more like modding a game than making a new game in terms of tech. It makes it seem like it's really easy to make a Game Boy game, when the creators of this put in heaps of work (more than just making a game) into making a tool that gives people the ability to reskin their base game.

Homebrew that's designed to run in an emulator isn't the same as running on actual hardware either. In the past people had to think about things like how to fit a 20hr RPG into less than 1MB. Now you could make tile sheets for each room because the game can be much shorter. Other things like how art assets can look good on a modern LCD monitor when on an actual Game Boy they would be a blurry mess also contribute to a misunderstanding of retro games.

People already have an unrealistic view of "retro" games because in GameMaker or Unity it's easy to have 1000s of sprites, shaders and 32bit colour(You can even have HDR sprites if you want) when that isn't possible on the actual hardware.

I'm not trying to hate on GB Studio it looks great, just some thoughts.

I think this is using the HTML renderer. On any other platform it would be using Skia and should be faster. The author could compile the app using Skia on WebGL potentially giving a speed boost.

Usually a 3D artist would retopologize the model in a tool like ZBrush. For some models they are automatically "decimated" where the model is simplified using an algorithm. Decimating is not that common though in high end studios though.

With Unreal Engine 5 a feature called Nanite is supposed to allow high polycount models to be handled without preprocessing using some kind of runtime algorithm that simplified geometry.

These models also need all the lighting information extracted and turned into textures for use in a game engine(albedo, metalness, roughness etc). Most tools for automatically extracting the lighting information get it wrong most of the time leaving the artist to recreate it with a tool like Photoshop.