60 second binary options simulatorwww.nad.org.tw

2.9.3 Stable update!

2.9.3 Stable update!
What is up Depthians!
We are back with another monstrous update as this one incorporates five beta test builds, so we have a lot to cover.
If you want to dive straight into the massive changelog/dissertation Click
We should probably start with the biggest change to From The Depths in this update and that is the change of fuel and ammo storage.
Quoting Nick, our lead developer
The change is quite simple: "remove ammo and fuel as separate resources. Weapons will consume materials directly, fuel engines and CJEs will burn materials directly".
Before I dig into why I think this is the right thing for FtD, I'd like to explain a few details.
Energy, fuel and ammo are still needed for your constructs.
We have changed the "ammo barrels (etc)" and "fuel tanks" so they are just alternative material storage containers, but with the following properties:
--"ammo barrels" now increase the maximum possible rate of usage of materials as "ammo" for reloading guns. They still explode.
--"fuel tanks" increase the maximum possible rate of use of materials as "fuel" for fuel engines and CJEs, with the future stretch goal of fuel tanks being flammable.
--So ammo racking is going to remain a feature of the game- vehicles that need to reload a large amount of materials may need additional ammo barrels
Ammo and oil processors are replaced ship-wide with existing material storage containers of the same size. They'll be made decorative blocks so you can still use them decoratively in future if you want to.
The oil refinery will be repurposed (described later in the patch notes)
There are two main reasons why I think this is the right move. Why it's right for the business and why it's right for the player.
Let's start with why I think it's right for the player:
Ammo and fuel containers are currently purchasable as either "empty or full". This is confusing when considered in the context of the campaign, story missions, custom battles, multiplayer matches...how do empty and full tanks behave in these modes? I'd need an hour to study the code and a small essay to explain it. That's not good game design.
Localised resources, when considering just the moving of material (and energy, if you want), becomes infinitely more manageable. The supply group system and the transit fleet system are not intuitive and for a lot of situations, their usage becomes fiddly and too complicated. We've replaced these systems with a new supply system that is much more intuitive for moving materials and energy around.
The UI is less cluttered now that ammo and fuel bars are not shown. This is not a minor point...it'll reduce the amount of data on screen by about 40% in a lot of the different views. It'll be so much easier to know at a glance if a particular fleet is running low on "materials" or doing fine. Is a transport ready to leave, or does it need to pick up more materials? Will a set of vehicles have enough materials for the next fight...this is so much easier with just one main resource type per vehicle.
When you or an enemy run out of ammo or fuel in a battle it's just frustrating. By combining fuel, ammo and materials for repairing you can guarantee that if someone runs out, the fight is going to be over quickly.
I imagine that deep down the majority of players would rather not have to create, stock and resupply fuel and ammo. I know that personally, the requirement to do this puts me off playing the campaign. By using a single material it still focuses the game on making efficient war machines, maintaining supply lines and growing your economy, but without the extra confusion of mat->ammo and mat-> fuel conversion.
Being able to assess weapons, engines and vehicles in terms of material cost and running cost is elegant.
Most grand strategy games and RTS games don't have localised resources, and many don't have more than 2 resource types to handle. Very few combine localised materials with multiple types.
Why it's right for the business:
The ammo and oil processors were created about 8 years ago. Boring single blocks that don't add much to the game. It's been our intention to add something similar to the oil refinery but for ammo creation. That's a lot of work and adds to the complexity of the logistical part of the game, which we feel is already a burden.
Making the localised resource supply system more user friendly to make it easy/natural/pleasant to move ammo, fuel and material around the map would require a lot of effort and, quite frankly, I'm not sure we'd ever manage it.
The complexity of the UI scares off a lot of our customers. The barriers to getting a gun firing or a boat moving will be lowered if a single material container can theoretically get everything working.
Running out of ammo/fuel in combat is a problem for our players. We want to find a solution to that, but it would take a lot of effort to do so. We also want the strategic AI to always enter a battle with enough ammo and fuel for the fight- that's another massive bunch of work.
The campaign's strategic AI has to work hard to get materials where it wants them. It's a bundle of work and added complexity to get NPC fleets to restock ammo and fuel as well.
We had proposed work to make resource dumps (from dead ships) contain ammo and fuel...again, that's more work, more bugs, more testing.
Certain game modes such as story missions, tournament mode, and multiplayer maps should theoretically allow the player to choose the amount of ammo or fuel stocked into their vehicles before the match begins. That's another bundle of work and added complexity we'd like to avoid.
Currently out of play units on the map can run out of fuel and will still continue to move "for free". It's exploitable and we don't have a solution to that...but if all the different out of play movement calculations are burning material, there will be no avoiding the cost.
The development effort can be much better spent polishing up other features that I actually believe in, rather than flogging the dead horse of logistical complexity in an attempt to make it interesting, approachable and fun for everyone (which I fundamentally don't think it would ever be).
Fundamentally I think that by winding back this feature we tie up a large number of loose ends and it results in a far more finished and enjoyable product.
And what's-more everyone on the development team agrees that we enjoy the game for fighting, looting and creating...not staring blankly at dozens of resource bars trying to figure out who needs to head back for more fuel and how long we need to wait for ammunition to process.
We've also simplified the resource transfer system. "Supply groups" and "Transit Fleets" have been replaced with a simple but comprehensive three-tier system. You can mark a vehicle as a "Creator", a "Cargo" or a "User". Creators fill up Cargos (and Users), Cargos give to Users (up to procurement levels). Users equalise their material with their neighbours, so do Creators, and there are a few handy transfers from Users back to Cargo and Creator to make sure they maintain their procurement levels as well. This system covers 95% of the way people were using the resource system and does it all semi-automatically. This simplification is much more possible now that materials are the only resource, as they invariably just need to flow from the resource zones to the front line, with everyone (Creators and Cargo) keeping what they need and passing the rest on. This new resource system also facilitates the long-range transport of materials from refinery to refinery, which is neat. The system also has an option, for Creator and Cargo types, to set their "supply chain index", so if you want to relay materials from output to output in order to accumulate them at a central location you can set the supply chain index to determine which way along the chain the materials will flow. It's all explained in the game.
After spending a lot of time with this new system from adventure to campaign and designer mode, the gameplay feels a little faster to get going and a little simpler for fleet management. As if you didn’t already know, you can shift+right click (with your supply construct selected) on the target construct / flagship of a fleet to keep supplied, keep holding down shift and right-click where you want to pick the resources up from and once again while not letting go of shift, shift+right click on the target construct/flag ship to finish the loop.
This would be done of course after setting up the settings Creator, Cargo and User.
Creator as an example is the harvesting construct, Cargo which would be the supply ship, User which would be a single target construct that uses the mats.
This will keep the supply ship target waypoint updated and therefore your supply ship will always head to the target construct no matter where it has moved to after setting up the loop.
You still need ammo and fuel boxes on your constructs, as these are governing the transfer rate / the speed that stock your turrets and fuel engine with the materials needed for them to run. You can run a construct without fuel or ammo boxes, however, once your APS clips are empty you will see a drop in your rate of fire as the material is not being transferred fast enough, this is the same for fuel engines and CJE.
Another change that goes hand in hand with resource management is the changes to fuel refineries.
In short:
Refineries on a force with greater than 1 million materials on it will begin refining the material into 'commodities' that are stored centrally. Commodities (AKA centralised materials) can be added by the player to any vehicle in allied territory, at any time.
Resource zones have a new feature too, and that is the ability to deactivate a resource zone on your owned tiles and if you own enough territory as you can see from the UI when double-clicking on the resource zone “Zone Deactivation”.
https://preview.redd.it/284w9khtt9t51.jpg?width=1920&format=pjpg&auto=webp&s=9dd61b06b2b6d0431bbb35c44a4d54563b81fbf0
Custom Jet Engines, have had some additional parts and new features.
We have the new ducted air intakes which as you can see have different attachment points
https://preview.redd.it/qaqeplmwt9t51.jpg?width=1920&format=pjpg&auto=webp&s=2ac2019d4b0c908019bf0ef0d53ad3a718fc4f4d
These ducted intakes allow you to have your CJE enclosed inside your construct enabling you to pass ducting through to access airflow outside.
https://preview.redd.it/pge1x43yt9t51.jpg?width=1920&format=pjpg&auto=webp&s=f2ee0cf35276f45feeb7320b29d844fa54776cdf
https://preview.redd.it/scych37zt9t51.jpg?width=1920&format=pjpg&auto=webp&s=1bf7559bc2379b692b7a318ba8f43708f5bba81e
And as you can see in the pic below they are enclosed and making use of the air duct intakes.
https://preview.redd.it/ucidv351u9t51.jpg?width=1920&format=pjpg&auto=webp&s=7d93e0c08d381fcaea2bcfc315c7b676f4006b51
You can also funnel the exhaust of your CJE's that would be under the waterline by using the two new connector blocks, a 90-degree corner and an extension piece which allows them to work as long as you funnel the exhaust out above the waterline.
https://preview.redd.it/aiofdee2u9t51.jpg?width=1920&format=pjpg&auto=webp&s=72c1dd2023195ef2337704d0547904031ad97e6c
PACs have also had a rework and new additions.
We now have the long-range lens which has a circular 10° field of fire, the close-range lens which has a circular 35° field of fire, the scatter lens which has a circular 30° field of fire, and the vertical lens which has a 10° horizontal / 60° vertical field of fire (good for AA). The other differences between them is the percentage of damage drop off at certain ranges, which is marked in their UI.
https://preview.redd.it/zvg2u0c5u9t51.jpg?width=1920&format=pjpg&auto=webp&s=567a2c4e092ea5fef62e67b051a74151e48b58d4
https://preview.redd.it/mboi63c5u9t51.jpg?width=1920&format=pjpg&auto=webp&s=78690d46df1466844cc38ff6b6623a30d910b726
One other awesome change to the PAC system is that melee lenses do not need to be hooked up to the now called long-range lens. Simply setup your melee head and snakey noodle PAC tubes with a terminator on the end, then link up to your other melee lens via Q in the drop-down menu. The scatter lens also deserves some attention here, as it can double up the number of beams if we increase the charge time max x4 at 30 seconds. The PAC system has had many tweaks which you should check up on in the changelogs.
Shields have also had some love. Projector shields reflect and laser scatter modes are now merged and have also had a slight buff to ricochet chance. Ring shields armour bonus has also increased by 50%.
We also have some new additions to APS in terms of coolers.
From left to right we now have an L shape, 4 way and a 5 way cooler.
https://preview.redd.it/lfi937e7u9t51.jpg?width=1920&format=pjpg&auto=webp&s=4ff99ceae914777137262754baa017300c2f4c1f
We now have some new wide wheel additions too for all you land vehicle lovers.
https://preview.redd.it/1ysi7u68u9t51.jpg?width=1920&format=pjpg&auto=webp&s=0760606aa3aebbde24a44fcb7319477453ee3b99
The next biggest change would be steam engines even though other changes will be implemented in this update. We are once again rehashing the whole system, which will be released in the following updates.
I had asked Weng a number of questions as to why the change was needed, why are the parts expensive, when and why would you use steam over fuel, and this is what he had to say:
Reason why steam changes are needed:
  • Steam was previously totally unbalanced and arbitrary. For example, 9 small boilers with 1 small piston was the optimal steam setup, which was more efficient and denser than almost all other engines; and turbine power generation only depended on its pressure, so compact turbines were always optimal.
  • It lacked many critical info in its UI.
  • It was hard to control the usage of steam

What's good with new steam:
  • A bit more of realism and complexity
  • Larger steam now generally have better efficiency and density than equivalent smaller steam
  • More useful info such as total power production, performance over time
  • Possibility to regulate steam usage with valves

Pros of steam compared to injector fuel:
  • Denser and more efficient
  • Even denser with turbines
  • Easier to fit into irregular space
  • Provides a buffer with flywheels or steam tanks
  • More efficient when used for propellers
  • Doesn't require fuel containers, uses material directly from any type of storage
  • Computationally less intensive
Cons of steam compared to fuel:

  • Still hard to regulate, so it's only useful when the power usage is constant or there's a buffer energy storage
  • Turbines waste energy when batteries are full
  • Crankshafts waste energy when reaching speed limit
  • More susceptible to damage (injector engines can often still run fine even when half of it is gone, steam can stop working when a single pipe is destroyed)
Why cost of parts is hilariously high: Steam engines have better efficiency and density (many players seem to forget that one) than injector engines. So a higher initial costs makes it less overpowered.
(In my opinion, the potential waste of energy is a major drawback of steam and justifies for its high potential power. But iirc Draba said that injector engines would be useless on designs that require a lot of power if steam doesn't have higher initial cost, which also makes sense.)
Problem with new steam that can't be fixed:
  • Many old designs are broken due to low power output
  • More complexity
Problems that can probably be fixed but I don't have a solution:
  • Inefficient steam engines are ridiculously bad (a bad steam engine is like 30 PPM and 50 PPV, while a good one is around 600 PPM and 110 PPV) (I tried to fix this and spent like 40 hours on that, but I only managed to make it easier to build a mediocre engine)
  • Cannot be simulated to calculate a stable power output, like fuel engines do (actually it's easy but would take a lot of time to do and I don't think it's necessary)

Another massive change is the detection rework which I also left a few questions for Ian AKA Blothorn to explain the system and how it works.
Why a change was warranted:
  • Different types of detection weren't well balanced--for instance, visual components had better accuracy than IR and vastly better range.
  • Detection autoadjust used an incorrect formula, so optimizing adjustment was both mechanical and tedious.
  • Trackers having much better detection ranges than search sensors meant that detection was very binary--if you could see something at all you could usually get a precise lock (barring ECM, which was only counterable by large numbers of components).
  • Needing both sensors and munitions warners made reactive missile defence difficult on small vehicles.
  • There were a number of other inconsistencies/imbalances, e.g. some visual/IR sensors working through water, steam engines producing no heat, etc.
Overview of the new system:
On the offensive side, each sensor type now has a role in which it is optimal, and large vehicles are best using a variety to cover their weaknesses. Visual probably remains the default for above-water detection--it remains impossible to reduce visual signature other than reducing size. IR is better against fast vehicles, as they have trouble avoiding high IR signatures from thrust and drag. Both visual and IR are weak in rangefinding (although coincidence rangefinders are adequate for most purposes); radar is correspondingly strong in range and weak in bearing, although it often offers better detection chances against vehicles that don't pay attention to radar stealth.
On the defensive side, there are two approaches. Most obvious is signature reduction--while it is deliberately difficult to avoid detection entirely, reducing signature reduces detection chances and thus degrades opposing accuracy. At short ranges, however, this doesn't work well--detection chances are likely high regardless, and low errors at short range mean even sparse detections can give a good fix. Smoke and chaff can be useful here: they increase detection chance while adding a distance-independent error to opponent's visual and radar sensors, respectively.
ECM, buoys, and radar guidance have also been reworked. Buoys are more powerful, becoming more accurate as they get closer to the target. While their base error is high, at long ranges a buoy at close range can beat the accuracy of any onboard sensor. If you worry about opponents’ buoys, ECM can now intermittently jam them--except if they are connected to their parent vehicle by a harpoon cable, in which case they don't need the vulnerable wireless connection.
Most blueprints should need no modifications under the new system, although a few may want a few more or less GPP cards. The one exception is water interactions--IR cameras, laser rangefinders, and retroreflection sensors can no longer work through water, so submarines that used them underwater or vehicles that used them to detect submarines will need to replace them (likely with buoys). Vehicles that predominantly used visual detection should also consider adding a greater variety of sensors--in particular, visual camera trackers tied to AA mainframes should likely be replaced with IR cameras. Also, radars and cameras can take over missile and projectile detection (radar is required for projectile detection), so munitions warners can be removed/replaced with additional sensors.
Last but not least a sweet little addition to our build menu prefabs.
https://preview.redd.it/iqw1ymabu9t51.png?width=1920&format=png&auto=webp&s=aa1e3cdba6e1d62e07aef83caf0acad2a39249ed
Please do make sure you go through the changelog as a hell of a lot has changed!
submitted by BaconsTV to FromTheDepths [link] [comments]

MAME 0.222

MAME 0.222

MAME 0.222, the product of our May/June development cycle, is ready today, and it’s a very exciting release. There are lots of bug fixes, including some long-standing issues with classics like Bosconian and Gaplus, and missing pan/zoom effects in games on Seta hardware. Two more Nintendo LCD games are supported: the Panorama Screen version of Popeye, and the two-player Donkey Kong 3 Micro Vs. System. New versions of supported games include a review copy of DonPachi that allows the game to be paused for photography, and a version of the adult Qix game Gals Panic for the Taiwanese market.
Other advancements on the arcade side include audio circuitry emulation for 280-ZZZAP, and protection microcontroller emulation for Kick and Run and Captain Silver.
The GRiD Compass series were possibly the first rugged computers in the clamshell form factor, possibly best known for their use on NASA space shuttle missions in the 1980s. The initial model, the Compass 1101, is now usable in MAME. There are lots of improvements to the Tandy Color Computer drivers in this release, with better cartridge support being a theme. Acorn BBC series drivers now support Solidisk file system ROMs. Writing to IMD floppy images (popular for CP/M computers) is now supported, and a critical bug affecting writes to HFE disk images has been fixed. Software list additions include a collection of CDs for the SGI MIPS workstations.
There are several updates to Apple II emulation this month, including support for several accelerators, a new IWM floppy controller core, and support for using two memory cards simultaneously on the CFFA2. As usual, we’ve added the latest original software dumps and clean cracks to the software lists, including lots of educational titles.
Finally, the memory system has been optimised, yielding performance improvements in all emulated systems, you no longer need to avoid non-ASCII characters in paths when using the chdman tool, and jedutil supports more devices.
There were too many HyperScan RFID cards added to the software list to itemise them all here. You can read about all the updates in the whatsnew.txt file, or get the source and 64-bit Windows binary packages from the download page.

MAME Testers Bugs Fixed

New working machines

New working clones

Machines promoted to working

Clones promoted to working

New machines marked as NOT_WORKING

New clones marked as NOT_WORKING

New working software list additions

Software list items promoted to working

New NOT_WORKING software list additions

submitted by cuavas to emulation [link] [comments]

Unkle Mike. Culling Of Invisible Objects In Quake Related Engines

Intro
Despite all these great achievements in video cards development and the sworn assurances of developers about drawing 2 to 3 million polygons on screen without a significant FPS drop, it’s not all that rosy in reality. It depends on methods of rendering, on the number of involved textures and on the complexity and number of involved shaders. So even if all this really does ultimately lead to high performance, it only happens in the demos that developers themselves kindly offer. In these demos, some "spherical dragons in vacuum" made of a good hundred thousand polygons are drawn very quickly indeed. However, the real ingame situation for some reason never looks like this funny dragon from a demo, and as a result many comrades abandon the development of their "Crysis killer" as soon as they can render a single room with a couple of light sources, because for some reason FPS in this room fluctuate around 40-60 even on their 8800GTS and upon creating second room it drops to a whopping 20. Of course with problems like this, it would be incorrect to say how things aren’t that bad and how the trouble of such developers are purely in their absence of correctly implemented culling, and how it is time for them to read this article. But for those who have already overcome “the first room syndrome" and tried to draw – inferior though, but, anyway - the world, this problem really is relevant.
However, it should be borne in mind that QUAKE, written in ancient times, was designed for levels of a “corridor" kind exclusively; therefore methods of clipping discussed in this article are not applicable to landscapes, such as ones from STALKER or Crysis, since completely different methods work there, whose analysis is beyond the scope of this article. Meanwhile we’ll talk about the classic corridor approach to mapping and the effective clipping of invisible surfaces, as well as clipping of entire objects.

The paper tree of baloon leaves

As you probably know, QUAKE uses BSP, Binary Spacing Partition tree. This is a space indexing algorithm, and BSP itself doesn’t care if the space is open or closed, it doesn’t even care if the map is sealed, it can be anything. BSP implies the division of a three-dimensional object into a certain number of secant planes called "the branches" or "the nodes" and volumetric areas or rooms called "the leaves". The names are confusing as you can see. In QUAKE / QUAKE2 the branches usually contain information about the surfaces that this branch contain, and the leaves are an empty space, not filled with nothing. Although sometimes leaves may contain water for example (in a form of a variable that indicates, specifically, that we’ve got water in this leaf). Also, the leaf contains a pointer to the data of potential visibility (Potentially Visible Set, PVS) and a list of all surfaces that are marked as being visible from this leaf. Actually the approach itself implies that we are able to draw our world however we prefer, either using leaves only or using branches only. This is especially noticeable in different versions of QUAKE: for example, in QUAKE1 in a leaf we just mark our surfaces as visible and then we also sequentially go through all the surfaces visible from a particular branch, assembling chains of surfaces to draw them later. But in QUAKE3, we can accumulate visible surfaces no sooner than we’ll get into the leaf itself.
In QUAKE and QUAKE2, all surfaces must lie on the node, which is why the BSP tree grows rather quickly, but in exchange this makes it possible to trace these surfaces by simply moving around the tree, not wasting time to check each surface separately, which affects the speed of the tracer positively. Because of this, unique surface is linked to each node (the original surface is divided into several if necessary) so in the nodes we always have what is known to be visible beforehand, and therefore we can perform a recursive search on the tree using the BBox pyramid of frustum as a direction of our movement along the BSP tree (SV_RecursiveWorldNode function).
In QUAKE3, the tree was simplified and it tries to avoid geometry cuts as much as possible (a BSP tree is not even obliged to cut geometry, such cuts are but a matter of optimality of such a tree). And surfaces in QUAKE3 do not lie on the node because patches and triangle models lie there instead. But what happens would they be put on the node nevertheless, you can see on the example of "The Edge Of Forever" map that I compiled recently for an experimental version of Xash. Turns out, in places that had a couple thousand visible nodes and leaves in the original, there are almost 170 thousand of them with a new tree. And this is the result after all the preliminary optimizations, otherwise it could have been even more, he-he. Yeah, so... For this reason, the tree in QUAKE3 does not put anything on the node and we certainly do need to get into the leaf, mark visible surfaces in it and add them to the rendering list. On the contrary, in QUAKE / QUAKE2 going deep down to the leaf itself is not necessary.
Invisible polygon cutoff (we are talking about world polys, separate game objects will be discussed a bit later) is based on two methods:
The first method is to use bit-vectors of visibility (so-called PVS - Potential Visible Set). The second method is regular frustum culling which actually got nothing to do with BSP but works just as efficiently, for a certain number of conditions of course. Bottom line: together these two methods provide almost perfect clipping of invisible polygons, drawing a very small visible piece out of the vast world. Let's take a closer look at PVS and how it works.

When FIDO users get drunk

Underlying idea of PVS is to expose the fact that one leaf is visible from another. For BSP alone it’s basically impossible because leaves from completely different branches can be visible at the same time and you will never find a way to identify the pattern for leafs from different branches seeing each other - it simply doesn’t exist. Therefore, the compiler has to puff for us, manually checking the visibility of all leaves from all leaves. Information about visibility in this case is scanty: one Boolean variable with possible values 0 and 1. 0 means that leaf is not visible and 1 means that leaf is visible. It is easy to guess that for each leaf there is a unique set of such Boolean variables the size of the total number of leaves on the map. So a set like this but for all the leaves will take an order of magnitude more space: the number of leaves multiplied by the number of leaves and multiplied by the size of our variable in which we will store information of visibility (0 \ 1).
And the number of leaves, as you can easily guess, is determined by map size map and by the compiler, which upon reaching a certain map size, cease to divide the world into leaves and treat resulting node as a leaf. Leaf size vary for different QUAKE. For example, in QUAKE1 leaves are very small. For example I can tell you that the compiler divide standard boxmap in QUAKE1 into as many as four leaves meanwhile in QUAKE3 similar boxmap takes only one leaf. But we digress.
Let's estimate the size of our future PVS file. Suppose we have an average map and it has a couple thousand leaves. Would we imagine that the information about the leaf visibility is stored in a variable of char type (1 byte) then the size of visdata for this level would be, no more no less, almost 4 megabytes. That is, much AF. Of course an average modern developer would shrug and pack the final result into zip archive but back in 1995 end users had modest machines, their memory was low and therefore visdata was packed in “more different” ways. The first step in optimizing is about storing data not in bytes, but in bits. It is easy to guess that such approach reduce final result as much as 8 times and what's typical AF – does it without any resource-intensive algorithms like Huffman trees. Although in exchange, such approach somewhat worsened code usability and readability. Why am I writing this? Due to many developers’ lack of understanding for conditions in code like this:
if ( pvs [ leafnum >> 3 ] & ( 1 << ( leafnum & 7 ) ) ) { } 
Actually, this condition implement simple, beautiful and elegant access to the desired bit in the array (as one can recall, addressing less than one byte is impossible and you can only work with them via bit operations)

Titans that keep the globe spinning

The visible part of the world is cut off in the same fashion: we find the current leaf where the player is located (in QUAKE this is implemented by the Mod_PointInLeaf function) then we get a pointer to visdata for the current leaf (for our convenience, it is linked directly to the leaf in the form of "compressed_vis" pointer) and then stupidly go through all the leaves and branches of the map and check them for being visible from our leaf (this can be seen in the R_MarkLeaves function). As long as some leaves turn out to be visible from the current leaf we assign them a unique number from "r_visframecount" sequence which increases by one every frame. Thus, we emphasize that this leaf is visible when we build the current frame. In the next frame, "r_framecount" is incremented by one and all the leaves are considered invisible again. As one can understand, this is much more convenient and much faster than revisiting all the leaves at the end of each frame and zeroing their "visible" variable. I drew attention to this feature because this mechanism also bothers some and they don’t understand how it works.
The R_RecursiveWorldNode function “walk” along leaves and branches marked this way. It cuts off obviously invisible leaves and accumulate a list of surfaces from visible ones. Of course the first check is done for the equivalence of r_visframecount and visframe for the node in question. Then the branch undergoes frustum pyramid check and if this check fails then we don’t climb further along this branch. Having stumbled upon a leaf, we mark all its surfaces visible the same way, assigning the current r_framecount value to the visframe variable (in the future this will help us to determine quickly whether a certain surface is visible in the current frame). Then, using a simple function, we determine which side we are from the plane of our branch (each branch has its own plane, literally called “plane” in the code) and, again, for now, we just take all surfaces linked to this branch and add them to the drawing chain (so-called “texturechain”), although nobody can actually stop us from drawing them immediately, right there, (in QUAKE1 source code one can see both options) having previously checked these surfaces for clipping with the frustum pyramid, or at least having made sure that the surface faces us.
In QUAKE, each surface has a special flag SURF_PLANEBACK which help us determine the orientation of the surface. But in QUAKE3 there is no such flag anymore, and clipping of invisible surfaces is not as efficient, sending twice as many surfaces for rendering. However, their total number after performing all the checks is not that great. However, whatever one may say, adding this check to Xash3D raised average FPS almost one and half times in comparison to original Half-Life. This is on the matter whether it is beneficial. But we digress.
So after chaining and drawing visible surfaces, we call R_RecursiveWorldNode again but now - for the second of two root branches of BSP tree. Just in case. Because the visible surfaces, too, may well be there. When the recursion ends, the result will either be a whole rendered world, or chains of visible surfaces at least. This is what can actually be sent for rendering with OpenGL or Direct3D, well, if we did not draw our world right in the R_RecursiveWorldNode function of course. Actually this method with minor upgrades successfully used in all three QUAKEs.

A naked man is in a wardrobe because he's waiting for a tram

One of the upgrades is utilization of the so-called areaportals. This is another optimization method coming straight out of QUAKE2. The point of using areaportals is about game logic being able to turn the visibility of an entire sectors on and off at its discretion. Technically, this is achieved as follows: the world is divided into zones similar to the usual partitioning along the BSP tree, however, there can’t be more than 256 of them (later I will explain why) and they are not connected in any way.
Regular visibility is determined just like in QUAKE; however, by installing a special “func_areaportal” entity we can force the compiler to split an area in two. This mechanism operates on approximately the same principle as the algorithm of searching for holes in the map, so you won’t deceive the compiler by putting func_areaportal in a bare field - the compiler will simply ignore it. Although if you make areaportal the size of the cross-section of this field (to the skybox in all directions) in spite of everything the zones will be divided. We can observe this technique in Half-Life 2 where an attempt to return to old places (with cheats for example) shows us disconnected areaportals and a brief transition through the void from one zone to another. Actually, this mechanism helped Half-Life 2 simulate large spaces successfully and still use BSP level structure (I have already said that BSP, its visibility check algorithm to be precise, is not very suitable for open spaces).
So installed areaportal forcibly breaks one zone into two, and the rest of the zoneization is at the discretion of the compiler, which at the same time makes sure not to exceed 256 zones limit, so their sizes can be completely different. Well, I repeat, it depends on the overall size of the map. Our areaportal is connected to some door dividing these two zones. When the door is closed - it turns areaportal off and the zones are separated from each other. Therefore, if the player is not in the cut off zone, then rendering it is not worth it. In QUAKE, we’d have to do a bunch of checks and it’s possible that we could only cut off a fraction of the number of polygons (after all, the door itself is not an obstacle for either visibility check, or even more so, nor it is for frustum). Compare to case in point: one command is issued - and the whole room is excluded from visibility. “Not bad,” you’d say, “but how would the renderer find out? After all, we performed all our operations on the server and the client does not know anything about it.” And here we go back to the question why there can’t be more than 256 zones.
The point is, information about all of zone visibility is, likewise, packaged in bit flags (like PVS) and transmitted to the client in a network message. Dividing 256 bits by 8 makes 32 bytes, which generally isn’t that much. In addition, the tail of this information can be cut off at ease if it contains zeroes only. Though the payback for such an optimization would appear as an extra byte that will have to be transmitted over the network to indicate the actual size of the message about the visibility of our zones. But, in general, this approach justified.

Light_environment traces enter from the back

Source Engine turned out to have a terrible bug which makes the whole areaportal thing nearly meaningless. Numerous problems arise because of it: water breaks down into segments that pop in, well, you should be familiar with all this by now. Areaportal cuts the geometry unpredictably, like an ordinary secant plane, but its whole point is being predictable! Whereas areaportal brushes in Source Engine have absolutely no priority in splitting the map. It should be like this: first, the tree is cut the regular way. And when no suitable planes left, the final secant plane of areaportal is used. This is the only way to cut the sectors correctly.

Modern problems

The second optimization method, as I said, is increased size of the final leaf akin to QUAKE3. It is believed that a video card would draw a certain amount of polygons much faster than the CPU would check whether they are visible. This come from the very concept of visibility check: if visibility check takes longer than direct rendering, then well, to hell with this check. The controversy of this approach is determined by a wide range of video cards present at the hands of the end users, and it is strongly determined by the surging fashion for laptops and netbooks in which a video card is a very conditional and very weak concept (don’t even consider its claimed Shader Model 3 support). Therefore, for desktop gaming machines it would be more efficient to draw more at a time, but for weak video cards of laptops traditional culling will remain more reliable. Even if it is such a simple culling as I described earlier.

Decompression sickness simulator

Although I should also mention the principles of frustum culling, perhaps they are incomprehensible to some. Cutoff by frustum pyramid is actually pure mathematics without any compiler calculations. From the current direction of the player’s gaze, a clipping pyramid is built (the tip of the pyramid – in case someone can’t understand - is oriented towards the player’s point of view and its base is oriented in the direction of player’s view). The angle between the walls of the pyramid can be sharp or blunt - as you probably guessed already, it depends on the player's FOV. In addition, the player can forcefully pull the far wall of the pyramid closer to himself (yes, this is the notorious “MaxRange” parameter in the “worldspawn” menu of the map editor). Of course, OpenGL also builds a similar pyramid for its internal needs when it takes information from the projection matrix but we’re talking local pyramid now. The finished pyramid consists of 4-6 planes (QUAKE uses only 4 planes and trusts OpenGL to independently cut far and near polygons, but if you write your own renderer and intend to support mirrors and portals you will definitely need all six planes). Well, the frustum test itself is an elementary check for a presence of AA-box (AABB, Axis Aligned Bounding Box) in the frustum pyramid. Or speaking more correctly, this is a check for their intersection. Let me remind you that each branch has its own dimensions (a fragment of secant plane bound by neighboring perpendicular secant planes) which are checked for intersection. But unfortunately the frustum test has one fundamental drawback - it cannot cut what is directly in the player’s view. We can adjust the cutoff distance, we can even make that “ear feint” like they do in QFusion where final zFar value is calculated in each frame before rendering and then taken into account in entity clipping, but after all, whatever they say, the value itself was obtained from PVS-information. Therefore, neither of two methods can replace the other but they just complement each other. This should be remembered.

I gotta lay off the pills I'm taking

It seems that we figured out the rendering of the world and now we are moving on smoothly to cutting off moving objects... which are all the visible objects in the world! Even ones that, at te first glance, stand still and aren’t planning to move anywhere. Cause the player moves! From one point he still sees a certain static object, and from another point, of course, he no longer does. This detail should also be considered.
Actually, at the beginning of this article I already spoke in detail about an algorithm of objects’ visibility check: first we find the visible leaf for the player, then we find the visible leaf for the entity and then we check by visdata whether they see each other. I, too, would like to clarify (if someone suddenly does not understand) how each moving entity is given the number of its current visible leaf, i.e. directly for entity’s its own current position, and the leaves themselves are of course static and always in the same place.

Ostrich is such an OP problem solver

So the method described above has two potential problems:
The first problem is that even if A equals B, then, oddly enough, B is far from being always equal A. In other words, entity A can see entity B, but this does not mean that entity B see entity A, and, no, it’s not about one of them “looking” away. So why is this happening? Most often for two reasons:
The first reason is that one of the entities’ ORIGIN sit tight inside the wall and the Mod_PointInLeaf function for it points to the outer “zero” leaf from which EVERYTHING is visible (haven’t any of you ever flown around the map?). Meanwhile, no leaf inside the map can see outer leaf - these two features actually explain an interesting fact of an entire world geometry becoming visible and on the contrary, all objects disappearing when you fly outside the map. In regular mode, similar problems can occur for objects attached to the wall or recessed into the wall. For example, sometimes the sounds of a pressed button or opening door disappear because its current position went beyond the world borders. This phenomenon is fought by interchanging objects A and B or by obtaining alternative points for the position of an object, but all the same, it’s all not very reliable.

But lawyer said that you don't exist

In addition, as I said, there is another problem. It come from the fact that not every entity fits a single leaf. Only the player is so small that he can always be found in one leaf only (well, in the most extreme case - in two leaves on the border of water and air. This phenomenon is fought with various hacks btw), but some giant hentacle or on the contrary, an elevator made as a door entity, can easily occupy 30-40 leaves at a time. An attempt to check one leaf (for example, one where the center of the model is) will inevitably lead to a deplorable result: as soon as the center of an object will be out of the player’s visibility range, the entire object will disappear completely. The most common case is the notorious func_door used as an elevator. There is one in QUAKE on the E1M1. Observe: it travels halfway and then its ORIGIN is outside the map and therefore it must disappear from the player’s field of view. However, it does not go anywhere, right? Let us see in greater detail how this is done.
The simplest idea that comes to one’s mind: since the object occupies several leaves, we have to save them all somewhere in the structure of an object in the code and check them one by one. If at least one of these leaves is visible, then the whole object is visible (for example, it’s very tip). This is exactly what was implemented in QUAKE: a static array for 16 leaves and a simple recursive function SV_FindTouchedLeafs that looks for all the leaves in range hardcoded in "pev->absmins" and "pev->absmax" variables (pev i.e. a Pointer to EntVars_t table). absmins and absmax are recalculated each time SV_LinkEdict (or its more specific case of UTIL_SetOrigin) is called. Hence the quite logical conclusion that a simple change of ORIGIN without recalculating its visible leaf will take the object out of visibility sooner or later even if, surprisingly enough, it’s right in front of the player and the player should technically still be able to see it. Inb4 why one have to call UTIL_SetOrigin and wouldn’t it be easier to just assign new value to the "pev->origin" vector without calling this function. It wouldn’t.
With this method we can solve both former problems perfectly: we can fight the loss of visibility if the object's ORIGIN went beyond the world borders and level the difference of visibility for A->B versus visibility for B->A.

A secret life of monster_tripmine

Actually we’ve yet to encounter another problem, but it does not occur immediately. Remember, we’ve got an array of 16 leaves. But what if it won’t be enough? Thank God there are no beams in QUAKE and no very long elevators made as func_door either. For this exact reason. Because when the array is filled to capacity, the SV_FindTouchedLeafs function just stop and we can only hope that there won’t be that many cases when an object disappear right before our eyes. But in the original QUAKE, such cases may well be. In Half-Life, the situation is even worse - as you can remember there are rays that can reach for half the map, tripmine rays for example. In this case, a situation may occur when we see just the very tip of the ray. For most of these rays, 16 leaves are clearly not enough. Valve tried to remedy the situation by increasing the array to 48 leaves. That helped. On early maps. If you remember, at the very beginning of the game when the player has already got off the trailer, he enters that epic elevator that takes him down. The elevator is made as a door entity and it occupies 48 leaves exactly. Apparently, the final expansion of the array was based after its dimensions. Then the programmers realized that this isn’t really a solution, because no matter how much one would expand the array, it can still be lacking for something. So then they screwed up an alternative method for visibility check: a head branch (headnode) check. In short, this is still the same SV_FindTouchedLeafs but now it is called directly from the place of visibility check and with a subsequent transfer of visdata in there. In general, it is not used very often because it is slower than checking pre-accumulated leaves, that is, it is intended just for such non-standard cases like this one.
Well, and since, I hope, general picture of the clipping mechanism already beginning to take shape in your mind, I will finish the article in just a few words.
On the server, all objects that have already passed the visibility check are added to the network message containing information about visible objects. Thus, on the client, the list of visible entities is already cut off by PVS and we do not have to do this again and therefore a simple frustum check is enough. You ask, "why did we have to cut off invisible objects on the server when we could do this later when we are on the client already?" I reply: yes, we could, but now the objects cut off on the server didn’t get into the network message and saved us some traffic. And since the player still does not see them, what is the point of transferring them to the client just to check them for visibility after? This is a kind of double optimizing :)
© Uncle Mike 2012
submitted by crystallize1 to HalfLife [link] [comments]

AJ ALMENDINGER

glimpse into the future of Roblox

Our vision to bring the world together through play has never been more relevant than it is now. As our founder and CEO, David Baszucki (a.k.a. Builderman), mentioned in his keynote, more and more people are using Roblox to stay connected with their friends and loved ones. He hinted at a future where, with our automatic machine translation technology, Roblox will one day act as a universal translator, enabling people from different cultures and backgrounds to connect and learn from each other.
During his keynote, Builderman also elaborated upon our vision to build the Metaverse; the future of avatar creation on the platform (infinitely customizable avatars that allow any body, any clothing, and any animation to come together seamlessly); more personalized game discovery; and simulating large social gatherings (like concerts, graduations, conferences, etc.) with tens of thousands of participants all in one server. We’re still very early on in this journey, but if these past five months have shown us anything, it’s clear that there is a growing need for human co-experience platforms like Roblox that allow people to play, create, learn, work, and share experiences together in a safe, civil 3D immersive space.
Up next, our VP of Developer Relations, Matt Curtis (a.k.a. m4rrh3w), shared an update on all the things we’re doing to continue empowering developers to create innovative and exciting content through collaboration, support, and expertise. He also highlighted some of the impressive milestones our creator community has achieved since last year’s RDC. Here are a few key takeaways:
And lastly, our VP of Engineering, Technology, Adam Miller (a.k.a. rbadam), unveiled a myriad of cool and upcoming features developers will someday be able to sink their teeth into. We saw a glimpse of procedural skies, skinned meshes, more high-quality materials, new terrain types, more fonts in Studio, a new asset type for in-game videos, haptic feedback on mobile, real-time CSG operations, and many more awesome tools that will unlock the potential for even bigger, more immersive experiences on Roblox.

Vibin’

Despite the virtual setting, RDC just wouldn’t have been the same without any fun party activities and networking opportunities. So, we invited special guests DJ Hyper Potions and cyber mentalist Colin Cloud for some truly awesome, truly mind-bending entertainment. Yoga instructor Erin Gilmore also swung by to inspire attendees to get out of their chair and get their body moving. And of course, we even had virtual rooms dedicated to karaoke and head-to-head social games, like trivia and Pictionary.
Over on the networking side, Team Adopt Me, Red Manta, StyLiS Studios, and Summit Studios hosted a virtual booth for attendees to ask questions, submit resumes, and more. We also had a networking session where three participants would be randomly grouped together to get to know each other.

What does Roblox mean to you?

We all know how talented the Roblox community is from your creations. We’ve heard plenty of stories over the years about how Roblox has touched your lives, how you’ve made friendships, learned new skills, or simply found a place where you can be yourself. We wanted to hear more. So, we asked attendees: What does Roblox mean to you? How has Roblox connected you? How has Roblox changed your life? Then, over the course of RDC, we incorporated your responses into this awesome mural.
📷
Created by Alece Birnbach at Graphic Recording Studio

Knowledge is power

This year’s breakout sessions included presentations from Roblox developers and staff members on the latest game development strategies, a deep dive into the Roblox engine, learning how to animate with Blender, tools for working together in teams, building performant game worlds, and the new Creator Dashboard. Dr. Michael Rich, Associate Professor at Harvard Medical School and Physician at Boston Children’s Hospital, also led attendees through a discussion on mental health and how to best take care of you and your friends’ emotional well-being, especially now during these challenging times.
📷
Making the Dream Work with Teamwork (presented by Roblox developer Myzta)
In addition to our traditional Q&A panel with top product and engineering leaders at Roblox, we also held a special session with Builderman himself to answer the community’s biggest questions.
📷
Roblox Product and Engineering Q&A Panel

2020 Game Jam

The Game Jam is always one of our favorite events of RDC. It’s a chance for folks to come together, flex their development skills, and come up with wildly inventive game ideas that really push the boundaries of what’s possible on Roblox. We had over 60 submissions this year—a new RDC record.
Once again, teams of up to six people from around the world had less than 24 hours to conceptualize, design, and publish a game based on the theme “2020 Vision,” all while working remotely no less! To achieve such a feat is nothing short of awe-inspiring, but as always, our dev community was more than up for the challenge. I’ve got to say, these were some of the finest creations we’ve seen.
WINNERS
Best in Show: Shapescape Created By: GhettoMilkMan, dayzeedog, maplestick, theloudscream, Brick_man, ilyannna You awaken in a strange laboratory, seemingly with no way out. Using a pair of special glasses, players must solve a series of anamorphic puzzles and optical illusions to make their escape.
Excellence in Visual Art: agn●sia Created By: boatbomber, thisfall, Elttob An obby experience unlike any other, this game is all about seeing the world through a different lens. Reveal platforms by switching between different colored lenses and make your way to the end.
Most Creative Gameplay: Visions of a perspective reality Created By: Noble_Draconian and Spathi Sometimes all it takes is a change in perspective to solve challenges. By switching between 2D and 3D perspectives, players can maneuver around obstacles or find new ways to reach the end of each level.
Outstanding Use of Tech: The Eyes of Providence Created By: Quenty, Arch_Mage, AlgyLacey, xJennyBeanx, Zomebody, Crykee This action/strategy game comes with a unique VR twist. While teams fight to construct the superior monument, two VR players can support their minions by collecting resources and manipulating the map.
Best Use of Theme: Sticker Situation Created By: dragonfrosting and Yozoh Set in a mysterious art gallery, players must solve puzzles by manipulating the environment using a magic camera and stickers. Snap a photograph, place down a sticker, and see how it changes the world.
OTHER TOP PICKS
HONORABLE MENTIONS
For the rest of the 2020 Game Jam submissions, check out the list below:
20-20 Vision | 20/20 Vision | 2020 Vision, A Crazy Perspective | 2020 Vision: Nyon | A Wild Trip! | Acuity | Best Year Ever | Better Half | Bloxlabs | Climb Stairs to 2021 | Double Vision (Team hey apple) | Eyebrawl | Eyeworm Exam | FIRE 2020 | HACKED | Hyperspective | Lucid Scream | Mystery Mansion | New Years at the Museum | New Year’s Bash | Poor Vision | Predict 2020 | RBC News | Retrovertigo | Second Wave | see no evil | Sight Fight | Sight Stealers | Spectacles Struggle | Specter Spectrum | Survive 2020 | The Lost Chicken Leg | The Outbreak | The Spyglass | Time Heist | Tunnel Vision | Virtual RDC – The Story | Vision (Team Freepunk) | Vision (Team VIP People ####) | Vision Developers Conference 2020 | Vision Is Key | Vision Perspective | Vision Racer | Visions | Zepto
And last but not least, we wanted to give a special shout out to Starboard Studios. Though they didn’t quite make it on time for our judges, we just had to include Dave’s Vision for good measure. 📷
Thanks to everyone who participated in the Game Jam, and congrats to all those who took home the dub in each of our categories this year. As the winners of Best in Show, the developers of Shapescape will have their names forever engraved on the RDC Game Jam trophy back at Roblox HQ. Great work!

‘Til next year

And that about wraps up our coverage of the first-ever digital RDC. Thanks to all who attended! Before we go, we wanted to share a special “behind the scenes” video from the 2020 RDC photoshoot.
Check it out:
It was absolutely bonkers. Getting 350 of us all in one server was so much fun and really brought back the feeling of being together with everyone again. That being said, we can’t wait to see you all—for real this time—at RDC next year. It’s going to be well worth the wait. ‘Til we meet again, my friends.
© 2020 Roblox Corporation. All Rights Reserved.

Improving Simulation and Performance with an Advanced Physics Solver

August

05, 2020

by chefdeletat
PRODUCT & TECH
📷In mid-2015, Roblox unveiled a major upgrade to its physics engine: the Projected Gauss-Seidel (PGS) physics solver. For the first year, the new solver was optional and provided improved fidelity and greater performance compared to the previously used spring solver.
In 2016, we added support for a diverse set of new physics constraints, incentivizing developers to migrate to the new solver and extending the creative capabilities of the physics engine. Any new places used the PGS solver by default, with the option of reverting back to the classic solver.
We ironed out some stability issues associated with high mass differences and complex mechanisms by the introduction of the hybrid LDL-PGS solver in mid-2018. This made the old solver obsolete, and it was completely disabled in 2019, automatically migrating all places to the PGS.
In 2019, the performance was further improved using multi-threading that splits the simulation into jobs consisting of connected islands of simulating parts. We still had performance issues related to the LDL that we finally resolved in early 2020.
The physics engine is still being improved and optimized for performance, and we plan on adding new features for the foreseeable future.

Implementing the Laws of Physics

📷
The main objective of a physics engine is to simulate the motion of bodies in a virtual environment. In our physics engine, we care about bodies that are rigid, that collide and have constraints with each other.
A physics engine is organized into two phases: collision detection and solving. Collision detection finds intersections between geometries associated with the rigid bodies, generating appropriate collision information such as collision points, normals and penetration depths. Then a solver updates the motion of rigid bodies under the influence of the collisions that were detected and constraints that were provided by the user.
📷
The motion is the result of the solver interpreting the laws of physics, such as conservation of energy and momentum. But doing this 100% accurately is prohibitively expensive, and the trick to simulating it in real-time is to approximate to increase performance, as long as the result is physically realistic. As long as the basic laws of motion are maintained within a reasonable tolerance, this tradeoff is completely acceptable for a computer game simulation.

Taking Small Steps

The main idea of the physics engine is to discretize the motion using time-stepping. The equations of motion of constrained and unconstrained rigid bodies are very difficult to integrate directly and accurately. The discretization subdivides the motion into small time increments, where the equations are simplified and linearized making it possible to solve them approximately. This means that during each time step the motion of the relevant parts of rigid bodies that are involved in a constraint is linearly approximated.
📷📷
Although a linearized problem is easier to solve, it produces drift in a simulation containing non-linear behaviors, like rotational motion. Later we’ll see mitigation methods that help reduce the drift and make the simulation more plausible.

Solving

📷
Having linearized the equations of motion for a time step, we end up needing to solve a linear system or linear complementarity problem (LCP). These systems can be arbitrarily large and can still be quite expensive to solve exactly. Again the trick is to find an approximate solution using a faster method. A modern method to approximately solve an LCP with good convergence properties is the Projected Gauss-Seidel (PGS). It is an iterative method, meaning that with each iteration the approximate solution is brought closer to the true solution, and its final accuracy depends on the number of iterations.
📷
This animation shows how a PGS solver changes the positions of the bodies at each step of the iteration process, the objective being to find the positions that respect the ball and socket constraints while preserving the center of mass at each step (this is a type of positional solver used by the IK dragger). Although this example has a simple analytical solution, it’s a good demonstration of the idea behind the PGS. At each step, the solver fixes one of the constraints and lets the other be violated. After a few iterations, the bodies are very close to their correct positions. A characteristic of this method is how some rigid bodies seem to vibrate around their final position, especially when coupling interactions with heavier bodies. If we don’t do enough iterations, the yellow part might be left in a visibly invalid state where one of its two constraints is dramatically violated. This is called the high mass ratio problem, and it has been the bane of physics engines as it causes instabilities and explosions. If we do too many iterations, the solver becomes too slow, if we don’t it becomes unstable. Balancing the two sides has been a painful and long process.

Mitigation Strategies

📷A solver has two major sources of inaccuracies: time-stepping and iterative solving (there is also floating point drift but it’s minor compared to the first two). These inaccuracies introduce errors in the simulation causing it to drift from the correct path. Some of this drift is tolerable like slightly different velocities or energy loss, but some are not like instabilities, large energy gains or dislocated constraints.
Therefore a lot of the complexity in the solver comes from the implementation of methods to minimize the impact of computational inaccuracies. Our final implementation uses some traditional and some novel mitigation strategies:
  1. Warm starting: starting with the solution from a previous time-step to increase the convergence rate of the iterative solver
  2. Post-stabilization: reprojecting the system back to the constraint manifold to prevent constraint drift
  3. Regularization: adding compliance to the constraints ensuring a solution exists and is unique
  4. Pre-conditioning: using an exact solution to a linear subsystem, improving the stability of complex mechanisms
Strategies 1, 2 and 3 are pretty traditional, but 3 has been improved and perfected by us. Also, although 4 is not unheard of, we haven’t seen any practical implementation of it. We use an original factorization method for large sparse constraint matrices and a new efficient way of combining it with the PGS. The resulting implementation is only slightly slower compared to pure PGS but ensures that the linear system coming from equality constraints is solved exactly. Consequently, the equality constraints suffer only from drift coming from the time discretization. Details on our methods are contained in my GDC 2020 presentation. Currently, we are investigating direct methods applied to inequality constraints and collisions.

Getting More Details

Traditionally there are two mathematical models for articulated mechanisms: there are reduced coordinate methods spearheaded by Featherstone, that parametrize the degrees of freedom at each joint, and there are full coordinate methods that use a Lagrangian formulation.
We use the second formulation as it is less restrictive and requires much simpler mathematics and implementation.
The Roblox engine uses analytical methods to compute the dynamic response of constraints, as opposed to penalty methods that were used before. Analytics methods were initially introduced in Baraff 1989, where they are used to treat both equality and non-equality constraints in a consistent manner. Baraff observed that the contact model can be formulated using quadratic programming, and he provided a heuristic solution method (which is not the method we use in our solver).
Instead of using force-based formulation, we use an impulse-based formulation in velocity space, originally introduced by Mirtich-Canny 1995 and further improved by Stewart-Trinkle 1996, which unifies the treatment of different contact types and guarantees the existence of a solution for contacts with friction. At each timestep, the constraints and collisions are maintained by applying instantaneous changes in velocities due to constraint impulses. An excellent explanation of why impulse-based simulation is superior is contained in the GDC presentation of Catto 2014.
The frictionless contacts are modeled using a linear complementarity problem (LCP) as described in Baraff 1994. Friction is added as a non-linear projection onto the friction cone, interleaved with the iterations of the Projected Gauss-Seidel.
The numerical drift that introduces positional errors in the constraints is resolved using a post-stabilization technique using pseudo-velocities introduced by Cline-Pai 2003. It involves solving a second LCP in the position space, which projects the system back to the constraint manifold.
The LCPs are solved using a PGS / Impulse Solver popularized by Catto 2005 (also see Catto 2009). This method is iterative and considers each individual constraints in sequence and resolves it independently. Over many iterations, and in ideal conditions, the system converges to a global solution.
Additionally, high mass ratio issues in equality constraints are ironed out by preconditioning the PGS using the sparse LDL decomposition of the constraint matrix of equality constraints. Dense submatrices of the constraint matrix are sparsified using a method we call Body Splitting. This is similar to the LDL decomposition used in Baraff 1996, but allows more general mechanical systems, and solves the system in constraint space. For more information, you can see my GDC 2020 presentation.
The architecture of our solver follows the idea of Guendelman-Bridson-Fedkiw, where the velocity and position stepping are separated by the constraint resolution. Our time sequencing is:
  1. Advance velocities
  2. Constraint resolution in velocity space and position space
  3. Advance positions
This scheme has the advantage of integrating only valid velocities, and limiting latency in external force application but allowing a small amount of perceived constraint violation due to numerical drift.
An excellent reference for rigid body simulation is the book Erleben 2005 that was recently made freely available. You can find online lectures about physics-based animation, a blog by Nilson Souto on building a physics engine, a very good GDC presentation by Erin Catto on modern solver methods, and forums like the Bullet Physics Forum and GameDev which are excellent places to ask questions.

In Conclusion

The field of game physics simulation presents many interesting problems that are both exciting and challenging. There are opportunities to learn a substantial amount of cool mathematics and physics and to use modern optimizations techniques. It’s an area of game development that tightly marries mathematics, physics and software engineering.
Even if Roblox has a good rigid body physics engine, there are areas where it can be improved and optimized. Also, we are working on exciting new projects like fracturing, deformation, softbody, cloth, aerodynamics and water simulation.
Neither Roblox Corporation nor this blog endorses or supports any company or service. Also, no guarantees or promises are made regarding the accuracy, reliability or completeness of the information contained in this blog.
This blog post was originally published on the Roblox Tech Blog.
© 2020 Roblox Corporation. All Rights Reserved.

Using Clang to Minimize Global Variable Use

July

23, 2020

by RandomTruffle
PRODUCT & TECH
Every non-trivial program has at least some amount of global state, but too much can be a bad thing. In C++ (which constitutes close to 100% of Roblox’s engine code) this global state is initialized before main() and destroyed after returning from main(), and this happens in a mostly non-deterministic order. In addition to leading to confusing startup and shutdown semantics that are difficult to reason about (or change), it can also lead to severe instability.
Roblox code also creates a lot of long-running detached threads (threads which are never joined and just run until they decide to stop, which might be never). These two things together have a very serious negative interaction on shutdown, because long-running threads continue accessing the global state that is being destroyed. This can lead to elevated crash rates, test suite flakiness, and just general instability.
The first step to digging yourself out of a mess like this is to understand the extent of the problem, so in this post I’m going to talk about one technique you can use to gain visibility into your global startup flow. I’m also going to discuss how we are using this to improve stability across the entire Roblox game engine platform by decreasing our use of global variables.

Introducing -finstrument-functions

Nothing excites me more than learning about a new obscure compiler option that I’ve never had a use for before, so I was pretty happy when a colleague pointed me to this option in the Clang Command Line Reference. I’d never used it before, but it sounded very cool. The idea being that if we could get the compiler to tell us every time it entered and exited a function, we could filter this information through a symbolizer of some kind and generate a report of functions that a) occur before main(), and b) are the very first function in the call-stack (indicating it’s a global).
Unfortunately, the documentation basically just tells you that the option exists with no mention of how to use it or if it even actually does what it sounds like it does. There’s also two different options that sound similar to each other (-finstrument-functions and -finstrument-functions-after-inlining), and I still wasn’t entirely sure what the difference was. So I decided to throw up a quick sample on godbolt to see what happened, which you can see here. Note there are two assembly outputs for the same source listing. One uses the first option and the other uses the second option, and we can compare the assembly output to understand the differences. We can gather a few takeaways from this sample:
  1. The compiler is injecting calls to __cyg_profile_func_enter and __cyg_profile_func_exit inside of every function, inline or not.
  2. The only difference between the two options occurs at the call-site of an inline function.
  3. With -finstrument-functions, the instrumentation for the inlined function is inserted at the call-site, whereas with -finstrument-functions-after-inlining we only have instrumentation for the outer function. This means that when using-finstrument-functions-after-inlining you won’t be able to determine which functions are inlined and where.
Of course, this sounds exactly like what the documentation said it did, but sometimes you just need to look under the hood to convince yourself.
To put all of this another way, if we want to know about calls to inline functions in this trace we need to use -finstrument-functions because otherwise their instrumentation is silently removed by the compiler. Sadly, I was never able to get -finstrument-functions to work on a real example. I would always end up with linker errors deep in the Standard C++ Library which I was unable to figure out. My best guess is that inlining is often a heuristic, and this can somehow lead to subtle ODR (one-definition rule) violations when the optimizer makes different inlining decisions from different translation units. Luckily global constructors (which is what we care about) cannot possibly be inlined anyway, so this wasn’t a problem.
I suppose I should also mention that I still got tons of linker errors with -finstrument-functions-after-inlining as well, but I did figure those out. As best as I can tell, this option seems to imply –whole-archive linker semantics. Discussion of –whole-archive is outside the scope of this blog post, but suffice it to say that I fixed it by using linker groups (e.g. -Wl,–start-group and -Wl,–end-group) on the compiler command line. I was a bit surprised that we didn’t get these same linker errors without this option and still don’t totally understand why. If you happen to know why this option would change linker semantics, please let me know in the comments!

Implementing the Callback Hooks

If you’re astute, you may be wondering what in the world __cyg_profile_func_enter and __cyg_profile_func_exit are and why the program is even successfully linking in the first without giving undefined symbol reference errors, since the compiler is apparently trying to call some function we’ve never defined. Luckily, there are some options that allow us to see inside the linker’s algorithm so we can find out where it’s getting this symbol from to begin with. Specifically, -y should tell us how the linker is resolving . We’ll try it with a dummy program first and a symbol that we’ve defined ourselves, then we’ll try it with __cyg_profile_func_enter .
[email protected]:~/src/sandbox$ cat instr.cpp int main() {} [email protected]:~/src/sandbox$ clang++-9 -fuse-ld=lld -Wl,-y -Wl,main instr.cpp /usbin/../lib/gcc/x86_64-linux-gnu/crt1.o: reference to main /tmp/instr-5b6c60.o: definition of main
No surprises here. The C Runtime Library references main(), and our object file defines it. Now let’s see what happens with __cyg_profile_func_enter and -finstrument-functions-after-inlining.
[email protected]:~/src/sandbox$ clang++-9 -fuse-ld=lld -finstrument-functions-after-inlining -Wl,-y -Wl,__cyg_profile_func_enter instr.cpp /tmp/instr-8157b3.o: reference to __cyg_profile_func_enter /lib/x86_64-linux-gnu/libc.so.6: shared definition of __cyg_profile_func_enter
Now, we see that libc provides the definition, and our object file references it. Linking works a bit differently on Unix-y platforms than it does on Windows, but basically this means that if we define this function ourselves in our cpp file, the linker will just automatically prefer it over the shared library version. Working godbolt link without runtime output is here. So now you can kind of see where this is going, however there are still a couple of problems left to solve.
  1. We don’t want to do this for a full run of the program. We want to stop as soon as we reach main.
  2. We need a way to symbolize this trace.
The first problem is easy to solve. All we need to do is compare the address of the function being called to the address of main, and set a flag indicating we should stop tracing henceforth. (Note that taking the address of main is undefined behavior[1], but for our purposes it gets the job done, and we aren’t shipping this code, so ¯\_(ツ)_/¯). The second problem probably deserves a little more discussion though.

Symbolizing the Traces

In order to symbolize these traces, we need two things. First, we need to store the trace somewhere on persistent storage. We can’t expect to symbolize in real time with any kind of reasonable performance. You can write some C code to save the trace to some magic filename, or you can do what I did and just write it to stderr (this way you can pipe stderr to some file when you run it).
Second, and perhaps more importantly, for every address we need to write out the full path to the module the address belongs to. Your program loads many shared libraries, and in order to translate an address into a symbol, we have to know which shared library or executable the address actually belongs to. In addition, we have to be careful to write out the address of the symbol in the file on disk. When your program is running, the operating system could have loaded it anywhere in memory. And if we’re going to symbolize it after the fact we need to make sure we can still reference it after the information about where it was loaded in memory is lost. The linux function dladdr() gives us both pieces of information we need. A working godbolt sample with the exact implementation of our instrumentation hooks as they appear in our codebase can be found here.

Putting it All Together

Now that we have a file in this format saved on disk, all we need to do is symbolize the addresses. addr2line is one option, but I went with llvm-symbolizer as I find it more robust. I wrote a Python script to parse the file and symbolize each address, then print it in the same “visual” hierarchical format that the original output file is in. There are various options for filtering the resulting symbol list so that you can clean up the output to include only things that are interesting for your case. For example, I filtered out any globals that have boost:: in their name, because I can’t exactly go rewrite boost to not use global variables.
The script isn’t as simple as you would think, because simply crawling each line and symbolizing it would be unacceptably slow (when I tried this, it took over 2 hours before I finally killed the process). This is because the same address might appear thousands of times, and there’s no reason to run llvm-symbolizer against the same address multiple times. So there’s a lot of smarts in there to pre-process the address list and eliminate duplicates. I won’t discuss the implementation in more detail because it isn’t super interesting. But I’ll do even better and provide the source!
So after all of this, we can run any one of our internal targets to get the call tree, run it through the script, and then get output like this (actual output from a Roblox process, source file information removed):
excluded_symbols = [‘.\boost.*’]* excluded_modules = [‘/usr.\’]* /uslib/x86_64-linux-gnu/libLLVM-9.so.1: 140 unique addresses InterestingRobloxProcess: 38928 unique addresses /uslib/x86_64-linux-gnu/libstdc++.so.6: 1 unique addresses /uslib/x86_64-linux-gnu/libc++.so.1: 3 unique addresses Printing call tree with depth 2 for 29276 global variables. __cxx_global_var_init.5 (InterestingFile1.cpp:418:22) RBX::InterestingRobloxClass2::InterestingRobloxClass2() (InterestingFile2.cpp.:415:0) __cxx_global_var_init.19 (InterestingFile2.cpp:183:34) (anonymous namespace)::InterestingRobloxClass2::InterestingRobloxClass2() (InterestingFile2.cpp:171:0) __cxx_global_var_init.274 (InterestingFile3.cpp:2364:33) RBX::InterestingRobloxClass3::InterestingRobloxClass3()
So there you have it: the first half of the battle is over. I can run this script on every platform, compare results to understand what order our globals are actually initialized in in practice, then slowly migrate this code out of global initializers and into main where it can be deterministic and explicit.

Future Work

It occurred to me sometime after implementing this that we could make a general purpose profiling hook that exposed some public symbols (dllexport’ed if you speak Windows), and allowed a plugin module to hook into this dynamically. This plugin module could filter addresses using whatever arbitrary logic that it was interested in. One interesting use case I came up for this is that it could look up the debug information, check if the current address maps to the constructor of a function local static, and write out the address if so. This effectively allows us to gain a deeper understanding of the order in which our lazy statics are initialized. The possibilities are endless here.

Further Reading

If you’re interested in this kind of thing, I’ve collected a couple of my favorite references for this kind of topic.
  1. Various: The C++ Language Standard
  2. Matt Godbolt: The Bits Between the Bits: How We Get to main()
  3. Ryan O’Neill: Learning Linux Binary Analysis
  4. Linkers and Loaders: John R. Levine
  5. https://eel.is/c++draft/basic.exec#basic.start.main-3
Neither Roblox Corporation nor this blog endorses or supports any company or service. Also, no guarantees or promises are made regarding the accuracy, reliability or completeness of the information contained in this blog.
submitted by jaydenweez to u/jaydenweez [link] [comments]

MAME 0.222

MAME 0.222

MAME 0.222, the product of our May/June development cycle, is ready today, and it’s a very exciting release. There are lots of bug fixes, including some long-standing issues with classics like Bosconian and Gaplus, and missing pan/zoom effects in games on Seta hardware. Two more Nintendo LCD games are supported: the Panorama Screen version of Popeye, and the two-player Donkey Kong 3 Micro Vs. System. New versions of supported games include a review copy of DonPachi that allows the game to be paused for photography, and a version of the adult Qix game Gals Panic for the Taiwanese market.
Other advancements on the arcade side include audio circuitry emulation for 280-ZZZAP, and protection microcontroller emulation for Kick and Run and Captain Silver.
The GRiD Compass series were possibly the first rugged computers in the clamshell form factor, possibly best known for their use on NASA space shuttle missions in the 1980s. The initial model, the Compass 1101, is now usable in MAME. There are lots of improvements to the Tandy Color Computer drivers in this release, with better cartridge support being a theme. Acorn BBC series drivers now support Solidisk file system ROMs. Writing to IMD floppy images (popular for CP/M computers) is now supported, and a critical bug affecting writes to HFE disk images has been fixed. Software list additions include a collection of CDs for the SGI MIPS workstations.
There are several updates to Apple II emulation this month, including support for several accelerators, a new IWM floppy controller core, and support for using two memory cards simultaneously on the CFFA2. As usual, we’ve added the latest original software dumps and clean cracks to the software lists, including lots of educational titles.
Finally, the memory system has been optimised, yielding performance improvements in all emulated systems, you no longer need to avoid non-ASCII characters in paths when using the chdman tool, and jedutil supports more devices.
There were too many HyperScan RFID cards added to the software list to itemise them all here. You can read about all the updates in the whatsnew.txt file, or get the source and 64-bit Windows binary packages from the download page.

MAME Testers Bugs Fixed

New working machines

New working clones

Machines promoted to working

Clones promoted to working

New machines marked as NOT_WORKING

New clones marked as NOT_WORKING

New working software list additions

Software list items promoted to working

New NOT_WORKING software list additions

submitted by cuavas to MAME [link] [comments]

60 Second Binary Options Strategy Wins 90% of The Time ... 1-minute (“60-second”) Binary Options Strategy - YouTube BINARY OPTIONS: profitable strategy 60 seconds - YouTube 60 Second Binary Options - YouTube Binary Options 60 Seconds Indicator 99% Winning Live ... 60 Sekunden Optionen - YouTube

Here is our short list of binary options brokers who offer real demo trading accounts and 60 second trades. A Legit Demo Account at 24option – “Trading binary options involves substantial risk and may lead to loss of all invested capital.” 24 Option – Excellent reputation and customer service. 60 second binary options are a fast growing type of trading. These options can give you a large rate of return almost instantly, but there are many things you need to know before you start off in trading these fast paced options. They can have big returns, but there is also a great deal of risk associated with them. Your potential for losses are bigger than your potential for gains, so you do ... 5 Decimale 60 Seconden Binaire Opties Simulator »jamie Harris Studio Just diving into the Neon Breakout system and trying to 5 Decimale 60 Seconden Binaire Opties Simulator »jamie Harris Studio absorb all of the amazing amount of information. Looks like a great system, can't wait to start using it on my demo acct. Definitely a lot more tools to use than previous systems. Thanks binary options safe strategy. اخر اخبار binary options welcome bonus مصر السياسية binary options 60 second signals نعرض اسعار الدولار في مصر من السوق السوداء يوميا.. casa granada. european binary option تجارة الفوركيس حلال ام حرام تحذير المخاطرة: التداول في الاسواق المالية ... 60 second binary options brokers list Find The Best Binary Brokers in PH. Compare Start Trading. دانلود comبرنامه بازار The number of Binary options brokers has globally and continually grown over the years, with new 60-second options traders joining the market on a daily basis. Simulator, these type of binary options let you jump into the trend of the market, and get out of a trade quickly before a major market reversal occurs This allows you to take advantage of multiple profit opportunity Disadvantages While you can trade a lot in a day with 60 second binary options and second make a lot of money, you could also lose a lot. To make a decent second your win rate ... 60 Seconds Strategy Binary Options Binary options of 60 seconds are options for which the completion of the contract (expiration) is 1 minute. This means that you purchase an option and 1 minute later get the result of trade. The 60-second turbo-options trade has become quite popular - experienced traders and beginners work with these... System 60 second binary options simulator A great agricultural raw ebook get money. and paper. Options Trading 101. Menirva EURUSD 5,000.00 $ 125.00 $ 60 Second Binary Option Scalping 49.00 $ 25.00 $ Add to cart-84%. Author: TheBinary Destroyer Views: 56K Binary Options Trading Strategy Youtube, My 1-Minute (60 https://solutionsforsyspro.com › binary-options-trading-strategy-youtube This ... Polega of these sex eight can be explained by the 60 second binary option strategy simulator options between the dutch and the sensitive asset. You probably ask yourself, why exactly is this guy selling his binary options strategies? We complement highlighting the education package on your skills. Remember that generally the riskier and faster paced an investment is, the more you need to ... The Binary Options Trading Simulator can also be used to backtest different trading strategies or indicators by making use of the strategy tester on your Metatrader 4. We have found that this function is particularly useful for those traders who are unable to practice during regular market hours. Using the strategy tester enables you to trade a few weeks’ worth of data in just a few hours ...

[index] [25439] [21132] [19124] [22738] [14850] [15807] [785] [36] [29532] [18545]

60 Second Binary Options Strategy Wins 90% of The Time ...

Mail: [email protected] telegram and whatsapp 3460784176 *link stars binary: https://starsbinary.com/ref/sb542 Hi Friends I will Show This Video Binary Options 60 Seconds Indicator Signal 99% Winning Live Trading Proof -----... http://60secondcashsystem.com/ Click Link To Left To Receive Your FREE Binary Options Trading Guide! 60 Second Binary Options http://www.youtube.com/watch?v=... 1-minute (“60-second”) Binary Options Strategy Download App... https://app.appsflyer.com/com.iqoptio... https://affiliate.iqoption.com/redir/... 60 Seconds binary options strategy 99 - 100% Winning (100% profit guaranteed) 90 - 95% Winning Binary Options Strategy in case of correct prediction - 1 to 5... Download this template here: http://barbarianarrow.com In this tutorial I teach how to win 90% of the time with 60 second strategy for binary options. This i... Binäre Optionen Anbieter Banc de Binary Erfahrung - Binäre Optionen Anbieter Banc de Binary Erfahrun - Duration: 12 minutes, 41 seconds. 60 Sekunden Optionen 6,491 views

http://arab-binary-option.riecimemrigecon.tk