New core starting to come together!

News from administrators.
User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Tue Dec 30, 2014 8:31 pm

I broke SSE2 builds in getting the new core slapped together (sorry). That function only gets compiled when SSE2 is used as a build type, so double check your CMake configuration.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Wed Dec 31, 2014 11:19 am

Squashed that one last RSP bug I was talking about.

VMACU and LTV/STV still aren't implemented, so there are significant lighting issues (especially because of the former); those are expected for now.

I'm ecstatic about the new core's ability to keep the frame rate pumping even in high-poly scenes.
Attachments
mk64.png
mk64.png (72.22 KiB) Viewed 20422 times
starfox64.png
starfox64.png (45.47 KiB) Viewed 20422 times
sm64.png
sm64.png (92.54 KiB) Viewed 20422 times

User avatar
Nacho
Posts: 66
Joined: Thu Nov 07, 2013 9:25 am

Re: New core starting to come together!

Post by Nacho » Wed Dec 31, 2014 12:41 pm

Testing Mario Kart I get strange behavior of the textures, specially the track textures: they rotate in a funny way.

Maybe it's supossed to happen like that, maybe not, but I drop it here :P
Testing CEN64 on: Intel Core i5 520M 2.4 GHz. SSE2 SSE3 SSE4.1 SSE4.2 SSSE3, but no AVX. Ubuntu Linux

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Wed Dec 31, 2014 12:45 pm

Wave Race 64 boots for the first time on CEN64! :D
Attachments
WaveRace64.png
WaveRace64.png (84.03 KiB) Viewed 20398 times
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Wed Dec 31, 2014 12:56 pm

Nacho wrote:Testing Mario Kart I get strange behavior of the textures, specially the track textures: they rotate in a funny way.

Maybe it's supossed to happen like that, maybe not, but I drop it here :P
Probably because of the unimplemented instructions. Notice the skybox in Wave Racer 64 in Snowstorm's post (above) illustrates this as well.

EDIT: Nope, AIO found the clipping bug and it's been fixed. :D Now just for the lighting...

User avatar
Alegend45
Posts: 11
Joined: Mon Oct 07, 2013 11:24 am

Re: New core starting to come together!

Post by Alegend45 » Wed Dec 31, 2014 6:43 pm

Super Smash Bros still doesn't boot, but now Star Fox 64 does, and even on my Ivy Bridge i3, I get a solid 50-60 VI/s ingame.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Wed Dec 31, 2014 9:40 pm

Most games boot, I just have to merge in bits of code that I haven't fully tested first. e.g., OoT:
Attachments
psnap.png
psnap.png (76.19 KiB) Viewed 20255 times
zeldaoot.png
zeldaoot.png (86.17 KiB) Viewed 20255 times

User avatar
OldGnashburg
Posts: 91
Joined: Tue Nov 19, 2013 3:00 pm
Location: Sherwood Park, Alberta, Canada: A place with free universal healthcare, and lots and lots of oil.

Re: New core starting to come together!

Post by OldGnashburg » Wed Dec 31, 2014 10:09 pm

So what's next? Add the last few instructions, then optimize? What do you plan to do once you've finished the RSP?
Gnash, Gnash, Gnash...

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Wed Dec 31, 2014 10:33 pm

OldGnashburg wrote:So what's next? Add the last few instructions, then optimize? What do you plan to do once you've finished the RSP?
Well, aside from finishing the unimplemented RSP stuff, there's a truckload of optimizations that'll irk out another handful of VI/s. I also have to test the corner cases for loads and stores and some odds and ends that I haven't seen documented elsewhere. And add SSE2 support.

But that's just the RSP... there's a ton of VR4300 stuff that I haven't gotten around to merging in yet, save states, better Win/Mac support, gamepads, full screen resolutions, debugging capabilities, ... I could go on and on.

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: New core starting to come together!

Post by Narann » Wed Dec 31, 2014 11:18 pm

Impressive! I'm surprised about the darkness of the provided screenshots.

Silly question: No RDP rewrite? You will remain on the angrylion one?

User avatar
Alegend45
Posts: 11
Joined: Mon Oct 07, 2013 11:24 am

Re: New core starting to come together!

Post by Alegend45 » Wed Dec 31, 2014 11:44 pm

Narann wrote:Impressive! I'm surprised about the darkness of the provided screenshots.

Silly question: No RDP rewrite? You will remain on the angrylion one?
The angrylion RDP is already pixel-accurate. What more could you want?

