stateoff

I don't know about this particular developer but I don't think there is anything "obviously" out of scope. I've worked in the animation industry and creating hard surface models with this quality is not really that hard for a skilled artist. As such I still stand by the opinion that it could be a solo effort depending on the developers background/skill.

I depends on the background. I'm 2 years into solo developing a game and all programming, artwork and animation is my own. I had to invest into quite some learning to make it possible, but I figured it's a worthwhile investment. I do work with a composer, though.

Point being, it depends on which skills you bring to the table, which ones you are willing to learn and which ones are worth collaborating on.

I still think the term Solo-developer is justified in any case. The one who soley carries the burden of bringing the game from idea to the finish line is the solo developer, IMHO.

A consumers tale about enshitification. Look to the sky and enjoy your ESPP everyone :)

"Raspberry Pi CM0 is a yet-to-be-officially-announced castellated Compute Module based on the Raspberry Pi RP3A0 SiP (System-in-Package) found in the Raspberry Pi Zero 2 W and Raspberry Pi Compute Module 3E (CM3E)."

More information on the chip here: https://www.cnx-software.com/2025/05/14/sifli-sf32lb52j-big-...

I was referring to Mozilla's past investment into advertising: https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...

To me that and the new ToS add up, why else would they remove the FAQ entry.

Absolutely agree. The blog post is claiming the opposite to what their ToS is granting - but one is fluff (that will be forgotten soon) while the other is legally binding. I cannot imagine applications like browsers that would require such an unrestricted license for user input just to do its service. That clearly indicates some "other" future motive that is underlined by the notion to remove the FAQ entry and other past actions towards an advertising future at Mozilla.

Am looking forward to explore some of the alternatives. And no, I don't want a just a correcting/updating/informing follow-up blog post of how we the users got it all wrong. In fact, the current UPDATE makes it worse:

"UPDATE: We’ve seen a little confusion about the language regarding licenses, so we want to clear that up. We need a license to allow us to make some of the basic functionality of Firefox possible. Without it, we couldn’t use information typed into Firefox, for example. It does NOT give us ownership of your data or a right to use it for anything other than what is described in the Privacy Notice."

vs. the ToS:

"You give Mozilla all rights necessary to operate Firefox, including processing data as we describe in the Firefox Privacy Notice, as well as acting on your behalf to help you navigate the internet. When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox."

No - you don't need a license for my input. Just pass the butter, it's not your job to "use that information" in any way, form or shape. How did you survive 26 years without any license to our input? What did legally change that would require that license? No one asked you to: "We use data to make Firefox functional and sustainable, improve your experience, and keep you safe." (from the blog). What does that even mean? If you have specific use-cases in mind state them clearly, instead of this overreaching general license, that may or may not be misused now or in future. As of this ToS you may very sell my data to AI companies to "help me navigate the internet" which is not even part of the Privacy Notice protection.

Reinstatement your privacy guarantees in the ToS and be transparent about explicit use-cases.

Meanwhile, so long, and thanks for all the fish.

Maybe, but SEGA seems to muddy their own case as their official support FAQ section [1] states: "Will I still be able to play the SEGA Classics games? Absolutely! All SEGA Classics games and bundles you own will remain in your library, ready to be downloaded and played at any time."

Note the "you own" here that is in dispute with the Steam user agreement.

[1] https://support.sega.com/hc/en-gb/articles/29776767664145-SE...

xetdata is retired and recently became part of hugging face. I wonder if nfsserve will be still supported.

Are there other recommended NFS server codebases?

Examples will be based on this repo, I believe: https://github.com/TheSpydog/SDL_gpu_examples

This article from the main author of the API describes how the buffer cycling works: https://moonside.games/posts/sdl-gpu-concepts-cycling/

If it came in a yellow and not a blue bag, we should have known.

Gamma should not have any effect on the alpha channel, which is linear by definition. The alpha channel represents the average coverage of (infinite) subpixels within the pixel. The color encoding of an object should not have any impact on the coverage within that pixel.

