You are not logged in.
Lost Password?


Register To Post



 Bottom   Previous Topic   Next Topic

#141
Re: PVB Emulator
Posted on: 5/12 6:17
Virtual Freak
Joined 1/27
USA
91 Posts
Eight years for a handheld is a hell of a run. The GBA lasted 9 years, the original Gameboy was 9 (1989) alone 14 including the Color (1989-2003). Interestingly the DS line also lasted 9 years 2004-13.

The GBC being the extension system, if you look at the main line of units, they all seemingly have lasted with the overlap to more or less 8-9 years. That's a good long run for a single piece of hardware with minor changes/revisions.
Top

#142
Re: PVB Emulator
Posted on: 7/20 15:52
VUE(xpert)
Joined 2003/9/3
Sweden
442 Posts
PVBCC EntryHighscore Top10 3rdCoderContributorHOTY09 2ndLong Time User (15 Years) DonatorApp CoderPVBCC 2010 1st20+ Game RatingsPVBCC 2013 2nd
Wow, this emulator has already sailed up there to be the very best one available for us developers! Thanks Guy Perfect!

Mednafen has a weird bug with bitstrings copied to one of the frame buffers, but this one works spot on!

I love the VIP window, and if I could make one request it would be to have it update continuously while a game is running as well.
I realize this could potentially be thousands of times per frame, but doing it just once at the end of each frame would be enough. VisualBoy Advance has this feature for GBA for example, and it helps for studying how different games pull off animations under the hood.

Please continue working on this project, much appreciated!

Also, my red/blue glasses doesn't quite match any of the presets, so prioritizing the color settings dialog would be cool too ;-)
Top

#143
Re: PVB Emulator
Posted on: 7/20 20:27
VUE(xpert)
Joined 2003/9/3
Sweden
442 Posts
PVBCC EntryHighscore Top10 3rdCoderContributorHOTY09 2ndLong Time User (15 Years) DonatorApp CoderPVBCC 2010 1st20+ Game RatingsPVBCC 2013 2nd
I was messing around with Red Alarm a bit, and it turns out the game IS actually running, it just doesn't draw anything to the console before reaching the title screen. If you press A a couple of times in the dark, and F5 in and out of the debugger, you can see the framebuffers gets updated with all the precaution graphics, but not the console itself. Of course the CPU window also highlight alot of exceptions all the time...

It's actually kind of playable after that :)

Attach file:



png  red_alarm.png (40.04 KB)
27_5d335cf76604a.png 681X635 px
Top

#144
Re: PVB Emulator
Posted on: 7/22 11:24
Virtual Freak
Joined 2017/6/24
USA
69 Posts
Long Time User (2 Years)
Quote:

DanB wrote:
I was messing around with Red Alarm a bit, and it turns out the game IS actually running, it just doesn't draw anything to the console before reaching the title screen. If you press A a couple of times in the dark, and F5 in and out of the debugger, you can see the framebuffers gets updated with all the precaution graphics, but not the console itself. Of course the CPU window also highlight alot of exceptions all the time...

It's actually kind of playable after that :)


Question: Does Red Alarm put graphics data in any of the other tabs besides the framebuffers' tab?
Top

#145
Re: PVB Emulator
Posted on: 7/22 12:04
VUE(xpert)
Joined 2003/9/3
Sweden
442 Posts
PVBCC EntryHighscore Top10 3rdCoderContributorHOTY09 2ndLong Time User (15 Years) DonatorApp CoderPVBCC 2010 1st20+ Game RatingsPVBCC 2013 2nd
Quote:

StinkerB06 wrote:

Question: Does Red Alarm put graphics data in any of the other tabs besides the framebuffers' tab?


Yes, all of them are loaded correctly.
Top

#146
Re: PVB Emulator
Posted on: 8/19 9:06
Newbie
Joined 8/19
1 Posts
Hi projesct is dead ? I want so much this emulator !
Top

#147
Re: PVB Emulator
Posted on: 9/9 16:58
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
To the future researcher looking for answers: I revisited the audio thing for an unrelated project and took the time to work through it and find a passable solution. Java is not set up for this.

Audio output in Java is most easily accomplished via AudioSystem.getSourceDataLine(), which in turn directly provides a line object and methods for sending output to the speakers. For most applications, this is how you'll want to manage audio.

SourceDataLine has some methods for tracking playback status, namely getLongFramePosition() and available(). Although the frame position is useful for determining approximately how much data has been consumed, it does not reliably reflect how many resources are currently available to the line. And while available() does give the number of bytes that can be written without blocking, it is likewise not reliable due to an unintuitive behavior of the implementation. If there are n bytes available and you write some number of bytes m, it would be reasonable to expect that the next call to available() would give either n - m or a slightly larger number depending on playback, but that's not always the case for whatever reason.

Ultimately, there is no way to monitor the state of resources within a SourceDataLine during playback. The emulator depends on the opposite being the case, and consequently falters pretty spectacularly.

Further experiments and profiling of Java's audio behaviors have turned up a best-case scenario, which is still not completely satisfactory, but if it's the best-case, it won't get any better, right? The solution is two-fold:

1) In order to minimize the opportunities for stuttering during playback, data should be fed to the SourceDataLine object in its own thread, where it can block on a call to write() and likewise block when retrieving sample buffers via something like a BlockingQueue. This ensures data will always be made available to the SourceDataLine with minimal latency.

2) The amount of data written at once to a SourceDataLine should be as large as possible. SourceDataLine appears to introduce some overhead and begins to stutter if the data buffers are too small, and the garbage collector can potentially interrupt the software while it's attempting to have samples ready in time. Bear in mind that the thread scheduler may give the thread something like 15ms at a time to execute. By minimizing the number of calls to write(), overhead is kept low and garbage collection has less of an opportunity to interrupt playback.

The concern now lies in the fact that the actual delay between an action occurring on-screen and the audio for that action coming from the speakers should ideally be as short as possible, and that contrasts with Java's approach to audio. I was able to set up a mechanism that initializes audio output with a configurable initial delay built of empty samples, and writes to the output line in buffers with a configurable length. On my personal rig the optimal setup is something around a 0.15s initial delay and a 0.1s block size, although once in a great while a very short, single stutter does occur. Eventually the JVM profiler seems to get the hang of it, so any window of interruptions in playback should be short-lived.

According to my time log, I spent 30.847 hours working on this problem. It was not a simple problem!
Top

 Top   Previous Topic   Next Topic


Register To Post