AIO
Posts: 51
Joined: Wed Nov 05, 2014 4:56 pm

Re: New core starting to come together!

Post by AIO » Wed Dec 31, 2014 11:53 pm

Alegend45 wrote:
Narann wrote:Impressive! I'm surprised about the darkness of the provided screenshots.

Silly question: No RDP rewrite? You will remain on the angrylion one?
The angrylion RDP is already pixel-accurate. What more could you want?
Speed :D !

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: New core starting to come together!

Post by beannaich » Thu Jan 01, 2015 12:34 am

Alegend45 wrote:
Narann wrote:Impressive! I'm surprised about the darkness of the provided screenshots.

Silly question: No RDP rewrite? You will remain on the angrylion one?
The angrylion RDP is already pixel-accurate. What more could you want?
It's also a monolith that could stand to be split into multiple, logically grouped files.

EDIT: How about some audio? :D

User avatar
OldGnashburg
Posts: 91
Joined: Tue Nov 19, 2013 3:00 pm
Location: Sherwood Park, Alberta, Canada: A place with free universal healthcare, and lots and lots of oil.

Re: New core starting to come together!

Post by OldGnashburg » Thu Jan 01, 2015 3:19 am

As an accuracy fanatic, I REALLY hope MarathonMan makes the RDP both cycle and pixel accurate. Because if you're going to make a cycle accurate simulator, the WHOLE thing should be cycle accurate, otherwise IMHO it's a complete waste of time. And besides by the time MarathonMan finishes CEN64 and optimizes the shit out of it, most low to medium end gaming rigs (or high end gaming laptops) will be able to pump out an almost orgasmic 60 VI/s.

Also, Happy New Year everybody!!!
Gnash, Gnash, Gnash...

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Thu Jan 01, 2015 5:12 am

Outside of the games already shown running, here are some others that boot and at least run the title screen demo seemingly infintely without crashing (I would test farther into the games, but broken keyboard input and all):
  • California Speed
  • Doom 64
  • Wipeout 64
And some new games that now boot but require controller input to continue to the title screen:
  • Hey You, Pikachu!
  • Mario Party
  • Mario Party 2
  • Star Wars: Shadows of the Empire
And lastly, new games that now boot but eventually crash or freeze at the title screen or similar:
  • Rush 2: Extreme Racing USA
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
The Extremist
Posts: 29
Joined: Sun Nov 03, 2013 6:11 pm
Location: Canadian Prairie

Re: New core starting to come together!

Post by The Extremist » Thu Jan 01, 2015 5:54 am

LOVELY progress!

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Thu Jan 01, 2015 8:23 am

How about CIC detection/handling code instead? Please, please, MarathonMan, consider it a high priority, because I'm too tired to edit si/controller.c and then produce a new binary for each CIC, for (almost) each update of CEN64...Do you agree?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Thu Jan 01, 2015 9:49 am

Snowstorm64 wrote:How about CIC detection/handling code instead? Please, please, MarathonMan, consider it a high priority, because I'm too tired to edit si/controller.c and then produce a new binary for each CIC, for (almost) each update of CEN64...Do you agree?
You're not the only one. :p

This is a high-priority ATM, right behind unbreaking the Windows stuff.
Narann wrote:Impressive! I'm surprised about the darkness of the provided screenshots.
There's a bug in the RSP multiply code that's causing all sort of lighting issues. If you boot Super Mario 64 and wait for Mario's face to spin around, you'll see how bad the lighting can be, heh.

Fortunately, I have narrowed it down to the exact instruction causing the issue!
Attachments
sm64_dark.png
sm64_dark.png (92.54 KiB) Viewed 20112 times
vmacf.png
vmacf.png (97.25 KiB) Viewed 20112 times

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Thu Jan 01, 2015 11:39 am

MarathonMan wrote:
You're not the only one. :p

This is a high-priority ATM, right behind unbreaking the Windows stuff.
Good! :)
MarathonMan wrote:
There's a bug in the RSP multiply code that's causing all sort of lighting issues. If you boot Super Mario 64 and wait for Mario's face to spin around, you'll see how bad the lighting can be, heh.

Fortunately, I have narrowed it down to the exact instruction causing the issue!
Still doesn't look right. For comparison here is a screenshot from cen64-backport with old RSP:
Attachments
sm64-oldrsp.png
sm64-oldrsp.png (100.33 KiB) Viewed 20098 times
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Thu Jan 01, 2015 11:40 am

Good eye! Mario does look a little dimly lit still...

