Ranzear posted:

My ideal is more of an Entity+Tag+Behavior system. Sounds like ECS with extra steps, but ECS iterates entities to find components to execute behaviors while I want to flip that around and iterate behaviors to find entities (by tags in basically a publish/subscribe registration) that want to execute them. This is even still separate from the effect chains I mentioned in the prior post which are just a stack of interactions that might form one 'behavior' with multiple inputs or interrupts.

Tags work as both an 'invoke me for x behavior' and 'I am a potential target for x or y behavior'. Also an entity can have varying presence in different layers of the simulation, even different hitboxes for stuff like physics vs contact checks, and tags control those interaction layers as well.

Chainclaw posted:

The problem with Entity Component Systems and entity systems with components is they share a lot of terminology but aren't really related.

Ranzear posted:

In as much as I've experienced and understood, Unity and Godot do a lot more of the latter than the former and that context was rather important to what I wanted to convey. They don't really expose the 'system' side of things in a useful way to many detriments.

I'm currently writing the system I described in Rust and just used it as a pointer on how Unity mucks up temporality so much that every game made in it ends up with the forbidden behavior singleton eventually.

But yes, 'let the behavior/system find the entities' does read like how an ECS should work just like how my isolation of the simulation model and sending only display data for the client to view and receiving only remapped controller inputs back across the server/client gap might sound familiar too. I'm not claiming to have invented anything new.

Megafunk posted:

I didn't mean to accuse you of pretending to invent that pattern, I just thought you might enjoy the video.

leper khan posted:

Unity has an ECS that behaves nothing like you implied it behaved. And isn't central to the general operation of the engine in any way. You're basically just spewing FUD

Megafunk posted:

And yeah, in the new UE5 ECS (Mass) they opted to call systems Processors and components Fragments to avoid confusion. It's fairly similar to the early days of DOTS but it's already been used in their Matrix demo. It is designed to live alongside actors rather than replacing them if that assuages fears of the DOTS debacle.

more falafel please posted:

Makes sense that they call them Processors and Fragments considering they already have long-standing things called Systems and Components.

quote:

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Megafunk posted:

I wonder if this unique "local systems" ECS idea would appeal to you. It's a long video but he goes into his new ideas in the later sections.
https://youtu.be/jjEsB611kxs

The gist is each entity updates it's own set of systems instead of the "global" conventional ecs querying loops etc. Of course, global systems can still be there.

Ranzear posted:

Ranzear posted:

Today I learned the original quote never had "... and off-by-one errors."

Fuschia tude posted:

Tim Bray says that was added later by someone else.

https://twitter.com/dkarlton/status/895871336941211648
https://twitter.com/timbray/status/506146595650699264

And this guy claims to be the source:
https://twitter.com/secretGeek/status/552779013890904064

Jabor posted:

Gotta add "date handling" to the joke I guess.

leper khan posted:

Lmao the off by one joke has been around since at least mid 2000s

Jabor posted:

Have you considered antialiasing your lines? Instead of having a hard "close to a line -> set colour to black; not close enough -> do nothing", you'd set a shade of grey based on how close the pixel is to the line.

Raenir Salazar posted:

Hrm, well, my goal is to eventually be generating a polygon based procedural world map (finally got back to this project since where I last left off in 2021!!! ) so the goal is not necessarily nice lines in of themselves, I just wanted to test displaying the results to a texture where it'd be nice if the lines happened to be of a certain type. Last time I draw lines to a texture (using the CPU; which honestly is probably not that slow? Might be worth re-examining! Since the number of length of lines might be reasonably finite relative to the area of a texture?)

roomforthetuna posted:

Yeah, if it's a one-off generate-stuff operation, drawing 600 lines on CPU with a bresenham algorithm is probably just as good as doing 600 operations per pixel in the whole rectangle on the GPU (the increased parallelism isn't really giving you much when you're using it to do hundreds of times more operations).
But what about drawing the lines on the GPU using line-drawing or triangle-pairs? It's super optimized for that poo poo.
Edit: like you said in your edit while I was saying this.

Boldor posted:

Arcane question, I'm not sure where to ask.

I'm reverse-engineering old computer games, primarily on x86 or possibly x64 architecture (DOS/Windows), but 65xx (Apple ][, Commodore 64) is also on the table. (How old: 10+ years bare minimum, mostly 25+, possibly 40+.)

What I'm trying to crack is the random number generator, which is key to many older games. This long ago it was common for programmers to roll their own RNG (believe it or not, this was actually a good idea in C before 1997) but far from universal. I'm not sure where I can find previously-done work on this, however; this is difficult enough work that I'm trying to avoid reinventing the wheel.

All resources I know of are either primarily hardware-focused (like vogons.org), or are concerned with adventure games which mostly don't use RNG (like the ScummVM forums).

Is there such a thing?

I don't believe this exists for DOS/Windows (you can easily find it for specific console games, like the original Final Fantasy), because all sources I can find are not reliable enough for my purposes. I'm currently looking at the Turbo Pascal library, which as far as I know is best described in The Random Number Generators of the Turbo Pascal Family (1991). That's reasonably accurate but still has some mistakes and omissions, and anything else I know of (Wikipedia, or any other academic paper I could find) is worse.

If that doesn't exist, I'm interested in curating a list of RNGs .. except I'm not sure where to put my work, aside from "my own Github repository, or Web page". What forum might be most interested?

roomforthetuna posted:

Yeah, if it's a one-off generate-stuff operation, drawing 600 lines on CPU with a bresenham algorithm is probably just as good as doing 600 operations per pixel in the whole rectangle on the GPU (the increased parallelism isn't really giving you much when you're using it to do hundreds of times more operations).
But what about drawing the lines on the GPU using line-drawing or triangle-pairs? It's super optimized for that poo poo.
Edit: like you said in your edit while I was saying this.

TooMuchAbstraction posted:

I have a CoolShots system in my game that takes automatic screenshots when interesting things happen, to show to the player later. This system needs to not draw the HUD, so I turn it off before its camera renders, and then back on afterwards. I've noticed though that sometimes the HUD visibly flickers, which implies that the main camera is also rendering when the CoolShots camera is rendering. Or something.

The CoolShots render code is pretty simple:

code:

        bool hudOn = ToggleableHUD.isHUDOn;
        if (hudOn) {
            GlobalPubSub.Publish(new ToggleHUDEvent(false));
        }
        var current = RenderTexture.active;
        RenderTexture.active = cam.targetTexture;
        cam.Render();
        RenderTexture.active = current;
        if (hudOn) {
            GlobalPubSub.Publish(new ToggleHUDEvent(true));
        }

`cam` here is the CoolShots camera. I slapped some debug code together to log every time OnPostRender fires, and it confirms that the main camera isn't rendering in-between when the HUD is disabled and when it's enabled. I've also been unable to reproduce this in builds, though admittedly I haven't made a huge dedicated effort...has anyone else experienced editor-only issues like this?

TooMuchAbstraction posted:

I don't think so...that looks like it's doing some kind of turbo-manual rendering where the projection matrix is being set manually, and then not cleared reliably. I'm doing straightforward renders, I just need certain parts of the game to be disabled when I do.

(it sure would be nice if I could just put those parts on a layer that's invisible to the CoolShots camera, but Screen Space: Overlay canvases ignore that whole system )

Raenir Salazar posted:

So I got a voronoi mesh now, but the results aren't ideal; in particular the voronoi mesh has a lot of outgoing edges along the outermost perimeter of the mesh; so there's parts where there's like several tiny adjacent voronoi cells.



While I am aiming for something more like this.





It isn't exactly clear to me what settings or parameters I'm getting wrong.

Maybe, but here's the full script for context in case it does turn out to be useful!

leper khan posted:

Probably easiest to push the edge nodes to the edges

TooMuchAbstraction posted:

OK, this is a weird issue: I have to restart Unity to get it to actually pick up changes to my preprocessor. I have a BETA preprocessor directive, which is used to control access to certain prerelease game content. Attempting to add/remove that directive via Project Settings > Player > Scripting Define Symbols just straight up does not work unless I restart Unity. I know this because I have a build preprocessor script, which uses the directive to move some files around, and it logs what it's doing. And while the Project Settings dialog may claim that the symbol is/is not set, the logs will say otherwise.

I feel like this has to be some kind of disconnect between Unity and the compiler? I'm using Visual Studio 2019 (version 16.11.16) for this. Any suggestions for steps I might take to fix the issue? It's mildly annoying in that it adds extra steps to the build process. Mostly I'm worried that I'll accidentally send prerelease content into the real world ahead of schedule.