wareya |
Posted on 18-12-18, 12:05 in Mozilla, *sigh* (revision 1)
|
Post: #21 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Shadow DOM Version 0 was never supposed to land in browsers except behind super ultra experimental settings, it working in Chrome by default was a serious mistake and Youtube of all things using it is doubly/triply a mistake. |
wareya |
Posted on 18-12-25, 23:59 in Something about cheese!
|
Post: #22 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
The motive was actually stealing land from japanese-american farmers. |
wareya |
Posted on 18-12-29, 19:19 in Mozilla, *sigh*
|
Post: #23 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Remember when software let you install themes, and new default themes would first be introduced as options, then the default, then the old theme would be removed or disabled? I do. Hello, I'm using Windows 7 with almost the same exact windows decorations as were available on Windows 98, despite the fact that the OS has gone through three UI renovations since then. |
wareya |
Posted on 18-12-30, 16:22 in Mozilla, *sigh*
|
Post: #24 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Posted by Nicholas Steel You can still use userchrome modifications. |
wareya |
Posted on 18-12-31, 18:59 in amethyst (text editor) (revision 1)
|
Post: #25 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Modal editors are a lot less intuitive than non-modal editors, and it's impossible to justify making a modal editor in 2018 if you're not already indoctrinated into using them. Heavily scripted editor customization always leads to serious problems with performance or design down the line. It's also opaque and hard to learn. Of course, if you know the systems well and you've spent enough time with them, modal interfaces and heavy scripting can make it easier to do certain things, but a lot of the things that they make easier can be made easier by just improving your editor - support for multiple text cursors is a good first. Customizable editors are still around, you just see "plugins" instead of "scripts" (even if they're still written in a scripting language), because you need a clean interface for extensions to talk to the editor through anyway. |
wareya |
Posted on 19-01-03, 21:01 in Various copyrighted stuff is finally becoming public domain (revision 1)
|
Post: #26 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Posted by Nicholas Steel Kingdom Hearts 2 has a steamboat willie tie-in. Its Mickey has gloves etc though. |
wareya |
Posted on 19-01-04, 09:45 in I have yet to have never seen it all.
|
Post: #27 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
oh god, the physics speed is tied to the framerate |
wareya |
Posted on 19-01-06, 08:21 in Sneeze9x
|
Post: #28 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Some hacks are too obscure to find and fix. Like, personally distributed to three or four people obscure. |
wareya |
Posted on 19-01-15, 23:22 in Computer Technology News/Discussion
|
Post: #29 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
I have over a terabyte of music. Could you imagine if I stored backups of every show I've ever watched? The space it would take would be huge. |
wareya |
Posted on 19-01-16, 17:17 in JILost's computer stuff returns
|
Post: #30 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
The difference between integrated and discrete graphics chips is much more complicated than that. Shared memory is better when the emulator tries to do shittons of texture modifications, for example. |
wareya |
Posted on 19-01-21, 03:15 in Mozilla, *sigh*
|
Post: #31 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
We know what tomman meant by full page. Firefox has a hidden "developer console" command to take a full page screenshot, too. |
wareya |
Posted on 19-01-29, 01:45 in Gammakit and Magmakit - an insane language and a game engine (revision 1)
|
Post: #32 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Well, it's been well over five years since I first started getting into game engine programming, and I guess it's finally official: I didn't just pull off the "make your own game engine" meme. I didn't just pull off the "make your own game logic scripting language" meme. I made an insane high-level programming language with support for runtime procedural metaprogramming and a simple game engine around it. I took two stabs at making the language before, but both old versions were a lot worse than what I have now. So, here it is: https://github.com/wareya/gammakit https://github.com/wareya/magmakit https://streamable.com/p7xrd Gammakit is a ridiculous toy programming language that supports runtime code generation, lambdas, generators, first-class primitive data structures (arrays, dicts, maps), and coherent integration into the parent application (magmakit)'s design philosophy with custom types. It has support for GameMaker-like objects and wrapping the current scope with that of a given instance (i.e. with()), and also implicitly looping over all extant instances of a given object (i.e. GameMaker's specific with()). Scope looks just like lexical scope, but nested functions don't close over the scope they're defined in. Functions can be passed around in variables. Global variables are supported but have to be prefixed with "global."; global functions exist and don't need to be prefixed. There are "subroutine"-like functions which execute as though they were code written inline where they were called (i.e. they can access the parent stack frame). Primitive collections stored in variables can be modified with method-like function bindings, like myarray->remove(5). The language doesn't have a concept of references, except for the manually-managed IDs of instances. Yes, really. Gammakit is implemented without anything resembling a garbage collector, and without doing any analysis of what variables or values belong to what code. Everything is managed at runtime. The language's grammar has a declarative specification. The parser is a PEG-like recursive descent parser with support for backtracking. The compiler compiles to bytecode, which is executed in an ad-hoc virtual machine. There are built-in binding functions like "print", but the parent application doesn't have to provide them to the interpreter. Code can be generated at runtime using parsing and compilation bindings, resulting in a function-like value that you can store in a variable and pass around cheaply and call however many times you want. Did I mention that it supports generators? You know, semicoroutines? Those things that are super useful for AI scripts, visual novels, and virtual machines? And it's not JUST a toy. I have a proof-of-concept of the very beginnings of a game written in Magmakit, a toy game engine that adds bindings for things like sprite loading, drawing, and input, and has a mainloop. Let me link that streamable again. https://streamable.com/p7xrd THIS is what you get when you go "I don't like this. I want to make my own." instead of just making a game in an existing game engine. A dev art sprite jumping around on tiles. |
wareya |
Posted on 19-01-29, 16:17 in Mozilla, *sigh*
|
Post: #33 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
https://mozilla.github.io/FirefoxColor/ |
wareya |
Posted on 19-01-29, 16:38 in Mozilla, *sigh*
|
Post: #34 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Posted by Nicholas Steel You can emulate it with a custom background image, which is why I linked the git version instead of the stable version. |
wareya |
Posted on 19-01-30, 05:54 in Gammakit and Magmakit - an insane language and a game engine (revision 7)
|
Post: #35 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
> ...so, dynamic scope? That's normally considered a downside for predictability reasons (changing the name of a variable in a function that calls another function that eventually calls a callback can break your program), but I guess it's got significant upsides for your specific domain? To put it another way, with() blocks just have another source to search for variables for - the instance you give to with(). If it fails to find a variable in the current frame, it'll look in the instance you gave with(). Like JS's with. But unlike JS's with, it also loops over instances if you pass it an object ID instead of an instance ID. This sounds bad, but it dramatically simplifies very simple system-as-in-the-S-in-ECS style state update code. > Can "break" in a subroutine break out of a loop in the caller? Hey now, I'm not THAT crazy. The way they're implemented is that, when the interpreter searches for a variable, it can search outside from subroutine-like function frames, but not normal function frames. > So... automatic reference counting, or actual "I forgot to decref, therefore memory leak" and "I forgot to incref, therefore use-after-free"? "Instances" are manually managed with instance_create() and instance_kill(). Everything else is automatically managed and copied by value whenever it's assigned to a new variable or passed to a function. Both of these design choices mirror GameMaker; "instances" belong to the game world, everything else belongs to the current code. GameMaker only has floats and strings as primitive types though, not also collections like Gammakit does. > Are you using a parser-combinator library like pest or nom, or doing the whole thing from scratch? From scratch. > If it's from scratch, do you use the packrat optimization? Do you have the cut operator to clean up the packrat cache? I have no idea what that is, so probably not. EDIT: I looked packrat parsing up again and realized that it's conceptually similar to how the viterbi algorithm works, up until the part where it decides what parse to pick, so in theory I could probably do it. > BTW, your readme is a bit broken, and is using double-bullets for nested lists. I was using "-- ..." before when it was plain text, but it didn't work, so I just changed it to "- - ..." > You should totally adopt Rust's raw-string-literal syntax, it's simple to write and easy to parse. I might, but I want to handle multi-line string literals first. > A language with first-class generators, but C-style for loops? :/ There's for-each loops (i.e. "for ( varname in collection )"), but I don't have a range function to produce a collection, since it's more expensive, since I don't have lazy collections and for-each loops don't work on generators yet. (generators currently work like "while(generator) invoke generator;".) > A language with first-class lambdas, but awkward C++ style syntax instead of nice Rust syntax? :/ This is the only lambda syntax that makes sense for gammakit, since there aren't references anywhere and the compiler and runtime are too simplistic for me to want to do implicit captures of specific variables. > You're probably sensing a theme here, but I've really enjoyed Rust's "everything is an expression" consistency over the traditional C "expressions and atatements are totally different, but this expression does basically the same thing as that statement". The way the compiler is designed would make "everything is an expression" extremely fragile. I considered it a few times but put the thought on the back burner for "maybe if I make a less insane language some day". That reminds me - I did remember to make it so "and" and "or" short-circuit, thankfully. (Old versions of GameMaker don't.) > I've heard a lot of people talking about how entity-component-system libraries are much better for game development than traditional inheritance; it'd be neat to explore a gamedev-optimized language that natively used ECS for its data structures rather than inheritance. Inheritance is useful for the specific case of making pre-baked variants of objects that construct/destruct differently but have all the same "properties", rather than passing configuration data to the constructor or having separate factories for different variants. This is what Gang Garrison 2 uses inheritance for, for example. In general, since gammakit lets you store functions in variables (game maker forces you to use execute_string(), which is very slow), it would be realistic to avoid inheritance by ~pretending~ to have overloaded functions. This wouldn't help with variant-specific constructors/destructors, but it's there. You wouldn't be able to call the "parent's" version of those functions, though, which is why true inheritance might be useful. |
wareya |
Posted on 19-01-31, 06:10 in Mozilla, *sigh*
|
Post: #36 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
The more likely outcome is someone's business forking firefox after oxidization gets to sufficient levels. |
wareya |
Posted on 19-01-31, 09:57 in Mozilla, *sigh*
|
Post: #37 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Posted by jimbo1qaz Replacement of core web engine components with modular ones written in rust. For example, Servo's CSS engine. https://wiki.mozilla.org/Oxidation#Completed |
wareya |
Posted on 19-02-01, 12:17 in Mozilla, *sigh* (revision 1)
|
Post: #38 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Speak of the devil. https://discourse.mozilla.org/t/calling-all-test-pilots-reference-browser-ready-for-testing/35433 >This is NOT a new end product, it is a collection of parts, some or all of which may be used to create web browsers for different platforms. But before we can use them, we need to make sure they all work together in one place. >may be used to create web browsers Of course, I'm concerned that this is mobile-focused, but just having more non-chromium browsers on mobile platforms would be a good thing. |
wareya |
Posted on 19-02-02, 13:54 in Gammakit and Magmakit - an insane language and a game engine (revision 2)
|
Post: #39 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Yeah, JS doesn't give you a whole lot of reason to use "with", and the way that JS objects work and how idiomatic JS looks make it very bad form to use it, just like, in general. |
wareya |
Posted on 19-02-02, 22:25 in Gammakit and Magmakit - an insane language and a game engine (revision 3)
|
Post: #40 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Just realized that switching to packrat parsing would fix a design flaw in my current parser caused by backtracking being limited in how it can maneuver around failed grammar points (i.e. if a grammar point fails, it doesn't try looking for ambiguous rules inside the point that fails, it just tries the next alternative to the one that failed). Or, rather, packrat parsing would make it much easier to make my "backtracking" function correctly. No idea if I'll actually switch, but it's funny that the method with the faster worst case is also easier to implement "well". |