New core/version 0.3

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

Re: New core/version 0.3

Post by MarathonMan » Sun Aug 24, 2014 9:47 pm

Ahhh... that's because I made a careless mistake out of excitement. Both now boot and work. ;)

EDIT: I think a variation of this bug still lives... I need to spend more time looking into it.

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

Re: New core/version 0.3

Post by MarathonMan » Mon Aug 25, 2014 2:02 am

Committed a ton of changes to cen64-backport to hopefully help with some TLB stuff. Star Wars: Battle for Naboo seems to be almost taking off, according to debug output. A couple ROMs still spam seemingly legitimate virtual addresses and keep jumping to the TLB exception handlers; not sure what that's about yet.

EDIT: Interesting, seems to be (possibly?) audio-related. Wonder how many other ROMs are suffering from that.

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Mon Aug 25, 2014 4:32 am

Did some tests, loads of games are showing stuff now =D
I think I should mention that Fire Demo by Lac (PD) seems to be showing a small refresh bug in the top part of the screen, compared to the perfect screen updates in previous builds...
MarathonMan wrote:EDIT: Interesting, seems to be (possibly?) audio-related. Wonder how many other ROMs are suffering from that.
Dunno if it related to this specific game, but lots of games give a black screen on bootup (on real hardware), if they use internal cartridge SRAM and the game code reports none or the wrong size of SRAM it was expecting.
Adding internal cartridge SRAM emulation into the new cen64 might get alot of black screen games to run =D

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

Re: New core/version 0.3

Post by Snowstorm64 » Mon Aug 25, 2014 7:05 am

Also Gauntlet Legends, Castlevania, Turok 2/3 and Perfect Dark! :D Mario Golf now works correctly! I think we can assert that the new core has a higher compatibility than the old one, but we need to check with controller support. :)
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/version 0.3

Post by MarathonMan » Mon Aug 25, 2014 8:05 am

krom wrote:Did some tests, loads of games are showing stuff now =D
I think I should mention that Fire Demo by Lac (PD) seems to be showing a small refresh bug in the top part of the screen, compared to the perfect screen updates in previous builds...
MarathonMan wrote:EDIT: Interesting, seems to be (possibly?) audio-related. Wonder how many other ROMs are suffering from that.
Dunno if it related to this specific game, but lots of games give a black screen on bootup (on real hardware), if they use internal cartridge SRAM and the game code reports none or the wrong size of SRAM it was expecting.
Adding internal cartridge SRAM emulation into the new cen64 might get alot of black screen games to run =D
I thought the refresh bug had returned for quite a while... could be a couple things. I'll look into it.

Hmmm... very interesting observation about the SRAM emulation. Do you have any particular carts that demonstrate this behaviour that I can debug with?
Snowstorm64 wrote:with controller support. :)
Yeah that's been a cloud looming over my head... I'll try to at least get keyboard stuff going.

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

Re: New core/version 0.3

Post by Snowstorm64 » Mon Aug 25, 2014 8:27 am

MarathonMan wrote: I thought the refresh bug had returned for quite a while... could be a couple things. I'll look into it.

Hmmm... very interesting observation about the SRAM emulation. Do you have any particular carts that demonstrate this behaviour that I can debug with?
OoT, Super Smash Bros, Harvest Moon64, Mario Golf, all of them use SRAM and they work without problems...
MarathonMan wrote:
Yeah that's been a cloud looming over my head... I'll try to at least get keyboard stuff going.
Yeah, I think at least basic controls (keyboard) are needed, for now. One question: Assuming you don't want to use layer libraries or something of similar (e.g. SDL & GLFW), are you planning to read raw dev or use udev in order for gamepads to work on Linux? Then, I'd suggest to check Higan's own implementation of it. ;)
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/version 0.3

Post by MarathonMan » Mon Aug 25, 2014 9:09 am

Snowstorm64 wrote:Yeah, I think at least basic controls (keyboard) are needed, for now. One question: Assuming you don't want to use layer libraries or something of similar (e.g. SDL & GLFW), are you planning to read raw dev or use udev in order for gamepads to work on Linux? Then, I'd suggest to check Higan's own implementation of it. ;)
I'll use low-level libraries -- udev, XInput, etc.

I would, but it's GPL, so I can't... tell Stallman that you don't like viral software licensing. :(

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

Re: New core/version 0.3

Post by Narann » Mon Aug 25, 2014 9:24 am

MarathonMan wrote:I would, but it's GPL, so I can't... tell Stallman that you don't like viral software licensing. :(
Just a question: What motivate the choose of a permissive licence for Cen64.
For me, permissive licence are for technology that could be shared between other companies for a business perspective and restrictive licence (like GPL) is what you would choose for a project like Cen64.

I'm just curious.

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

Re: New core/version 0.3

Post by Snowstorm64 » Mon Aug 25, 2014 9:30 am

I didn't mean to tell you to take code directly by Higan, I wanted to say that you can have an idea of how it works and take inspiration of it. Or you can ask directly the author.

(I personally like GPL license more than 3-clause BSD and I think there's nothing wrong with GPL's viral licensing, but...de gustibus non est disputandum :P )

@Narann: CEN64 was GPL'ed previously, but it was relicensed to 3-clause BSD. The more you know. EDIT: Oops, I was wrong, CEN64 never had GPL license, it was only considered. My bad!
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/version 0.3

Post by MarathonMan » Mon Aug 25, 2014 11:27 am

Snowstorm64 wrote:@Narann: CEN64 was GPL'ed previously, but it was relicensed to 3-clause BSD. The more you know. EDIT: Oops, I was wrong, CEN64 never had GPL license, it was only considered. My bad!
Nope; you were correct. A very, very, very early version of CEN64 was indeed GPL'd.
Narann wrote:For me, permissive licence are for technology that could be shared between other companies for a business perspective and restrictive licence (like GPL) is what you would choose for a project like Cen64.

I'm just curious.
As a developer, it's incredibly irritating when you're like... oh here's a nice libr-oh, it's not compatible with the GPL, and my binary is GPL, so I can't link against it. Woe is me.

Nobody in the emulation community seems to actually enforce the GPL anyways. Purchase and ask the authors of Mupen64Plus AE and N64oid for source code and I'll be amazed if both comply. But the thing is, they're both forks of Mupen64Plus, which is GPLv2, so they're legally bound to releasing code.

