Charles Rector

Greenhorn
+ Follow
since Feb 18, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Charles Rector

Got this puppy figured out! Efficient diagonal scrolling baby!

Here's a link: CustomViewport.java

Primarily of interest are the computeBlit(), computeBlitRects(), windowBlitPaint() and blitDoubleBuffered() methods. I didn't pay too much attention to any of the other methods. I don't think blitDoubleBuffered() is tied to setDoubleBuffered(), but I could be wrong. I think regardless of the scroll method, it always tries to use a VolatileImage back buffer so that all your rendering isn't taking place directly on visible video memory (slooow).

The key modification was arranging everything so that blitDoubleBuffered() could refresh more than one rectangle (well, 2 basically) when scrolling diagonally, ie. the L-shape area which just scrolled into view. To compute the refresh rectangles, I added the computeBlitRects() method. I also modified the computeBlit() method so that it would return true when a diagonal scroll was detected. The computeBlitRects() method is called when a scroll is detected in windowBlitPaint(), and I modified the parameter list for blitDoubleBuffered() to accept an array of rectangles rather than a single rectangle (the clip arguments.) A few dozen tweaks to blitDoubleBuffered() and computeBlitRects() later, I finally broke down and reasoned out what I was doing and then it was all good. ;-)

I tossed in some comments here and there where I thought they might do some good. But I figure anybody with a reason to use this class probably already has a head on their shoulders well enough to use and/or modify it further. Speaking of which, hopefully someone else will find this useful!
19 years ago
Wow, so someone else has actually run into this problem. Many thanks for the link, Ilja! Gregg, I'm surprised I was able to myself, to tell the truth. I give all the credit to stubbornness.

Reading the bug listing was a hoot. They mention subclassing JViewport is not easy, and let me tell you: it ain't. However! I am just *this* close to having a subclassed JViewport that scrolls diagonally quickly. I basically copied the entire JViewport source, then tossed as many methods as possible, leaving only paint(), windowBlitPaint(), and a bunch of other private support crap.

It scrolls great so far, except for some artifacts trailing from the corners (all except the lower right, for some reason). As soon as I have a working version I'll link to it, for anybody that's interested.
19 years ago
After digging around even further, I found the actual reason why diagonal scrolling causes full repaints. JViewport's paint() method only takes into account one rectangle when drawing the newly exposed area. Its computeBlit() method returns false for diagonal scrolls, which means "cannot do a partial blit" and a full repaint is triggered. On the bright side, I may be able to override some methods to get diagonal scrolling working. On the not so bright side, I might have to override a lot of methods. Ah well!
19 years ago
Well, I was able to roll my own solution. It took a little while, but it was educational at least. Having dug through all the machinery behind JViewport, I'm just about convinced rolling my own is a better solution for my particular case. The diagonal scrolling is now just as quick as vertical and horizontal scrolling, but it's a little bit faster overall as well.

I'm still baffled as to why JViewport is triggering those full repaints when scrolling diagonally. Slower or not, just using a JScrollPane would've been less work than writing my own! If anybody is good and familiar with JViewport's refresh mechanics, I'd be very interested to know what the deal is!
19 years ago
Heya!

As far as character movement, I've been using the second method for a long time now. I personally think it's a lot simpler and more flexible than the first method you mentioned. Speed only becomes an issue if you've got a lot of characters onscreen at once. Even in that situation, there are ways to speed up processing with caching and other little tricks. But cross that bridge when/if you get to it!
19 years ago
I've got a large scrollable view tied to a minature view, where if you drag the mouse around the minature view, the large view scrolls as well to match it. If anybody has Paint Shop Pro 8, it's much like the Preview pane. For maximum rendering speed when scrolling, I call the scroll pane viewport's scrollRectToVisible() method when adjusting the viewport position. When dragging perfectly horizontally or vertically against the edges of the miniature view, the speed is excellent and only partial repaints are occurring. However, when dragging diagonally or erratically (in increments smaller than the viewable area), lots of full repaints are triggering and I can visibly see the large view refreshes slow down as a result. Is there any way to avoid these full repaints?

As I understand it, ultimately the speed scrollRectToVisible() offers is due to calls to Graphics.copyArea() which can quickly "shift" the center(ish) region of what has already been painted in an appropriate direction, after which the viewed component's paint() method is called, with a clipping region that constitutes what areas of the viewed component have just scrolled into the viewport. I've done a few tests using copyArea() for "infinite scrolling" of a pattern, and it seems to behave exactly as I would expect it to for diagonals. That being the case, I don't understand why I'm getting these full repaints when scrolling diagonally in relatively small increments with scrollRectToVisible().

