Ehrm you don't want to do that, because you don't want java to decide when java will paint something on screen. At least for games, which is usually the scope here at tdc. You want active rendering and probably with a double buffer. On which is currently being displayed and the other one to draw on. Which is easy once your image is loaded and the graphics object is know. Just use the drawImage() (see note for html link) method for the graphics class, even better the Graphics2D class.
After all drawing has been done, flip the buffers et voila. No just try to limit this process to say ... 60 fps?
sorry, you obviously don't understand how java does its rendering. or how rendering is done in general.
if you make continious calls to paint "active rendering" you are using unnecessary cpu, and will slow down your game even more than it might if you only render when the entire scene has been rendered. this is how java works. you make a call to repaint which is like telling java "hey i would like you to draw my scene now" and java either says "okay!" or "look, im not even done drawing the last scene yet, let me finish then i will draw your new scene". this is a lot more efficient, and what makes java a great platform. or you can implement your own way of determining when to paint, and just call your own paint method directly. but you should never just continuously call any rendering method. I was just giving Sketchy an example of how easy drawing in java CAN be.
as for double buffering, this is also very simple. it is a bit more complicated than drawing itself so i wont show an example, but yes, you draw to a surface that is not visible, then draw that surface to the screen (flipping the image).
because of both of these, flicker is almost non existent.
and about limiting it to 60 fps. You actually really should seperate your Frames per Second and your Updates per second. you can still be updating at your preferred rate, but draw at a slower rate if the resources are not available. this way all logic is still done and the game doesnt skip a beat. logic should never be tied to the games rendering.
Originally Posted by Chris Street MMF3 development hasn't started yet; I believe Clickteam are planning though.
Says who?
If I remember correctly they mentioned at the convention that they had a list of things they wanted to implement in MMF3. In the Questions and Answers segment.
Originally Posted by The Cecilizer I was just giving Sketchy an example of how easy drawing in java CAN be.
Yeah, it does look pretty easy. HTML5+JS still seems a little easier, because javascript is so simple, and because of all the things the browser does for you (double-buffering is not required, for example).
Obviously I'm not saying HTML5 is "better" - it's too much like comparing apples and oranges.
Originally Posted by Chris Street MMF3 development hasn't started yet; I believe Clickteam are planning though.
Says who?
If I remember correctly they mentioned at the convention that they had a list of things they wanted to implement in MMF3. In the Questions and Answers segment.
That's over a year ago almost maybe Development has started, but it is still in a very early stage.
Have you even been far as decided to use even go want to do look more like?
Originally Posted by The Cecilizer
sorry, you obviously don't understand how java does its rendering. or how rendering is done in general.
Perhaps I am reading your post wrong, but what part don't I understand? That is, you don't want active rendering because it will be using all cpu/gpu power for a game? Isn't that a matter of choice?
I know of implementing time-steps, decoupling the main game loop from your render and indirect rendering, but probably I don't want that and you do.
My purpose was also showing how easy drawing in java can be, just like the drawImage() function in html5 which was more or less modelled after java's function. But I also wanted to show a different point of view on the rendering process, that's a little habit of mine with no harm intended. I just want to give some more information so the big picture might become clearer.
But perhaps you can then explain it to me, because I don't know what's wrong with drawing on a buffer and then flip the buffer on screen?
Perhaps I am reading your post wrong, but what part don't I understand? That is, you don't want active rendering because it will be using all cpu/gpu power for a game? Isn't that a matter of choice?
a pretty bad choice if you decide to let your game just hog cpu/gpu.
I know of implementing time-steps, decoupling the main game loop from your render and indirect rendering, but probably I don't want that and you do.
again a pretty bad choice if you decide not to. not as bad as above, but it makes things a lot easier to maintain and scale.
But perhaps you can then explain it to me, because I don't know what's wrong with drawing on a buffer and then flip the buffer on screen?
I...never said anything was wrong with double buffering...??? O_o