Forums

Finally found the time to work on JMasterSystem again! There are a few changes this release, mostly minor.

Link to previous release:
http://www.smspower.org/forums/viewtopic.php?t=13705

Changes:
Fullscreen mode - this can be triggered by using the F key or the View menu and switched off by using the F key again.
Sprite fixes - the main fix was getting sprites with Y-positions of 0xF0 to 0xFF to render properly. There were other minor bugs in my sprite rendering code that I've fixed too.
Expanded menu system - help menu with controls and about items.

With regards to the sound code, although performance is more or less the same this release, my testing leads me to believe (so far) that the JVM garbage collector is the issue - when I run the emu with more RAM than the default, it results in a much more stable audio stream. I plan to combat this by (a) Cutting the sample rate in half (it is currently 44.1 KHz) - this will result in half the number of buffer creations and writes, leading to less memory usage and (b) bundling a launcher script to run the JVM with more RAM. Both of these should result in a much better sounding audio subsystem, and will be addressed in the next release.

I have attached the source code this time as well, as promised :-) It is GPLv3 licensed, and currently takes the form of a NetBeans project.

I look forward to people using JMasterSystem 0.2, and appreciate any feedback. Thanks :-)

Regards,
Phil Potter

JMasterSystem.zip (135.91 KB)

JMasterSystem 0.2 binary

JMasterSystem source.zip (111.63 KB)

JMasterSystem 0.2 source

Very nice! I hope to start making an attempt at porting in a few weeks. Just got around to moving so it's been hectic lately.

Yeah, the GC is probably going to be your enemy here. I'd advise against just bundling a script that bumps the -Xmx and instead look at where you may be allocating heap memory in your game loop. You should take a look at some of the methods that may be causing hidden allocations.

For example, "panelSize = this.getSize()". The JComponent.getSize() method will allocate a new Dimension object for each call. With this in your paint method you'll be getting a new object with each frame. When the heap usage reaches the threshold the GC will kick in.

Also, it might be worth switching to an active rendering approach rather than relying on the EDT (videoPanel.repaint() - which also causes a heap allocation).

How do you in install it??

Glitch: Thanks, good point - there are many places I can optimise the code. The reason I do all my GUI code on the EDT is I've seen a few people suggesting that as Swing is not thread safe, all GUI manipulation should be done on the EDT. I'm happy to be shown a better way though :-)

KnightWarrior: No installation, just execute the jar file.

It's a java file..

What kind of program to do this?

If you have Java installed, the file should open with "Java(TM) Platform SE Binary" and will run by double-clicking it. If the file type and Java exe aren't associated for some reason, the exe will probably be located at
C:\Program Files\Java\jre6\bin\javaw.exe

PhilPotter wrote

The reason I do all my GUI code on the EDT is I've seen a few people suggesting that as Swing is not thread safe, all GUI manipulation should be done on the EDT.

That's correct. However, in the case of active rendering you *can* take your rendering off of the EDT under specific circumstances: chiefly, when you are not rendering or otherwise manipulating any Swing components.

I've attached some source files from a game engine idea that I have been toying with. It uses off-EDT active rendering with an AWT Canvas. Another example can be found here: http://www.cokeandcode.com/index.html?page=tutorials/spaceinvaders101

For the record, you're calling videoPanel.repaint() from your EmuCore thread :).

GameCanvas.java.txt (3.84 KB)

GraphicsContext.java.txt (703 B)

Excellent, I've not used a BufferStrategy myself before, although I've seen others do so - looks like a good idea, will have to put it in the next release. There are many little things in my code that aren't as efficient as they could be - repaint() is one, another that comes to mind is the cloning of the sound buffer on the sound thread - this creates another array object each time and isn't really necessary. I look forward to tightening things up - thanks for your help :-)

Did some analysis into how often the GC is kicking in - about 8-9 times per second! Once I commented out the sprite rendering and tile rendering routines in my VDP, this dropped to about once every 15-20 seconds. This is clearly where the majority of the allocations are happening - the active rendering approach is a definite for the next release but so is trimming this down somehow - I can't believe how inefficiently I've written these two routines! :-p

Author	Message
PhilPotter Joined: 08 Nov 2011 Posts: 67 Location: United Kingdom	JMasterSystem 0.2 release Posted: Thu May 03, 2012 11:25 pm
	Finally found the time to work on JMasterSystem again! There are a few changes this release, mostly minor. Link to previous release: http://www.smspower.org/forums/viewtopic.php?t=13705 Changes: Fullscreen mode - this can be triggered by using the F key or the View menu and switched off by using the F key again. Sprite fixes - the main fix was getting sprites with Y-positions of 0xF0 to 0xFF to render properly. There were other minor bugs in my sprite rendering code that I've fixed too. Expanded menu system - help menu with controls and about items. With regards to the sound code, although performance is more or less the same this release, my testing leads me to believe (so far) that the JVM garbage collector is the issue - when I run the emu with more RAM than the default, it results in a much more stable audio stream. I plan to combat this by (a) Cutting the sample rate in half (it is currently 44.1 KHz) - this will result in half the number of buffer creations and writes, leading to less memory usage and (b) bundling a launcher script to run the JVM with more RAM. Both of these should result in a much better sounding audio subsystem, and will be addressed in the next release. I have attached the source code this time as well, as promised :-) It is GPLv3 licensed, and currently takes the form of a NetBeans project. I look forward to people using JMasterSystem 0.2, and appreciate any feedback. Thanks :-) Regards, Phil Potter JMasterSystem.zip (135.91 KB) JMasterSystem 0.2 binary JMasterSystem source.zip (111.63 KB) JMasterSystem 0.2 source

