Author Topic: Second OpenDingux developer prerelease  (Read 33032 times)

mth (OP)

  • Posts: 317
Second OpenDingux developer prerelease
« on: September 19, 2011, 10:15:36 am »
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 + select
The 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

  • Posts: 55
Re: Second OpenDingux developer prerelease
« Reply #1 on: September 19, 2011, 01:31:54 pm »
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
http://dingoowiki.com - let's fill it!

pcercuei

  • Posts: 1689
    • My devblog
Re: Second OpenDingux developer prerelease
« Reply #2 on: September 19, 2011, 05:17:46 pm »
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

  • Posts: 1689
    • My devblog
Re: Second OpenDingux developer prerelease
« Reply #3 on: September 19, 2011, 05:45:39 pm »
made framebuffer cacheable; this can speed up rendering considerably

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: [Select]
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

OpenDingux 2011-09-04 (first pre-release), software surface:
Code: [Select]
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

OpenDingux 2011-09-18 (second pre-release), software surface:
Code: [Select]
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

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: [Select]
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

OpenDingux 2011-09-04 (first pre-release), hardware surface:
Code: [Select]
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

OpenDingux 2011-09-18 (second pre-release), hardware surface:
Code: [Select]
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

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.
« Last Edit: September 19, 2011, 05:55:26 pm by Ayla »

mth (OP)

  • Posts: 317
Re: Second OpenDingux developer prerelease
« Reply #4 on: September 19, 2011, 05:58:39 pm »
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.

lordblip

  • Posts: 11
Re: Second OpenDingux developer prerelease
« Reply #5 on: September 20, 2011, 04:05:01 am »
friends I need to know how I can change the tv-out PAL to NTSC, I do not understand what you explained in the wiki if, in advance thank you very much, and pardon my English but I am a user of opendingux from chile.

virusmater

  • Posts: 55
Re: Second OpenDingux developer prerelease
« Reply #6 on: September 20, 2011, 04:46:55 am »
write to local/etc/tvout.conf (this is just txt file) word pal or ntsc
http://dingoowiki.com - let's fill it!

virusmater

  • Posts: 55
Re: Second OpenDingux developer prerelease
« Reply #7 on: September 20, 2011, 04:52:50 am »
maybe disable sound and backlight feature in gmenu2x (because they don't work anymore) and display in dock of gmenu2x (in bottom of the screen) global volume and backlight
http://dingoowiki.com - let's fill it!

wy_scorpio

  • Posts: 368
Re: Second OpenDingux developer prerelease
« Reply #8 on: September 20, 2011, 05:57:45 am »
bug report...
1.LCDbacklight setting is no use..when you set it ,it did nothing..only can set with power+ up or down..but when you reboot dingoo..that is no use too..
2.cant use 'Y' to read readme.txt file...

pixador

  • Posts: 7
Re: Second OpenDingux developer prerelease
« Reply #9 on: September 20, 2011, 06:20:58 am »
I just wanted to write to say that the speed of my dingux-msx-pixamod was noticeabily faster with this second release when I've seen Ayla's post with the results of his tests :) This is certainly sweet!!! :) Great work!!

By the way I'm having some issues with audio. I'm using SDL audio and sometimes I hear some 'clicks' and noise while the very same executable file sounds fine in legacy Dingux. I still have to do some testing (right now I was focusing on making it work and fixing some stuff to make a new release soon) but it might happen when several msx's audio channels are played at the same time, maybe with a high volume (I know this doesn't help too much...). Maybe it's some clipping? Maybe some samplerate conversion not working properly?
I'll post more info (and more useful I hope) when I can do some tests.

virusmater

  • Posts: 55
Re: Second OpenDingux developer prerelease
« Reply #10 on: September 20, 2011, 06:40:23 am »
CR:
after resume from long suspend (longer than backlight timeout) display blinking once and turned off
and we need press any key to wake it up
can you do this automatically?
« Last Edit: September 20, 2011, 10:17:32 am by virusmater »
http://dingoowiki.com - let's fill it!

pcercuei

  • Posts: 1689
    • My devblog
Re: Second OpenDingux developer prerelease
« Reply #11 on: September 20, 2011, 09:37:51 am »
2.cant use 'Y' to read readme.txt file...
It's on the contextual menu.