Oh, and Project64?
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL.
The GPL is a virus in obfuscated text form, complete with a resistance is futile mentality. :lol:

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

Re: New core/version 0.3

Post by Narann » Mon Aug 25, 2014 12:03 pm

MarathonMan wrote:As a developer, it's incredibly irritating when you're like... oh here's a nice libr-oh, it's not compatible with the GPL, and my binary is GPL, so I can't link against it. Woe is me.
I didn't get you example. Most of the time it's the invert: You are writting non GPL code and want to use GPL libs. Any example?
MarathonMan wrote:Nobody in the emulation community seems to actually enforce the GPL anyways. Purchase and ask the authors of Mupen64Plus AE and N64oid for source code and I'll be amazed if both comply. But the thing is, they're both forks of Mupen64Plus, which is GPLv2, so they're legally bound to releasing code.
I don't get that too. mupen64plus-ae repo is here. And N64oid is illegal.
MarathonMan wrote:Oh, and Project64?
I don't get it. ASAIK Project64 has never used GPL stuff.

Anyway, the fact nobody care about licence stuff in N64 emu scene doesn't mean their right. :)
MarathonMan wrote:
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL.
The GPL is a virus in obfuscated text form, complete with a resistance is futile mentality. :lol:
This is what LGPL is supposed to solve.

LGPL mean you do a GPL library that can be dynamically linked to closed source program (or lib).

I must admit I didn't get all your points MarathonMan. ^^'

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

Re: New core/version 0.3

Post by Snowstorm64 » Mon Aug 25, 2014 12:42 pm

MarathonMan wrote:
Nope; you were correct. A very, very, very early version of CEN64 was indeed GPL'd.
Then I remembered well, just I wasn't sure of it.
MarathonMan wrote:
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL.
The GPL is a virus in obfuscated text form, complete with a resistance is futile mentality. :lol:
While I didn't really want to join in this interesting topic, as I'm not really into legal stuff, but I want to say one thing: It doesn't necessarily require that the main program or the plugin has to be under GPL along with the other one in order to redistribute the binaries, just that the license has to be compatible with GPL, one example is the 3-clause BSD. Otherwise, you can redistribute separated files (e.g. Mupen64plus's binaries in one .zip file, and a proprietary plugin in one another .zip file. Just like ZFS and Linux, they cannot be distributed or be linked together, but ZFS can be a separate module and be loaded into kernel).
MarathonMan wrote: As a developer, it's incredibly irritating when you're like... oh here's a nice libr-oh, it's not compatible with the GPL, and my binary is GPL, so I can't link against it. Woe is me.
It depends on case by case basis. For example, do you intend to use proprietary system license? You can, without hassle. And what if is it not system-wide? You can too, simply you have to write an additional clause in the license to add an exception for it. In fact the only case that prevents you to use any proprietary non-system library is that you use a fork of others software and you don't hold copyright of it, and therefore you cannot add that exception in the license.
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/version 0.3

Post by MarathonMan » Mon Aug 25, 2014 2:34 pm

Narann wrote:I don't get that too. mupen64plus-ae repo is here. And N64oid is illegal.
Ah, good on Paul then. As for N64oid, people are still buying it, it's still for sale, etc... the license isn't being enforced!
Narann wrote:
MarathonMan wrote:Oh, and Project64?
I don't get it. ASAIK Project64 has never used GPL stuff.
PJ64 is GPL'd now... :o
Narann wrote:This is what LGPL is supposed to solve.

LGPL mean you do a GPL library that can be dynamically linked to closed source program (or lib).
Isn't this contingent upon the author releasing their plugin under LGPL? Who's to say they are going to, or want to, do that?

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

Re: New core/version 0.3

Post by MarathonMan » Mon Aug 25, 2014 2:39 pm

Snowstorm64 wrote:While I didn't really want to join in this interesting topic, as I'm not really into legal stuff, but I want to say one thing: It doesn't necessarily require that the main program or the plugin has to be under GPL along with the other one in order to redistribute the binaries, just that the license has to be compatible with GPL, one example is the 3-clause BSD. Otherwise, you can redistribute separated files (e.g. Mupen64plus's binaries in one .zip file, and a proprietary plugin in one another .zip file. Just like ZFS and Linux, they cannot be distributed or be linked together, but ZFS can be a separate module and be loaded into kernel).
That, I didn't know. Is that why they distribute them separately then?
Snowstorm64 wrote:It depends on case by case basis. For example, do you intend to use proprietary system license? You can, without hassle. And what if is it not system-wide? You can too, simply you have to write an additional clause in the license to add an exception for it. In fact the only case that prevents you to use any proprietary non-system library is that you use a fork of others software and you don't hold copyright of it, and therefore you cannot add that exception in the license.
I didn't know that either. Still, irritating to make exceptions for everything.

The only motivation I'd have for switching the CEN64 license to GPL is if somebody is withholding commits and making serious progress. Otherwise, I think the BSD license is "more free" in the sense that it's both concise and lets you link and whatnot as you please -- no exceptions, no mess, no worries. I can read the license without having a headache!

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Mon Aug 25, 2014 3:06 pm

MarathonMan wrote:Hmmm... very interesting observation about the SRAM emulation. Do you have any particular carts that demonstrate this behavior that I can debug with?
Yeah sure:
Doraemon 3 - Nobita no Machi SOS! (J) - Gives a black screen on real hardware if the save type is not set to exactly EEPROM 16Kbit in size.
If it is any lower, it gives a black screen, if it is any higher it gives a black screen.

You can test this for yourself easily by using the 64drive:
1. Select the game Doraemon 3 - Nobita no Machi SOS! (J) in the 64drive Menu
2. You will see 4 options for internal cartridge EEPROM Save RAM Size which you can force the game to run with (4Kbit, 16Kbit, 256Kbit, 1Mbit)
3. Selecting 4Kbit, 256Kbit, 1Mbit will result in a black screen on real hardware, only selecting 16Kbit will run the game.

Cen64 currently shows a black screen for this game, so my hypothesis is that if we program in EEPROM save support & force it to be only 16Kbit in size this game might boot for the 1st time.
Snowstorm64 wrote:OoT, Super Smash Bros, Harvest Moon64, Mario Golf, all of them use SRAM and they work without problems...
Yes you are totally correct, and I tested all these exact games you have stated on hardware in the same way as I have shown above, with all the different EEPROM save sizes, & every combination still booted these games on hardware.
This Doraemon 3 EEPROM save size type is surely an example of cartridge piracy protection, as I think the programmers have done a check on the EEPROM save size on boot up, & crash the system to a black screen if it is not exactly 16Kbit in size.

