Hacker Newsnew | past | comments | ask | show | jobs | submit | nnevatie's commentslogin

> with a language

I think it simply wouldn't work. Which kind of GUI (library) would C++ have, imagining it came with one?


You missed that they gave an example that does work—Java Swing is bundled with the JVM, making it more or less part of the standard library. Python itself also has Tkinter, which exists inside the cpython repo and is installed with Python [0].

C++ may not work, but most other languages (especially VM-based) can and many do.

[0] https://github.com/python/cpython/blob/3.12/Lib/tkinter/__in...


wxwidgets, or maybe they'd just go crazy and build Qt in


Considering Stadia's demise, is orbit dead as well?


Yeah a nice optimization, but is "return c * c;" really a good approximation of sRGB gamma?


No it's not. But, the previous code was already effectively doing "c * c" for the last 15 years. So for now, just keep doing that, a bit faster.

A more proper way would be to do proper color-space aware luma calculation. Which under default settings is sRGB indeed, but not necessarily so (VSE can be set to operate in some other color space). Someday!


Yes, it's weird they used 2.0 in the original code too. Doing proper gamma for any regular space (sRGB, YUV Rec.705, etc.) isn't actually that heavy (even without LUTs).


My guess is that the code was written by someone in 1995 back when no one understood color spaces, or something (it's hard to track down who and when wrote it exactly due to all file moves and refactors etc.)


Some typos in the URL: htttps://chesss.com/registration-invite?hash=XXX


OP - Wow, can't believe I missed that! Thanks!


I found the explanation quite convoluted (pun intended). Any system with billions of parameters is bound to be difficult to reason about.


Apart from the obvious z-popping, looks quite good.


It might be possible to reduce that effect by applying a mix-blend-mode to the layers.


The intention is good, from an AI-opponent's perspective. I don't think will work practically, though. The drawbacks for actual users of the image galleries, plus the level of complexity involved in poisoning the samples makes this unfeasible to implement at the scale required.


A nice article. It would be cool to go a little bit deeper to finding the collision points and depths, though. These are very useful for the next phase, which is typically reacting to detected collisions, e.g. by applying some impulse to the objects involved.


DOS extenders and Watcom C/C++ were heaven-sent after spending years targeting real-mode with its segments and offsets.


I do wonder if it's possible to write a DOS extender for 64 bits.


The big problem is that 64-bit x86 long mode removes the V86 mode that made DOS 386 memory managers possible.

This is why the DOSemu project has been doing a multi-year rewrite: to create a new, full-VM-based DOSemu2 that can run DOS without emulation on x86-64 machines.

https://github.com/dosemu2/dosemu2/wiki


In most EVs you can control the intensity of one-pedal breaking. I have it set to adaptive, which uses speed as one of its factors.


> In most EVs you can control the intensity of one-pedal breaking.

In all EVs you can control the intensity real time with your foot. I concede, though, that I have friends whose driving style is best described as "binary" and I imagine they wouldn't be big fans of one-pedal mode.


Yes, your foot is the ultimate the control. However, there are settings for the steepness of the maximum deceleration for the scenario where the foot is completely lifted.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: