2010-08-09 13:28:56 +00:00
|
|
|
include nall/Makefile
|
Updated to 20100813 release.
byuu says:
Since we're now talking about three splits, that's getting a bit out of
hand.
This WIP combines everything back into one project again. Added the
src/fast folder that has all the speed-oriented cores.
A slight slowdown to csnes from what it was before, I'm using blargg's
accurate DSP. I just don't like the idea of releasing a less accurate
DSP core than Snes9X v1.52 has. Plus the fast DSP core doesn't serialize
yet.
I moved back to snes_spc 0.9.0 because I care more about Tales and Star
Ocean than I do about Earthworm Jim 2. So if you try EWJ2 on csnes,
expect it to sound like it does on Snes9X. In other words, don't wear
headphones if you value your hearing.
The middle-of-the-road bsnes core uses blargg's accurate DSP, because
it's about 3% faster than mine which removes all of blargg's
optimizations. There is absolutely no accuracy loss here. bsnes v067.20
that is included should be equal to v067 official.
Performance:
Code:
asnes = 58fps
bsnes = 172fps +2.97x
csnes = 274fps +1.59x +4.72x
The binaries are not profiled, so that's an additional 15% slower from
the previous builds.
Save states only work on asnes, as I don't know how to serialize
blargg's cores yet. The copy_func thing is very confusing to me for some
reason. The debugger won't work anywhere.
Outside of that, please go ahead and bug test. Once I get the debugger
and save states working, I'll build some profiled v1.0 releases for all
three, and we can test that for a bit and then release.
2010-10-20 11:20:39 +00:00
|
|
|
snes := snes
|
Updated to v067r23 release.
byuu says:
Added missing $4200 IRQ lock, which fixes Chou Aniki on the fast CPU
core, so slower PCs can get their brotherly love on.
Added range-based controller IOBit latching to the fast CPU core, which
enables Super Scope and Justifier support. Uses the priority queue as
well, so there is zero speed-hit. Given the way range-testing works, the
trigger point may vary by 1-2 pixels when firing at the same spot. Not
really a big deal when it avoids a massive speed penalty.
Fixed PAL and interlace-mode HVIRQs at V=0,H<2 on the fast CPU core.
Added the dot-renderer's sprite list update-on-OAM-write functionality
to the scanline-based PPU renderer. Unfortunately it looks like all the
speed gain was already taken from the global dirty flag I was using
before, but this certainly won't hurt speed any, so whatever.
Added #ifdef to stop CoInitialize(0) on non-Windows ports.
Added #ifdefs to stop gradient fade on Windows port. Not going to fuck
over the Linux port aesthetic because of Qt bug #47,326,927. If there's
a way to tell what Qt theme is being used, I can leave it enabled for
XP/Vista themes.
Moved HDMA trigger from 1104 to 1112, and reduced channel overhead from
24 to 16, to better simulate one-cycle DMA->CPU sync.
Code clarity: I've re-added my varint.hpp classes, and am actively using
them in the accuracy cores. So far, I haven't done anything that would
detriment speed, but it is certainly cool. The APU ports exposed by the
CPU and SMP now take uint2 address arguments, the CPU WRAM address
register is a uint17, and the IRQ H/VTIME values are uint10. This
basically allows the source to clearly convey the data sizes, and
eliminates the need to manually mask values when writing to registers or
reading from memory. I'm going to be doing this everywhere, and it will
have a speed impact eventually, because the automation means we can't
skip masks when we know the data is already masked off.
Source: archive contains the launcher code, so that I can look into why
it's crashing on XP tomorrow.
It doesn't look like Circuit USA's flags are going to work too well with
this new CPU core. Still not sure what the hell Robocop vs The
Terminator is doing, I'll read through the mega SNES thread for clues
tomorrow. Speedy Gonzales is definitely broken, as modifying the MDR was
breaking things with my current core. Probably because the new CPU core
doesn't wait for a cycle edge to trigger.
I was thinking that perhaps we could keep some form of cheat codes list
to work as game-specific hacks for the performance core. Keeps the hacks
out of the emulator, but could allow the remaining bugs to be worked
around for people who have no choice but to use the performance core.
2010-08-16 09:42:20 +00:00
|
|
|
profile := performance
|
2010-08-09 13:28:56 +00:00
|
|
|
ui := qt
|
|
|
|
|
|
|
|
|
|
# compiler
|
|
|
|
|
c := $(compiler) -std=gnu99
|
|
|
|
|
cpp := $(subst cc,++,$(compiler)) -std=gnu++0x
|
|
|
|
|
flags := -O3 -fomit-frame-pointer -I. -I$(snes)
|
|
|
|
|
link :=
|
|
|
|
|
objects :=
|
|
|
|
|
|
|
|
|
|
# profile-guided instrumentation
|
|
|
|
|
# flags += -fprofile-generate
|
|
|
|
|
# link += -lgcov
|
|
|
|
|
|
|
|
|
|
# profile-guided optimization
|
|
|
|
|
# flags += -fprofile-use
|
|
|
|
|
|
|
|
|
|
# platform
|
|
|
|
|
ifeq ($(platform),x)
|
|
|
|
|
link += -s -ldl -lX11 -lXext
|
|
|
|
|
else ifeq ($(platform),osx)
|
|
|
|
|
else ifeq ($(platform),win)
|
|
|
|
|
link += -mwindows
|
|
|
|
|
# link += -mconsole
|
|
|
|
|
link += -mthreads -s -luuid -lkernel32 -luser32 -lgdi32 -lshell32
|
|
|
|
|
link += -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc
|
|
|
|
|
else
|
|
|
|
|
unknown_platform: help;
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# implicit rules
|
|
|
|
|
compile = \
|
|
|
|
|
$(strip \
|
|
|
|
|
$(if $(filter %.c,$<), \
|
|
|
|
|
$(c) $(flags) $1 -c $< -o $@, \
|
|
|
|
|
$(if $(filter %.cpp,$<), \
|
|
|
|
|
$(cpp) $(flags) $1 -c $< -o $@ \
|
|
|
|
|
) \
|
|
|
|
|
) \
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
%.o: $<; $(call compile)
|
|
|
|
|
|
|
|
|
|
all: build;
|
|
|
|
|
|
|
|
|
|
include $(snes)/Makefile
|
|
|
|
|
include $(ui)/Makefile
|
|
|
|
|
|
|
|
|
|
objects := $(patsubst %,obj/%.o,$(objects))
|
|
|
|
|
|
|
|
|
|
# targets
|
|
|
|
|
build: ui_build $(objects)
|
|
|
|
|
ifeq ($(platform),osx)
|
Updated to v067r23 release.
byuu says:
Added missing $4200 IRQ lock, which fixes Chou Aniki on the fast CPU
core, so slower PCs can get their brotherly love on.
Added range-based controller IOBit latching to the fast CPU core, which
enables Super Scope and Justifier support. Uses the priority queue as
well, so there is zero speed-hit. Given the way range-testing works, the
trigger point may vary by 1-2 pixels when firing at the same spot. Not
really a big deal when it avoids a massive speed penalty.
Fixed PAL and interlace-mode HVIRQs at V=0,H<2 on the fast CPU core.
Added the dot-renderer's sprite list update-on-OAM-write functionality
to the scanline-based PPU renderer. Unfortunately it looks like all the
speed gain was already taken from the global dirty flag I was using
before, but this certainly won't hurt speed any, so whatever.
Added #ifdef to stop CoInitialize(0) on non-Windows ports.
Added #ifdefs to stop gradient fade on Windows port. Not going to fuck
over the Linux port aesthetic because of Qt bug #47,326,927. If there's
a way to tell what Qt theme is being used, I can leave it enabled for
XP/Vista themes.
Moved HDMA trigger from 1104 to 1112, and reduced channel overhead from
24 to 16, to better simulate one-cycle DMA->CPU sync.
Code clarity: I've re-added my varint.hpp classes, and am actively using
them in the accuracy cores. So far, I haven't done anything that would
detriment speed, but it is certainly cool. The APU ports exposed by the
CPU and SMP now take uint2 address arguments, the CPU WRAM address
register is a uint17, and the IRQ H/VTIME values are uint10. This
basically allows the source to clearly convey the data sizes, and
eliminates the need to manually mask values when writing to registers or
reading from memory. I'm going to be doing this everywhere, and it will
have a speed impact eventually, because the automation means we can't
skip masks when we know the data is already masked off.
Source: archive contains the launcher code, so that I can look into why
it's crashing on XP tomorrow.
It doesn't look like Circuit USA's flags are going to work too well with
this new CPU core. Still not sure what the hell Robocop vs The
Terminator is doing, I'll read through the mega SNES thread for clues
tomorrow. Speedy Gonzales is definitely broken, as modifying the MDR was
breaking things with my current core. Probably because the new CPU core
doesn't wait for a cycle edge to trigger.
I was thinking that perhaps we could keep some form of cheat codes list
to work as game-specific hacks for the performance core. Keeps the hacks
out of the emulator, but could allow the remaining bugs to be worked
around for people who have no choice but to use the performance core.
2010-08-16 09:42:20 +00:00
|
|
|
test -d ../bsnes-$(profile).app || mkdir -p ../bsnes-$(profile).app/Contents/MacOS
|
|
|
|
|
$(strip $(cpp) -o ../bsnes-$(profile).app/Contents/MacOS/bsnes-$(profile) $(objects) $(link))
|
2010-08-09 13:28:56 +00:00
|
|
|
else
|
Updated to v067r21 release.
byuu says:
This moves toward a profile-selection mode. Right now, it is incomplete.
There are three binaries, one for each profile. The GUI selection
doesn't actually do anything yet. There will be a launcher in a future
release that loads each profile's respective binary.
I reverted away from blargg's SMP library for the time being, in favor
of my own. This will fix most of the csnes/bsnes-performance bugs. This
causes a 10% speed hit on 64-bit platforms, and a 15% speed hit on
32-bit platforms. I hope to be able to regain that speed in the future,
I may also experiment with creating my own fast-SMP core which drops bus
hold delays and TEST register support (never used by anything, ever.)
Save states now work in all three cores, but they are not
cross-compatible. The profile name is stored in the description field of
the save states, and it won't load a state if the profile name doesn't
match.
The debugger only works on the research target for now. Give it time and
it will return for the other targets.
Other than that, let's please resume testing on all three once again.
See how far we get this time :)
I can confirm the following games have issues on the performance
profile:
- Armored Police Metal Jacket (minor logo flickering, not a big deal)
- Chou Aniki (won't start, so obviously unplayable)
- Robocop vs The Terminator (major in-game flickering, unplayable)
Anyone still have that gigantic bsnes thread archive from the ZSNES
forum? Maybe I posted about how to fix those two broken games in there,
heh.
I really want to release this as v1.0, but my better judgment says we
need to give it another week. Damn.
2010-10-20 11:22:44 +00:00
|
|
|
$(strip $(cpp) -o out/bsnes-$(profile) $(objects) $(link))
|
2010-08-09 13:28:56 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
install:
|
|
|
|
|
ifeq ($(platform),x)
|
2010-08-16 04:10:50 +00:00
|
|
|
install -D -m 755 out/bsnes-$(profile) $(DESTDIR)$(prefix)/bin/bsnes-$(profile)
|
2010-08-11 00:40:59 +00:00
|
|
|
install -D -m 644 qt/data/bsnes.png $(DESTDIR)$(prefix)/share/pixmaps/bsnes.png
|
|
|
|
|
install -D -m 644 qt/data/bsnes.desktop $(DESTDIR)$(prefix)/share/applications/bsnes.desktop
|
2010-08-09 13:28:56 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
uninstall:
|
|
|
|
|
ifeq ($(platform),x)
|
2010-08-16 04:10:50 +00:00
|
|
|
rm $(DESTDIR)$(prefix)/bin/bsnes-$(profile)
|
2010-08-09 13:28:56 +00:00
|
|
|
rm $(DESTDIR)$(prefix)/share/pixmaps/bsnes.png
|
|
|
|
|
rm $(DESTDIR)$(prefix)/share/applications/bsnes.desktop
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
clean: ui_clean
|
|
|
|
|
-@$(call delete,obj/*.o)
|
|
|
|
|
-@$(call delete,obj/*.a)
|
|
|
|
|
-@$(call delete,obj/*.so)
|
|
|
|
|
-@$(call delete,obj/*.dylib)
|
|
|
|
|
-@$(call delete,obj/*.dll)
|
|
|
|
|
-@$(call delete,*.res)
|
|
|
|
|
-@$(call delete,*.pgd)
|
|
|
|
|
-@$(call delete,*.pgc)
|
|
|
|
|
-@$(call delete,*.ilk)
|
|
|
|
|
-@$(call delete,*.pdb)
|
|
|
|
|
-@$(call delete,*.manifest)
|
|
|
|
|
|
|
|
|
|
archive-all:
|
Updated to v067r23 release.
byuu says:
Added missing $4200 IRQ lock, which fixes Chou Aniki on the fast CPU
core, so slower PCs can get their brotherly love on.
Added range-based controller IOBit latching to the fast CPU core, which
enables Super Scope and Justifier support. Uses the priority queue as
well, so there is zero speed-hit. Given the way range-testing works, the
trigger point may vary by 1-2 pixels when firing at the same spot. Not
really a big deal when it avoids a massive speed penalty.
Fixed PAL and interlace-mode HVIRQs at V=0,H<2 on the fast CPU core.
Added the dot-renderer's sprite list update-on-OAM-write functionality
to the scanline-based PPU renderer. Unfortunately it looks like all the
speed gain was already taken from the global dirty flag I was using
before, but this certainly won't hurt speed any, so whatever.
Added #ifdef to stop CoInitialize(0) on non-Windows ports.
Added #ifdefs to stop gradient fade on Windows port. Not going to fuck
over the Linux port aesthetic because of Qt bug #47,326,927. If there's
a way to tell what Qt theme is being used, I can leave it enabled for
XP/Vista themes.
Moved HDMA trigger from 1104 to 1112, and reduced channel overhead from
24 to 16, to better simulate one-cycle DMA->CPU sync.
Code clarity: I've re-added my varint.hpp classes, and am actively using
them in the accuracy cores. So far, I haven't done anything that would
detriment speed, but it is certainly cool. The APU ports exposed by the
CPU and SMP now take uint2 address arguments, the CPU WRAM address
register is a uint17, and the IRQ H/VTIME values are uint10. This
basically allows the source to clearly convey the data sizes, and
eliminates the need to manually mask values when writing to registers or
reading from memory. I'm going to be doing this everywhere, and it will
have a speed impact eventually, because the automation means we can't
skip masks when we know the data is already masked off.
Source: archive contains the launcher code, so that I can look into why
it's crashing on XP tomorrow.
It doesn't look like Circuit USA's flags are going to work too well with
this new CPU core. Still not sure what the hell Robocop vs The
Terminator is doing, I'll read through the mega SNES thread for clues
tomorrow. Speedy Gonzales is definitely broken, as modifying the MDR was
breaking things with my current core. Probably because the new CPU core
doesn't wait for a cycle edge to trigger.
I was thinking that perhaps we could keep some form of cheat codes list
to work as game-specific hacks for the performance core. Keeps the hacks
out of the emulator, but could allow the remaining bugs to be worked
around for people who have no choice but to use the performance core.
2010-08-16 09:42:20 +00:00
|
|
|
tar -cjf bsnes-`date +%Y%m%d`.tar.bz2 launcher libco nall obj out qt ruby snes Makefile sync.sh cc.bat clean.bat
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
|
help:;
|