Post v1.42 ZSNES WIPs

Noxious Ninja · Post by **Noxious Ninja** » Fri Nov 04, 2005 1:42 am

Aerdan wrote:Please don't use mingw32-make.exe. It sucks.

Except it works fine in this context and is easier.

Jipcy · Post by **Jipcy** » Fri Nov 04, 2005 2:27 am

Clements wrote:Thankyou. That worked.

Edit: Yay!

Notice any changes/improvements with the cpu optimizations?

Clements · Post by **Clements** » Fri Nov 04, 2005 2:45 am

Jipcy wrote:
Clements wrote:Thankyou. That worked.

Edit: Yay!
Notice any changes/improvements with the cpu optimizations?

Not really, since the optimisations only affect the SDL port for now. I'm really chuffed that my build works just like ipher's.

washuu108 · Post by **washuu108** » Fri Nov 04, 2005 4:14 am

Clements wrote:
Jipcy wrote:
Clements wrote:Thankyou. That worked.

Edit: Yay!
Notice any changes/improvements with the cpu optimizations?
Not really, since the optimisations only affect the SDL port for now. I'm really chuffed that my build works just like ipher's.

As far as I can tell, all that the SDL port has over the Windows port is that it will add the optimizations automatically. You can add them yourself fairly easily. Simply go to zsnes\src\tools in the command prompt (make sure the MinGW\bin folder is in PATH) and run the following:

Code: Select all

gcc -o archopt.exe archopt.c
archopt

Now cd back to zsnes\src and build zsnes as normal, adding CPUOPT=value to the make command, where value is whatever archopt showed you.

EDIT: Just noticed that archopt is not in the latest WIP source distribution. It is in CVS, or a binary can be found in Nach's link here as cpuopt.exe.

Jipcy · Post by **Jipcy** » Fri Nov 04, 2005 4:34 am

Clements wrote:chuffed

I'm American. Does that mean "good"?

Clements · Post by **Clements** » Fri Nov 04, 2005 4:58 am

washuu108 wrote:
Clements wrote:
Jipcy wrote:
Clements wrote:Thankyou. That worked.

Edit: Yay!
Notice any changes/improvements with the cpu optimizations?
Not really, since the optimisations only affect the SDL port for now. I'm really chuffed that my build works just like ipher's.
As far as I can tell, all that the SDL port has over the Windows port is that it will add the optimizations automatically. You can add them yourself fairly easily. Simply go to zsnes\src\tools in the command prompt (make sure the MinGW\bin folder is in PATH) and run the following:
Code: Select all
gcc -o archopt.exe archopt.c
archopt
Now cd back to zsnes\src and build zsnes as normal, adding CPUOPT=value to the make command, where value is whatever archopt showed you.

EDIT: Just noticed that archopt is not in the latest WIP source distribution. It is in CVS, or a binary can be found in Nach's link here as cpuopt.exe.

Thanks a lot. In my case, I added CPUOPT=athlon-xp to the end of the command and it definitely worked, as I saw with the output. I may have to test it to see which games it makes a difference with.

Jipcy wrote:I'm American. Does that mean "good"?

It's another word for pleased. I guess this means we should all compile our own optimised builds now. There's no excuse if I can manage it!

Post by **Nach** » Fri Nov 04, 2005 10:53 am

washuu108 wrote: Now cd back to zsnes\src and build zsnes as normal, adding CPUOPT=value to the make command, where value is whatever archopt showed you.

There is no CPUOPT command.

Code: Select all

#Parameters:
#
# PLATFORM=platform_name  Chose target platform and how you're creating it.
#                         Valid options are:
#                         dos, dos-cross, msvc, win32, win32-cross, win32-unix-shell
#
# RELEASEGRADE=yes        for high assembly optimization for releases, will take at least half an hour.
# clean                   cleans object and executable files.
#
# --Not for MSVC--
# DEBUG=yes               for debugging with GDB.
# CPU=cpu-type            optimize for a particular CPU, find a list of cpu types in the GCC manual.

And be warned I will probably change CPU to ARCH in my next makefile update.

Clements · Post by **Clements** » Fri Nov 04, 2005 6:01 pm

CPU=athlon-xp worked for me as well. Out of interest, how do you get the 'burning GUI' effect to work when you are compiling? I ruled out upx and CPU optimisations causing the problem. The other GUI effects work regardless.

Edit: Also, from Nach's info, I'm guess that:

mingw32-make -f makefile.ms PLATFORM=win32 CPU=athlon-xp RELEASEGRADE=yes

..would provide the most optimised build for me (at the expense of compiling time)?

Aerdan · Post by **Aerdan** » Fri Nov 04, 2005 6:20 pm

The burning effect, IIRC, uses MSVC-specific code that doesn't do anything at all in gcc, apparently.

Post by **Nach** » Sat Nov 05, 2005 6:28 pm

Clements wrote: ..would provide the most optimised build for me (at the expense of compiling time)?

Yes. And be warned there is one file that takes ~5 min to compile, and another one ~25 min when doing release grade. It does not freeze.