I also think the 64drive itself has a database stored inside it's menu system that statically stores the correct EEPROM save size settings for all the N64 games, to make problem games like this boot.
You need to keep up-to-date with the newest menu.bin file for the database to be correct as it keeps getting updated with new fixes.

It is also my hypothesis that we will need such a database for cen64 to boot every game out of box, without having to specify the EEPROM save size at the command line...
I would be happy to do the horse-work for you if you want this MarathonMan =D
Also in making this database, I would also find out which games use this style of piracy detection...

I would be happy to make some bespoke N64 tests using SRAM, and showing how to count the size of the EEPROM save ram on hardware, to make sure that we have emulated the different EEPROM save sizes correctly in cen64.

Hope this clears everything up for people, this is all my knowledge on EEPROM save chips on the N64, if anyone else has something to add I would love to know your thoughts on the subject =D
Last edited by krom on Mon Aug 25, 2014 3:33 pm, edited 4 times in total.

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

Re: New core/version 0.3

Post by Narann » Mon Aug 25, 2014 3:12 pm

MarathonMan wrote:As for N64oid, people are still buying it, it's still for sale, etc... the license isn't being enforced!
No, and that's why N64oid is illegal. :)
MarathonMan wrote:Isn't this contingent upon the author releasing their plugin under LGPL? Who's to say they are going to, or want to, do that?
I don't get this. If somebody want to create a library that could be dynamically linked to closed software but want to keep the library code under GPL, he put the lib under LGPL. This avoid to statically link the lib and so, avoid the "virality" of the GPL. Most "commercial licences" of Libre software are based on this. The commercial licence allow statically linking without have to "suffer" from the GPL virality. Qt and Intel TBB use such approach.
MarathonMan wrote:The only motivation I'd have for switching the CEN64 license to GPL is if somebody is withholding commits and making serious progress. Otherwise, I think the BSD license is "more free" in the sense that it's both concise and lets you link and whatnot as you please -- no exceptions, no mess, no worries. I can read the license without having a headache!
I agree, but one of the lack of such licence is that Cen64 can be improved (never commit back of course) and shipped in any closed source build and it's perfectly legal.

For "research" code or libraries shared between multiple business companies MIT and BSD has sense. But in the case of Cen64, I don't see any benefit to have a permissive licence except you will see a lot of "New pay or free with ads accurate N64 emulator" with no credit to anyone. And this will be legal.

It's your code so do what you want. :) I'm not a religious about Libre software. I just consider GPL valid if you want to keep your code a kind of "Do what you want but you must open it or it's illegal".

A good example is Wine. Initially, Wine where released under MIT licence but it bring to a lot of proprietary payable forks that improve it and never commit back to the project, leaving Wine without improvement.

This example is often taken as cons of permissive licence.

The reason why GPL seems complex it's because it try to protect the code to be closed. Permissive licences are far less complicated but it let everybody (specially peoples that want to do business with the code) to do anything with it.

It's up to you again. But when I see how it's hard to get the GPL respected, a permissive licence will be a golden choice for peoples that will sell .zip files with renamed and credit-removed builds in it. GPL try to make this practice illegal.

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

Re: New core/version 0.3

Post by Snowstorm64 » Mon Aug 25, 2014 4:39 pm

MarathonMan wrote: That, I didn't know. Is that why they distribute them separately then?
To be fair, it was just an example, I'm not sure if is that the reason for it, as the official release includes only two GPL'd video plugin and there are plenty of video plugins left out. Anyway... a better example: You want to fork Mupen64plus (GPLv2) and create your own emulator based on it and you write your own video plugin that is the most awesome N64 video plugin ever made, but that it is proprietary as you don't want to share with the world your discoveries and you might want to make profit with it. So that means, you cannot upload a bundle with the fork's binaries and the proprietary video plugin, as GPL states that when you ship the binaries, you must release the entire source code along with it, which means that you must also release source code of the proprietary plugin. But there's a loophole that allows you to redistribute anyways the proprietary plugin: just ship it standalone and you are done. This is not the case of N64oid, because it is not feasible on Android this way, and they decided to sell it bundled anyways, violating the license. That's a shame...However they did released the source code of their emulator without the video plugin.
MarathonMan wrote: I didn't know that either. Still, irritating to make exceptions for everything.

The only motivation I'd have for switching the CEN64 license to GPL is if somebody is withholding commits and making serious progress. Otherwise, I think the BSD license is "more free" in the sense that it's both concise and lets you link and whatnot as you please -- no exceptions, no mess, no worries. I can read the license without having a headache!
Yes, the 3-clause BSD license is very simple to read, but it doesn't offer enough guarantees for copyright holder if compared to GPL, IMHO. Basically, you give away months of hard work, someone decides to fork it under EULA, improves the code and sell it on market, and makes profit. And in return maybe you receive something useful from it like money or improvements, maybe you receive nothing from it, and the community wouldn't benefit anything from this, and you wouldn't do nothing about it because it's perfectly legal. This is infuriating and that is why I like GPL more than BSD License. However, you hold the copyright on CEN64's code, it's up to you. You decide that CEN64 is licensed under 3-clause BSD, and I respect your decision. ;)
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

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

Re: New core/version 0.3

Post by Snowstorm64 » Mon Aug 25, 2014 4:46 pm

krom wrote:...
Oh, that's why, I didn't think of piracy protections, this would explain everything. As for the database, this is a great idea! Expect a PM from me soon about this. ;)
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

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

Re: New core/version 0.3

Post by Ambient_Malice » Mon Aug 25, 2014 9:30 pm

I cannot for the life of me figure out how to compile this build. Can someone advise me, or at least link to a guide? I'm using Github\Git Shell with TDM-GCC, and managed to clone to my HDD from the git repository. But I hit a brick wall when trying to compile.

The guides for pre-0.3 builds talk about necessary binary files. But the relevant link is dead.

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Mon Aug 25, 2014 10:20 pm

