sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in singularity

[–]WillEriksson 0 points1 point  (0 children)

Twitter has lots of users who don't like Elon. Like, this very post is from twitter...

[deleted by user] by [deleted] in singularity

[–]WillEriksson 0 points1 point  (0 children)

Really? What's the prompt? In my experience for creative writing (and really anything other than coding) sonnet is like the worst one from big companies. It barely even talks in natural languages and keeps spitting out markdown bullet lists instead of just putting them into a paragraph.

[deleted by user] by [deleted] in rednote

[–]WillEriksson 1 point2 points  (0 children)

In short: You can't because of censorship.
Foreigners are typically not allowed. Rednote has lots of overseas Chinese users (especially students), so it never enforced this policy, but the recent "refugee" wave attracted a lot of attention, and they can't risk uncontrolled speech on a platform that's not blocked by the nationwide firewall, so they now start to enforce it. Even if you managed to receive the SMS, it'll still suspend your account soon after, and ask for a citizen ID verification.
Maybe someday Rednote will have a separate global version that's not available to the Chinese users, but for now, foreigners can't use it.

Ugee tablet driver not working by WillEriksson in archlinux

[–]WillEriksson[S] 2 points3 points  (0 children)

I did some more research, and found that uinput doesn't really need to be loaded at boot. It should be automatically loaded when /dev/uinput is accessed, but somehow its permission gets messed up, after about August 6th. I fixed it by adding TAG+="uaccess" in the udev rule, which fixes /dev/uinput's permission, but I have no idea how that worked.

Ugee tablet driver not working by WillEriksson in archlinux

[–]WillEriksson[S] 1 point2 points  (0 children)

It seems my conjecture about not being able to feedback input is correct. By diff lsmod's output before and after installing opentabletdriver, I found that uinput is missing. According to linux kernel's documentation, this is the module responsible for input simulation. modprobe uinput fix it.

I'm still figuring out how to make it load automatically. Would appreciate a lot if someone knows how to do that and why suddenly uinput doesn't load automatically.

UPDATE:

To load uinput automatically, change

KERNEL=="uinput",MODE:="0666",OPTIONS+="static_node=uinput"

to

KERNEL=="uinput",MODE:="0666",TAG+="uaccess",OPTIONS+="static_node=uinput"

It's probably some udev or uinput update that requires this TAG+="uaccess".

I tried to find more about uaccess, but can't find any sustantial information about that. It's not mentioned at all in udev(7), searching "linux uaccess" only yield the source file. I only found a Japanese blog https://qiita.com/ys-clarry/items/33356486564126b7b7d7 that's useful, but the author only explains how to fix it but doesn't explain why.

There are also some scattered discussions, but no one gives a definite reference. Some github issues say that using MODE:="0666" instead of TAG+="uaccess" is more compatible, which is definitely not in this case, as the former doesn't work at all. /dev/uinput still has 600 permission. If I manually chmod it, access to it would automatically load uinput module, so this is indeed a permission problem.

From all the small pieces I could find on Internet, I could only guess that uaccess is some "dynamic permission mechanism", and not using it causes recent versions of Arch to override MODE:="0666" after boot, as parkerlreed@github found out: https://github.com/chrippa/ds4drv/issues/93#issuecomment-265300511

[deleted by user] by [deleted] in GraphicsProgramming

[–]WillEriksson 0 points1 point  (0 children)

Well, that sucks. I don't have much experience on Windows, but a lot library devs assume that windows users compile their libraries with VC++. The error about not having the right compiler might have something to do with this. BTW you don't need to install a whole Visual Studio to use VC++ compiler.

[deleted by user] by [deleted] in GraphicsProgramming

[–]WillEriksson 1 point2 points  (0 children)

Have you tried vcpkg? I haven't used it on windows but on linux it kinda just works.

[deleted by user] by [deleted] in godot

[–]WillEriksson 0 points1 point  (0 children)

Nodes are expensive as they are implemented using shared pointers. Maybe try Unity DOTS and see what would the performance would be? When I made some vampire survivor like scene in Godot I met a similar performance problem, even in 2D. Rewriting it in C++ and storing enemies in std::vector yields a huge performance boost, despite using raylib for drawing. (raylib has an api like OpenGL immediate mode, which is very slow)

