TylerGlaiel

yeah that, include is a textual replacement, so anything placed before the include is seen by all the code in the include. Not just other preprocessor stuff and pragmas but all of the other function definitions as well. There are some cases where this has legitimate use, but also is one of the main reasons why compilers can't just "compile the .h files separately and reuse that work whenever its included, automatically"

you define #import as "include but no context leaks into it" and that should on its own be enough to let the compiler just, compile that file once and reuse it wherever else its imported. That's like 95% of the benefit of what modules offered but much much simpler

All that the C++ committee needed to do was just introduce "import" as "this is the same as include except no context can leak into it".

Would have been dirt simple to migrate existing codebases over to using it (find and replace include with import, mostly), and initial implementations of it on the compiler side could have been nearly identical to what's already there, while offering some easy space for optimizing it significantly.

Instead they wanted to make an entirely new thing that's impossible to retrofit into existing projects so its basically DOA

This implementation grows indefinitely if you repeatedly push to the head and remove from the tail, even if the max number of elements in the array is small

this is my quote https://twitter.com/TylerGlaiel/status/1724907097031414240

Biggest place for improvement performance-wise I can see from this is that you aren't taking into account cache coherency here. Horizontal blurs with this method are going to be ripping fast, but vertical blurs are going to constantly cache miss. There's a number of ways to potentially fix this, the fact that you only need to store 3 sums for one line means you could do a few (64) columns at a time and just store that many distinct sets of sums (sorta like doing 64 columns in parallel, just making sure to use the data thats in the cache while its still in the cache)

There's nothing wrong with spamming 1000s of raycasts per frame in a 2D game. They should be very cheap, so the performance impact of that should not be something you have to think about, and if some interaction or mechanic is easy to express with a boatload of raycasts, you should be able to just do that

I think openAI might be experimenting with smaller context lengths to save on costs or something since I've had a few other things break down like this for me today too (even in GPT-4)

note that when they went and analyzed that AI they found out it was using the smudges on the google car camera as a sort of fingerprint (as those are consistent for the many pictures taken by one camera) so that AI would almost certainly not do well against pictures taken from different sources

the last time I tried it (it was years ago) std::regex was taking a measurable number of milliseconds to evaluate which is kind of a very long time even outside of performance critical paths.

if you actually wanted to you could probably wrap thread to pass the stacktrace of the spawning thread into the worker thread whenever you spawn a thread and then output that upon a crash as well. the library seems pretty simple and flexible.

oh yeah C++ regex is stupidly inefficient, like "python is faster" inefficient. I tried to use it for text replacements and pretty much immediately abandoned it

please... just explicitly calculate index() first on its own line if the order matters like this...

thats also not a correct formulation of the problem, as it needs to minimize the number of fire tiles it passes through. which is where a lot of the complication comes from.

it had 4 movement as its base, the numbers over its head were a bonus movement status effect (used for testing this stuff)

I have not tried, but I suspect if I described the algorithm I have instead of the problem that it could translate the algorithm into code pretty well. But I'm also unsure of that, some experiments with GPT 3.5 I did would definitely cause it to default to a common solution (ex, A) if the description was sufficiently similar to A, or not realize that a small deviation was intended. But also like... the point here was to see if it could solve a hard problem that has a non-obvious solution. not if it can translate an english description of an algorithm into code.

chill, I'm the only programmer on the project, and I don't have any problems understanding what the code is doing (only lost track of some of the "why", the process that led me there. which was only relevant here because I was trying to recreate that process with ChatGPT). The original algorithm involved a ton of trial and error from my end, so the "why" is really just "I tried a bunch of permutations of this and ended up with this as the version that worked".

Interesting, not a single one of these things it asked for clarifications on are things it actually got wrong in its suggested solution

string view is theoretically going to be faster, but its the type of thing you'd really need to profile in actual context to see to what extent that is true or not. I was mainly just pointing out that (small) strings are actually way faster than people would think since they don't actually need to allocate memory

if I was actually tasked with hyper-optimizing a tokenizer I would probably skip past string view and do a pair of U16 indexes instead assuming the input file is less than 65k characters [with a "slow path" that uses U32 instead]. I just think that its probably not actually going to be a whole order of magnitude faster than just using string (unless there's long tokens)

sure but this is how pretty much every implementation does it these days, so you should be able to safely rely on that (or just drop in your own version that provides that guarantee if you are really concerned about it)

> Tokenizing by storing strings in a vector is almost never what you want for high performance code, as it will result in an allocation for each token.

not quite, std::string can store <=22 character strings without needing to allocate (in 64 bit mode at least) (look up short string optimization), 22 characters is actually quite a lot in the context of tokenization, so its not a given that switching to string views would be an improvement here

> and to actually have your game designed first (not designing while you code.)

tell me you've never made a game without telling me you've never made a game

flashpoint is not a flash emulator, its a preservation effort that has archived tons of flash content from the web

Ruffle is the flash emulator https://ruffle.rs/

Flash is great and tons of devs still use flash. I also use flash in my custom game engine (the one powering The End is Nigh and the upcoming Mewgenics), a different approach to what the dev in this article did (seeing as these are new games and not ports of existing flash games), my approach is to load SWF files as the resource files for art and animation in my game, and render them as vector. Flash puts a lot of information in those files, and I parse just enough actionscript bytecode that I hook and trigger C++ functions from my actionscript parser. This lets us use flash almost exactly the way we used it for making flash games back in the mid 2000s, with all of the interesting workflow tricks and hacks that made it so nice, while being able to write all the actual gameplay code in a real language and render it with openGL so its actually fast.

I've been making video games for a long time and while it's true they can feel unfinished for a long time, they shouldn't ever feel completely broken/disasterous/failed. One of the key things when making a video game is to make sure that it is fun and playable as early as possible into development, and when someone is grinding away working on something that isn't fun that's a pretty huge red flag to me.

No, the standard is to project against a flat plane, regular rasterization is not suited for rendering to anything else, however in theory you could fake it with a post processing distortion filter

With full raytracing it might be possible to correctly render to a curved view plane, but right now even games that support raytracing tend to be a mix of rasterization and raytracing

Not a single one of the things he has as a shared pointer needed to be a pointer at all.

This feels like it was written by someone who started learning C++ the day before he wrote this tutorial

Haven't had to do this with google (yet) but filing a complaint with the FCC usually gets you a very prompt response from the company the complaint is about, and I imagine this would be the best thing to do in this case https://consumercomplaints.fcc.gov/hc/en-us

since C++20 you can get around this

https://en.cppreference.com/w/cpp/language/attributes/no_uni...

this is a specific limitation I'm imposing because it makes for an interesting problem, not because its meant to be optimal.