Ambient_Malice wrote:I cannot for the life of me figure out how to compile this build. Can someone advise me, or at least link to a guide? I'm using Github\Git Shell with Mingw-w64, and managed to clone to my HDD from the git repository. But I hit a brick wall when trying to compile.
Hi Ambient_Malice try following my new guide for compilation on Mingw-w64 / Msys Shell without cmake, which should work for you on your Mingw-w64 / Git Shell:

1. Get a fresh clean cen64-backport source from github
2. Copy the common.h.in file to a file called common.h
3. Edit the new common.h file and convert the 2 cmakedefine options to normal define options, at the end of the file it should look like this:

Code: Select all

//#define DEBUG_MMIO_REGISTER_ACCESS
#ifdef DEBUG_MMIO_REGISTER_ACCESS
#ifndef __cplusplus
#include <stdio.h>
#else
#include <cstdio>
#endif
#define debug_mmio_read(what, mnemonic, val) printf(#what": READ [%s]: 0x%.8X\n", mnemonic, val)
#define debug_mmio_write(what, mnemonic, val, dqm) printf(#what": WRITE [%s]: 0x%.8X/0x%.8X\n", mnemonic, val, dqm)
#else
#define debug_mmio_read(what, mnemonic, val) do {} while (0)
#define debug_mmio_write(what, mnemonic, val, dqm) do {} while (0)
#endif

#define VR4300_BUSY_WAIT_DETECTION
4. Create a new makefile text file in the same directory, copy & paste this into it:

Code: Select all

