Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Discuss emulation or program issues here.
Post Reply
User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by Nintendo Maniac 64 » Thu May 04, 2017 12:17 am

Back in 2016, I was able to run Cen64 without specifying any extras (saves, controllers, etc) just fine with the following simple command:

Code: Select all

cen64.exe pifdata.bin game.z64
But now when I try to do that with the newest Windows build (after renaming the EXE to "cen64.exe"), I get the following error:
error.png
error.png (3.32 KiB) Viewed 763 times

So what does this mean? Is AVX now required or something? (my Pentium G3258 does not support AVX)
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
Nacho
Posts: 66
Joined: Thu Nov 07, 2013 9:25 am

Re: Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by Nacho » Thu May 04, 2017 7:48 am

As I understand, CEN64 has been completely rewrite, taking an entirely different approach: It will take a source file, compile it an execute it.

With this aproach, a .z64 file has to be decompiled and compiled again for CEN64.

As far as I understand...
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: 302
Joined: Sun Oct 20, 2013 8:22 pm

Re: Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by Snowstorm64 » Thu May 04, 2017 8:58 am

CEN64 has just been re-written by scratch, with a new approach, and I believe, at this state, it won't boot anything.

Although, if you still need the old one, you can find it there: https://github.com/tj90241/cen64
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
ShadowFX
Posts: 86
Joined: Sat Oct 05, 2013 2:08 am
Location: The Netherlands

Re: Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by ShadowFX » Thu May 04, 2017 5:34 pm

I haven't yet discovered where the last Linux/Windows binary (pre-compiled) is located before the rewrite. I hope MM can comment on this.
"Change is inevitable; progress is optional"

OS: Windows 10
Specs: Intel Core i7-7700K @ 4.2GHz, 16GB DDR4-RAM, NVIDIA GeForce GTX 1080 Ti
Main build: AVX (official)

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

Re: Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by Nintendo Maniac 64 » Thu May 04, 2017 5:40 pm

ShadowFX wrote:
Thu May 04, 2017 5:34 pm
I haven't yet discovered where the last Linux/Windows binary (pre-compiled) is located before the rewrite. I hope MM can comment on this.
In the meantime I'm using the 2016-11-14 build from archive.org:
http://wayback.archive.org/web/20161114 ... cen64.com/
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
izy
Posts: 25
Joined: Tue Jun 02, 2015 11:34 am

Re: Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by izy » Thu May 04, 2017 7:55 pm

It seems cen64 is gonna be a compiler an operating system and at a some point in an undisclosed future also an emulator
At the moment it is in its first stage -- a compiler. If you want to see something from the current cen64 then you should cmake it with the debug flag in order to get some verbose outputs on exec. Binary .z64 files aren't valid inputs for the parser. At the moment you should try with text files. MarathonMan posted a couple of working demos time ago. It is an impressive work he has put himself into. It has been without a doubt done so far at the highest professional level possible. It is a giant project by itself - being a spare time project these are the things you know when you begin them and cannot know when they'll be over ... if ever :evil: No wonder cen64.exe pifdata.bin game.z64 doesn't work. Yet i wonder Windows does :twisted:

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

Re: Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by MarathonMan » Sun May 07, 2017 10:20 am

The Windows builds were broken in

Code: Select all

8d0e7bb627b91f4d592ebd2a7e3d87cf580cdb32

pi: add support for IS Viewer 64
When -is-viewer is passed on the command line, create an IS Viewer
object that intercepts writes at 0x13FF0000. This is used by Ocarina of
Time Master Quest Debug to log debug messages.

The messages are encoded in EUC-JP, so we bring in iconv to convert that
to UTF-8 so the messages can be printed to modern consoles.

Props to jrra (@jkbenaim) and spinout for reverse engineering the
interface and documenting it: http://wiki.spinout182.com/w/IS64
I have a buildbot for the "old builds" setup at https://github-buildbot.cen64.com, but until somebody fixes it, it won't do much good.

User avatar
izy
Posts: 25
Joined: Tue Jun 02, 2015 11:34 am

Re: Are the recent 2017 Windows builds broken? Or is AVX now required or something?

Post by izy » Sun May 07, 2017 9:38 pm

In Windows you could avoid to create a new dependency on iconv for the old cen64 (also the call to iconv_close is nowhere to be seen). It is easier to add an exception... include windows.h, add a few #ifdef _WIN32 and just call MultiByteToWideChar to make the conversion. It is straightforward after having read the docs and found out the proper "code page identifier" -- i see in the list two identifiers for EUC-JP. The WinAPI-function will write the output to an array of WideChars. They should be an alias for wchar_t* and were basically plain UCS-2 characters, then turned into stricter UTF-16 characters after the standardization process. If you really need a new UTF-8 string then you should also call WideCharToMultiByte to convert it back to utf or anything. If you only need to print the string (it seems so) it is much easier to call printf with the proper identifier for wide strings printf("%S", L"widechar"), printf("%ls", L"longchar") or whatever the used libc wants. So that a second conversion won't be needed. Now somebody knows how to fix it.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest