GP2X 940-based Ogg Decoding

[Gadget]

Thanks for the replies guys!

I have the same problem now. Got it working in my game, but frame rate roughly halves. It drops from 60 to 33 ish on a screen with an additional large blit (320 x 240), but when the large blit routine stops it increase to 40 ish fps. It's odd to think that I can get 60 fps when the 920 is handling the ogg, but the 940 causes it to drop to around 40?

Epicenter, out of interest, do you have sound working as well? I had to disable SDL sound completely to get this baby running.

Dzz, thanks for this, and any time you can spend on helping us. You can expect a paypal donation from me as well!

 

[Gadget]

I suppose memory contention seems the most likely suspect; I am doing a TON of blitting and all my surfaces are in the upper 32mb, so is the framebuffer, and I imagine so is the data the OGG decoder is working with. I wonder if there'd be an improvement if more of the components involved were using the lower 32MB, but for all I know, it's just one memory bus and utilization of the 2 banks in any configuration will result in the same bandwidth limitations..

If you can lend a hand it would mean a lot to me; thanks. Of course I understand as well as anyone if you can't fit it into your schedule, though.

The interesting thing is I am using the SW SDL at the moment, so my surfaces are all in the lower 32Mb!

 

[Epicenter]

I didn't disable SDL sound, but I did stop calling the functions to play/load OGG Music that I used to be using. I was getting ~112 FPS without OGG playback, 86 FPS with the 920T doing it, and now, ~55 with the 940 doing it.

 

[Shikaku]

I didn't disable SDL sound, but I did stop calling the functions to play/load OGG Music that I used to be using. I was getting ~112 FPS without OGG playback, 86 FPS with the 920T doing it, and now, ~55 with the 940 doing it.

I really can't see why you need more than 60 FPS, especially when not only the LCD, but your EYE can't process more than that much...

 

[Gadget]

I didn't disable SDL sound, but I did stop calling the functions to play/load OGG Music that I used to be using. I was getting ~112 FPS without OGG playback, 86 FPS with the 920T doing it, and now, ~55 with the 940 doing it.

I really can't see why you need more than 60 FPS, especially when not only the LCD, but your EYE can't process more than that much...

I am pretty sure he's going to be adding lots more effects / sprites (like me) and requiring more CPU... I am already at a point where the adding a few more sprites is noticably effecting the FPS. I can't use the HW SDL because it doesn't appear to work with FW 2.0 (I get mad flickering related to VBlank timing). So for me, 940 ogg decoding could be a god send.

 

[Epicenter]

That's precisely it. Plus, due to the nature of how scrolling works in this game, a sustainable framerate over 90 FPS is crucial or there will be very hideously choppy animation. You'd have to see it to fully understand, but 55 FPS is unacceptable. And 85 is much too close.

 

[gfoot]

The "mad flickering" is probably due to the vsync polarity being switched in the latest firmware. It should be a trivial change to the code - or you could poke a register if you prefer to put it back the other way.

