Author Topic: Dingux PuzzleTube (Read 9923 times)

nsaraiva · « **on:** January 26, 2012, 09:32:38 pm »

I installed Puzzletube in my A320, but the video is flicking.

My LCD is the ILI9325

Anyone can help me?

thanks.

Nelson Saraiva from Brazil.

Coccijoe · « **Reply #1 on:** January 26, 2012, 10:03:38 pm »

Same problem here, and i have the same screen, but i don't think it's due to it. Is anybody with an other screen can try?
http://dl.openhandhelds.org/cgi-bin/dingoo.cgi?0,0,0,0,25,563

Btw it's a dingux game, not a native one

DiegoSLTS · « **Reply #2 on:** January 27, 2012, 12:07:47 am »

I have ILI9338 and OpenDingux and have the same problem.

Maybe it works in Legacy Dingux.

nsaraiva · « **Reply #3 on:** January 27, 2012, 12:01:57 pm »

HI,
I installed in legacy Dingux.

pcercuei · « **Reply #4 on:** January 27, 2012, 01:10:36 pm »

That's what occurs when you use hardware surfaces without double buffering.
Two solutions for this guy:
- either he recompiles his game and use (much slower) software surfaces to keep compatibility with legacy,
- or he recompiles his game with double buffering but it will be compatible only with opendingux.

nsaraiva · « **Reply #5 on:** January 30, 2012, 06:50:27 pm »

thanks.

Ziz · « **Reply #6 on:** February 03, 2012, 10:43:37 pm »

Hi,

I AM the guy making this game. Unfortunately I am not registered in every forum - especially not of consoles I do not own. So, what I want to say: If my games don't work fine on your dingoos, just send me an e-mail!

But by accident I found this thread and I will try to make the suggested changes

greetings,
Ziz

Ziz · « **Reply #7 on:** February 03, 2012, 10:52:53 pm »

Okay, I tried to change it to double buffering. Open is always better, but if you tell my a method to find out, whether is starts in Dingux or the build in operating system, I will ad this, too.

http://ziz.delphigl.com/data/puzzletube-dingoo.zip (or the openhandhelds archive, but the version has to be 1.0.4! at the moment it is 1.0b in the archive!)

Pingouin · « **Reply #8 on:** February 04, 2012, 10:11:55 pm »

It works great in Dingux now, the flickering is completely gone for me.
Thanks!

Ziz · « **Reply #9 on:** February 04, 2012, 10:33:27 pm »

I fixed it with the help of zear. He tested for me a lot.

btw.: SDL_DOUBLEBUF doesn't work very well because of kernel bugs.

Creating an second surface, drawing in this and blitting at the flip-step to the screen surface (INSTEAD of flipping!) works great

@Pingouin: There was still a little bug I fixed 10 minutes ago. You should download the newest version: http://ziz.delphigl.com/data/puzzletube-dingoo.zip

pcercuei · « **Reply #10 on:** February 05, 2012, 10:54:32 am »

Quote from: Ziz on February 04, 2012, 10:33:27 pm

btw.: SDL_DOUBLEBUF doesn't work very well because of kernel bugs.

Creating an second surface, drawing in this and blitting at the flip-step to the screen surface (INSTEAD of flipping!) works great

That's also much slower. But please don't do that. No need to work around a bug in the kernel, when it can be fixed in the kernel directly. Once it's fixed on the kernel (and in SDL too actually), your double buffered apps will work just fine. Note that this bug was known and is the last one on the TODO list for OD.

Ziz · « **Reply #11 on:** February 05, 2012, 02:04:31 pm »

Oh don't think so. Blitting from HW Surface to HW Surface is quite fast. Without my Bugfix just with one HW Screen Surface with Fullscreen flag, I had the same fps on the Dingoo. ;-)

Pingouin · « **Reply #12 on:** February 05, 2012, 02:54:55 pm »

Quote from: Ziz

@Pingouin: There was still a little bug I fixed 10 minutes ago. You should download the newest version: http://ziz.delphigl.com/data/puzzletube-dingoo.zip

Thanks, just downloaded it!

Quote from: Ayla

No need to work around a bug in the kernel, when it can be fixed in the kernel directly.

I'll take it you're talking about OpenDingux? If the bug is in Dingux, which I'm still using, isn't it unlikely to ever get fixed as I don't expect any Dingux updates anymore?

pcercuei · « **Reply #13 on:** February 05, 2012, 10:01:51 pm »

Quote from: Pingouin on February 05, 2012, 02:54:55 pm

I'll take it you're talking about OpenDingux? If the bug is in Dingux, which I'm still using, isn't it unlikely to ever get fixed as I don't expect any Dingux updates anymore?

I'm talking about OpenDingux yes. Nobody works on the legacy kernel anymore.

Ziz · « **Reply #14 on:** February 05, 2012, 11:16:27 pm »

However. Ask zear, my method - which works for dingux and opendingux - is not slower than double buffering.

pcercuei · « **Reply #15 on:** February 05, 2012, 11:32:15 pm »

It is slower as you have to blit the whole intermediate surface on the screen.

Ziz · « **Reply #16 on:** February 06, 2012, 12:22:13 am »

Don't you listen to me? Zear tested it for me. It is not slower.

Both times 20 fps (with textures).

I know in theory it should be slower because of blitting. But it isn't. Some reason could be, that blitting of hw-surface to the screen-hw-surface is very fast because of some hw-optimization. I really don't know. I just know: It works.

greetings, Ziz

pcercuei · « **Reply #17 on:** February 06, 2012, 12:51:37 am »

The slowdown does not appear in your case because 20fps is really low. If you render at 60fps, you will render three times more frames in a second, so the slowdown will be three times higher. Probably more than that actually, because you eat more memory baudwidth.

If you really want to see the difference, try to implement it whithin gpmark.

Ziz · « **Reply #18 on:** February 07, 2012, 12:28:35 am »

If I have 20 fps with Double Buffering and 20 fps with my method then my way needs at most 0,9period ~ 1 frame more (if we assume 19.5 fps with my method and 20.49period with Double Boufering, so that is always shows 20). 1 frame at ~20 fps is 50ms. We have 20 frames per second, so my method needs at most 2.5 ms more time per frame.

Lets assume I have with Double buffering 60 fps. Then every frame needs ~16.7 ms to draw. Furthermore we assume, that my method is with more fps still as slow as with 20 fps. Then with my method we need at most 2.5 ms more per frame. That would mean 19.2 ms per frame. That would be ~52 fps. So I loose ~8 fps in a worst case reflection.

That's acceptable if it runs with this method on Dingux and OpenDingux. ;-)

Pingouin · « **Reply #19 on:** February 07, 2012, 05:10:42 pm »

I agree with both.

Ayla is right that if there is an optimum way to do stuff, you might as well use it, especially if you need all the performance you can get.

But I also agree with Ziz: if it already works perfectly fine, not much point in trying to squeeze out a few more CPU cycles that you do not need to do anything else.

In this case, it works flawlessly so I'm not bothered whether memory accesses are optimum!

Author Topic: Dingux PuzzleTube (Read 9923 times)

nsaraiva (OP)

nsaraiva (OP)

nsaraiva (OP)