I recommend reading the technical memo "Alpha and the History of Digital Compositing" by Alvy Ray Smith [1] to get a better intuition on the matter.

[1] http://alvyray.com/Memos/CG/Microsoft/7_alpha.pdf

https://laion.ai/faq/ Based on the FAQ of the dataset that was used for training of https://huggingface.co/spaces/stabilityai/stable-diffusion

   LAION datasets are simply indexes to the internet, i.e. lists of URLs to the original images together with the ALT texts found linked to those images. While we downloaded and calculated CLIP embeddings of the pictures to compute similarity scores between pictures and texts, we subsequently discarded all the photos. Any researcher using the datasets must reconstruct the images data by downloading the subset they are interested in. For this purpose, we suggest the img2dataset tool.

1. The LAION group committed possible copyright infringements and even left undeniable evidence that they did - on top of their written testimony (dumping the "stolen goods into the river" does not make the infringement undone, does it?)

2. Any model trained on the "linked" data may commit copyright infringement.

3. As consequence, you using generated images may be liable.

I always wonder how it possibly is legal at all - considering that as a human artist if I was to copy material and remix it it without proper permission would be liable (again depending on situation), but suddenly ML is around the corner and it's all great and now you can keep remixing the potential problematic output further - no questions asked!?

I guess there are no precedence cases but why should an automaton/software (and its creators) be judged differently to persons? I don't want to spoil the fun but what am I missing?

Also disappointed that this dataset did not make sure to only collect unproblematic content like Creative Commons that allows remixing. Would be a hell of a attribution list but definitely better than what is presented here.

EDIT: Formatting

EDIT2: I actually followed one of the projects mentioned not the linked repository. Clarified above.

We're very excited about this new release. I'm pipeline lead at Tangent Animation. Blender was used for "NextGen" and our future projects. I may answer how it is to be part of the development (Blender/Cycles) while producing features, but better yet you can talk to us at the SparkFX in Vancouver if you happen to be there.

Please check your facts: https://ziglang.org/documentation/master/#Integer-Overflow

Worth mentioning that the vfx/animation industry is using PyQt and PySide for quite some time now [1].

Major third-party applications and libraries like Autodesk Maya, Pixar's Usd etc. make use of it.

My point being, it is not brand new technology just because it is now maintained by the Qt company. In fact I wouldn't be surprised if this industry is part of the reason why it gained official support.

The use in VFX also spawned a shim library called Qt.py that abstracts PySide, Pyside2, PyQt4 and PyQt5 away [2] - with certain limitations. Highly recommended in the transition phase from Qt4 to Qt5, or when you can't control the underlying Qt-Python library.

[1] http://vfxplatform.com/

[2] https://github.com/mottosso/Qt.py

There are so many neat design choices in zig that make it a joy to code in it even these days. Can't imagine what we get with 1.0.

Some of my personal highlights:

- clean syntax

- comptime (as explicit and simple as it should be)

- reflection

- minimal/no external dependencies

- single threaded mode (instead of taking cuts at runtime)

- concise and explicit error handling

- build-in build system

- amazing C interop

...

Good sample code can also be found in the standard library, and it has the benefit of being up to date with with language.

Thanks Andy!

Worth mentioning that one allocator in the std-library is wrapping malloc.

Here some more details:

[1] https://www.youtube.com/watch?v=WLJ_7lpBhys

I think Andy refers to this [1].

For example you can do:

  const std = @import("std");
  
  fn Int(comptime value: i32) type {
      return struct {
          pub fn value() i32 {
              return value;
          }
      };
  }
  
  pub fn main() anyerror!void {
      const int3 = Int(3);
      const int4 = Int(4);
  
      std.debug.warn("Types: {} {}\n", @typeName(int3),   @typeName(int4));
      std.debug.warn("Sum: {}\n", int3.value() + int4.value());
  }

  Types: Int(3) Int(4)
  Sum: 7

[2] https://godbolt.org/z/eLWeU2

[1] https://ziglang.org/documentation/master/#Generic-Data-Struc...

