MAMEWorld Forums - EmuChat - Re: Another annoying MAME code question

> > I am using my own custom SDL implementation; and as far as I know I've never told
> > MAME the aspect ratio of my monitor, and I don't know how it would ever know. I am
> > just calling:
>
> Why exactly are you using your own SDL implementation? The existing one actually
> works and stuff.

Whoops, I misspoke. I didn't mean to say "SDL implementation", I meant to say "OSD implementation". Yes, the existing SDL implementation is a good implementation of the OSD layer using SDL and I would not embark to redo that as I can't see how I could do it any better.

I am writing my own OSD implementation though; I think I explained this before. I implemented a minimal OSD using pure POSIX API and called the OSD "posix". Because it's pure POSIX it can't do any of the rendering, or audio, or controller input, or any of the stuff that goes beyond simple file management, memory management, threading, etc.

So as an OSD it's not very useful or complete; but it does have the unique characteristic of, when combined with a separate piece of code I call 'libmame', allow MAME to be linked as a library against any other application. A fairly simple callback-based API is provided so that the linking program can receive the audio and video that the running MAME thread is generating as well as supply controller inputs to it and pause/start/stop/etc.

Then I take this library and link it against the frontend that I am writing, which allows me to, in the front end, have MAME running as just another thread in my program and I can transform or present the video or audio any way I want to.

The problem that resulted in this thread is that I normalize the primitive bounds to a unit square and then place that unit square in the appropriate place in my OpenGL scene to have it appear to be within an arcade cabinet; then I zoom the camera up to it when the user wants to play. Calculating the camera vectors to use when zoomed in to play the game requires knowing the visible region of the game within its unit square. I suffered from massive amounts of confusion when looking at the game resolutions that are reported by the games (e.g. Donkey Kong at 224x256) versus the primitive bounds that MAME was reporting, and trying to figure out how the render target bounds fit into all of it.

In the end I think it's really very simple: just let MAME figure everything out. I'll tell it that the render_target is 10000x10000, and then divide its primitive bounds by 10000 to get me the unit square that circumscribes the game display. Then I just have to zoom the camera to fit that region within a unit square on the screen.

The thing that was biting me is that I was setting up my camera coordinates for the zoom before even starting the game; I was relying on the geometries for the game (i.e. Donkey Kong at 224x256) but these can't actually be relied upon to represent the aspect ratio that the game will actually be rendered at. It seems to me that you have to wait for your first render update call for the render target to be set up to be able to even tell you what the visible bounds for the game are (because it uses the current view for that and the current view isn't set up until the game actually starts).

So that's what I'll have to do: start the game but don't zoom until the first render callback from which I can discern the viewable region to zoom to.