User avatar
OldGnashburg
Posts: 91
Joined: Tue Nov 19, 2013 3:00 pm
Location: Sherwood Park, Alberta, Canada: A place with free universal healthcare, and lots and lots of oil.

Re: New core starting to come together!

Post by OldGnashburg » Thu Jan 01, 2015 1:38 pm

I also noticed that your screenshot of Ocarina of Time seemed way too dark. Is that also caused by the bug?
Gnash, Gnash, Gnash...

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Thu Jan 01, 2015 2:13 pm

OldGnashburg wrote:I also noticed that your screenshot of Ocarina of Time seemed way too dark. Is that also caused by the bug?
Yes.

BTW, Windows builds should now be working. Yell at me if this is not the case, because I'm assuming that they're no longer broken. Also, please let me know if it's slower or faster than the old core, etc. I don't have a actual machine to test it on myself. I should mention that I'm only really interested in the performance reports (especially vs. the old core, if possible) and reports such as "it crashes when I do X".

EDIT: I also automatically seed the PIF RAM based on the CIC of the cart now (determined using a CRC of the cart's header). So editing si/controller.c to get non-6102 carts to boot is no longer a requirement; it just works.

EDIT 2: I still need to merge in some TLB fixes and other tidbits before a large number of carts work: OoT, Goldeneye 64, SSB, etc. to name a few. A general rule of thumb is if CEN64 magically quits or crashes, I know about it. If it doesn't, that's just non-conclusive (i.e,. OoT).

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Thu Jan 01, 2015 4:36 pm

MarathonMan wrote:Also, please let me know if it's slower or faster than the old core
This will be difficult to tell since the older broken versions didn't have a VI/s counter... Nevertheless, with just eyeballing it, it doesn't seem like it's any slower, and in fact it might even be a bit faster (but maybe that's just placebo from now having an actual numerical value attached to the performance?)

Nevertheless, I just want to say how I love in this cycle-accurate stuff that, once you implement something, things just suddenly work - no hacking around or anything!
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Thu Jan 01, 2015 4:48 pm

Nintendo Maniac 64 wrote:Nevertheless, I just want to say how I love in this cycle-accurate stuff that, once you implement something, things just suddenly work - no hacking around or anything!
I agree! :D

(Most) TLB support and pending stuff is back in, so OoT, Goldeneye 007, SSB, and many other classic titles should boot.

User avatar
Nacho
Posts: 66
Joined: Thu Nov 07, 2013 9:25 am

Re: New core starting to come together!

Post by Nacho » Thu Jan 01, 2015 5:04 pm

Well, I'm confused. If I want to compile CEN64 to take advantages of the intrinsics of my processor... which flag do I have to choose?

If I write "Native" at CEN64_ARCH_SUPPORT, then build fails.

If I write SSE4.1, then builld success. But I'm not sure if I'm taking all the possible advantage from my processor (i5-i520M), therefore I can't compare.

Beside that, do you want comparison between the first CEN64 and the new one? Or just between cen64-backport and the actual one?
Testing CEN64 on: Intel Core i5 520M 2.4 GHz. SSE2 SSE3 SSE4.1 SSE4.2 SSSE3, but no AVX. Ubuntu Linux

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Thu Jan 01, 2015 5:08 pm

Nacho wrote:Well, I'm confused. If I want to compile CEN64 to take advantages of the intrinsics of my processor... which flag do I have to choose?

If I write "Native" at CEN64_ARCH_SUPPORT, then build fails.
I removed "Native" temporarily due to the fact that I haven't been able to figure out how to tell GNU ASsembler what instructions are available.