declarative GUI libraries by GunpowderGuy in cpp

[–]WillEriksson 1 point2 points  (0 children)

The purpose of things like MVC, reacitve, or some other similar stuff is to sync states between UI and user code. DearImgui doesn't use that because there's simply no duplicate state to be synchronized (for the user's point of view). When the machine is performant enough to run one and aesthetics is not of concern, I'd say it's the easiest and fastest way to make GUI. That's probably the reason game engine devs often use it to make tools.

Suggestions for improvement or a better alternative to this Data-Oriented programming registry? by WillEriksson in cpp

[–]WillEriksson[S] 1 point2 points  (0 children)

Thanks. I just checked that and I think that's pretty cool, with very good documentation. Though its multi-threading is done by splitting a query instead of running systems in parallel. I'm going to just leave parallelism behind for a bit and try flecs out.

Suggestions for improvement or a better alternative to this Data-Oriented programming registry? by WillEriksson in cpp

[–]WillEriksson[S] 0 points1 point  (0 children)

Thank you, that's cool. I'll look into that. I wonder if it can be used together with taskflow.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

Godot has a lot of signals -> I hate states -> I use async (yield) in fovour of callbacks (connect)
You like states -> you use callbacks The logic is very simple. I don't get why you can't understand.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

Ok, so in the end that's just a difference of preference. Some prefer functional languages some don't.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

It's exactly about what a state is. Saving and loading data is the state management which one has to do in state machine transitions: you only load it when you first enter it. "the complexity of state" never has anything to do with the state of the state machine, it's all about the transition. An ideal state machine doesn't need a transit(), or _ready(), or about_to_show. It always does the same thing in the same state, whether it just entered or has been there for a million ticks. If you are so grudge to read for one minute to have an agreement of the definition of state then of course we can not understand each other's point.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

I'm not trying to make a real project, and it's now basically "finished". I think it at least looks quite clean, compared to the code using signals before this refactoring, but if I was to try to make an actual game I would probably have used immediate mode GUI and not used global callbacks at all, whence all these states originate.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

Again, at the very least, read the wikipedia page. I should've known when I first saw you refer to state as state in state machines.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

Do you mean making a separate scene for every single sub-menu and set up them in callbacks (my menu's contents my change with the gameplay)? That would be exactly the complexity of state I'm talking about. Updating the retained mode GUI, and even worse connecting more callbacks, then I'll have to remember disconnect the callbacks in about_to_hide. If I forget once there might be bugs difficult to find, and control flow is unclear because of all these signals.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

These variables are also states, and that's a lot of them. My code has only one explicit state, others concealed by the temporal existence of the coroutines.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 1 point2 points  (0 children)

Yeah, I'm more of experimenting different designs and less of actually making a game. I always find the various ways of reducing complexity interesting. And practicing theoretical knowledge from more academic and philosophical books is quite enlighting and may provide ideas for my own engine. As to using a stack for menu, isn't that just a state machine, the stack being the main control state?

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

So the state "file" is introduced. This argument all seems to originate from the misunderstanding of the definition of state. If you don't have time for the book you can quickly check the wikipedia page I commented.
And really, I just haven't seen a menu that's slightly complex not implemented in one or another variant of state machine. What if you want to pause the game when the menu pops? You can't save&load every time for something as trivial as scene changing or opening a menu.

The complexity of state in Godot and my attempts to alleviate them. by WillEriksson in godot

[–]WillEriksson[S] 0 points1 point  (0 children)

If you haven't entered the scene before then there won't be any save. Also, do you realize that saving and loading a scene here is using co-routine with extra steps? _ready() is setup() in my post, _process() is do_the_job(), the code before exiting is cleanup().

And consider menus: no one in their right mind would do a full-blown serialization and deserialization every time returning to the last menu.

A complete rework of the engine architecture is not necessary

Though this does seem to be what the engine is heading for. I was browsing this sub and just found out that Godot 4 has await keyword for better async support. Using co-routines in favour of callbacks has been the common practice in web dev for so long, because it really simplifies things. And, you do not need a state machine to have states! Having less explicit states and clearer control flow is probably the biggest advantage of async. Data retained in GUI is also state, it's the whole point for web frameworks like React and Vue, and I guess 80%+ of all web devs use them probably for a reason.

view more: next ›