|
Joined: Nov 2003
Posts: 808
Senior Member
|
Senior Member
Joined: Nov 2003
Posts: 808 |
Originally posted by arekkusu: Originally posted by R. Belmont: Try something from konamigv.c ... That would let us rule out the SPU as opposed to the znsec, which I suspect is the real enemy. You're right-- weddingr runs fine, with sound. 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
|
|
|
|
Joined: Feb 2004
Posts: 314
Senior Member
|
Senior Member
Joined: Feb 2004
Posts: 314 |
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.
|
|
|
|
Joined: Mar 2001
Posts: 17,294 Likes: 272
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,294 Likes: 272 |
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.
|
|
|
|
Joined: Feb 2004
Posts: 314
Senior Member
|
Senior Member
Joined: Feb 2004
Posts: 314 |
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 
|
|
|
|
Joined: Nov 2003
Posts: 808
Senior Member
|
Senior Member
Joined: Nov 2003
Posts: 808 |
Originally posted by arekkusu: 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
|
|
|
|
Joined: Jun 2004
Posts: 6
Junior Member
|
Junior Member
Joined: Jun 2004
Posts: 6 |
Originally posted by smf: 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:
Sleep or debug - my biggest dilemma in life.
|
|
|
|
Joined: Aug 2002
Posts: 129
Member
|
Member
Joined: Aug 2002
Posts: 129 |
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
BEWARE: I LIVE! I HUNGER.
|
|
|
|
Joined: Jun 2004
Posts: 6
Junior Member
|
Junior Member
Joined: Jun 2004
Posts: 6 |
Originally posted by Carsten: 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:
Sleep or debug - my biggest dilemma in life.
|
|
|
|
Joined: Aug 2002
Posts: 129
Member
|
Member
Joined: Aug 2002
Posts: 129 |
(On second thought... looks way too complicated for me.  )
BEWARE: I LIVE! I HUNGER.
|
|
|
|
Joined: Aug 2002
Posts: 129
Member
|
Member
Joined: Aug 2002
Posts: 129 |
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
BEWARE: I LIVE! I HUNGER.
|
|
|
2 members (MilanSK, AJR),
228
guests, and
3
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,381
Posts122,711
Members5,085
|
Most Online1,529 Jun 7th, 2025
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|