Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (843)
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 / J2ME / T720 drawString() bug on: 2003-07-16 23:18:37
Hey guys,
 I just submitted this bug to Motorola.  Anyone developing for the T720 should watch out for this as I lost a day trying to nail it down.  Note that this only works on the phone: no emulators reproduce it.
 The problem is that Graphics.drawString() isn't properly clipped.  Drawing a string near the bottom edge of an image appears to corrupt memory and will crash the KVM once you try to do anything important with it.

Sample code:
Image img = Image.createImage(50, 4);
img.getGraphics().drawString("Howdy", 5, 7, Graphics.LEFT|Graphics.BASELINE);
Image.createImage(img);  //crash

If someone here is clever enough to use this bug to write to the memory space outside the KVM and hijack the phone, please post your results in this thread. :)
2  Java Game APIs & Engines / J2ME / Re: Curious.. on: 2003-06-25 00:13:13
Go here:

Yes, you want the Wireless Toolkit.  Yes you want jEdit for an editor.  If you don't believe me, find your own answers.  Sun's site has plenty of them :)
3  Java Game APIs & Engines / Java 2D / Re: Is smooth animation in an applet possible? on: 2003-06-03 16:54:05
If it's Java 1.1 you're using, maybe I can help.

First, if your applet has a lot of moving objects, don't even try to go above a 550x400 res.  This is about the bleeding edge for an applet that wants to do large graphics updates and still maintain 20 fps.  Of course, smaller always runs faster.

Also, for maximal graphics performance, you'll need to implement your own ImageProducer.  All you do with this is duplicate functionality of MemoryImageSource, but it will run 20% faster, and should only take an hour or so to implement.

Anyway, I guess your real question is timing?  Yes, this is tricky, but not impossible.  First, recognize that different platforms have different timing resolutions, but they're consistent: that is, win98 will only return System.currentTimeMillis() in multiples of 50ms, WinNT/2000 returns in multiples of 10ms, etc.
 So 50ms resolution would normally hose your chance of getting robust 20fps, right?  Here's the trick: don't sample the time every frame.  Sample it, say, every 10 frames and then compare the current time to where you expected to be.  How you work with this is up to you.  TheLorax posted code a while back that takes advantage of this, and many people here use it (someone else repost it plz?).  That code attempts to keep a fixed framerate by estimating the amount of time you spend sleeping each frame, and then adjusting that time every 10 frames or so based on whether you've slept too much or too little over the past 10 frames.  The problem with this is that your applet must have a relatively constant CPU use or time will be noticably inconsistent.  I'd recommend writing your own class which governs your applet's sleep time based on this principle.
 Good luck.
4  Game Development / Performance Tuning / Re: 1.1 performance renderer on: 2003-03-10 17:43:24
Hey guys,
 Thanks for the help.  The ImageProducer wasn't that hard to implement (thanks NielsJ and erikd), and is buying me about a 20% speed increase.  That could be because it's allowing me to draw 20% fewer unnecessary pixels.  Regardless, it's good to see these gains.
5  Game Development / Performance Tuning / Re: 1.1 performance renderer on: 2003-02-25 00:53:12
 Maybe it would help if I was more specific, eh?
-no important code is taking place in synchronized() or try/catch blocks
-most of this code is running in a separate thread from the browser
-full window updates (all 550x400 pixels) are, unfortunately, necessary

Here's a speed breakdown.  In a 40 ms frame:
14 ms - newPixels()
17 ms - drawImage()
8 ms - renderer fooling around with the int[] m_pixels

This leaves a sad 1 ms/frame for other game code.  Is it possible I'm hitting a bus bandwidth limitation?  I'm at a loss for further ideas.  Any expert advice is most welcome.
6  Game Development / Performance Tuning / 1.1 performance renderer on: 2003-02-25 00:38:23
Hey guys,
 I'm trying to write a high-performance Java 1.1 renderer for a 2d game and am having some frustrations.  Things run okay, but I'm convinced there are more efficient ways to push image data around within Java.
Here's what the renderer does:

DirectColorModel cm = new DirectColorModel(24,0x00ff0000,0x0000ff00,0x000000ff);
mis = new MemoryImageSource(m_width, m_height, cm, m_pixels, 0, m_width);
m_image = GetAppInstance().createImage(mis);

Then, for every frame, the renderer writes to the m_pixels int array, calls mis.newPixels() and repaint()s.  When Applet.paint() is called, it does a g.drawImage(mis, 0, 0, null).

The problem is that, in 550x400 at 25 fps, the newPixels() call takes 1/3 of a frame, and the drawImage() takes about 1/2.  This only leaves a 1/6 of a frame for the game to do its real work.  Does anyone know if this is normal?  Is it possible to combine these two calls?  This is a painful overhead.
 Thanks for your help.
Pages: [1]
EgonOlsen (37 views)
2018-06-10 19:43:48

EgonOlsen (20 views)
2018-06-10 19:43:44

EgonOlsen (39 views)
2018-06-10 19:43:20

DesertCoockie (186 views)
2018-05-13 18:23:11

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

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

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

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

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

Solater (139 views)
2018-03-17 05:04:08
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!