Dingux (Dingoo Linux) > Releases
Second OpenDingux developer prerelease
mth:
We released an updated developer pre-release of OpenDingux, based on the feedback we got on the first pre-release. We had almost 500 rootfs downloads of the first pre-release and almost 200 toolchain downloads. There are still some rough edges, but adventurous users are encouraged to try this second pre-release, as long as they don't expect everything to work yet.
Most notable changes:
* fixed double buffering when TV-out is active
* made framebuffer cacheable; this can speed up rendering considerably
* changed supported image formats for SDL_image; fixes games that use JPEG images
* added libmikmod and support for it in SDL_mixer; fixes games that use music in MOD or other tracker formats
* many small improvements to gmenu2x
* ability to kill active application using power + selectThe full list of changes is on the download page.
Release notes and downloads: http://www.treewalker.org/opendingux/.
That page also contains links to relevant documentation pages on the Dingoo Wiki. Especially the development page and FAQ are useful when porting applications from legacy Dingux to OpenDingux.
virusmater:
if set sound volume to min (power+down down down.. :)) and start play in game with sound (i test on picodrive) - dingoo will be make buzzzing noises
if increase volume for one delimiter - noise will gone
maybe it bug of picodrive, because i don't hear any noises in gpsp
pcercuei:
I saw that bug this week-end, I did hope you wouldn't notice it ;D
I'll fix that in the next release.
It's occuring only on the apps using libAO, the library used to simplify porting from OSS. Currently only Picodrive uses that library.
pcercuei:
--- Quote from: mth on September 19, 2011, 10:15:36 AM ---made framebuffer cacheable; this can speed up rendering considerably
--- End quote ---
Here are some benchmarks with GPMark. The dingoo is running at 336MHz, and for each test (using software surface, then hardware surface), the binaries executed on OD and the legacy Dingux are the very same.
All the figures are in FPS.
legacy Dingux, software surface (most of the apps):
--- Code: ---Blitting test 186.2
Plasma 140.0
Rotozoomer 112.1
Rotozoomer near 141.2
Rotozoomer far 53.0
Radial blur 27.4
3D bunny 4.6
--- End code ---
OpenDingux 2011-09-04 (first pre-release), software surface:
--- Code: ---Blitting test 183.4
Plasma 127.0
Rotozoomer 106.7
Rotozoomer near 128.6
Rotozoomer far 54.5
Radial blur 26.2
3D bunny 4.8
--- End code ---
OpenDingux 2011-09-18 (second pre-release), software surface:
--- Code: ---Blitting test 207.8
Plasma 142.2
Rotozoomer 116.0
Rotozoomer near 142.5
Rotozoomer far 56.5
Radial blur 27.1
3D bunny 4.8
--- End code ---
While the first pre-release of OpenDingux did obtain lower values in general, the second pre-release outperforms the legacy Dingux kernel in each one of the tests.
It means that at least for the rendering part, the games compatible with the legacy Dingux will need less time to render on the screen, and at the end they'll run a bit faster (but we can't say that for now as it depends on other parts of the system which haven't been optimized yet).
But using software surfaces on OpenDingux is useful only when you want to keep the compatibility with the older kernel; the next part will show that this new kernel is much more powerful when using hardware surfaces, which the legacy Dingux can't use without having rendering issues, as hardware surfaces somewhat require double buffering which the legacy Dingux does not have (some emus still use it on legacy, like psx4all, on which the flickering is clearly visible).
legacy Dingux, hardware surface (almost never used):
--- Code: ---Blitting test 443.7
Plasma 255.9
Rotozoomer 174.4
Rotozoomer near 259.1
Rotozoomer far 67.8
Radial blur 29.9
3D bunny 4.7
--- End code ---
OpenDingux 2011-09-04 (first pre-release), hardware surface:
--- Code: ---Blitting test 171.3
Plasma 111.7
Rotozoomer 101.0
Rotozoomer near 123.3
Rotozoomer far 49.6
Radial blur 25.6
3D bunny 4.8
--- End code ---
OpenDingux 2011-09-18 (second pre-release), hardware surface:
--- Code: ---Blitting test 465.1
Plasma 235.3
Rotozoomer 172.9
Rotozoomer near 240.4
Rotozoomer far 67.3
Radial blur 29.1
3D bunny 4.8
--- End code ---
As you can see, the second pre-release version of OD clearly outperforms the first release. Hell, Picodrive did gain ~10fps on the new kernel (at 336MHz) :)
But you can also notice how faster hardware surfaces are comparing to software surfaces on OpenDingux.
It means that when the whole system will be optimized, most of the apps will run faster on OD than they were running on the legacy Dingux.
IMPORTANT NOTE: GPMark does stress a lot the video driver, so don't expect that your program will magically run twice faster when switching to hardware surfaces. But it'll probably grab some FPS.
mth:
The reason hardware surfaces are not really usable on the legacy kernel is that it does not support double buffering. Without double buffering, everything you draw into the hardware surface (the frame buffer) can end up on the screen immediately. So if you draw the screen in multiple passes (overlays), a partially drawn screen will sometimes become visible and this looks bad (flickering). With double buffering, you always draw to a different buffer than the one that is currently visible on the screen; when you're done drawing one frame you flip the buffers, making the frame that has just finished visible and continue drawing in the buffer of the previous frame.
OpenDingux does support double buffering. If you're using SDL, pass SDL_HWSURFACE | SDL_DOUBLEBUF to SDL_SetVideoMode() and end a frame with SDL_Flip(). This is incompatible with legacy though: the legacy kernel has bugs that will likely hang your application if you attempt to do double buffering on it.
The OpenDingux double buffering is not synchronized to the screen updates yet and this can lead to flickering in some cases, but it is pretty rare (it tends to happen with frame rates above 60 fps, which is not common on the Dingoo). It will be properly synchronized in a future kernel release.
Navigation
[0] Message Index
[#] Next page
Go to full version