JoeyJoJoJr

But the human hand was designed to hold a banana.

I’ve actually found Sol delivers great results with Odin, despite there not being much Odin code available. I think it is able to work well with it because:

- It is a rather simple language - It has a lot of very useful libraries already built in.

With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.

I have personally had three conversations (2 online, 1 in person) where the other person has said, almost verbatim, “I have never had a typing error in JavaScript”. Two of these people were people whose work I respected, so it could not understand how they could possibly hold that position.

I would say yes, but only because I have played that game to death since childhood and would really only play it now with a more analytical/developer mindset, so the illusion is no longer present.

For 2D games I can usually tell if it is made in Unity, and I don’t even develop with Unity. Hollow Knight for instance does not get me immersed like I do for Celeste or Bolatro. When I look at Hallow Knight I see moving animated sprites instead of characters, and it’s like that for the majority of 2D Unity games for me.

Sorry, but we aren’t at the “press a button to build a game/app” yet.

I don’t think it’s an outlandish take at all. You can possibly also put orthotics and spectacles in the list of interventions as solutions to problems largely induced by unnatural adaptations to an unnatural environment.

A partial solution is to put DD/MM/YYYY (or the appropriate format) as the input placeholder. You could also display the format as a tooltip when the input field is focused. IMO this is better than dealing with date pickers.

I’m not the commenter that you asked, but I have also built a cross platform game framework with backends for SDLGPU and WebGL. The answer to your question is pretty basic. AI did it for me.

I asked it to create a canvas-like API, noting that it should create platform independent code. The canvas API populates arrays for vertices, indices, and other relevant things relating to draw batches. My game is built on top of this platform independent canvas code, and is itself platform independent.

Then you have the platform code, which simply reads the memory of those arrays and does what it needs to do to draw it in its environment. I have barely looked at the platform code but it seems to just work, and it is really performant. It around 1000 lines of code for the web target. The key is to use shared memory as the bridge between the compiled WASM code and the platform code for draw calls. As I said, it’s mostly just arrays of vertices, texture ids, and indices.

It took me some thinking on how to define textures in a platform independent way, but it all ended up working well. I bounced some ideas with the AI to come up with a solution just using ids.

From there I just kept adding more features, FMOD support, shaders, etc.

Edit: Oops, I misread that your comment was referring specifically to getting Monogame on web. I thought I’d leave it here anyway though because it might help you. The key insight for me was that the canvas API (and Monogame as well) is just batching up vertices, indices, into draw calls, before the platform specific stuff happens. I realised this after investigating how the Spine animation software was able to achieve so much cross platform support (it’s just providing triangles with texture ids to platform code). You don’t need any concept of a platform to represent the entirety of your games as triangles associated with texture ids in memory.

I’m not at my computer so I can’t remember the exact behavior of this situation, but was OP more so referring to autocomplete abilities of typescript? I think they were saying, you first must know if the object barks or meows, you must first type that in in order to get the benefit of type checking and subsequent autocomplete conditional body, which is annoying when you are dealing with complicated types. It requires you to do some hunting in to the types, rather than using a piece of code more like an interface.

It depends on what you are doing. I really like it for creating animated characters. Resprite has some nice feature for creating tilesets. Standard raster editing software might be better for big static scenes.

I’d highly recommend going with SDL if it’s 2D. IMO libraries like MonoGame, Love2D, LibGDX only offer small conveniences over SDL with big negative tradeoffs, sacrificing portability, quality of libraries, and conventions. The downsides of using C++ are now heavily mitigated with the use AI tools.

I could never jell with C++ until I had Cursor hold my hand (especially around the build system), and now I feel like I am developing games with a razor sharp knife that I could never before access. The patterns associated working directly with memory suddenly clicked and now it’s the only I want to build games.

Such as?

I’m not criticizing the library of SNES. I have very fond memories playing SNES games. It was more in response to the statement that there are dozens of 10/10 games on SNES. Let me clarify, there are not many 10/10 games on SNES (or any system for that matter), let alone dozens.

This might be a nitpick, but I could probably only count 5-10 SNES games that would be considered 10/10 IMO, and not many that I think are worth sinking decent time into these days, compared to something like Burnout Revenge - a great game but certainly not a 10/10 game.

Still, I do find the SNES library, and 16bit games in general, quite astounding from a creative and artistic perspective, but not so much from a player’s perspective.