I've been using zig for the past 2 weeks in my spare time. I had so much fun writing in it that I ended up supporting Andrew on his mission and became a Patreon.

In one word zig is "joy". I forget that I am actually writing a compiled language. It feels almost like python. Everything just snapped into place for me.

I encourage everyone interested to give it a try, especially if you prefer C over languages with a strong paradigm. It is very easy to pick up zig. Read the short manual, check some samples or the "std" library and you can be immediately productive.

C interop is amazing. comptime is a sample of how it should work in other languages. syntax is clean and simple. no headers, good error strategies, a (rather) helpful compiler, build system included etc.

The only downside is now it feels heavy to go back to work and hammer on C++ ...

"V-EZ is being released as closed source. ..." quote from the site.

So far only Windows libs. Not sure if AMD will be lucky with this strategy. I understand that they usually are much more open then their competition but I am a bit baffled that they chose to open-source more complex things like Radeon-Rays but leave a high-level wrapper around Vulkan closed (which kind of leaves you unable to tweak it depending on your application).

Is this the beginning on closing more efforts? If yes they probably need a new domain ;)

That being said I highly respect AMD for not vendor-locking (many) technologies.

I think Cocos2d-x is a perfectly suited alternative, especially when you target mobile. However I remember that e.g. render targets were experimental, and in general Desktop is not the main platform. That being said if you hook up an input library even for desktop you can achieve remarkable results [1].

I haven't used the editor much so I won't make any claims here, but if you want to use code, C++ or one of the bindings is your favorite why not Cocos2D-x.

I hope my initial comment did not sound to biased, but to clean this up:

Use whatever feels right to you. I felt very productive with Godot for the type of game I am doing and I just wanted to share my experience :)

[1] Cocos2D-x desktop game "Songbringer" http://store.steampowered.com/app/367080/Songbringer/

(Please correct me if any of the following is imprecise, as I am not a core dev of Godot)

Languages are roughly stacked like this:

1. Internal scripting

Godot internally (C++ source) makes a distinction between core and modules. So many of the functionality that do not necessarily belong to the core engine are modules.

You are free to write your own extension to and modules to the editor (for example custom Node types). There is also an EditorPlugin API so you do not necessarily have to get your hands wet in the engine API itself if not necessary. Btw. the latter API is also exposed in GDScript.

Anything that implements script_language.h as a module is considered part of the editor (e.g. exposed in-editor script support etc.)

In 3.0 that would be GDScript and C#.

2. GDNative

Additionally 3.0 introduced GDNative which in essence is an API that exposes the internal C++ API that makes up the In-Game scripting as C symbols. This has the benefit that C can be bound to anything. Going this route even the C++ API is bindings created through C :-). More details here [1].

It is a relatively new effort but so far the following languages are supported (not making claims about stability/maturity here):

- C (just the API itself via the shipped headers)

- C++ [2]

- D [2]

- Rust [2]

- Python [3]

- Nim [4]

- Possibly others?

Once you have a library that can be hooked into you load it in the editor for each individual platform you try to target.

That being said: There is no heavy boilerplate-magic going on. I've setup a CMake file to handle C++ plugins without big issues. There is no real hot-loading AFAIK but you do not need to restart the editor since it loads the libraries in play mode.

This is a sample of the GDNative API [5].

Here is a manual setup with C [6]. While the tooling improved meanwhile (e.g. in editor tools to set the libraries) it gives you a good overview how the GDNative API works.

Hope that makes sense.

[1] GDNative Architecture https://godotengine.org/article/look-gdnative-architecture

[2] Main GDNative Language Bindings https://github.com/GodotNativeTools

[3] Python via GDNative https://github.com/touilleMan/godot-python

[4] Nim via GDNative https://github.com/pragmagic/godot-nim

[5] GDNative C++ API Sample https://github.com/GodotNativeTools/godot-cpp#creating-simpl...

[6] C example of GDNative (Godot Docs) http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnativ...

Here is my personal opinion about Godot vs Unity.

Background Unity:

- I've used Unity for small to medium sized commercial industry projects (3D, VR Tours etc.).

- I've used Unity for a 2D Gamejam.

- Various Unity research projects.

Background Godot:

- I've started using Godot v2.1 with little preparation successfully on two Game jams (2D) [1]

- I've contributed smaller additions and bugfixes to Godot in the past months, in order to help the 3.0 release and also to understand more of the internals.

- I am currently working on a bigger 2D game in Godot 3.0.

This is my personal experience and opinion: First of all: For sure Unity is great and I would not hesitate to use it again in future, especially for 3D (without having much experience in Godot 3.0 3D environment).

However it has drawbacks compared to Godot, especially for 2D which is my main focus:

- Terrible 2D support in Unity (for retro/pixel perfect projects). It's not that it is impossible but you need to know and work around many aspects to setup something that works. Same setup in Godot needs literally two clicks. Units in Godot are pixel units. Perfect.

- No Nested prefabs in Unity. Check out their GDC 2018 keynote (end). It is even a joke to them. Well, to me it isn't. Godot does nested instances and it is a great productivity gain.

- (Open/Public) Source code access in Godot. That probably only applies to people with C++ experience but it was great that I was not stuck since I could dive in and find and fix my problems. Often I found other people with the same problem, and sometimes a PR to fix it, so I could build it from their PR before the official merge and could go on doing my work.

- Source code state/community for Godot. Godot has a pretty non-idealistic style of code. It's not heavily abstracted. And while one could argue if it always has best design choices at least it makes it very easy to dive in. My PRs and fixes were gratefully accepted, it is a very open and productive community. Discussions on Github were constructive in my experience.

- Unity has second class Linux (editor) support. To be fair: it seems to gradually improve. Thanks for that btw. But whenever I try I get showstopping weird issues. Every build is a different problem. In contrast: Godot under Linux is flawless. To be honest: Unity Editor does much more under the hood. And again: I personally do not care. I am focused on 2D and I feel I pay a lot extra.

- GUI. I know that there is now a new GUI framework in Unity but I feel like it made things worse. I have a hard time getting the results I want as compared to Godot's GUI system. Not impossible per se, just not as intuitive as I would like it. Godot's GUI frameworks works similar to Qt Designer. Simple layouts and widgets.

- Nodes and scripts (Godot) vs. Objects and Components (Unity). I have found that the nodes available in Godot make it very easy to come up with various setups. There is just a bunch of (useful) functionality build in. Especially their viewport/offscreen rendering on top of canvas mixed with GUI and shaders make things pretty easy. No need to script for various scenarios + the benefit of these nodes being native.

- 2D Physics. Unity uses box2D (like?) physics. Godot has a custom physics engine that works pretty much like old school arcade physics. It is a perfect starting point for platformers etc. without the sacrifice in control. If your game is NOT an angry birds clone then probably a box2D like physics engine is not what you want.

I was quite surprised myself that Godot boosted my productivity so much as compared to former workflows.

Initially one of my first doubts with Godot was GodotScript. And I must say I was wrong. It is a great little language which helps iterating quickly. And if you are not happy with the performance, you can use C++ or C# or anything else with GodotNativeScript (around 2.6x speedups with C++ in my measurement[2]). I for myself kept GodotScript as iteration speed is more important to me than native performance, especially in the initial stage.

The big negative point as already pointed out is that Godot has few proven examples of successful bigger projects. Therefor platforms may be another issue. But having the source code under control helps, plus there is a drive that hopefully spawns more interest and support in future. Godot deserves it.

To conclude. For 2D I have not found a better tool than Godot. Please disagree if you like but give the tool a fair chance.

[1] Small Godot based Game jam projects: https://itch.io/profile/stateoff

[2] Personal benchmark of GDNativeScript: https://twitter.com/StateOffGames/status/944878511801753601

In this case he really did invent the "Realtime-RPG" that made Diablo what it is.

In his own words: https://www.youtube.com/watch?v=VscdPA6sUkc

I agree. I think the main purpose is a "2D Accelerated Rendering" replacement that allows for shaders and other custom techniques.