Delete you build/ folder (or the CMake build folder you're using) and regenerate everything -- it shouldn't appear anymore.

If you _really_ want native builds for now, replace -march=msse41, -march=avx, etc. with with -march=native in CMakeLists.txt.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Thu Jan 01, 2015 5:11 pm

Yakouchuu II
Yakouchuu.png
Yakouchuu.png (10.54 KiB) Viewed 20127 times
It shows only the half top of the screen.

Hey you, Pikachu!
creepypikachu.png
A wild faceless Pikachu just appeared!
creepypikachu.png (80.39 KiB) Viewed 20127 times
I guess it's due to unimplemented VMACU. That's scary!
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Thu Jan 01, 2015 5:20 pm

Could one of you guys with a fancy AVX-enabled CPU compare the performance difference between the AVX build(s) and the SSE 4.1 build(s)?

For reference, the performance of the SSE4.1 Windows build is easily within the magin of error compared to the SSSE3 Windows build.
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Thu Jan 01, 2015 5:36 pm

I have tried SSB64 and Mario Kart 64 with AVX and SSE 4.1. The speed doesn't change much, like ~0.5 VI/s. Of course AVX is the best option.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
darkszero
Posts: 4
Joined: Fri Oct 25, 2013 12:52 pm

Re: New core starting to come together!

Post by darkszero » Thu Jan 01, 2015 6:18 pm

I decided to try running something again, given that there's a build for windows, I have a new CPU and the rewrite usable, so here we go:

Ocarina of Time, during intro SSE4.1
http://imgur.com/a/4NJ4v#1
Reasonable number of VI/s, but things are definitely not looking right.

An extra screen shot because you can clearly see the reason. http://i.imgur.com/c5wz10Z.png

Compared VI/s on the file selection screen of AVX/SSE4.1: no difference

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Thu Jan 01, 2015 6:29 pm

I just want to confirm one thing - no gamepad support is implemented at this time, correct? Not traditional HID controllers nor Xinput devices, right?

EDIT:
Snowstorm64 wrote:I have tried SSB64 and Mario Kart 64 with AVX and SSE 4.1. The speed doesn't change much, like ~0.5 VI/s. Of course AVX is the best option.
OK so I'm not really missing anything on my Pentium G3258. :P
Last edited by Nintendo Maniac 64 on Thu Jan 01, 2015 6:31 pm, edited 2 times in total.
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Thu Jan 01, 2015 6:31 pm

Nintendo Maniac 64 wrote:I just want to confirm one thing - no gamepad support is implemented at this time, correct? Not traditional HID controllers nor Xinput devices, right?
Correct. Only keyboard is supported.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

AIO
Posts: 51
Joined: Wed Nov 05, 2014 4:56 pm

Re: New core starting to come together!

Post by AIO » Thu Jan 01, 2015 6:54 pm

I think you guys should wait until RSP is fixed up, before doing serious performance testing. These bugs could effect the VI/s for all we know. I've seen that happen before. Also the AVX code optimizations are not completely done :D . So the gap will only get wider.

Also a good way to test RSP speed is to run a game that where the RSP is a significant bottleneck (Kirby64, Rogue Squadron, etc). In games like SSB64 and F-Zero, the pixel accurate RDP is a huge bottleneck, so you won't notice much of a difference (if any) in those games.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Thu Jan 01, 2015 8:01 pm

AIO wrote:I think you guys should wait until RSP is fixed up, before doing serious performance testing. These bugs could effect the VI/s for all we know. I've seen that happen before. Also the AVX code optimizations are not completely done :D . So the gap will only get wider.

Also a good way to test RSP speed is to run a game that where the RSP is a significant bottleneck (Kirby64, Rogue Squadron, etc). In games like SSB64 and F-Zero, the pixel accurate RDP is a huge bottleneck, so you won't notice much of a difference (if any) in those games.
Thanks for the advice.

I have just discovered another bug (or an unimplemented opcode) running Kirby 64:
kirby64.png
kirby64.png (74.69 KiB) Viewed 20196 times
Dark Matter's aura is pixelated instead of being softened like this:
Image
(Sorry, I haven't found a better image, but I hope you get the idea)

Also, Waddle Dee's texture is screwed when being attacked.

EDIT: Maybe the aura is not bugged, it was the fault of an emulator that I used to play Kirby64...
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: New core starting to come together!

Post by Narann » Thu Jan 01, 2015 9:48 pm

IIRC, Kirby "dark" effect use RDP combiner's noise.

Some games use Combiner noise noise for various effects. See the end of this chapter for more explanations.

IIRC, the N64 use a analog filter to "smooth" the dither effect (something you don't really want actually) while transforming the numerical signal to analog (composite).

From my perspective, the "noisy" image is more accurate than the second one.

Any RDP expert could confirm this?

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Thu Jan 01, 2015 10:41 pm

The aura will likely be smoothed out with the VI filters once they're enabled, too, remember... I think that might be right!

User avatar
Ambient_Malice
Posts: 21
Joined: Mon Aug 25, 2014 9:04 am

Re: New core starting to come together!

Post by Ambient_Malice » Thu Jan 01, 2015 10:54 pm

I'm very impressed by C64's progress. For the first time, the new version booted on my PC today. Thank you very much for taking the time to unbreak the Windows builds, MM.

I'm gonna do some extensive testing, but I was pleasantly surprised to see that the homebrew Doom ports seem to run. I'm getting about 30-40 VIs on my Core Quad @ 3.2Ghz running the SSE4.1 build on Windows.

The emulator only takes z64 roms at the moment, so I'm converting my collection to big-endian for testing. Will this always be required?

On another note, I can't help feeling Cen64 should assume the PIF file is in the same directory as the Cen64 executable. Because while I'm fine with batch files and dragging rom+pif onto Cen64, I think that this minor change would make the emu a tad more usable.

Obsessive that I am, my first instinct was to test Infernal Machine and Body Harvest. Neither game seems to boot. But I'm gonna do more testing, and I hope to be a bit more active on these forums. I've a passion for N64 emulation, and emulation in general, despite being unable to code my way out of a damp paper bag.

Another thing - I keep the Cen64 dowload link handy, but will that be added to the front page anytime soon?

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Fri Jan 02, 2015 12:06 am

Quick question - is there any kind of fullscreen support at all and/or any way to toggle it and/or enable it when launching a game from command line?

Just want to get this question out of the way before I do things the more "work-around" way by manually changing my desktop resolution so that I don't have to click "Maximize" every single time.

EDIT: Derp, I forgot about the "start /max" command! Nevermind then...
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
iwasaperson
Posts: 49
Joined: Tue Apr 22, 2014 12:50 am

Re: New core starting to come together!

Post by iwasaperson » Fri Jan 02, 2015 1:22 am

Majora's Mask kind of works: https://i.imgur.com/6hKSFnB.png

Lot's of flickering, no UI in the menu, no Nintendo text (although the spinning 'N' shows up). I just kept mashing X and Enter and I started the game.

Honestly, I wasn't expecting it to work at all.

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Fri Jan 02, 2015 1:32 am

iwasaperson wrote:Lot's of flickering, no UI in the menu, no Nintendo text (although the spinning 'N' shows up). I just kept mashing X and Enter and I started the game.
That's odd. I'm using the build from 02:41 UTC (only 2 hours ago) and everything seems pretty much flawless except that things seem darker, you start with ocarinas for days (letting you skip the first part of the game :P), and you don't have your sword and shield, though the guard(s) still allow you to leave Clock Town (but you can't use the owl statues and can only attack via Deku scrub).

Also, holy dithering & aliasing batman @ Majora's Mask. That explains why the last time I booted up my N64 cart a few years back, even on an standard definition Trinitron CRT TV, I saw jaggies out the wazoo - and to think I completed the game on that very same TV years prior with the same video connections and all. :shock:
Last edited by Nintendo Maniac 64 on Fri Jan 02, 2015 2:11 am, edited 1 time in total.
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
Ambient_Malice
Posts: 21
Joined: Mon Aug 25, 2014 9:04 am

Re: New core starting to come together!

Post by Ambient_Malice » Fri Jan 02, 2015 1:59 am

The dark lighting bug from Mario 64 also affects Rocket: Robot on Wheels.

Image

This is how it should look.

Image

64Doom works. It already worked on MESS, I believe.

Image

Wonder Project J2 has a strange bug. When you reach the main menu, you get this.

Image

But it should look like this, with the cursor automatically moving.

Image

I tested a clean WPJ2 rom just in case it was the fan translation, but the same thing happens.

Also, Cen64 can't handle PAL games. It displays the "this game is not designed for this system" message specific to that game.

User avatar
iwasaperson
Posts: 49
Joined: Tue Apr 22, 2014 12:50 am

Re: New core starting to come together!

Post by iwasaperson » Fri Jan 02, 2015 2:55 am

Nintendo Maniac 64 wrote:
iwasaperson wrote:Lot's of flickering, no UI in the menu, no Nintendo text (although the spinning 'N' shows up). I just kept mashing X and Enter and I started the game.
That's odd. I'm using the build from 02:41 UTC (only 2 hours ago) and everything seems pretty much flawless except that things seem darker, you start with ocarinas for days (letting you skip the first part of the game :P), and you don't have your sword and shield, though the guard(s) still allow you to leave Clock Town (but you can't use the owl statues and can only attack via Deku scrub).

Also, holy dithering & aliasing batman @ Majora's Mask. That explains why the last time I booted up my N64 cart a few years back, even on an standard definition Trinitron CRT TV, I saw jaggies out the wazoo - and to think I completed the game on that very same TV years prior with the same video connections and all. :shock:
I just built it. Still has that problem. Other games work just fine.

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Fri Jan 02, 2015 2:59 am

iwasaperson wrote:I just built it. Still has that problem. Other games work just fine.
Well I just downloaded cen64-win64-sse41-latest.exe version 2015-01-02 04:14 and everything looks the same as I previously described...

I'm using the one from here for reference:
http://downloads.cen64.com/


--------------------------------EDIT--------------------------------


Finally finished testing everything. Thanks to good ol' JoyToKey, I've rigged up cheaty controller support which definitely made testing games easier since I use the Colemak keyboard layout.

Now then, here's an update on what's booting and the like - lots of games this time (doesn't include games already known).


Seemingly fully playable:
  • BattleTanx: Gloabal Assault
  • California Speed
  • Cruis'n World
  • Diddy Kong Racing
  • GoldenEye 007
  • Hydro Thunder (got 1st place on Arctic Circle first try - I've still got it!)
  • Legend of Zelda: Majora's Mask (start with tons of ocarinas but have no sword, though you can still leave Clock Town)
  • San Francisco Rush: Extreme Racing
  • Sin & Punishment / Tsumi to Batsu (requires mashing the A button at boot to avoid freezing)
  • Star Wars: Shadows of the Empire
  • Super Smash Bros.
  • Wipeout 64
Seems fully playable, but will eventually freeze depending on what you do in-game:
  • Mario Party
Can play the titlescreen demo or the first level, but still ends up crashing, hanging, or similar:
  • 007: The World is Not Enough
  • Donkey Kong 64
  • Mario Party 2
Control input doesn't work:
  • Star Wars: Episode 1 - Racer
Makes it to title screen and/or main menu but crashes during or after:
  • San Francisco Rush: 2049
  • Mario Golf (requires mashing the A button at boot to avoid freezing)
Boots but doesn't even make it to the title screen before crashing or freezing:
  • Paper Mario
  • Pokemon Stadium
  • Pokemon Stadium 2
  • Quake II
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Fri Jan 02, 2015 10:28 am

Ambient_Malice wrote:The emulator only takes z64 roms at the moment, so I'm converting my collection to big-endian for testing. Will this always be required?
Ambient_Malice wrote:On another note, I can't help feeling Cen64 should assume the PIF file is in the same directory as the Cen64 executable. Because while I'm fine with batch files and dragging rom+pif onto Cen64, I think that this minor change would make the emu a tad more usable.
Frontends should solve both of these problems... the ones designed for the old core should still mostly work, so long as you don't use the save options or anything unimplemented yet.
Ambient_Malice wrote:Another thing - I keep the Cen64 dowload link handy, but will that be added to the front page anytime soon?
/me pokes beannaich :). I don't do any of the website stuff really. I setup the forums and stuff, but that's about it.
Nintendo Maniac 64 wrote:Quick question - is there any kind of fullscreen support at all and/or any way to toggle it and/or enable it when launching a game from command line?
Not ATM. I'd need to bind an escape keep or toggle key, which I haven't done yet.

The other bugs are hopefully mostly unimplemented stuff or the known RSP multiply bug. A lot of those things worked fine on the old core.
- I noticed that when I merged angrylion'd latest RDP into the backported CEN64, DK64 no longer boots. I'm not sure if that's because the RSP is sending the RDP invalid triangle commands and causing the whole thing to come crashing down or what the deal is.
- The ocarinas/LoZ:MM bug is due to unimplemented save support (I forgot what type it uses, but if you don't implement it that's what happens on other emulators as well). This game also looked fine in the previous core, so I'm hoping unimplemented RSP opcodes/vector multiply issue will fix it up.
- Lots of the menu text missing issues are hopefully related to the new core as well. Goemon's Great Adventure worked fine on the old core, but in the new one the menu is really glitchy and CEN64 kinda just dies shortly afterwards.

User avatar
chriztr
Posts: 38
Joined: Sun Oct 06, 2013 4:15 pm

Re: New core starting to come together!

Post by chriztr » Fri Jan 02, 2015 1:53 pm

Figured you guise needed some screen from the windows build.

*NOTE* This is done on my laptop, not my desktop

Image Image Image Image Image Image Image

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Fri Jan 02, 2015 2:26 pm

Thank you, chriztr. That is exactly what I was looking for. :)

So, I have bad news and good news for you Windows guys:
  • The bad: There may be a giant performance issue w/ the Windows builds.
  • The good: It's fixable if you compile it yourself with MinGW.
Speaking to krom (who always builds his custom Windows binaries), he was able to get up to 10VI/s extra in 3D scenes. For an i5-3210M, I would expect way more VI/s than ~25 or so... but maybe I'm disillusioned. :p

Not sure how to solve/debug this ATM, but I'll try and look into it after the lighting issue. Speaking of the lighting issue:
Snowstorm64 wrote:Still doesn't look right. For comparison here is a screenshot from cen64-backport with old RSP:
Right, so the image is definitely still wrong after the RSP fix. However, it turns out because of LTV/STV. If I comment out LTV/STV in the old core, Mario's cap becomes dimly lit just as in the current core (but the lighting looks "mostly" right, or at least very similar to the current core). So I will fix VMACF and then try to implement LTV/STV sometime in the future.

User avatar
darkszero
Posts: 4
Joined: Fri Oct 25, 2013 12:52 pm

Re: New core starting to come together!

Post by darkszero » Fri Jan 02, 2015 3:28 pm

The screenshots I posted before (http://imgur.com/a/4NJ4v#1 and http://i.imgur.com/c5wz10Z.png) are from my i5-3570K @ 3.4GHz (and 3.8 GHz turbo boost?) running on Windows 7.

Tried building cen64 from URL with mingw, but got the following error:

[ 45%] Building ASM-ATT object CMakeFiles/cen64arch.dir/arch/x86_64/rsp/gcc/vabs.s.obj
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s: Assembler messages:
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:27: Warning: .type pseudo-op used outside of .def/.endef ignored.
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:27: Error: junk at end of line, first unrecognized character is `R'
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:61: Warning: .size pseudo-op used outside of .def/.endef ignored.
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:61: Error: junk at end of line, first unrecognized character is `R'
CMakeFiles\cen64arch.dir\build.make:53: recipe for target 'CMakeFiles/cen64arch.dir/arch/x86_64/rsp/gcc/vabs.s.obj' failed

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core starting to come together!

Post by Snowstorm64 » Fri Jan 02, 2015 3:29 pm

Narann wrote:IIRC, Kirby "dark" effect use RDP combiner's noise.

Some games use Combiner noise noise for various effects. See the end of this chapter for more explanations.

IIRC, the N64 use a analog filter to "smooth" the dither effect (something you don't really want actually) while transforming the numerical signal to analog (composite).

From my perspective, the "noisy" image is more accurate than the second one.

Any RDP expert could confirm this?
MarathonMan wrote:The aura will likely be smoothed out with the VI filters once they're enabled, too, remember... I think that might be right!
So the aura is rendered correctly as it is in the framebuffer, and then smoothed as one player would see it on TV screen, right? I wonder if the VI filters will be restored back or not. :P
MarathonMan wrote:Right, so the image is definitely still wrong after the RSP fix. However, it turns out because of LTV/STV. If I comment out LTV/STV in the old core, Mario's cap becomes dimly lit just as in the current core (but the lighting looks "mostly" right, or at least very similar to the current core). So I will fix VMACF and then try to implement LTV/STV sometime in the future.
So, excluding LTV/STV, the RSP opcodes, that are still missing, are the following:
  • NOP
  • CTC2
  • VMACQ
  • VMACU
  • VMULQ
  • VRNDN
  • VRNDP
  • LFV
  • LHV
  • SFV
  • SHV
  • SWV
We know that VMACU is needed by some game like Hey You, Pikachu! or Animal Forest, but what are the others for?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: New core starting to come together!

Post by Nintendo Maniac 64 » Fri Jan 02, 2015 4:00 pm

chriztr wrote:Figured you guise needed some screen from the windows build.
Is that with the latest 2015-01-02 04:14 build? If so, how did you get Link to have a sword? At least with the SSE41 build I start with no sword and tons of ocarinas.
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core starting to come together!

Post by MarathonMan » Fri Jan 02, 2015 4:07 pm

darkszero wrote:The screenshots I posted before (http://imgur.com/a/4NJ4v#1 and http://i.imgur.com/c5wz10Z.png) are from my i5-3570K @ 3.4GHz (and 3.8 GHz turbo boost?) running on Windows 7.

Tried building cen64 from URL with mingw, but got the following error:

[ 45%] Building ASM-ATT object CMakeFiles/cen64arch.dir/arch/x86_64/rsp/gcc/vabs.s.obj
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s: Assembler messages:
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:27: Warning: .type pseudo-op used outside of .def/.endef ignored.
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:27: Error: junk at end of line, first unrecognized character is `R'
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:61: Warning: .size pseudo-op used outside of .def/.endef ignored.
D:\programming\projects\cen64\arch\x86_64\rsp\gcc\vabs.s:61: Error: junk at end of line, first unrecognized character is `R'
CMakeFiles\cen64arch.dir\build.make:53: recipe for target 'CMakeFiles/cen64arch.dir/arch/x86_64/rsp/gcc/vabs.s.obj' failed
Yes, so... here's the way krom did it (his directions). There's a much easier way, but it may be what's causing the low performance. So if you don't mind:
krom wrote:Hi MM,

Here is how I compile cen64 latest build:

1. edit CMakeLists.txt
and replace the line:

Code: Select all

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse4")
with this:

Code: Select all

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse4 -O3 -flto -flto-partition=none -fdata-sections -ffunction-sections -march=native")
2. I use cmake-gui, and tick the options: sse 4.1 & busy wait detection

3. Also my msys/mingw64 setup complains on the RSP arch .s files, here is how I fix up arch/x86_64/rsp/gcc/vabs.s
(I need todo this to all .s files in this dir)

Code: Select all

//
// arch/x86_64/rsp/gcc/vabs.s
//
// CEN64: Cycle-Accurate Nintendo 64 Simulator.
// Copyright (C) 2014, Tyler J. Stachecki.
//
// This file is subject to the terms and conditions defined in
// 'LICENSE', which is part of this source code package.
//

.include "rsp/gcc/defs.h"

.text

//.ifdef __MINGW__
.globl RSP_VABS
//.def RSP_VABS; .scl 2; .type 32; .endef
//.seh_proc RSP_VABS
//.ifndef __VECTORCALL__
RSP_VABS:
  movdqa (%r8), %xmm0
  movdqa (%r9), %xmm1
  pxor %xmm2, %xmm2
//.endif
//.else
//.global RSP_VABS
//.type	RSP_VABS, @function
//RSP_VABS:
//.endif

.ifdef __AVX__
  vpsraw $0xf, %xmm1, %xmm3
  vpsignw %xmm1, %xmm0, %xmm5
  vpaddw %xmm3, %xmm5, %xmm2
  vpsubsw %xmm3, %xmm2, %xmm0
  retq

.elseif __SSSE3__ == 1
  psignw %xmm1, %xmm0
  psraw $0xF, %xmm1
  movdqa %xmm0, %xmm5
  paddw %xmm1, %xmm0
  psubsw %xmm1, %xmm0
  retq

.else
  pcmpeqw %xmm1, %xmm2
  psraw $0xF, %xmm1
  pandn %xmm0, %xmm2
  pxor %xmm1, %xmm2
  movdqa %xmm2, acc_lo
  psubsw %xmm1, %xmm2
  psubw %xmm1, acc_lo
  movdqa %xmm2, %xmm0
  retq
.endif

//.ifdef __MINGW__
//.seh_endproc
//.else
//.size RSP_VABS,.-RSP_VABS
//.endif
Hope this helps =D
Snowstorm64 wrote:
Narann wrote:IIRC, Kirby "dark" effect use RDP combiner's noise.

Some games use Combiner noise noise for various effects. See the end of this chapter for more explanations.

IIRC, the N64 use a analog filter to "smooth" the dither effect (something you don't really want actually) while transforming the numerical signal to analog (composite).

From my perspective, the "noisy" image is more accurate than the second one.

Any RDP expert could confirm this?
MarathonMan wrote:The aura will likely be smoothed out with the VI filters once they're enabled, too, remember... I think that might be right!
So the aura is rendered correctly as it is in the framebuffer, and then smoothed as one player would see it on TV screen, right? I wonder if the VI filters will be restored back or not. :P
MarathonMan wrote:Right, so the image is definitely still wrong after the RSP fix. However, it turns out because of LTV/STV. If I comment out LTV/STV in the old core, Mario's cap becomes dimly lit just as in the current core (but the lighting looks "mostly" right, or at least very similar to the current core). So I will fix VMACF and then try to implement LTV/STV sometime in the future.
So, excluding LTV/STV, the RSP opcodes, that are still missing, are the following:
  • NOP
  • CTC2
  • VMACQ
  • VMACU
  • VMULQ
  • VRNDN
  • VRNDP
  • LFV
  • LHV
  • SFV
  • SHV
  • SWV
We know that VMACU is needed by some game like Hey You, Pikachu! or Animal Forest, but what are the others for?
Filters? Maybe eventually, not a priority issue by any means though.

I can't describe what they're used for because I've never extensively studied the ucodes. I just know what the instructions do.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest