It is currently Fri Dec 15, 2017 1:35 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun Jul 26, 2015 6:03 am 
Offline

Joined: Fri Feb 14, 2014 11:16 pm
Posts: 30
Location: Linköping, Sweden
tepples wrote:
I wish you luck on this because "best viewed with Chrome; click here to download and install Chrome"

Not just Chrome. Webkit is the reason. Safari and Opera use it as well, and Safari is pre-installed on Macs. Later on Microsoft Edge will be also pre-installed on Windows 10 and will probably run em-fceux as well... Currently however, em-fceux seems to work best with webkit-based browsers... Don't get me wrong. I'm not dissing Firefox. I love it.

tepples wrote:
tsone wrote:
tepples wrote:
Zap Ruder, Vaus Test, and Eighty don't do $#!+.

em-fceux doesn't use the new PPU in FCEUX as that's more computationally heavy. Do these work without problems with the old PPU in FCEUX 2.2.2?

Yes. They just require Zapper, Arkanoid Controller, and Four Score support respectively. It wasn't obvious how to enable the Zapper.

I tried Zap Ruder and at least pong and the music thingy works fine. Also the Y coordinate seems to be registered correctly (as I'd expect from FCEUX old PPU)... Can you be more clear on what is not working with Zap Ruder (not counting FCEUX 2.2.2 old PPU issues)?

Sorry, but Arkanoid controller and FourScore are not supported ATM. I had to focus on basic features first. I'll continue improve the emulator incrementally when I have time.

tepples wrote:
I don't know the intricacies of waiting for vblank and presenting the next frame on 2D canvas or WebGL. But given how many NES games use a 30 Hz flicker to indicate mercy invincibility, I'd recommend showing every third frame or every fifth frame if the machine isn't fast enough to show every frame.

There is no standard way to set canvas rendering frame rate or enabling/disabling vblank from browser javascript. The "proper" way to redraw canvas is to do it in a callback registered to requestAnimationFrame(). Problem is, the callback will be called rather erratically (however, 60 fps at max), and there's no way to predict when next frame will land... But I got what you meant by rendering every 3,5,7.. frames when frameskipping. Thanks! I've added a feature request so I remember this later :)


Top
 Profile  
 
PostPosted: Sun Jul 26, 2015 8:00 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19346
Location: NE Indiana, USA (NTSC)
tsone wrote:
submit bugs/feature requests in the bitbucket project issue tracker.

I'm trying to use your time wisely up front so that I don't waste it later, and I have three issue reports saved on my computer that I will post once these two issues are clarified:

If I'm still seeing an issue in both Firefox and Chrome on my machine, even though it's been marked as "RESOLVED", should I add a comment, create another issue, or do something else?

Should I try to report issues against the normal URL or against whatever's at the staging URL? Or do I need to reproduce the problem in all four environments (Chrome at normal URL, Firefox at normal URL, Chrome at staging URL, and Firefox at staging URL) before reporting anything?


Top
 Profile  
 
PostPosted: Mon Jul 27, 2015 8:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5898
Location: Canada
tepples wrote:
rainwarrior wrote:
It's a bit bizarre to suggest the user wait for an essentially unpredictable, but relatively short delay for deletion.

It's modeled after the "Undo Send" delay that Gmail users can enable on the basis that undo is better than confirmation.

I wrote an angry reply to this earlier, but I was ashamed of myself and deleted it. Now that the moment has passed I think I can respond reasonably.

The trash can itself is the "undo" step for removing a game. That's the important use case. It's already fine with just the trash can.

Emptying the trash is not something that needs to be made more convenient, and having it take two clicks to do is essentially a "confirmation". This is a "confirmation" on whether you want to eliminate your ability to "undo" trashing a game.

Your suggestion was that emptying the trash should not have a confirmation, but instead be automatic with a specific 5 minute delay. This works against the usefulness of the trash can as an "undo" feature, which is why I think it is a bad idea. When the trash can is automatically emptied, its undo functionality is defeated at that moment.