ipher · Post by **ipher** » Sun Nov 06, 2005 2:37 am

Emulation fixes!

11/05/05
ALL: Updated BG scroll register behaviour using anomie's formula. Got it done thanks to pagefault, too. [grinvader]
ALL: Fixed small screen extra line issues (fixes Super Metroid annoying line issue). [pagefault]
ALL: Fixes for DMA, so we can have the recent improvements without breaking tons of other game. (SSF2, SFA2, FFMQ, TOP, CT, YI, Probably others). [pagefault]
SDL: SCons now using parsegen the right way [Snarius]
TOL: Architecture detection tool which may be used for various purposes. [Nach]
SRC: Updated tools compile info and 'make tools' for new tool. [grinvader]
SRC: Typo fix in todo list. [grinvader]
SRC: Cleanup (whitespace & useless EXTSYM). [grinvader]

Post by **grinvader** » Sun Nov 06, 2005 2:41 am

Nach wrote:
Clements wrote: ..would provide the most optimised build for me (at the expense of compiling time)?
Yes. And be warned there is one file that takes ~5 min to compile, and another one ~25 min when doing release grade. It does not freeze.

And consider yourself lucky, it was a whoppy 45 minutes just for that file before we cleansed the source from all unused stuff.

Post by **Agozer** » Sun Nov 06, 2005 2:41 am

Excellent work and a nice list of fixes.

Truth Unknown · Post by **Truth Unknown** » Sun Nov 06, 2005 2:57 am

It still says 10/31 WIP on the site.
But Good Job on the new build.

ipher · Post by **ipher** » Sun Nov 06, 2005 3:18 am

True X Unknown wrote:It still says 10/31 WIP on the site.
But Good Job on the new build.

I knew that release went a little too smoothly, fixed now

kevman · Post by **kevman** » Sun Nov 06, 2005 3:24 am

FIXED METRIOD BITCH!

snkcube · Post by **snkcube** » Sun Nov 06, 2005 5:35 am

Nice emulation fixes! Great job devs.

Deathlike2 · Post by **Deathlike2** » Sun Nov 06, 2005 6:13 am

---------------------Internal ROM Info----------------------
File: Super Offroad Baja (U).smc
Name: SuperOffroad:The Baja Company: Tradewest
Header: Exists (type?) Bank: LoROM
Interleaved: No SRAM: 0 Kb
Type: Normal ROM: 8 Mb
Country: USA Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x8C2C CRC32: CB483EAD
--------------------------Database--------------------------
Name: Super Off Road - The Baja
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Racing Genre 2: None

Super Offroad Baja bug still there.. it changes between the messed up time (as shown in the pic) to the correct look.

No rush to fix this bug... I don't care about this game.. lol

The DMA fixes for the most part worked...

Post by **Nach** » Sun Nov 06, 2005 1:14 pm

Deathlike2 wrote: Super Offroad Baja bug still there.. it changes between the messed up time (as shown in the pic) to the correct look.

What are you saying exactly? That the recent DMA fix broke this and the recent one didn't fix it?

Or that it's always been broken and you suppose DMA should fix it and that it didn't?

Deathlike2 · Post by **Deathlike2** » Sun Nov 06, 2005 6:34 pm

What are you saying exactly? That the recent DMA fix broke this and the recent one didn't fix it?

Or that it's always been broken and you suppose DMA should fix it and that it didn't?

It's the first one. The first DMA fix broke it and the recent DMA fix did nothing to help this game.

I refrained from posting pics of this problem (I did mention it in a different thread) because of the known DMA issue... well now you have the fix.. and nothing happened.. so now I'm reporting one of the exceptions to the fix.

Jonas Quinn · Post by **Jonas Quinn** » Sun Nov 06, 2005 7:16 pm

That's not DMA related AFAIK.
That problem was already in the 4/04/05 WIP but not in the 2/28/05 WIP.
I guess I have to narrow down the problem.

Post by **Nach** » Sun Nov 06, 2005 7:19 pm

Is this when using a save state, or even from a fresh game start?

Jonas Quinn · Post by **Jonas Quinn** » Sun Nov 06, 2005 7:24 pm

It appears even from a fresh game start.

Deathlike2 · Post by **Deathlike2** » Sun Nov 06, 2005 7:32 pm

Is this when using a save state, or even from a fresh game start?

You could just let the game intro run (it runs a demo of the game, which will show the problem.

That's not DMA related AFAIK.
That problem was already in the 4/04/05 WIP but not in the 2/28/05 WIP.
I guess I have to narrow down the problem.

To me, I believed it was a DMA problem since it occured after the DMA changes occured in the 10/8/05 WIP.. it looked just fine in the 9/09/05 WIP...

Though, I might be wrong, but it could be this line in the 10/8/05 WIP that I didn't consider...

SRC: Removed some alignment dependancy, removed some archaic code such as Dracula X hack. [Nach]

Post by **pagefault** » Sun Nov 06, 2005 7:34 pm

Maybe I didn't break something this time