Home Page Forums Archives Zinc 1.0.1 posted

You may get errors if you try to download it right away - please allow up to an hour for ZTnet's caches to synchronize.

Changes:
- Tekken 3 and SWS99 disabled for blatent non-workingness
- Added US version of Street Fighter EX
- Synced ROMs to MAME 0.88, thanks to Brian Troha
- Added --rotate option for arcade monitors and LCD users
- Fixed "Susume" loading crash in the Windows version
- Fixed controls not working in Konami GV games on the Windows version
- Fixed Pentium 4 specific code in the Linux version (same fix as 1.0a)

Great ! Downloading now...

Sorry, i found 1 tiny 'bug':

7 Street Fighter EX 2 (US) [sfex2j, parent sfex2, BIOS cpzn2]
8 Street Fighter EX 2 (JP) [sfex2j, parent sfex2, BIOS cpzn2]

Sets 07 & 08 with the same zip name

1.02 need

No 1.0.2 necessary, it'll still work properly.

blahhhh

MAME will want Gallop Racer 3 as:

gra3u.119 & gra3u.120

While ZiNc wants:

gra3u119.119 & gra3u120.120

ZiNc is right and MAME will be corrected in 88u1 (I'm guessing :p )

MAME will work with ZiNc's version, since it can load by CRC. So that's the way to do it

Can ZiNc load by CRC? I'm sure MAME will decide to change some other names in the future, would be nice if you could always use the MAME roms instead of an extra dir for ZINC.

No, ZiNc can't load by CRC. But since it's the playable PSX emulator you should clearly maintain your ROMs in it's format.

Okays.

Well anyway I did some work on my frontend, should be 1.0.1 compatible now. WinterBlast 1.5 still seems to work fine on it.

http://darkfalz.kiczek.com/software/

Thanks ! First working frontend for 1.x. The end of .bat madness

WinterBlast 1.5 causes a startup failure in some games, like DoA++

Winter Blast controller plugin v 1.5
ERROR: System not yet emulated
DirectInput: 1 joystick(s) found
WinMM: 1 joystick(s) found ( JOY1 )
ERROR: cannot open controller plugin

Just use the regular ZiNc plugin for the time being, I guess.

Yup. Like I said, it needs to be updated to handle the new systems - otherwise it'll only work with games that existed in 0.9.

Could you perhaps update the readme with specifics of what games belong to which systems, like is in the 0.9 readme? It helps for frontend authors like myself..

They're mostly grouped in --list-games by system actually.

In 1.0.1:
1-6, 21-22: Capcom ZN-1
7-20, 23: Capcom ZN-2
24: Video System ZN-1
25-28: Raizing/Eighting PSArc '95
29-37: Taito FX-1
38-53: Namco System 11
54-57: Konami GV / Baby Phoenix
58-62: Namco System 12
63-68: Tecmo TPS
69: Atlus ZN-1

I know they are grouped like that but I was just wondering for my frontend want to call each system, I settled on just using the mame drivers but in that case the zn encompases many systems... :p maybe the bios names for the other ones, eh?

AFAIK The inputs are the same across all zn-1/zn-2 games ( There may the odd game that uses buttons instead of a joystick ). Some games use more of the buttons than the others.

The Capcom games have a CPS2 kick harness that is attached to the rom board, but neither MAME or ZiNc supports reading it ( it's relatively useless as the game just maps them to the same buttons you can get on the motherboard ).

smf

Do you have a list of what each system is called internally to the controller plugin (since it obviously works on a per system basis)?

Then I could just use that namenclature for my config files, much cleaner.

The system names are in fact what I said they were in my previous post on this thread. You can verify with the controller plugin source (comes with the Linux version, it's a separate download for Windows).

What's remaining for Tekken 3 work?

Okay, so no short names? I will check out that download then.

Someone needs to figure out what the main cpu doesn't like about the sound cpu.

smf

This is a pretty crappy bug for frontend authors doh, for example people using the --list-sets output to create their gamelist/dats in the Frontend will have troubles since the jap version will show up but the us version will simply not due to this ,just check dafreaks new zincgui it has this problem because it now uses --list-sets and will create sfex2j.dat twice (one time it'll overwrite). The only way they can get around this is to hard code the us version again, adapt the code for getting the data from --list-sets to bypass the wrong output or just hardcode all of them,which completly fails the purpose on getting it from --list-sets, just because of that small typo it's rather important that --list-sets has a correct output or it's rather useless to incorporate into frontends. It doesn't have effect when running from commandlines or frontends with hardcoded game lists. (--list-games has the same typo btw but isn't so important cause fe authors will most likely be using --list-sets)

Sure, it's not ideal but it can be worked around without fully hard-coding. Pseudo code for what I have done in my --list-sets parser:

if name="sfex2j" and description contains "(US)" then name=parent

Sorted! This will still work if/when the sfex2 details are corrected in the future too. The Japanese variant is pretty unlikely to ever contain the string "(US)" so my hack shouldn't misbehave in the future.

blah

hey darkfalz i am trying to use your zinc frontend 1.4 with zinc 1.0.1 but whenever i try to play a game the black background box appears then instantly close so i can't play any games,do you know why this is?

dukenukem go to command line version and try to load the game manually, see what error you are getting

darkfalz u can create an option in the frontend aswell by using for example "zinc.exe 1 > log.txt" output of zinc will be written to log.txt afterwards u can pop up a messagebox with the contents of the file.

zinc.exe 1 >> log.txt will append to log.txt > wil overwrite each time

No need for that, it doesn't do anything fancy, it just passes along zinc <game number> -renderer blah.znc

Come to think of it, that is most likely your problem. If you check the readme of the frontend, I expect renderers to be named specifically

d3d_renderer.znc
ogl_renderer.znc
glide_renderer.znc
ogl2_renderer.znc
soft_renderer.znc

Ie. the default renderer.znc will be ignored. I should probably make that clearer in the readme, it's very likely what the problem is. I could add a "Disabled" option to that too which will simply use the default.

yeah but for example when they have a bad romset or a missing set, ... zinc would output this and doesn't start, u'd need never be able to show this error msg which zinc outputs in your frontend unless u used the > or >> delimiter to capture zincs output into a file. (check zincgui) or unless u start zinc without using shellexec or similar. Not that big of a deal doh but it's nicer to see why a certain game wouldn't start then just see nothing hehe

Well I'd expect people could go and load it via command line if they wanted to, but I could add logging I guess. Anyways if you're happy with one of the other frontends there's no need to be mine, it's intended to be as "lite" as possible while allowing you just to load the games.