Any help is appreciated!
19 years ago
Right, the creation of tools. I'm working on a tile-based map editor and there are about a million topics I'd love to discuss. I could talk forever on rendering alone, such as how to make threaded rendering play nice with the GUI when doing things like focused zooming, what the pros and cons of different caching algorithms are, and what kind of rendering algorithms degrade well when animating a full screen of 1600x1200 tiles on multiple layers. :-)
19 years ago
What about killer game-related tools, like for editing maps and stuff? Is that fair game also?
19 years ago
If I create a JFrame and then drag a component over it, it constantly clears the "damaged" area of the JFrame with its background color before repainting. To make the behavior more noticeable as I was trying to alleviate it, I set the background color to red. Repainted areas became VERY evident, especially when dragging windows from other apps over the frame, and even more especially when the OS is set to repaint window contents while dragging, instead of the outline dragging method. No matter what I seem to try overriding, the clearing still occurs.

Even without the red, this behavior really annoys me. It looks ugly and unprofessional and I really don't see why JFrame seems to think it's necessary to clear the background at all. It always gets completely painted over in the end anyway.

Is there any way to stop this clearing from happening? I've tried overriding update() and paint() and many other things without much luck.
19 years ago
Whether or not you can append your own personal properties to a file depends upon the format of the file in question. Some file types perform exhaustive checking for validity, whereas others are more lenient.
In any event, you'll want to research the file formats you're interested in dealing with. If you're looking for a mechanism which can be applied to all files, regardless of type, it may be a better option to create separate files which complement existing files.
For example, if you have an image named "moose.jpg", your program could create a counterpart for it named "moose.jpg.properties" which would be a normal text file. In your program you could then grab all the filenames in a folder and check for any matching ".properties" filenames. Any files with matches would be the ones which have custom properties specified.
21 years ago
They are loaded on demand (when their containing class is used in some way), and then persist for the duration of the application.
21 years ago
I believe the .class files will have been created in the com/project/databases/ folder.
21 years ago
I've been delving into a bit of game-related development lately, and I have thread which constantly renders an offscreen buffer to a panel. I'm emulating 80x25 text-mode, so 16-colors are available (4-bit IndexColorModel). I had quite the time figuring out how to get fades to work smoothly, both in speed and quality, but now I've got most everything working how I'd like.
My only gripe is, whenever performing fades, I must recreate the offscreen image (a BufferedImage) with the altered ColorModel each step along the way. This eats up a couple megs worth during each fade. That wouldn't even particularly bother me, except that it causes the garbage colletion to trigger every so often, and my fades will ungracefully pause.
If I call System.gc() before each fade, I get the wait up front and then the fades are always fine, but I'd really rather just figure out how to switch the color model without having to reallocate memory, ie. a more elegant solution. I do realize that I might not always be able to avoid these kind of pauses in my Java apps, but I can at least take some preventive measures. :-)
A ColorModel is just a rule for color conversion after all, right? It seems rather silly that there wouldn't be some simple mechanism available for swapping out different ones. Perhaps right under my nose? Wouldn't that be swell...
So far I've been unable to find anything that does what I want, and I've been picking through the API for I don't know how long (okay, a couple weeks in my spare time). I've also surfed around quite a bit, in search of some example code doing anything similar, but the only example I did find was something to do with fractals and palette rotation -- but it also regenerates the image every frame.
Any help/hints anyone can offer would be much appreciated!
21 years ago
I've been delving into a bit of game-related development lately, and I have thread which constantly renders an offscreen buffer to a panel. I'm emulating 80x25 text-mode, so 16-colors are available (4-bit IndexColorModel). I had quite the time figuring out how to get fades to work smoothly, both in speed and quality, but now I've got most everything working how I'd like.
My only gripe is, whenever performing fades, I must recreate the offscreen image (a BufferedImage) with the altered ColorModel each step along the way. This eats up a couple megs worth during each fade. That wouldn't even particularly bother me, except that it causes the garbage colletion to trigger every so often, and my fades will ungracefully pause.
If I call System.gc() before each fade, I get the wait up front and then the fades are always fine, but I'd really rather just figure out how to switch the color model without having to reallocate memory, ie. a more elegant solution. I do realize that I might not always be able to avoid these kind of pauses in my Java apps, but I can at least take some preventive measures. :-)
A ColorModel is just a rule for color conversion after all, right? It seems rather silly that there wouldn't be some simple mechanism available for swapping out different ones. Perhaps right under my nose? Wouldn't that be swell...
So far I've been unable to find anything that does what I want, and I've been picking through the API for I don't know how long (okay, a couple weeks in my spare time). I've also surfed around quite a bit, in search of some example code doing anything similar, but the only example I did find was something to do with fractals and palette rotation -- but it also regenerates the image every frame.
Any help/hints anyone can offer would be much appreciated!
21 years ago