Previous Thread
Next Thread
Print Thread
Page 3 of 9 1 2 3 4 5 6 7 8 9
Joined: Nov 2003
Posts: 804
S
smf Offline
Senior Member
Offline
Senior Member
S
Joined: Nov 2003
Posts: 804
Quote:
Originally posted by arekkusu:
Quote:
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: 312
A
Senior Member
OP Offline
Senior Member
A
Joined: Feb 2004
Posts: 312
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: 16,923
Likes: 57
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,923
Likes: 57
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: 312
A
Senior Member
OP Offline
Senior Member
A
Joined: Feb 2004
Posts: 312
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 wink

Joined: Nov 2003
Posts: 804
S
smf Offline
Senior Member
Offline
Senior Member
S
Joined: Nov 2003
Posts: 804
Quote:
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 wink
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
H
Junior Member
Offline
Junior Member
H
Joined: Jun 2004
Posts: 6
Quote:
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
Offline
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
H
Junior Member
Offline
Junior Member
H
Joined: Jun 2004
Posts: 6
Quote:
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
Offline
Member
Joined: Aug 2002
Posts: 129
(On second thought... looks way too complicated for me. frown )


BEWARE: I LIVE! I HUNGER.
Joined: Aug 2002
Posts: 129
Member
Offline
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.
Page 3 of 9 1 2 3 4 5 6 7 8 9

Link Copied to Clipboard
Who's Online Now
1 members (Bletch), 26 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,103
Posts119,284
Members5,019
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com