Home Page Forums Archives MacMAME MacMAME 0.84 Xcode source leveraged

There is a known ( intermitent ) issue with at least bloody roar 2 which causes a lockup when booting, it seems to happen if frame skipping is active. It might be that is causing you more issues than it does under windows. Knock out all the calls to set_visible_area in vidhrdw/psx.c and see if any of the zn.c games boot.

smf

Nope, Strider 2/Brave Blade/Ray Storm all still lock up, with set_visible_area commented out and fskp0. (Working PSX games like Dancing Eyes, Wedding Rhapsody, Tekken are running at 25-40 fps ingame, really wish there was a ppc_drc... )

I had actually just started to look at set_visible_area, since that seems like half of the resolution switch problem. The mac video plugins (well, the GL one anyway) should probably disable window size changes when the visible area changes, and just stretch the bitmap to fill the initial (largest?) size.
The other half is somewhere else, it is still squishing the bitmap. Not sure where yet.

Squishing the bitmap means the driver and your OSD code are disagreeing on the bit depth probably.

And disabling size changes and stretching to initial is what the Win32 version does. That's why the initial size is so large even though only 1 game (doapp) actually uses a mode that large for more than a splash screen.

NeoGeo and Virtua Fighter Kids look like bpp issues. But I think this is something else, since Tekken for example is squished to 512x240 in a 640x480 window

A 640x480 window is the intended behaviour. You then need to make it stretch the 512x240 image to 640x480. Thats easy for the height ( in theory you only need to space the lines out as you'll then get scanlines ), the width is trickier and would require something like OpenGL to stretch the image.

smf

Been doing some experimenting along these lines. Maybe someone will find this helpful.

If I take out all the AdjustWindowSize() calls except for the one in UpdateBitmap(), the window remains the correct size, although the "squishing" still occurs.

If I force the offsets in ComputeSourceandDest to be the same as the window (in software.c using software rendering) and turn off fast blitting, everything looks *almost* like it is supposed to. There are two asterisks in the lower left corner, but CopyBits obviously stretches the bitmap to fit. Of course, it's slow as molasses, and it really posses off OpenGL.

CopyBit is not a workable solution. Has anyone tried to use the open source DDX -> OpenGL front end and the windows DDX video/winddraw files? Seems like that would be a quicker fix, at least temporarily, over rewriting macvideo, software and/or the OpenGL plugins, since someone has already written the DDX code. It's at http://sourceforge.net/projects/dxglwrap .

Cheers,
Hack7 :shadow:

About the assembly cores:

What needs to be done to get these to compile in XCode? Will Tiger's Xcode & gcc address this?

It it just changing asm to __asm__, and __inline__ instead of inline for gcc etc?

I'm way in over my head when it comes to assembly, but if it's just a tedious "monkey job" like searching and replacing keywords I'm willing to spend the time doing this sort of thing:

#ifdef __GNUC__
__asm__ ...
#else
asm ...
#endif

I'd just need a couple examples to get me started.

ck

They'll have to be converted. While XCode supports CodeWarrior style inline assembly, you can't access global variables from within the routines. I suppose you could mix gcc style assembly and CodeWarrior inline assembly to access globals, such as:

//Begin CodeWarrior assembly
__asm__ {
mflr r0
stmw r15,-76(sp)
stw r0,8(sp)
stwu sp,-128(sp)
}
//GCC assembly
__asm__ (" lis r4,hi16(GLOBAL_VAR)\n\t ori r4,r4,lo16(GLOBAL_VAR)": : ) ;

//Back to CodeWarrior
__asm__ { ...

But honestly I have never tested this myself. Maybe someone else has? I suppose any assembly routines which just use passed parameters and no globals could be converted by placing the __asm__ {} around them, but most of the ones I looked at access global vars. What a pain...

MacBlitters.S and MacBlitters.c are good comparisons for insight into assembly conversion IMHO.

Hack7 :shadow:

(On second thought... looks way too complicated for me. )

tabreport.patch.gz (patches: macstrings.h, macreports.h, macreports.c. Requires a RSRC patch to reportopt.rsrc and mamelang.rsrc).

This is finished. Adds a new report called "Game Properties (Tab-delimited)", which outputs a table of the following properties
for all ROMs:

Name, Descriptive name, Manufacturer, Year, Video type, Stereo, Video orientation, Width, Height, Colors, Video refresh Hz, Parent, BIOS, Source file, Sound status, Color status, Samples, Multiple monitor, Pixel aspect, Not working, Parent or clone, Analog controls, Digital controls, Other inputs, Coinslots & Switches

Patch available at my web site (already emailled to Brad).

Carsten