Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
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 04: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 04: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.   
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 21:40:53
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 21: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,
5  Java Game APIs & Engines / Java Sound & OpenAL / Re: JStella - Pitfall II sound is scratchy, but I don't know why on: 2007-09-28 23: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-28 23:26:23
(Yeah, Pitfall II was the coolest game when it came 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.
7  Java Game APIs & Engines / Java Sound & OpenAL / JStella - Pitfall II sound is scratchy, but I don't know why on: 2007-09-27 21: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 and select Pitfall II.  (Click on applet, then hit F1 to flip RESET switch).
Source code can be found by browsing CVS at

8  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-27 20: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.
9  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-25 00: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.
10  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-24 17: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...?

11  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-24 00:32:40
Whoops...hadn't updated the CVS when I made that last 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...
12  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-21 01: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, 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
13  Java Game APIs & Engines / Java 2D / Re: JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-18 00: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?

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

I'm not familiar with how Java does hardware/software 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...
  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

Thanks again

15  Java Game APIs & Engines / Java 2D / JStella - Atari 2600 emulator in Java - performance issues on: 2007-09-12 22:41:26
I manage the JStella project at SourceForge (at  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 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 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 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.)
Pages: [1]
DesertCoockie (20 views)
2018-05-13 18:23:11

nelsongames (68 views)
2018-04-24 18:15:36

nelsongames (65 views)
2018-04-24 18:14:32

ivj94 (749 views)
2018-03-24 14:47:39

ivj94 (79 views)
2018-03-24 14:46:31

ivj94 (595 views)
2018-03-24 14:43:53

Solater (95 views)
2018-03-17 05:04:08

nelsongames (168 views)
2018-03-05 17:56:34

Gornova (378 views)
2018-03-02 22:15:33

buddyBro (1038 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!