Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / Java Sound & OpenAL / Re: JStella - Pitfall II sound is scratchy, but I don't know why on: 2007-10-02 06:37:01
No, I think the VCS is older...the VCS (2600) to my knowledge was 99.9% games.  it was born around the same time as Star Wars, and it was popular until NES & SMS came along in the mid 80s.
Hmmm...what about an open-source combined 1980s console emulator in Java?  This would treat the VCS as an 80s machine, but the Sega Genesis as a 90s machine...of course, there would need to be a NES component (and possibly the various other machines), which would be work, but at least there is plenty of available C++ code to port.
2  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-10-02 06:26:24
I tried it once with disastrous results (on account of my experience with it).  If anyone wants to take a stab at it (or take over the project), let me know.  Medical school is devouring all my time.   
JLA
3  Java Game APIs & Engines / Java Sound & OpenAL / Re: JStella - Pitfall II sound is scratchy, but I don't know why on: 2007-09-29 23:40:53
Thanks.
Off the subject, how does your Sega Master System emulator work without OpenGL / native add-ons / etc.?
4  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-29 23:39:28
I'm not totally sure threading is a big problem at this point...the graphic slow down issues have been resolved.  Occasionally when loading a game, there will be a thread incident, but I think overall everything works well.  I agree that the threading situation is not legit, but I don't see the negative consequences at this point. 
Thanks for your help,
JLA
5  Java Game APIs & Engines / Java Sound & OpenAL / Re: JStella - Pitfall II sound is scratchy, but I don't know why on: 2007-09-29 01:28:36
I wonder if it has anything to do with "base amplitude", that is, the number I add to every sample value to prevent popping (or so I've been told).
6  Java Game APIs & Engines / Java Sound & OpenAL / Re: JStella - Pitfall II sound is scratchy, but I don't know why on: 2007-09-29 01:26:23
(Yeah, Pitfall II was the coolest game when it came out...so much better than the first.)

On the original (C++) Stella (ver 2.4.1) on my computer, the jumping sound is clear, while on JStella, it is very scratchy.  (JStella standalone has an option to use stereo, where the jumping and sound effects are separate from the music--the sound effects channel is scratchy as a whole).  Moreover, Pitfall 1 sounds are fine...on most ROMs, the sound is great.  A lot of people assumed Java couldn't do this type of sound, and I was skeptical as well, but it overall sounds very good (that is, sounds like the Atari sounded).  Except for this game...

Also, occasionally the emulator will play static/pops from manipulating the menu bar, etc.  I've tried to turn off the sound whenever it's paused to prevent this stuff, but I was curious if there was another way.
Thanks,
JLA 
7  Java Game APIs & Engines / Java Sound & OpenAL / JStella - Pitfall II sound is scratchy, but I don't know why on: 2007-09-27 23:12:27
Hey folks,
I doubt anyone can easily answer this question, but just in case someone wants an in-depth mystery to solve, I'll ask anyway:
I manage the JStella Atari 2600 emulator project at SourceForge.  It is a translation of Stella, which is open source C++ software.  The sound class is only a loose translation...I sort of had to do the main framework myself, learning about Java Sound as I went. 

Problem : Pitfall II has very scratchy sound, especially jumping, but Stella (its C++ parent) has decent sounds.   I can't figure out why...this may be a fault with another part of the emulator, but I figure the scratchy quality is indicative of some common phenomenon. 

If anyone wants to  hear the scratchy sound, visit http://www.ataritimes.com/jstella/index.php and select Pitfall II.  (Click on applet, then hit F1 to flip RESET switch).
Source code can be found by browsing CVS at https://sourceforge.net/projects/jstella.

Thanks,
JLA
8  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-27 22:56:28
The finer points of threading are currently over my head.  Do either of you want WRITE access to the CVS? (I am also unsure about Applet threads, e.g. calling an Applet method via JavaScript...I've heard that start(), stop(), etc. are executed by a different thread, but I really don't know how this stuff all plays together.
Thanks,
JLA
9  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-25 02:56:23
I just got word from one of the people who still had the slowdown, and he says that the newest version (0.8 - implementing the aforementioned changes) no longer slows down...that's good news.  Of course, there is still a lot of optimization that needs to be done, but I think one of the big hurdles has been jumped.  Thanks for your help.
JLA
10  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-24 19:25:48
So you suggest to just manually use TYPE_INT_RGB?  (This is what is returned as a "compatible image" with my setup.)

I used to have a lot of stuff synchronized, but I started eliminating them because I felt many of them were unneeded.  Every once in a while I'll get an exception thrown due to threads, but it isn't that often...I know thread handling needs to be tightened, but I figure I need to find where the blocking is going on first. 

I originally thought that the setRGB was blocking, but upon manual profiling, the delay seemed to be in a previous method call (in the same thread--the processFrame() method in JSTIA, called from JSConsole doFrame() method).  Maybe I'm totally wrong about the thread thing, but when the screen is large (i.e. the stand-alone window maximized), the paint-to-the-screen method would often take around 54 milliseconds (very long), and the processFrame() part in a different thread that immediately followed (well, actually called concurrently) would take the same amount, which is WAY too long...and when I did the createCompatibleImage thing, neither of them would last that long and so the problem was fixed for MY setup.   The processFrame() is just calculation stuff and shouldn't be dependent on the size of the emulator window or the rendering methods.  Or should it...?

Thanks
JLA
11  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-24 02:32:40
Whoops...hadn't updated the CVS when I made that last post...now it is updated.  I hope it doesn't mess things up...I am assuming that TYPE_INT_RGB, TYPE_INT_ARGB, and TYPE_INT_ARGB_(forgot what was here) are all the same general format, in terms of what color byte is located where.  If not, then some users may not be able to use the program...
JLA
12  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-21 03:30:31
I implemented something with getCompatibleImage thing that says if the type is an integer type with the equivalent RGB format, to use the method you suggested.  For those that get a non-equivalent type of image, it uses the old way of doing it.  I can't see a change on my system, but I never had a problem before, so there isn't much to see.  But from profiling using the nanoTIme feature, it appeared to me that the drawing to the back buffer wasn't necessarily the bottle neck, but instead it appeared that the bottle neck was the calculations part, but I think this was because it blocking due to the part that paints the back buffer to the screen...but I have no idea why it would block, because they are in separate threads.  This bottleneck and delay cleared up on my system when I originally did the getCompatibleImage thing, but it apparently hasn't on some other systems.  But this strongly suggested to me that the problem is in the graphics/threads.

I haven't been able to spend much time on it because of medical school, but if you (or whoever) want to become a developer on JStella, you would be more than welcome.  And you could experiment around with it.  There is a sort of fan-base for the software over at AtariAge.com, but they are more arcane assembly language than Java over there, so that's why I came here.   

JStella has had about 600 downloads over the past 8 or so weeks since its introduction. (This doesn't include people who play the JStella applet on websites) . The parent program Stella (in C++) averages about that many downloads in a day.  So a goal for anyone interested in promoting Java for desktop applications etc. (and helping prove Stevie Jobs wrong) would be for JStella to become competitive with its parent in popularity.  Let me know if you or anyone here is interested in becoming a developer on this SourceForge project...
Thanks again
JLA
13  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-18 02:06:46
Thanks again for your help.
As far as the getDataBuffer() stuff goes, what do I do if I create my BufferedImages via createCompatibleImage method in the toolkit?  I really have no way of knowing what the data type of the image is going to be (byte, int)...although I'm pretty sure my system generates ints.  Would I have to forgo the createCompatibleImage() method?

Thanks
JLA
14  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-15 10:30:09
Thanks for looking at the code.   

I'm not familiar with how Java does hardware/software rendering...as it is now, it checks to see if a pixel in a virtual buffer is different than the new one, and only if it is does it call setRGB.  So this means that some frames will do this for every pixel, while others will only do it for 10 or so...would the DataBuffer technique be faster (or equal) in both cases?  And should the emulator do hardware acceleration?  Everything about the emulator is flexible...well, except for the caveat (my own preference really) that it be pure Java.

As far as the painting of the back buffer goes, it does use clipping/dirty-rect technique, but does so through the repaint command...
e.g.
1  
repaint(rectangleThatNeedsToBeRepainted);
  I assume this works as I think it does, because when there is a busy frame (with different parts of the frame needing repainting), it takes a lot longer to paint.

And while I'm at it, what do you know about Toolkit.sync()?  Someone seemed to suggest it was necessary for Linux animations.  I think the current  version uses it, but I don't know if it slows stuff down, is unnecessary, etc...

By the way, if you want to check out the performance of the JStella applet, there is currently an applet set up at http://www.ataritimes.com/jstella/index.php.

Thanks again
JLA


15  Java Game APIs & Engines / Java 2D / JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-13 00:41:26
I manage the JStella project at SourceForge (at http://jstella.sourceforge.net).  JStella is an Atari 2600 emulator written in Java.  It is based on the open source Stella software, which is written in C++.  I translated Stella into Java mainly to prove wrong the people who said that it would not work well in Java.  And I think I have been largely successful in this...it currently runs just as well as the C++ on my computer.  But I really don't think it's optimized...I'm not a Java2D expert, or a Java performance person, and I think there is a lot of stuff relating to graphics in the code that causes it to not be as fast as it should.  (For example, I just found out about the createCompatibleImage method...that improved performance on my machine dramatically, but apparently not so much on other machines.)

I use clipping, so the main problems are when things on different parts of the screen get changed.  There is some slowdown...it slows down the virtual CPU (of the Atari) as well, which seems to me like somehow the code in the "calculation" thread is blocking while waiting for the thread that does the painting to finish...is this normal?  Of course, I may be completely wrong.  But if any Java2D pros out there want to look at it, contribute, etc., I (et al.) would be grateful.  (You can go to the JStella project page on Sourceforge and check out the CVS repository, where all the most recent source code is...the downloadable source code is a few weeks old.)
JLA
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (39 views)
2014-07-18 06:55:21

Zero Volt (36 views)
2014-07-17 23:47:54

danieldean (29 views)
2014-07-17 23:41:23

MustardPeter (32 views)
2014-07-16 23:30:00

Cero (47 views)
2014-07-16 00:42:17

Riven (48 views)
2014-07-14 18:02:53

OpenGLShaders (38 views)
2014-07-14 16:23:47

Riven (37 views)
2014-07-14 11:51:35

quew8 (33 views)
2014-07-13 13:57:52

SHC (70 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!