Well, I'm bored so I'll throw some more links at you;

This is the best peice I have ever read about software rendering.

There are alot more interesting articles at the same place.

Quote:
The hardware blitting that redmilamber mentioned has some major limitations wich makes it irrelivant for your case. Basicly you can only draw static images. Would be great if you did a tiling 2d game, but is less usefull in most other cases.

It only makes it irrelevant if you don't bother to try take advantage of it. I said you had to be cunning; I've seen plenty of situations where developers WERE cunning, and managed to get not quite the best of both worlds, but certainly noticeable performance improvements.

Also, c.f. Chet's article:

"Developers that care about top performance for these types of images may want to look into using VolatileImages instead. These images store the data in accelerated memory (when possible) and thus rendering to and from that image may be accelerated automatically. The downside is that these images require a bit more care and feeding, due to "surface loss" issues that arise with current video memory architectures and operating systems. Note that not all types of rendering to these images is accelerated, either, but simple types of rendering like lines and rectangular fills and copiescan usually be accelerated, depending on the platform configuration."

...so, with a bit of refactoring of your rendering, and a bit of cunning, and a tiny bit of effort to handle surface loss, you can make at least *some* use of hardware.

For instance, I've seen people often think of ways to replace per-pixel effects with pixel-tile effects. As one example, if VNC's authors had taken AP's approach and given up, then it would never have worked: instead, they decomposed their rendering into hextiles.

For the game engine, you should be able to work out some patterns of pixels that are often used and blit them - or even use the primitives (like line-drawing) directly onto a VolatileImage. etc.

Quote:Original post by Rocket05
oh yeah, the reason that we dont just use an OpenGL or java3d binding is that we're trying to target the broadest range of computers possible, not just gaming computers, and we're trying to make the game fast enough to run even on (today's) low end machines, i.e. about 700mhz with a generic video card (what most of our school computers have, where software 3d is faster than opengl).

I appreciate your predicament, and the fact that your school has a lot of computers with a particular configuration, but bear in mind also that most people with sub-1Ghz PC's IME seem to have 3d cards in there, usually a cheap ATI RagePro-based chip (they were very common in mass produced home user and corporate PC's for a long time in the P-2 and P-3 days), or a TNT2, or a Matrox G200 derivative. All of these are much faster than CPU rendering until you buy a CPU circa 2.5 Ghz, IIRC.

They're crappy, but worth using if you can.

redmilamber

Quote:Original post by nonnus29
To modify the pixels of an image the image must reside in main memory which is ALOT slower than vram (obviously).

No, only if you use certain image types. It is possible to modify images in VRAM, but java has only limited support for doing so.

Basically, you are stressing the efficiency of the AGP bus when you do so - but note that the AGP bus has a lot of bandwidth to spare on upload to the card, and latency is good (though not excellent).

So, it's worth trying. Obviously, it's best to blit to VRAM if you can, since this is effectively batching bus data, i.e. making using of the fact that AGP bandwidth is a heck of a lot better than AGP latency.

Quote:oh yeah, the reason that we dont just use an OpenGL or java3d binding is that we're trying to target the broadest range of computers possible, not just gaming computers, and we're trying to make the game fast enough to run even on (today's) low end machines, i.e. about 700mhz with a generic video card (what most of our school computers have, where software 3d is faster than opengl).

Then you definitly want AWT/MemoryImageSource. You can always check the java version and load a rendering class that uses BufferImage/getDataBuffer() for users that can use it.

Or do everyone a favor and redirect your users to the sun site to download a current JRE.

What ?!?!? He said that they have low hardware, NOT low JRE's.

If in doubt, you should be using a managed BufferedImage for everything, since they are accelerated if they can be, and there's generally no penalty if not.

My bad, I misread that part.

Quote:For instance, I've seen people often think of ways to replace per-pixel effects with pixel-tile effects. As one example, if VNC's authors had taken AP's approach and given up, then it would never have worked: instead, they decomposed their rendering into hextiles.

Whats the VNC of which you speak?

On windows, even for managed images DirectDraw is used (until java 5 final when opengl will be use?) so even 2d tile blitting isn't THAT fast especially now that newer cards have poorer support for 2d blitting than the old cards.

But most likely attempting to optimize your technique for certain hardware/paths can make the finished product nonportable. So... yes, managed BufferedImages for software rendering, I'll go along with that.

Quote:Original post by nonnus29
Whats the VNC of which you speak?

The original free remote-desktop program, which has versions available for most OS's and even a java version, so you can fullscreen to any other computer from your own one as if you were sitting there.

Obviously, sending 1024x768 (or more!) 24 bpp even over a LAN 20 times a second (minimum not to get really annoyed) is not easy. So, VNC used a lot of tricks to compress data based on domain-specific knowledge (e.g. most windowing systems use windows etc).

java sucks so hard in per-pixel stuff it simply isnt funny anymore.

you definitly want to do your effects in ram and then pump them over your agp bus in one go. SDL does it in a fraction of the time java did, and believe me ive tried.

exploiting hardware might be a good idea indeed tho. blitting scaled collumns of your textures should be possible in your situation, and i think thatd give a huge speedboost.

It's basically all been covered, but it depends on the version of java you are running. MemoryImageSource for 1.1, and BufferedImage for others. I've been writing a software 1.1 engine in my spare time. I've tried just about every trick, but MemoryImageSource is the fastest for what I was doing. I tried writing my own, but it didn't speed up my application.

http://www.freestandingentertainment.com/chance/test3