NESFreak

  • Posts: 12
Re: Second OpenDingux developer prerelease
« Reply #12 on: September 21, 2011, 05:09:43 pm »
Congrats with the amazing progress you've made compared to the original dingux.

Since we're now using ALSA I've got a small tip for everyone wanting to use the tv-out connector for their headphones. You can disable/enable the internal speaker with the following commands:

Code: [Select]
amixer set Speaker off
amixer set Speaker on
By putting each command in a separate file and adding those files to the settings menu you're now able to do just that.

speaker_on
Code: [Select]
#!/bin/sh
amixer set Speaker on
speaker_off
Code: [Select]
#!/bin/sh
amixer set Speaker off




pcercuei

  • Posts: 1689
    • My devblog
Re: Second OpenDingux developer prerelease
« Reply #13 on: September 21, 2011, 07:29:14 pm »
Please NEVER DO THAT.The "earphones" plug and the "TV-out" plug does not have the same impedence. In short, if you plug your earphones on the "TV-out" plug you will toast your earphones (I did burn mine...), and on the other hand, if you plug a line-out on the "earphones" plug, you risk to toast your audio system.

Re: Second OpenDingux developer prerelease
« Reply #14 on: September 21, 2011, 07:59:25 pm »
Please NEVER DO THAT.The "earphones" plug and the "TV-out" plug does not have the same impedence. In short, if you plug your earphones on the "TV-out" plug you will toast your earphones (I did burn mine...), and on the other hand, if you plug a line-out on the "earphones" plug, you risk to toast your audio system.

Huh. I wish someone would have said something about this earlier. :P

NESFreak

  • Posts: 12
Re: Second OpenDingux developer prerelease
« Reply #15 on: September 21, 2011, 09:43:31 pm »
Please NEVER DO THAT.The "earphones" plug and the "TV-out" plug does not have the same impedence. In short, if you plug your earphones on the "TV-out" plug you will toast your earphones (I did burn mine...), and on the other hand, if you plug a line-out on the "earphones" plug, you risk to toast your audio system.

You're wrong there. Let me explain this. The output voltages of both ports are the same, however the bottom one is supposed to be used as line-out devices to connect to a tv's line-in (which often have a high impedance, think as high as 10kOhm).

Now the formula for impedance is given by

Z = V / I, where Z impedance, V voltage and I current.

Now since headphones often have a lower impedance (mine has 32Ohm) this means the current drawn by headphones is many times larger than comparered to connecting the dingoo's line-out to a line-in. So if at all something is to be going to be blown up it would be the dingoo's interal amp, not the headphones. I guess you've just had bad luck with your headphones.
« Last Edit: September 21, 2011, 09:46:39 pm by NESFreak »

Megacubo

  • Posts: 66
Re: Second OpenDingux developer prerelease
« Reply #16 on: September 21, 2011, 11:45:29 pm »
I'm using the tv-out for headphones since the first day and nothing wrong happens, my dingoo have 2 months with me maybe i'm lucky

pcercuei

  • Posts: 1689
    • My devblog
Re: Second OpenDingux developer prerelease
« Reply #17 on: September 22, 2011, 12:08:49 am »
I do know what you are trying to explain, and your conclusion is right. For some reason I did inverse the conclusion, probably because it did make more sense to me (as I burned my Shure earbuds).

New theory. The TV-out and earphone outputs are both connected to the same amp. I just remembered that when I did fry my earbuds, I was working on the sound driver, and I had another pair of earphones plugged on the earphones jack. I strongly doubt it is a coincidence.

NESFreak

  • Posts: 12
Re: Second OpenDingux developer prerelease
« Reply #18 on: September 22, 2011, 10:35:57 pm »
New theory....

Wouldn't know about that. Sounds like an expensive accident.

I've got a tv-out bug btw. It seems to be misaligned. See the attached picture.

qbertaddict

  • * Former Staff
  • The Doctor
  • Posts: 1184
    • about.me
Re: Second OpenDingux developer prerelease
« Reply #19 on: September 23, 2011, 10:22:37 am »
I do not have that issue. Are you using pal or ntsc and what region are you in