Need Help For Snes Emulator Optimizing

[rohezal]

I don't have ICQ, use one of the chat contacts in my profile if you want to reach me. I'm on IRC sometimes on servers like freenode and efnet (as Exophase)

Ok.

Yes, Glamo has 2D acceleration/blits. But the dirty rectangles approach is going to fail so much of the time for SNES games that it's not worth it. Whenever the screen scrolls, to be precise, or palette changes.

[/quote]

First question: You can't decide which is the background on what are sprites who are painted on this background in an emulator or?
If you could it, wouldn't be so hard to decide how the background moved.
Important: Hope the opengl ES driver for the glamo works, else forget this idea.

Other idea: Hmm ok the scrolling is a real problem. Just theory but whats about this idea at least for top down games:
Can you render in an emulator more then you see? Like the whole city in Lufia instead of the part of screen that you can see? If yes whats about this:

Render the first frames to a quad. This could be a big quad. Decide which points are moving and which are. The not moving object are the texture on a background quad. The moving objects are sprites and will get there own quads. Only update the texture of the sprite quads. If the game is scrolling move the background quad. Will only work on static backgrounds (makes backgrounds static). If something moves it can get an own sprite quad like a smoking chimney or a river and stop beeing a background.

Will only work for top down games but I think I would fasten up thigs a lot.
The glamo has 8 MB RAM but can only support 511x511 pixel textures so we have to keep several background quads and move them together.

The problem is first: works only for top down games like secret of mana, lufia, chrono trigger etc.
Second: decide if the background is scrolling, find the right direction vector, deciding of a new level must be loaded or when the glamo RAM is full and must be cleared and a new part of the level must be transfered.

Don't know how complex it is. But I think the moved part can be handled with a few dozens of if questions if it has changed.

IMO, the best strategy for interfacing the Glamo is to have a tripling buffering scheme where, all in the same frame:

- CPU draws frame N - 2 into buffer A
- CPU uses DMA to gradually transfer frame N - 1 from buffer B to Glamo's buffer C, so it's spread out over the entire frame duration:
The idea here is that by making the DMA step off of a timer so it won't tie the bus 100% of the time. Although it'll steal many clock cycles and take main memory performance, the CPU will still be able to operate somewhat since it'll be spending a lot of cycles accessing cache instead of SDRAM. This idea has been suggested on the mailing list before.
- Glamo draws frame N from Glamo buffer D

Then at vsync buffers A and B are swapped, as are C and D.

Of course this involves some pretty complex setup and I doubt you can do it without kernel modifcations. You'd basically have to setup the frame rate in advance and hold to it. The actual upload to the Glamo would take significantly longer, but it'll be time where the CPU can generally get work done.

I don't understand the idea. The glamo has not a DMA acces, or? Can the cpu operate when you transfer the image to glamo? Can he do it because he uses his cache? Or is the idea to use the RAM DMA operation while the cpu can't do anything and do something usefull in this time?