Yes, it will eventually support dual screen, that is the playfield and the backglass. Today I will be working writing DMD screens using typescript, and I happen to prefer DMD over the newer LCD screens on modern tables.
When I get close to my initial source release I will look into what it takes to port tables from VPX to my engine. Right now I am purposefully not exploring that because I want an unclouded fresh start for pinball simulation.
No, but it will support PinMAME fully. For copyright reasons, I wll not however be developing both the engine, and recreating actual tables. That would be a bit too far from my legal perspective. I will leave it to other who want to do that.
Yes, I am aware of Visual Pinball. This is meant as a pinball simulation system for Linux, using a Javascript engine and not VB Script. Also, it will support running on Linux using dmks, so on PCs without a display server.
I started writing my own physics system a while back, and in January of this year started working on some tests befre realziing I was never going to get acceptable phyics on my own. In August I started using Jolt and it seems to work. So to answer your question, I am using Jolt for the physics now.
As the title says, I am working on a FOSS Linux Pinball Simulation Engine. It is based on my Pascal Tiny.Sim library which has been in github for many years. Tables are designed in parametric CAD (OnShape for now) and imported by my engine as 3D meshes. It simplifies many of the physics bodies into primitives and has options to configure how meshes are convert into a table. The logic for a table is written in Typescript. Users can also edit the table inside the game. The idea will be that users can use the engine to play and share pinball tables of their own designs. I am supporting Linux because I use Linux every day and it needs more support when it comes to playing good fun games.
If you want to help Linux and are an artist, I plan make the initial source code release with 3 different tables and a guide for how to create your own pinball tables. I am looking for artwork to help with table artwork. My contact information is on the page linked to this submission.
I started with Godot, and swtich back to Pascal. It will be and is cross platform, but I am focusing on Linux, because that is what I use.
With regards to Godot, while I like it, when using my own engine I can take a lot of shortcusts that Godot cannot. For example, I am able to save a lot of computational logic on reflections by making the requirements that reflections only world on right angled surfaces, which is fine for a pinball table. Also, I am able to cheap out with lighting using a my ouwn techniques for generating lighting maps in a shader, something that is hard to pull off with Godot.
This other game project of mine is written using Godot and C#:
I'd imagine that pinball is essentially 2D. Maybe some lanes and ramps would affect gravity, but I can imagine the few Z-direction adjustments aren't worth simulating everything in 3D.
The ball often jumps off the playfield in real pinball. It's not uncommon for it to jump high enough to hit the glass. You'll never get an accurate simulation if you simulate it in 2D.
While Space Cadet Pinball proudly calls itself '3D pinball' , the only 3D thing about it is that the table background bitmap is drawn in perspective and the ball gets smaller if farther away ;-)
But all the physics is 2D. Because the model is a circle on a map on to which 2D forces are applied. The ball moves in 2D. Even with ramps and shutes, which can be modeled like "extra 2d maps with entrances and exits (portals)".
I've made a pinball sim myself (in bevvy), and have poked around in FLOSS projects (vector pinball, Metal-Pinball) as inspiration for that sim. While some pinball games do use full 3D modeling, I fail to see the benefit that the 3rd dimension offers. The way I see it, it can add a tiny bit of extra realism (like bouncing off the floor, friction, curved ramps or floors etc). But a lot (and I expect not all) of that extra can be simulated in 2D by manipulating the 2d forces applied.
I can see how somebody could have this conception.
I grew up playing only video game pinball. It wasn't until I was living in a more urban area in my late teens / early twenties that I actually played on real pinball tables. Until I played real tables I don't think I understood the physicality of the game.
My website has been hosting downloads with alternate versions of the compiler and ide for nearly 15 years now. I also have published JsonTools, BareGame, TinySim, the original Shell Controls, and lots of other packages for the Lazarus community. The install scripts at https://www.getlazarus.org/setup simply download a seed compiler, the sources, and builds, while making certain it does not interfere with user's existing setups by restricting configuration settings to your chosen install folder. In other words, you can run my version and your existing version at the same time without any problems, and if you don't like my version the uninstall process is to delete a folder, and perhaps a shortcut if you copied it anywhere.
That feature you mentioned was added by the Delphi team in support of closures. They way they developed it was jankey IMO, as it creates an interface behind the scenes and populate with information about the local stack.
Though I do very much appreciate C#, with its lambda functions, expression trees, and especially the tooling, Free Pascal and Lazarus exist as a happy compromise between those things and native code integration, where working with C libraries like libcairo, libxml2, libssl, libsdl, and opengl are much easier and a pleasure to work with when using Free Pascal, and conversely are more difficult to wrangle when using C# or Java.
All OP is asking for is the ability to declare variables at first use instead of at the top of a function. You don't need closures or anything that'd inhibit C compatibility for this - C itself has supported this since C99. It's fairly simple if you're willing to give up single-pass compilation, which (I think?) FPC already has.
I think OP is talking about inline variables (in Delphi terminology), ie writing a var or const where you use it instead of in a var or const block at the top of the method.
Anonymous methods are the ones that are implemented via an interfaced object. It is a bit odd and I wish they had chosen something more ABI-compatible with a C++ functor, since it would have made mapping between the two easier IMO.
I have a test branch of the Oxygene compiler -- no idea if we'll merge it in, we make syntax experiments regularly -- where all callables are assignment-compatible. In Delphi terms this means assigning an anon method to an event handler would work, but equally for us, lambdas, blocks, and more. The idea is somewhat C++-like in terms of std::function and std::bind but with simple syntax in that you write it and it works: if it can be called, it can be applied where any callable method-like expectation exists.
I have been running the website getlazarus.org for 13 years to support add features to both FPC and Lazarus that jump ahead of the normal releases. We have been working of dynamic packages for a long time, and there will be a period between now, and when it is sent as a MR back into the mainline. When enough time has passed and feedback given these features are typically rolled into the main release, and at getlazarus I move on towards developing the next features.
reply