Maraakate Joined: 05 Jun 2010 Posts: 551 Location: Pennsylvania, USA	Posted: Fri May 04, 2012 4:21 am
	Very nice! I hope to start making an attempt at porting in a few weeks. Just got around to moving so it's been hectic lately.

Glitch Joined: 16 Dec 2008 Posts: 12 Location: UK	Posted: Fri May 04, 2012 5:55 pm
Glitch Joined: 16 Dec 2008 Posts: 12 Location: UK	Yeah, the GC is probably going to be your enemy here. I'd advise against just bundling a script that bumps the -Xmx and instead look at where you may be allocating heap memory in your game loop. You should take a look at some of the methods that may be causing hidden allocations. For example, "panelSize = this.getSize()". The JComponent.getSize() method will allocate a new Dimension object for each call. With this in your paint method you'll be getting a new object with each frame. When the heap usage reaches the threshold the GC will kick in. Also, it might be worth switching to an active rendering approach rather than relying on the EDT (videoPanel.repaint() - which also causes a heap allocation).

KnightWarrior Joined: 19 Feb 2009 Posts: 29	Posted: Fri May 04, 2012 9:41 pm
KnightWarrior Joined: 19 Feb 2009 Posts: 29	How do you in install it??

PhilPotter Joined: 08 Nov 2011 Posts: 67 Location: United Kingdom	Posted: Fri May 04, 2012 10:24 pm
	Glitch: Thanks, good point - there are many places I can optimise the code. The reason I do all my GUI code on the EDT is I've seen a few people suggesting that as Swing is not thread safe, all GUI manipulation should be done on the EDT. I'm happy to be shown a better way though :-) KnightWarrior: No installation, just execute the jar file.

KnightWarrior Joined: 19 Feb 2009 Posts: 29	Posted: Sat May 05, 2012 1:25 am
KnightWarrior Joined: 19 Feb 2009 Posts: 29	It's a java file.. What kind of program to do this?

albino_vulpix Joined: 05 Jun 2007 Posts: 247 Location: Melbourne, Australia	Posted: Sat May 05, 2012 5:04 am
	If you have Java installed, the file should open with "Java(TM) Platform SE Binary" and will run by double-clicking it. If the file type and Java exe aren't associated for some reason, the exe will probably be located at C:\Program Files\Java\jre6\bin\javaw.exe

Glitch Joined: 16 Dec 2008 Posts: 12 Location: UK	Posted: Sat May 05, 2012 10:12 am
Glitch Joined: 16 Dec 2008 Posts: 12 Location: UK	PhilPotter wrote The reason I do all my GUI code on the EDT is I've seen a few people suggesting that as Swing is not thread safe, all GUI manipulation should be done on the EDT. That's correct. However, in the case of active rendering you can take your rendering off of the EDT under specific circumstances: chiefly, when you are not rendering or otherwise manipulating any Swing components. I've attached some source files from a game engine idea that I have been toying with. It uses off-EDT active rendering with an AWT Canvas. Another example can be found here: http://www.cokeandcode.com/index.html?page=tutorials/spaceinvaders101 For the record, you're calling videoPanel.repaint() from your EmuCore thread :). GameCanvas.java.txt (3.84 KB) GraphicsContext.java.txt (703 B)

PhilPotter Joined: 08 Nov 2011 Posts: 67 Location: United Kingdom	Posted: Sat May 05, 2012 2:41 pm
	Excellent, I've not used a BufferStrategy myself before, although I've seen others do so - looks like a good idea, will have to put it in the next release. There are many little things in my code that aren't as efficient as they could be - repaint() is one, another that comes to mind is the cloning of the sound buffer on the sound thread - this creates another array object each time and isn't really necessary. I look forward to tightening things up - thanks for your help :-)

PhilPotter Joined: 08 Nov 2011 Posts: 67 Location: United Kingdom	Posted: Tue May 08, 2012 10:51 am
	Did some analysis into how often the GC is kicking in - about 8-9 times per second! Once I commented out the sprite rendering and tile rendering routines in my VDP, this dropped to about once every 15-20 seconds. This is clearly where the majority of the allocations are happening - the active rendering approach is a definite for the next release but so is trimming this down somehow - I can't believe how inefficiently I've written these two routines! :-p

Forums

View topic - JMasterSystem 0.2 release