3 stories
·
1 follower

mGBA 0.7.3

1 Share

A new release of mGBA, version 0.7.3, is available. This version is a bugfix release, which contains many stability and accuracy fixes. Notably, sprites that are broken at the top of the screen are fixed. An extensive list of changes follows after the cut.

Emulation fixes:

  • GB: Fix savedata initialization (fixes #1478, #1478)
  • GB: Fix SGB controller incrementing (fixes #1104)
  • GB Audio: Improve channel 4 supersampling
  • GB Printer: Reset printer buffer index after printing
  • GB Audio: Deschedule channel 3 when disabled (fixes #1463)
  • GB Audio: Deschedule channel 1 when disabled by sweep (fixes #1467)
  • GB Video: Increment BCPS/OCPS even in mode 3 (fixes #1462)
  • GBA Memory: Fix STM to VRAM (fixes #1430)
  • GBA Memory: Fix STM/LDM to invalid VRAM
  • GBA Video: Fix wrapped sprite mosaic clamping (fixes #1432)
  • GBA Audio: Fix channel 4 aliasing (fixes #1265)

Other fixes:

  • Core: Fix crashes if core directories aren’t set
  • Core: Fix crash when exiting game with cheats loaded
  • GBA: Set up GPIO mapping on null and ELF ROM regions (fixes #1481)
  • GBA Cheats: Fix PARv3 Thumb hooks
  • GBA Cheats: Fix value incrementing in CB slide codes (fixes #1501)
  • Qt: Fix FPS target maxing out at 59.727 (fixes #1421)
  • Qt: Cap audio buffer size to 8192 (fixes #1433)
  • Qt: Fix race conditions initializing GDB stub
  • Qt: Improve cheat view UX
  • Libretro: Fix crash changing allowing opposing directions (hhromic)
  • mGUI: Fix crash if last loaded ROM directory disappears (fixes #1466)
  • Switch: Fix threading-related crash on second launch

Misc:

  • Qt: Make mute menu option also toggle fast-forward mute (fixes #1424)
  • Qt: Show error message if file failed to load

Get it now in the Downloads section. Binaries are available for Windows, Ubuntu, macOS, 3DS, Switch, Vita, and Wii, and the source code is available for all other platforms.

Read the whole story
FrostedGlitch
1 day ago
reply
Share this story
Delete

This Week In Veloren 32

1 Share

Thanks to all of the contributors this week, @Desttinghim, @Imbris, @scott-c, @haslersn, @andymac, @Slipped, @xMAC94x, @AngelOnFira, @Pfauenauge, @Timo, @Geno, and @Zesterer!

The Future of Veloren by @Zesterer

Veloren started life as a Cube World clone. We make no secret about this, and it's very clear that Cube World is Veloren's primary influence. If you were to take a peek at the git history of the engine, you will find that, fittingly, 'Clone World' was the preliminary name we used for the project.

Times, however, have changed. Throughout Veloren's development, it has become clear to us that there are many aspects of Cube World that we feel dissatisfied with, and that there are many ideas we'd like to experiment with that Cube World does not explore.

Last week, the developer of Cube World, Wollay, broke his silence to announce a new Cube World release. Being fans of Cube World, we're all excited to play it - I'm sure it'll halt Veloren's development for at least a few days while we enjoy it.

Many have asked whether Cube World's imminent release will mean the end for Veloren. For us, without a shadow of a doubt, the answer is a decisive "no". Be it the community we've grown, the things we've learned, the artwork we've created, the engine we've built, or the ideas we've shared - it's clear to us that the potential for this project is unbounded.

That said, it's become clear to us that Veloren needs a stronger vision. It's not uncommon for us to find ourselves explaining what Veloren isn't rather than what it is. This partly stems from Veloren's origins as a clone, but it also stems from our open-ended development model. As of yet, we've avoiding planning more than one release ahead. In short, we've lacked a long-term vision for Veloren.

Starting this week, we intend to change that.

Throughout the next fortnight, we'll be looking to the future to plan a long-term roadmap for the project. We'll be talking to the community to gather as many ideas as possible, then we'll assemble them into a long-term plan that takes us from where we are now to a 1.0 release. That's not to say that this roadmap will be set in stone - as a community-driven project, new ideas will inevitably come along to replace old ones. However, this roadmap will provide us with the long-term vision we need to drive this project forward with purpose and clarity.

Development

Contributor work

@Sharp has been continuing work on lakes and rivers. There is a lot to fiddle around with to make them feel natural. @Xacromon has been continuing work on the auth side and has just started working on account management. @Yurimomo has worked on improving the way we go about testing, and how we can improve our changelog.

rivers

The debug work on the river systems

New Chunk Data Structure @haslersn

This week, @haslersn implemented a new chunk data structure. A chunk in Veloren is an arrangement of voxels which has an area of 32 by 32 voxels and is 16 voxels in height. All of the terrain is stored in a three-dimensional regular grid of such chunks. This holds true for both the old and the new data structure, both of which we'll now explain.

Previously, there were three types of chunks. The first type was a chunk that only contains copies of one voxel. This type was for example used if the chunk consisted solely of air. The second type was a chunk that mostly contains copies of one default voxel but is also sparsely filled with different voxels. Those deviations from the default voxel were stored in a hash table. The motivation for storing only the deviations was to save memory. The third type was a chunk that contains arbitrary voxels, stored in an array of length 32 x 32 x 16. This type was used if the second type couldn't save a considerable amount of memory anymore, because of too many deviations from the default.

waterfall

The first documented waterfall in Veloren!

However, the previous implementation wasn't very efficient because of two reasons. First, for every access to some voxel data there's a branch checking for the chunk type. Second, if the accessed chunk is of the second type and therefore uses a hash table, then a hash has to be calculated.

People tend to agree that the second reason is indeed a problem. For the first reason this less clear-cut. One might argue that consecutive accesses most often access the same chunk and then the branch predictor is right most of the time. We can't know without benchmarking and so we did. Before showing the benchmarking results, we explain the new data structure which gets along without a hash table.

In the new data structure, the chunk of 32 x 32 x 16 voxels is furthermore subdivided into groups of 4 x 4 x 4 voxels. Consequently, there are 256 such groups per chunk. Again, for every chunk, there's a default voxel. If within a group every voxel is a copy of that default voxel, then we don't store that group. If, on the other hand, a single voxel within a group deviates from the default voxel, then the whole group is stored. To store those groups, we have an array of voxels that grows dynamically every time a new group has to be stored. To track if a group is stored and wherein the voxel array it is stored, we have an extra index buffer that contains per group an index into the voxel array.

water-city

Still to work to do on town generation!

In comparison to the old data structure, we get a little bit of memory overhead for empty or almost empty chunks, because we always store the index buffer. But in other cases where most voxel groups are filled with non-air voxels, we win in this respect.

We benchmarked old versus new, considering an arrangement of five stacked chunks that are filled with voxels, and obtained the following results.

| Benchmark                                | Old data structure | New data structure   |
| ---------------------------------------- | -------------------|--------------------- |
| full read (81920 voxels)                 | 17.7ns per voxel   | 3.6ns per voxel      |
| constrained read (4913 voxels)           | 67.0ns per voxel   | 14.1ns per voxel     |
| local read (125 voxels)                  | 17.5ns per voxel   | 3.8ns per voxel      |
| X-direction read (17 voxels)             | 17.8ns per voxel   | 4.2ns per voxel      |
| Y-direction read (17 voxels)             | 18.4ns per voxel   | 4.5ns per voxel      |
| Z-direction read (17 voxels)             | 18.6ns per voxel   | 5.4ns per voxel      |
| long Z-direction read (65 voxels)        | 18.0ns per voxel   | 5.1ns per voxel      |
| full write (dense) (81920 voxels)        | 17.9ns per voxel   | 12.4ns per voxel     |

As you can see, the old data structure is defeated. Since we only considered completely filled chunks, the only seeming problem with the old data structure that could lead to this defeat was the extra branch. However, it's important to note that we can't be sure that this was the only reason why the old implementation performed worse. For sparsely filled chunks we assume an even greater improvement because hash tables are known to have slower access times than arrays, especially for the sizes relevant here.

Map and Minimap by @haslersn

@haslersn also did some work on adding a map and mini-map. This is not yet merged into master, but a feature branch and several screenshots have been shared.

map

The new minimap view!

As you can see, the map is three-dimensional and encompasses all of the structures which are present in the world. This is achieved by simply taking the actual terrain's voxel data and averaging a cube of 4 x 4 x 4 voxels into a single voxel on the map. Hereby the algorithm must consider only voxels that have, on any of the six squares, an adjacent air-voxel. Otherwise, a green pasture wouldn't look as green because not so green voxels from below the ground would be considered.

Implementation-wise, various additional code had to be added: Changes in the terrain need to trigger a generation or regeneration of the corresponding map chunk, map chunks need to be meshed and, of course, the minimap has to be rendered. If you pay close attention, you can see the player's figure on the minimap in one of the screenshots. Luckily the rendering code for the main scene could simply be re-used with some things disabled, so as to render the minimap and the desired figures thereon. Hence the main work was not to implement new code, but rather to adapt existing code to be re-usable in other contexts, such as for the minimap. This work is still ongoing.

mini-map

The real map and the player visible in the minimap. See you next week!

Read the whole story
FrostedGlitch
5 days ago
reply
Share this story
Delete

Reporters Without Borders: Posteo supports the Press Freedom Awards

1 Comment

Dear Posteo customers,

The Press Freedom Awards given by Reporters Without Borders (RSF) honours particularly courageous and independent journalists who will not be silenced despite adverse circumstances and great danger to life and limb. Posteo is donating the prize money for the “Courage” category in journalism.

The nominees for the &quotCourage&quot category in the Press Freedom Awards
The nominees for the “Courage” category in the Press Freedom Awards Source: Reporters Without Borders

It’s a pleasure for us to be able to support courageous media representatives in such a way. On September 12th, the Press Freedom Awards will be held in Berlin for the first time.

This year’s nominees for three prize categories hail from 12 different countries. Among them is a Russian investigative journalist who has already been the target of multiple attacks, a Vietnamese journalist who has been beaten and imprisoned because of her work as well as Pakistan’s oldest daily newspaper that has been repeatedly harrassed by officials.

The nominees from the “Courage” category sponsored by Posteo

Igor Rudnikov
Igor RudnikovSource: Reporters Without Borders


Igor Rudnikov (Russia) – There have been multiple attacks directed towards the founder of the independent newspaper Novye Kolesa because of his research on corruption and public fund embezzlement. Furthermore, he was arrested because of his work. In prison he continued to write articles and a book that contains the quote: “Thought cannot be handcuffed or thrown in prison. It will always be free.”

Eman al Nafjan
Eman al NafjanSource: Reporters Without Borders


Eman Al-Nafjan (Saudi Arabia) – The blogger and journalist has campaigned massively for women to be allowed to drive cars and to have more rights. Because of this, she was arrested. Currently she has been temporarily freed. She created the website SaudiWoman.me and writes for international media outlets like the British newspaper The Guardian and the New York Times. Since mid-2018 the state has also permitted women to drive cars.

Paolo Borrometi
Paolo Borrometi Source: Reporters Without Borders


Paolo Borrometi (Italy) – He is regularly threated with death because of his fearless reporting about the mafia and is constantly under police protection. He writes for the newspaper Giornale di Sicilia and his own website La Spia.

Lola Aronovich
Lola Aronovich Source: Reporters Without Borders


Lola Aronovich (Brazil) – The blogger has made a name for herself with her feminist texts and commitment to women’s rights. At the same time she has been treated increasingly with hostility. She receives hundreds of death threats online. Since 2018, a law has been put into effect in Brazil that enhances traceability for misogynistic crimes online. It has also been called the “Lola Law”.









Premiere in Germany

The non-government organization, Reporters Without Borders has been presenting the Press Freedom Awards for 27 years now. Traditionally the event takes place in France – the country where RSF was founded. To celebrate 25-years since its creation, the German section of the organisation is hosting the awards ceremony this year.

The awards recipients will be announced on September 12th in the Kammerspiele of Deutsche Theater in Berlin. The jury is made up of presidents from the seven global RSF sections. It will also include the so-called Emeritus Board, which consists of men and women that have rendered outstanding services in various areas of human rights and freedom of speech.

Our support

It is important to us to encourage social engagement and to take responsibility as a company. We therefore support selected charitable organisations in the areas of climate and environmental protection, internet politics and freedom of opinion, as well as refugee aid.

Best regards,
The Posteo Team

Read the whole story
FrostedGlitch
6 days ago
reply
This is absolutely great that Posteo is helping Reporters Without Borders. Humanity desperately needs people outing scum & unrelentingly advocating equality.
Share this story
Delete