If it was real files on a hard drive, there would be space to recover by automatic deletion, but these are just symbolic links, totally insignificant. The only thing automatically emptying the trash does is inconvenience the user who might take more than 5 minutes to decide they want to "undo" a game out of the trash (plausible situation, since they're probably busy playing games). Even a predictable empty-trash (like when you close the browser) would be a ton better than a 5 minute auto-delete.

Actually, in my opinion, the most practical thing to do would probably be no trash can at all. No implementation cost, and since removing a game wouldn't destroy the ROM on your hard drive anyway, it's easy to undo by just re-opening the file.


Anyhow, the part that made me mad was the article link. The article itself is annoying and arrogant enough; I absolutely despise "one size fits all" rules about programming or usability design. Good design responds to the specifics of the situation, always. You stating "undo is better than confirmation" irks me a lot just by itself, as it would be obviously ludicrious to apply to all situations. There is a time and place for both undo and confirmation in design, very often in tandem with each other. Saying it and linking to the article, instead of actually addressing its merit as applied to this specific situation is what set me off. So this author had some bad experiences with a particular kind of design, and maybe he's right that they should have been done differently in those cases, but to offer it as some generic design rule is awful. Design requires critical thinking, not dogma.

In Google's e-mail undo case, they were applying an incremental change to a send button with no undo. A hidden delay on e-mail was already practical for them (e.g. as part of an anti-spam measure), but they figured out a nice user-facing feature that could be implemented on top of it. It seems like a fine decision on their part, but only in the context in which that decision was made.


Top
 Profile  
 
PostPosted: Mon Jul 27, 2015 10:29 pm 
Offline

Joined: Fri Feb 14, 2014 11:16 pm
Posts: 30
Location: Linköping, Sweden
IMPORTANT NOTICE:

If em-fceux doesn't start after loader bar is full, please disable (or clear) the browser cache and reload the page. I'll fix this issue ASAP!

tepples wrote:
If I'm still seeing an issue in both Firefox and Chrome on my machine, even though it's been marked as "RESOLVED", should I add a comment, create another issue, or do something else?

Thanks for bringing this up! :beer: :D I found this bug (Zapper not working) and it's now fixed in staging. No need to add this bug. I simply forgot to attach a mousedown callback to the 2D canvas... :roll:

tepples wrote:
Should I try to report issues against the normal URL or against whatever's at the staging URL? Or do I need to reproduce the problem in all four environments (Chrome at normal URL, Firefox at normal URL, Chrome at staging URL, and Firefox at staging URL) before reporting anything?

It's entirely up to you which, and you can use any browser you want. However, staging version is preferred for reporting bugs as it has the latest changes. Idea with staging is to provide a "live" testable version for you guys to test (like a development build). Staging will gradually improve as bugs get fixed and features added, and finally it is deployed as the official version. My plan is that next official version is released when most of the current issues with >= major priority are resolved.


Top
 Profile  
 
PostPosted: Mon Jul 27, 2015 11:49 pm 
Offline

Joined: Fri Feb 14, 2014 11:16 pm
Posts: 30
Location: Linköping, Sweden
rainwarrior wrote:
tepples wrote:
rainwarrior wrote:
It's a bit bizarre to suggest the user wait for an essentially unpredictable, but relatively short delay for deletion.

It's modeled after the "Undo Send" delay that Gmail users can enable on the basis that undo is better than confirmation.

I wrote an angry reply to this earlier, but I was ashamed of myself and deleted it. Now that the moment has passed I think I can respond reasonably.

The trash can itself is the "undo" step for removing a game. That's the important use case. It's already fine with just the trash can.

Emptying the trash is not something that needs to be made more convenient, and having it take two clicks to do is essentially a "confirmation". This is a "confirmation" on whether you want to eliminate your ability to "undo" trashing a game.

...

Gentlemen! :) It's great to see your excitement, but IMO "trash can" feature doesn't fully justify the effort and added complexity. Also, browser local data storage can be quite small (5MB and up). The limited space shouldn't be used for trash. The Emscripten IndexedDB sync will also get slower with more files... But most importantly, think about the game stack metaphor -- you wouldn't throw valuable game carts in the trash, right? :D

I agree it's overkill to have double confirmation for simply deleting a game. I added the second one because the start and delete game confirmations look almost exactly the same. As the 'X' icon is over the game cart, it's easy to accidentally click it and quickly select 'Ok', only to find the game you wanted to play is gone... Second confirmation was the simplest way to solve this problem... I know this must be changed, so I have created a feature request for this.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group