cen64 : cen64.c
	gcc -o cen64 *.c ai/*.c arch/x86_64/rsp/*.c arch/x86_64/tlb/*.c bus/*.c common/*.c os/windows/*.c pi/*.c rdp/*.c ri/*.c rsp/*.c si/*.c vi/*.c vr4300/*.c -O3 -s -DNDEBUG -I. -I"./os/unix/x86_64" -I"./arch/x86_64" -flto -flto-partition=none -fdata-sections -ffunction-sections -std=c99 -march=native -mwindows -lopengl32 -lws2_32 -lwinmm
5. Now type make, & (fingers crossed) you should have a fresh Windows 64-bit build of cen64 =D

Hope this helps you out.

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

Re: New core/version 0.3

Post by MarathonMan » Mon Aug 25, 2014 11:40 pm

krom: Thank you for being my Windows assistant all this time. :lol:

Tweaked RAC timings for DK64, got this:
https://www.youtube.com/watch?v=NxHFFEWVO18

Looking good. :D

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Tue Aug 26, 2014 12:11 am

MarathonMan wrote:Tweaked RAC timings for DK64, got this:
https://www.youtube.com/watch?v=NxHFFEWVO18
Looks really great, amazing work MarathonMan =D

Also I saw you mention a while back, that you were thinking of maybe using the keyboard to start implementing the N64 joystick input without having to worry about which Linux/Windows joystick drivers to use atm...
I really think this is a good way to go, as keyboard input is quite simple compared to a joystick input setup =D

P.S Did you see my post about the save stuff, a few posts back, it was easy to miss!

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

Re: New core/version 0.3

Post by MarathonMan » Tue Aug 26, 2014 12:27 am

krom wrote:P.S Did you see my post about the save stuff, a few posts back, it was easy to miss!
Yep, sorry I never responded to that, got a lot going on.

Probably, some kind of ROM database for CEN64 is inevitable. Checksums (goodn64 matched) and other kinds of data that cannot be deduced from the ROM header (save type, save size) are not only helpful, but mandatory in some cases as you mentioned.

I propose that the best approach to this is to open a new thread to discuss the fields within a database that is distributed with the CEN64 binary. :?:

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Tue Aug 26, 2014 12:41 am

MarathonMan wrote:Yep, sorry I never responded to that, got a lot going on.
No probs, I just wanted to see if you had read it...
MarathonMan wrote:I propose that the best approach to this is to open a new thread to discuss the fields within a database that is distributed with the CEN64 binary.
Yep sounds good to me, great idea =D

**EDIT**
I have just released my Plot Fill Triangle demos on github:
https://github.com/PeterLemon/N64/tree/ ... gle320x240
https://github.com/PeterLemon/N64/tree/ ... gle320x240
This is a significant milestone, as these demos use the N64 floating point CP1 to display a triangle from an unsorted set of floating point X,Y triangle coordinates.
All my previous demos used python scripts to generate the triangle data for my tests, but this is a hard coded assembly version of these python algorithms for the Left & Right Major N64 Triangles.

I have tested lots of negative and positive X & Y coordinate triangles, and all display perfectly clipped by the screen space =D
And of course all triangles within the screen space display perfectly too!

It will be really easy for me to make a quick matrix multiplication with a static cos/sin rotation table, to get a triangle rotating on the screen, which will be my next demo hopefully =D

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

Re: New core/version 0.3

Post by ShadowFX » Tue Aug 26, 2014 3:29 am

MarathonMan wrote:Tweaked RAC timings for DK64, got this:
https://www.youtube.com/watch?v=NxHFFEWVO18

Looking good. :D
That so badly needs a beat ;)
Looking good indeed, apart from some flickering at the end, but I'm sure you're not done yet!
"Change is inevitable; progress is optional"

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

User avatar
Sintendo
Posts: 25
Joined: Thu Oct 31, 2013 9:11 am

Re: New core/version 0.3

Post by Sintendo » Tue Aug 26, 2014 6:26 am

What kind of hardware is that running on?

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

Re: New core/version 0.3

Post by Snowstorm64 » Tue Aug 26, 2014 9:49 am

MarathonMan wrote:krom: Thank you for being my Windows assistant all this time. :lol:

Tweaked RAC timings for DK64, got this:
https://www.youtube.com/watch?v=NxHFFEWVO18

Looking good. :D
Indeed! This new core is getting better and better... :D
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/version 0.3

Post by MarathonMan » Tue Aug 26, 2014 10:02 am

Sintendo wrote:What kind of hardware is that running on?
i7-4700k.

User avatar
juef
Posts: 31
Joined: Sun Oct 27, 2013 10:19 pm

Re: New core/version 0.3

Post by juef » Tue Aug 26, 2014 6:57 pm

I keep getting impressed everytime I read this thread! :D Thank you everyone, especially MarathonMan of course! Keep it up!!

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

Re: New core/version 0.3

Post by Ambient_Malice » Wed Aug 27, 2014 2:47 am

krom wrote:
Ambient_Malice wrote:I cannot for the life of me figure out how to compile this build. Can someone advise me, or at least link to a guide? I'm using Github\Git Shell with Mingw-w64, and managed to clone to my HDD from the git repository. But I hit a brick wall when trying to compile.
Hi Ambient_Malice try following my new guide for compilation on Mingw-w64 / Msys Shell without cmake, which should work for you on your Mingw-w64 / Git Shell:

1. Get a fresh clean cen64-backport source from github
2. Copy the common.h.in file to a file called common.h
3. Edit the new common.h file and convert the 2 cmakedefine options to normal define options, at the end of the file it should look like this:

Code: Select all

//#define DEBUG_MMIO_REGISTER_ACCESS
#ifdef DEBUG_MMIO_REGISTER_ACCESS
#ifndef __cplusplus
#include <stdio.h>
#else
#include <cstdio>
#endif
#define debug_mmio_read(what, mnemonic, val) printf(#what": READ [%s]: 0x%.8X\n", mnemonic, val)
#define debug_mmio_write(what, mnemonic, val, dqm) printf(#what": WRITE [%s]: 0x%.8X/0x%.8X\n", mnemonic, val, dqm)
#else
#define debug_mmio_read(what, mnemonic, val) do {} while (0)
#define debug_mmio_write(what, mnemonic, val, dqm) do {} while (0)
#endif

#define VR4300_BUSY_WAIT_DETECTION
4. Create a new makefile text file in the same directory, copy & paste this into it:

Code: Select all

cen64 : cen64.c
	gcc -o cen64 *.c ai/*.c arch/x86_64/rsp/*.c arch/x86_64/tlb/*.c bus/*.c common/*.c os/windows/*.c pi/*.c rdp/*.c ri/*.c rsp/*.c si/*.c vi/*.c vr4300/*.c -O3 -s -DNDEBUG -I. -I"./os/unix/x86_64" -I"./arch/x86_64" -flto -flto-partition=none -fdata-sections -ffunction-sections -std=c99 -march=native -mwindows -lopengl32 -lws2_32 -lwinmm
5. Now type make, & (fingers crossed) you should have a fresh Windows 64-bit build of cen64 =D

Hope this helps you out.
Unfortunately, still having problems.

Firstly, the makefile code didn't seem to work when pasted. (I think the forum converted TAB to spaces for some reason.) I tried removing the spaces and adding a TAB space to the start of the second line, and proceeded to get a list or errors along these lines (58KB or errors when logged with 2>>log.txt, so not good.):


In file included from ./arch/x86_64/fpu/fpu.h:39:0,
from ./os/unix/x86_64/fpu/fpu.h:15,
from ./vr4300/cp1.h:14,
from ./vr4300/cpu.h:15,
from vr4300/pipeline.c:14:
./arch/x86_64/fpu/cvt_f64_i64.h: In function 'fpu_cvt_f64_i64':
./arch/x86_64/fpu/cvt_f64_i64.h:17:3: warning: implicit declaration of function '_mm_cvtsi64_sd' [-Wimplicit-function-declaration]
fd_reg = _mm_cvtsi64_sd(fd_reg, *fs);
^
./arch/x86_64/fpu/cvt_f64_i64.h:17:10: error: incompatible types when assigning to type '__m128d' from type 'int'
fd_reg = _mm_cvtsi64_sd(fd_reg, *fs);
^
In file included from ./arch/x86_64/fpu/fpu.h:42:0,
from ./os/unix/x86_64/fpu/fpu.h:15,
from ./vr4300/cp1.h:14,
from ./vr4300/cpu.h:15,
from vr4300/pipeline.c:14:
./arch/x86_64/fpu/cvt_i64_f32.h: In function 'fpu_cvt_i64_f32':
./arch/x86_64/fpu/cvt_i64_f32.h:20:3: warning: implicit declaration of function '_mm_cvtss_si64' [-Wimplicit-function-declaration]
*fd = _mm_cvtss_si64(fs_reg);
^
In file included from ./arch/x86_64/fpu/fpu.h:43:0,
from ./os/unix/x86_64/fpu/fpu.h:15,
from ./vr4300/cp1.h:14,
from ./vr4300/cpu.h:15,
from vr4300/pipeline.c:14:
./arch/x86_64/fpu/cvt_i64_f64.h: In function 'fpu_cvt_i64_f64':
./arch/x86_64/fpu/cvt_i64_f64.h:20:3: warning: implicit declaration of function '_mm_cvtsd_si64' [-Wimplicit-function-declaration]
*fd = _mm_cvtsd_si64(fs_reg);
^
In file included from ./arch/x86_64/fpu/fpu.h:56:0,
from ./os/unix/x86_64/fpu/fpu.h:15,
from ./vr4300/cp1.h:14,
from ./vr4300/cpu.h:15,
from vr4300/pipeline.c:14:
./arch/x86_64/fpu/trunc_i64_f32.h: In function 'fpu_trunc_i64_f32':
./arch/x86_64/fpu/trunc_i64_f32.h:20:3: warning: implicit declaration of function '_mm_cvttss_si64' [-Wimplicit-function-declaration]
*fd = _mm_cvttss_si64(fs_reg);
^
In file included from ./arch/x86_64/fpu/fpu.h:57:0,
from ./os/unix/x86_64/fpu/fpu.h:15,
from ./vr4300/cp1.h:14,
from ./vr4300/cpu.h:15,
from vr4300/pipeline.c:14:
./arch/x86_64/fpu/trunc_i64_f64.h: In function 'fpu_trunc_i64_f64':
./arch/x86_64/fpu/trunc_i64_f64.h:20:3: warning: implicit declaration of function '_mm_cvttsd_si64' [-Wimplicit-function-declaration]
*fd = _mm_cvttsd_si64(fs_reg);
^
make: *** [cen64] Error 1

I'm using "make" from MSYS, with the cen64 source code in C:\Cen64, since I was concerned about spaces in the file names. Is it possible I messed up with 64 vs 32 bit MinGW?

User avatar
teres
Posts: 19
Joined: Fri Apr 11, 2014 9:44 am

Re: New core/version 0.3

Post by teres » Wed Aug 27, 2014 7:32 am

Ah, that's the fun part of public repo access (as opposed to occasional tarball drops) - they're a (sometimes extremely fast-)moving target. What works today might not work tomorrow. Or the other way round - update your source tree, maybe it's been fixed already. Anyway, in case it isn't:
Ambient_Malice wrote:./arch/x86_64/fpu/cvt_f64_i64.h:17:3: warning: implicit declaration of function '_mm_cvtsi64_sd' [-Wimplicit-function-declaration]
That's the error you care about, the rest are just followups to that.
You're missing a function declaration. Either look up the implementation of '_mm_cvtsi64_sd' and provide a prototype for it where needed, or see if there's already a header that has the prototype and include that.

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Wed Aug 27, 2014 7:39 am

Ambient_Malice wrote:Firstly, the makefile code didn't seem to work when pasted. (I think the forum converted TAB to spaces for some reason.
Yep you are right the forum did convert the second line tab to spaces, sorry about that :(
Ambient_Malice wrote:Is it possible I messed up with 64 vs 32 bit MinGW?
This could be the case sometimes mingw distributions come with both 32-bit & 64-bit varients, with 32-bit being the default...
I have a couple of ideas:

1. Try to find your "bin" directory e.g mingw\bin, if you have 64-bit Mingw GCC you might have a file called something like x86_64-w64-mingw32-gcc.exe.
If you do have a file that looks like this, try to replace the gcc part in the makefile, with the new filename like this:

Code: Select all

cen64 : cen64.c
	x86_64-w64-mingw32-gcc -o cen64 *.c ai/*.c arch/x86_64/rsp/*.c arch/x86_64/tlb/*.c bus/*.c common/*.c os/windows/*.c pi/*.c rdp/*.c ri/*.c rsp/*.c si/*.c vi/*.c vr4300/*.c -O3 -s -DNDEBUG -I. -I"./os/unix/x86_64" -I"./arch/x86_64" -flto -flto-partition=none -fdata-sections -ffunction-sections -std=c99 -march=native -mwindows -lopengl32 -lws2_32 -lwinmm
2. Type in your msys command line: gcc -v
If you can copy and paste the info from this into a forum post I will try & see what variation of GCC you are using.
If it is a Mingw 64-bit GCC, you should be able to see 64 dotted around the info it displays.

If you manage to get any further using the info above e.g different error messages, post them here & I'll try to see if I can help.
Otherwise, I think you might need a new Mingw GCC setup, I use a variant of mingw64 available from here: http://tdm-gcc.tdragon.net/

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

Re: New core/version 0.3

Post by MarathonMan » Wed Aug 27, 2014 10:01 am

Ambient_Malice wrote:./arch/x86_64/fpu/cvt_f64_i64.h:17:3: warning: implicit declaration of function '_mm_cvtsi64_sd' [-Wimplicit-function-declaration]
You need to ensure that your processor has SSE2. If it does, the -march=native flag should have taken care of things for you. Either way, try replacing -march=native with -msse2.

EDIT:
teres wrote:Ah, that's the fun part of public repo access (as opposed to occasional tarball drops) - they're a (sometimes extremely fast-)moving target. What works today might not work tomorrow. Or the other way round - update your source tree, maybe it's been fixed already.
To be fair... thanks to beannaich, MSVC builds are checked and status reported to me (and I never push a broken builds to master). If users aren't using the vanilla build system... they're asking for trouble. ;)

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

Re: New core/version 0.3

Post by Ambient_Malice » Wed Aug 27, 2014 9:35 pm

krom wrote:
Ambient_Malice wrote:Firstly, the makefile code didn't seem to work when pasted. (I think the forum converted TAB to spaces for some reason.
Yep you are right the forum did convert the second line tab to spaces, sorry about that :(
Ambient_Malice wrote:Is it possible I messed up with 64 vs 32 bit MinGW?
This could be the case sometimes mingw distributions come with both 32-bit & 64-bit varients, with 32-bit being the default...
I have a couple of ideas:

1. Try to find your "bin" directory e.g mingw\bin, if you have 64-bit Mingw GCC you might have a file called something like x86_64-w64-mingw32-gcc.exe.
If you do have a file that looks like this, try to replace the gcc part in the makefile, with the new filename like this:

Code: Select all

cen64 : cen64.c
	x86_64-w64-mingw32-gcc -o cen64 *.c ai/*.c arch/x86_64/rsp/*.c arch/x86_64/tlb/*.c bus/*.c common/*.c os/windows/*.c pi/*.c rdp/*.c ri/*.c rsp/*.c si/*.c vi/*.c vr4300/*.c -O3 -s -DNDEBUG -I. -I"./os/unix/x86_64" -I"./arch/x86_64" -flto -flto-partition=none -fdata-sections -ffunction-sections -std=c99 -march=native -mwindows -lopengl32 -lws2_32 -lwinmm
2. Type in your msys command line: gcc -v
If you can copy and paste the info from this into a forum post I will try & see what variation of GCC you are using.
If it is a Mingw 64-bit GCC, you should be able to see 64 dotted around the info it displays.

If you manage to get any further using the info above e.g different error messages, post them here & I'll try to see if I can help.
Otherwise, I think you might need a new Mingw GCC setup, I use a variant of mingw64 available from here: http://tdm-gcc.tdragon.net/
I'm now using TDM-GCC with MSYS (after adding the TDM-GCC directory to MSYS's fstab file.)

It now spits out the following errors while compiling.

os/windows/gl_window.c: In function 'create_gl_window':
os/windows/gl_window.c:105:20: warning: assignment from incompatible pointer type [enabled by default]
wc.lpszClassName = CLASSNAME;
^
os/windows/gl_window.c:120:5: warning: passing argument 2 of 'CreateWindowExA' from incompatible pointer type [enabled by default]
NULL, NULL, winapi_window->h_instance, NULL))) {
^
In file included from c:\tdm-gcc-64\x86_64-w64-mingw32\include\windows.h:72:0,
from ./os/gl_window.h:14,
from os/windows/gl_window.c:12:
c:\tdm-gcc-64\x86_64-w64-mingw32\include\winuser.h:1934:26: note: expected 'LPCSTR' but argument is of type 'const wchar_t *'
WINUSERAPI HWND WINAPI CreateWindowExA(DWORD dwExStyle,LPCSTR lpClassName,LPCSTR lpWindowName,DWORD dwStyle,int X,int Y,int nWidth,int nHeight,HWND hWndParent,HMENU hMenu,HINSTANCE hInstance,LPVOID lpParam);
^
os/windows/gl_window.c: In function 'destroy_gl_window':
os/windows/gl_window.c:178:5: warning: passing argument 1 of 'UnregisterClassA' from incompatible pointer type [enabled by default]
UnregisterClass(CLASSNAME, winapi_window->h_instance);
^
In file included from c:\tdm-gcc-64\x86_64-w64-mingw32\include\windows.h:72:0,
from ./os/gl_window.h:14,
from os/windows/gl_window.c:12:
c:\tdm-gcc-64\x86_64-w64-mingw32\include\winuser.h:1916:29: note: expected 'LPCSTR' but argument is of type 'const wchar_t *'
WINUSERAPI WINBOOL WINAPI UnregisterClassA(LPCSTR lpClassName,HINSTANCE hInstance);
^
os/windows/main.c: In function 'WinMain':
os/windows/main.c:24:7: warning: passing argument 2 of 'MessageBoxA' from incompatible pointer type [enabled by default]
MB_OK | MB_ICONEXCLAMATION);
^
In file included from c:\tdm-gcc-64\x86_64-w64-mingw32\include\windows.h:72:0,
from ./os/gl_window.h:14,
from ./vi/controller.h:14,
from ./device.h:21,
from os/windows/main.c:10:
c:\tdm-gcc-64\x86_64-w64-mingw32\include\winuser.h:3011:25: note: expected 'LPCSTR' but argument is of type 'short unsigned int *'
WINUSERAPI int WINAPI MessageBoxA(HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType);
^
os/windows/main.c:24:7: warning: passing argument 3 of 'MessageBoxA' from incompatible pointer type [enabled by default]
MB_OK | MB_ICONEXCLAMATION);
^
In file included from c:\tdm-gcc-64\x86_64-w64-mingw32\include\windows.h:72:0,
from ./os/gl_window.h:14,
from ./vi/controller.h:14,
from ./device.h:21,
from os/windows/main.c:10:
c:\tdm-gcc-64\x86_64-w64-mingw32\include\winuser.h:3011:25: note: expected 'LPCSTR' but argument is of type 'short unsigned int *'
WINUSERAPI int WINAPI MessageBoxA(HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType);
^
os/windows/main.c:29:3: warning: passing argument 3 of 'cen64_main' from incompatible pointer type [enabled by default]
if (!(status = cen64_main(&device, __argc, __argv)))
^
In file included from os/windows/main.c:11:0:
./os/main.h:14:5: note: expected 'const char **' but argument is of type 'char **'
int cen64_main(struct cen64_device *device, int argc, const char *argv[]);
^


EDIT:
gcc -v provides the following:

Using built-in specs.
COLLECT_GCC=c:\TDM-GCC-64\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/tdm-gcc-64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-2 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 4.8.1 (tdm64-2)

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Thu Aug 28, 2014 10:37 am

Ambient_Malice wrote:It now spits out the following errors while compiling.
Those are all warnings, I get the same warnings when I compile, you should have a cen64.exe file in the root of your source directory after only getting these warnings.
If you do not have a cen64.exe, there must have been an error, try to look for a line that says "Error", & copy and paste the error line that comes up.
Ambient_Malice wrote:gcc -v provides the following:
...
Those are the same GCC specs as me, you have done the hard part by setting up TDM GCC correctly, I am sure you should be able to compile cen64 =D

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Thu Aug 28, 2014 2:02 pm

I have added my fill triangle rotation demos:
https://github.com/PeterLemon/N64/tree/ ... gle320x240
https://github.com/PeterLemon/N64/tree/ ... gle320x240

On real N64 hardware, the triangle is rotated through all 1024 seperate X,Y,Z axis rotations, in only 3 seconds.
So about 341 Frames per second, and looks stunning =D

These demos prove that I can draw any clipped/Non Clipped triangle to the N64 screen.
Also this is the starting of my CP13D lib, for simple 3D object loading, XYZ axis rotation, matrix & perspective (Field Of View) camera setup.
I will try to rotate textured triangles as my next demo =D

Also I will try to offload all of these 3D calculations onto the RSP for a separate RSP3D Lib too =D
Last edited by krom on Thu Aug 28, 2014 5:08 pm, edited 1 time in total.

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

Re: New core/version 0.3

Post by MarathonMan » Thu Aug 28, 2014 2:24 pm

krom wrote:These demos prove that I can draw any clipped/Non Clipped triangle to the N64 screen.
Also this is the starting of my CP13D lib, for simple 3D object loading, XYZ axis rotation, matrix & perspective (Field Of View) camera setup.
I will try to rotate textured triangles as my next demo =D

Also I will try to offload all of these 3D calculations onto the RSP for a separate RSP3D Lib too =D
This is fantastic! If I'm not mistaken, not even libdragon was able to accomplish this feat. I think, for the purposes of community documentation, it would be great if we could get you to document your findings somewhere.

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

Re: New core/version 0.3

Post by Narann » Thu Aug 28, 2014 3:59 pm

I agree this is a massive improvement in the N64 scene! Once again, I can only push to improve libdragon to make it better and avoid another lib. :D

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

Re: New core/version 0.3

Post by Nintendo Maniac 64 » Fri Aug 29, 2014 2:58 pm

Regarding input controls, are there any considerations on looking to reduce any input lag that emulation would introduce vs the real console? There are two discussions over on byuu's forum regarding the matter:

What exactly causes input lag in emulation?

Idea to cut 16.7ms latency from almost any emulator


(btw, is email notification broken for thread subscriptions? I haven't gotten anything for the last week and they're not going into my Gmail's spam folder either...)
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/version 0.3

Post by Snowstorm64 » Fri Aug 29, 2014 3:13 pm

Honestly it's too early to worry about input latencies, right now even an i7-4770k with normal clock can't run any games at full speed. Not to mention the core is still unfinished (or so I think...), there's lack of save support and audio, there's preliminary keyboard support, etc etc...
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

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

Re: New core/version 0.3

Post by Nacho » Fri Aug 29, 2014 7:04 pm

I'v checked the preliminary input support.

A few toughts:

- No DPAD. Ouch. Must be trivial to implement.
- When you keep pressing a keyboard button (without releasing it), it seems that CEN64 interpret that as a fast series of press-release events. Like a "turbo mode". (at least on linux).
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
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/version 0.3

Post by MarathonMan » Fri Aug 29, 2014 11:59 pm

Nacho wrote:A few toughts:

- No DPAD. Ouch. Must be trivial to implement.
- When you keep pressing a keyboard button (without releasing it), it seems that CEN64 interpret that as a fast series of press-release events. Like a "turbo mode". (at least on linux).
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
os/input: Got keypress event: 65363
os/input: Got keyrelease event: 65363
Ah yes... not sure how I never noticed that. I'll read up on the X11 man pages and fix it and confirm the same fate doesn't hold for Windows.

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

Re: New core/version 0.3

Post by Snowstorm64 » Sat Aug 30, 2014 6:17 am

This is a normal behaviour, due to key repeat enabled by default (unless you want to press every time "a" key for composing the word "aaaaaaaaaaaaaaaaaaaaaaaaaa"! :P ) so it isn't a bug. However, it doesn't have any effect on CEN64, except maybe spamming the terminal with fprintf.
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/version 0.3

Post by MarathonMan » Sat Aug 30, 2014 11:50 am

Snowstorm64 wrote:This is a normal behaviour, due to key repeat enabled by default (unless you want to press every time "a" key for composing the word "aaaaaaaaaaaaaaaaaaaaaaaaaa"! :P ) so it isn't a bug. However, it doesn't have any effect on CEN64, except maybe spamming the terminal with fprintf.
Well, yes, I agree w/ the fact that ordinarily, key repeat is desirable behaviour... but in the context for which the keyboard is to be used, it's still "buggy" behavior in the sense that it's not desired.

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

Re: New core/version 0.3

Post by Snowstorm64 » Sat Aug 30, 2014 1:05 pm

Certainly it now works much better. However I wonder what are the keys for the N64 buttons, I discovered these:

(Key) -> (N64 button)
X -> A
C -> B
Enter -> Start
Z -> Z
S -> R
A -> L
←↑↓→ ->Control Stick

But what about (Nacho pointed this) D-pad and C-pad?

Also, when I press any direction, it seems movements are too slow and sometimes doesn't have any effect for example in a menu.
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/version 0.3

Post by MarathonMan » Sat Aug 30, 2014 1:10 pm

Snowstorm64 wrote:But what about (Nacho pointed this) D-pad and C-pad?
I was sloppy and didn't add them back in yet... :p. Giving the website a makeover; I'll get to that soon.
Snowstorm64 wrote:Also, when I press any direction, it seems movements are too slow and sometimes doesn't have any effect for example in a menu.
Controls are:
(Key) -> (N64 button)
X -> A
C -> B
Enter -> Start
Z -> Z
S -> R
A -> L
←↑↓→ ->Control Stick (push slightly)
LShift + ←↑↓→ ->Control Stick (push a lot)
You probably need to hold left shift to get it to register in a menu.

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

Re: New core/version 0.3

Post by Snowstorm64 » Sat Aug 30, 2014 1:21 pm

MarathonMan wrote: I was sloppy and didn't add them back in yet... :p. Giving the website a makeover; I'll get to that soon.
I'll wait then. :)
←↑↓→ ->Control Stick (push slightly)
LShift + ←↑↓→ ->Control Stick (push a lot)
It wouldn't make more sense if we switch them for reasons above? It wouldn't be very practical while holding down the button every time :P
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/version 0.3

Post by MarathonMan » Sat Aug 30, 2014 1:29 pm

Snowstorm64 wrote:It wouldn't make more sense if we switch them for reasons above? It wouldn't be very practical while holding down the button every time :P
Sure. I'll do that when I add the D/C-pad input.

EDIT:
Controls are now:
(Key) -> (N64 button)
X -> A
C -> B
Enter -> Start
Z -> Z
S -> R
A -> L
←↑↓→ ->Control Stick (push a lot)
LShift + ←↑↓→ ->Control Stick (push a little)
C← -> F
C↑ -> T
C↓ -> G
C→ -> H
D← -> J
D↑ -> I
D↓ -> K
D→ -> L
Phew... that's a lot of buttons.

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

Re: New core/version 0.3

Post by Nintendo Maniac 64 » Sat Aug 30, 2014 5:36 pm

Wouldn't the following be easier to use for actual gameplay?

(Key) -> (N64 button)
D -> A
S -> B
A -> C↓
Q -> C←
W -> C↑
E -> C→
Shift/N -> Z
Space Bar -> R
Left/Right Alt -> L
Enter -> Start

←↑↓→ - Control Stick
Caps Lock (toggle) - switch control stick between "push a lot" and "push a little"
Left/Right Ctrl (hold) - changes analog stick mode to opposite of what Caps Lock specifies
(NUM0 or Ins can also be used instead of Ctrl)

D↑ -> Y
D← -> G
D↓ -> H
D→ -> J

One thing in particular, the down-C button must be easily accessible because some games like F-Zero X use it as a third primary button to go along with A and B. Also you must consider being able to access the L button while using Z, the Dpad, and Analog stick for the few games that use the left&center controller grip (Sin & Punishment comes to mind).


EDIT: I am however a bit concerned about Alt+Spacebar. At least back in the day doing that totally didn't work in games because that would be the Windows command to bring up window-size menu or whatever it's call in the top-left corner of any window.

EDIT 2: Just tried with a modern game (AM2R) and the Alt+Spacebar thing is not an issue at all.

EDIT 3: Realized a huge mistake, Z being space and R being left shift would be very weird for sliding in F-Zero X, so I've changed Z to left shift and alternatively N (for left&middle prong grip).
Last edited by Nintendo Maniac 64 on Sat Aug 30, 2014 6:31 pm, edited 5 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
Ambient_Malice
Posts: 21
Joined: Mon Aug 25, 2014 9:04 am

Re: New core/version 0.3

Post by Ambient_Malice » Sat Aug 30, 2014 5:59 pm

Here's my 5 cents regarding optimal controls.

C = A
X = B
Z = Z

WASD = C Buttons.

Arrow Keys = Stick

Q = Left Shoulder Button.
E = Right Shoulder Button.
Enter Key = START.

D-Pad can be JIKL or something. D-pad is not used very often in N64 titles.

This is the layout I use for all-keyboard gaming. It offers easy access to C-buttons, A, B, and Z, as well as shoulder buttons.

Locked

Who is online

Users browsing this forum: No registered users and 2 guests