(I got this infromation from Dzz's demo tutorial thread, not sure where it ultimately came from though.)

 

[A_SN]

That's precisely it. Plus, due to the nature of how scrolling works in this game, a sustainable framerate over 90 FPS is crucial or there will be very hideously choppy animation. You'd have to see it to fully understand, but 55 FPS is unacceptable. And 85 is much too close.

Wouldn't be needed if you implemented some kind of motion blur, right?

 

[Gadget]

That's precisely it. Plus, due to the nature of how scrolling works in this game, a sustainable framerate over 90 FPS is crucial or there will be very hideously choppy animation. You'd have to see it to fully understand, but 55 FPS is unacceptable. And 85 is much too close.

Wouldn't be needed if you implemented some kind of motion blur, right?

True, but probably means less CPU available again...

Epicenter, I have had a mini breakthrough this morning. I don't fully understand what has solve the problem for me, but it's either one of two things.

I started by having a crack at the HW SDL libs again, posted on here today in the 'screen tearing testing FW 2.0' thread. So I put in the new headers, built against the new libs and found that the HW SDL was working as it had in the past, with VBlank issue. I am looking at resolving that now. (I know it's VBlank because when you pause the game and no blitter is occuring, the picture is perfect).

So my FPS was a constant 60 now (locked to 60 in code). I decided to test Dzz OGG engine (which I have dubbed 'Dzz's "s940 Inside"' - with a nice logo =D And found that it dropped back to 33 ish fps. I started thinking about the call to usleep and the fact that it may be bady placed in my main loop, being called every time, so I moved it out completely and it now works fine =O 60fps constant (with lots of cycles to do other stuff) and the OGG playback is pretty much perfect.

I thought that a call to usleep was required for threading of the OGG stuff - ie. interaction between the 920 and 940. I haven't looked at the code close enough to work out what goes on between the 920 and 940, but I guess usleep isn't actually required? If it is, maybe it should be called much less than every main loop pass. Hope this helps. I am still learning here and a lot of this stuff is over my head right now, or at least takes me a while to understand.


I am still wondering how sound is working for you? Presumably you are doing these things:-

SDL_Init(SDL_INIT_JOYSTICK | SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_TIMER | SDL_DOUBLEBUF

Mix_OpenAudio(MIX_DEFAULT_FREQUENCY, AUDIO_S16, MIX_DEFAULT_CHANNELS, 256);

Then loading your wav files and it just works??

Are you doing this before or after init of the 940 engine?

Thanks!

 

[BradN]

I wouldn't think the program would have to sleep at all to interact with the 940 - the operating system won't touch it, and I don't think there would be other threads on the 920 involved.

 

[Lint]

the question about the usleep is not to hammer the memory bus, which can be replaced by a dummy loop if your program don't have work to do

if you keep calling/interfacing 940, it's likely yo spend much more time/bandwidth interfacing the coprocessors than what is really consumed by ogg decoding

keep in mind that 940's memory is normally uncached on 920

 

[Dzz]

the question about the usleep is not to hammer the memory bus, which can be replaced by a dummy loop if your program don't have work to do

if you keep calling/interfacing 940, it's likely yo spend much more time/bandwidth interfacing the coprocessors than what is really consumed by ogg decoding

keep in mind that 940's memory is normally uncached on 920

Yes, I have not had time yet to dive into this analysis, but I am hoping that your suggestion is exactly the problem some people are having. I say 'hoping' because it should be fixable. Both sides of the example code that I published can be much less hard on the memory bus when waiting for the other side to be ready. The other 'hopeful' idea is that the sound thread is not friendly at all during the time when it is waiting for a music packet from the 940. I had expected that only a small amount of time would be spent in that state and that the thread would be spending almost all of its time blocked in the write call, but I could be wrong about that.

 

[Gadget]

It's worth reading my last reply. It's working for me now, but at the cost of disabling the SDL_mixer. ARGHHHH! It's a nightmare this and makes me want to jack in the GP2X to be honest. All I want to do is produce some fun games, not spend a day like today, wasting 7 hours on jack.

 

[Dzz]

It's worth reading my last reply.

I did read your last reply but I'm not sure why what you did would have the effect it did. I assume you have adapted the example code to feed the results of the decoding into SDL_mixer somehow -- I doubt it would work to have both my sample code accessing the sound hardware and SDL_mixer doing so at the same time. But more than that I can't say. I don't know antything in particular about SDL or how it operates.

ARGHHHH! It's a nightmare this and makes me want to jack in the GP2X to be honest. All I want to do is produce some fun games, not spend a day like today, wasting 7 hours on jack.

Best to stay within "standard" stuff then, as pushing the envelope is never easy. I did try to warn in the first message of this thread:

My advice is that if you aren't willing to spend significant time figuring it out and adapting it to your purposes, forget about it.

 

[Gadget]

I did read your last reply but I'm not sure why what you did would have the effect it did. I assume you have adapted the example code to feed the results of the decoding into SDL_mixer somehow -- I doubt it would work to have both my sample code accessing the sound hardware and SDL_mixer doing so at the same time. But more than that I can't say. I don't know antything in particular about SDL or how it operates.

I didn't think it would be able to handle the mixing either, but Epicenter says that SDL audio is working for him?

Best to stay within "standard" stuff then, as pushing the envelope is never easy. I did try to warn in the first message of this thread:

I wouldn't need to be looking to use the 940 so early on if it wasn't for HW SDL problems. I think I am going to ditch SDL completely and use the minimal lib.

My advice is that if you aren't willing to spend significant time figuring it out and adapting it to your purposes, forget about it.

I am willing to spend significant time, just a bit cheesed off... Thanks for replying though! =D

 

[Orkie]

Sorry to drag this back up, but does anybody have a copy of the zip? Dzz's site is dead...

 

[frutbunn]

Orkie, I think this may be it. Sorry to get your hopes up if it isn't!

http://frutbunn.googlepages.com/ogg940.zip

 

[Orkie]

Looks like it is, thanks!