Isn't that what these forums are for? Although I'd agree that the workbench gets way more coverage. I can think of at least one game where an author was told in those forums not to do X, and he did it anyway, and then his run got rejected for precisely that reason...
I just don't want someone to work on something which they may feel is wasted effort. If they want to know if their particular case does not fall into the near-blanket-ban, they can ask, and explain why they feel like their particular case may be different before embarking on a potentially lengthy creation process.
The problem with SMB PAL is that neither superiority nor diversity can be formalized for it. "One time exceptions", as moozooh pointed out, should either be legalized or not happen at all. My goal is to make the PAL ruling fully transparent, with no surprises. If we have to make an exception every now and then, the ruling is sloppy.
In the scenario we're discussing (games which have technical differences but have a very similar look and feel) I think acceptance and obsoletion end up being the same. Since introducing another branch would create unwanted redundancies, the only way it gets accepted is by obsoleting the existing movie (if any). And as mentioned before, I only consider that specific branch, not the game in general (other branches may have different outcomes).
Mmh, right. Did you test the speed with a function pointer (or a variable tested in a switch) that is set when timer_control is changed?
@Alyosha It sounds best at 1 (NESHawks default Audio Level) So I was wrong about raising the audio level. I have a question, is it possible to force the NESHawk audio to play at a Higher Quality with a Sample rate of 44100 Hz like how the Sega Emulator Kega Fusion 3.64 does it? Thank You for your time.
It doesn't matter if they have the same bits set or not since we're testing for zero/nonzero.
(state & state_c) == 0Audience support alone doesn't prove anything, if it can't be formalized in some statement, that is then put as a reason to accept a PAL submission. And to come up with such statement, we impose factors we want to get evaluated. To me the new question is... How many people think we should not change the movie rules, nor clarify them?
Due to this, PAL versions of ROMs are generally not allowed, unless there are significant technical and/or entertainment merits to using this version.
Due to this, PAL versions of ROMs are generally not allowed, unless there are significant technical and/or entertainment merits to using this version, or there is strong audience support.
Hello BizHawk developers, I just wanted to ask if you guys can please turn up the overall volume on the NESHawk's Emulator Core. I love the Emulator, it is great. It is just that the overall Audio volume is low, I turn up the volume on my computer to the max for my head phones and it is still kinda low. Thank you for your time.
I would posit that it's the sheer number of function calls to Bit() that eat away at performance. Can you run a disassembler to determine if the JIT compiler is inlining those calls? If it isn't, you could try the AggressiveInlining attribute that was mentioned in the NesHawk thread. I haven't done a huge amount of performance optimization in C#, but it's pretty fascinating.
public void tick_2()
{
divider_reg+=1;
// pick a bit to test based on the current value of timer control
switch (timer_control & 3)
{
case 0:
state = divider_reg & 0x200;
break;
case 1:
state = divider_reg & 0x8;
break;
case 2:
state = divider_reg & 0x20;
break;
case 3:
state = divider_reg & 0x80;
break;
default:
break;
}
// And it with the state of the timer on/off bit
state_c = timer_control & 0x4;
// this procedure allows several glitchy timer ticks, since it only measures falling edge of the state
// so things like turning the timer off and resetting the divider will tick the timer
if ((state == 0 || state_c == 0) && (old_state > 0 && old_state_c > 0))
{
timer_old = timer;
timer+=1;
// if overflow, set the interrupt flag and reload the timer (4 clocks later)
if (timer < timer_old)
{
pending_reload = 4;
reload_block = false;
}
}
old_state = state;
old_state_c = state_c;
}8-2 | 10979 12475 1496 24.892
8-2 | 10979 12363 1384 23.029Is that line using bit masking and shifting? You could also store each emulated bit as its own boolean.
public static bool Bit(this byte b, int index)
{
return (b & (1 << index)) != 0;
}
A few more small timing things to clean up and it will be time to start audio.
I also did some performance analysis, since this core runs much faster the NESHawk while not really having that much less to do, to see if I could learn anything from it.
One thing I did learn is that statements like this:
state = divider_reg.Bit(9);I picked a spot before the staircase a bit prior to where HL slows down, as an easy to notice spot. I then went through a bunch of previous movies for the game, looking for the one which did the staircase to flag fastest. Once I found the fastest, I added the time from that point to the time I calculated for HL till that point, and then subtracted that from HL's overall time. That's the thing, if you're aiming for fastest possible playable time don't do the glitch at all, as the glitch trades playable time for real time.