But that's not the point. The point is, that one is using software only mode for the reason that it works on each and every hardware/JavaVM there is. No need for OpenGL, no need for a fancy graphics card...plain and simple. If you add a kind of hardware acceleration via OpenGL to the mix, but are still doing rendering in software, you are getting the worst of both worlds: You are still not much faster than software (if even, YMMV) with the same pixelated look but you get all the problems that arise from using a third party, native library that relies on some hardware and proper driver support to be present. If you can ensure that a system meets the requirements you can already use OpenGL to the fullest. There's no need anymore for a half baked acceleration approach. Even more so because PBOs are a relatively new extension and every hardware that supports it is able to use jPCT's hardware mode.There's only one exception, which may to a degree apply to your game: I can make sense if it's not possible to directly translate what the software renderer is doing to what the hardware can do. Voxel graphics would be an example, raycasting may be another one. So if you can't or won't change the underlying rendering algorithm and it differs from what hardware offers, your approach may help to improve things. For jPCT, this is not true, because the software renderer does exactly the same as the hardware does: It renders arbitrary textured and vertex lit polygons.

the software renderer does exactly the same as the hardware does: It renders arbitrary textured and vertex lit polygons.

The rest of what you said is right, the last sentence is not true or I don't really understand what you mean. Under OpenGL, it is more complicated. You can eliminate plenty of data at different steps, I think about the clipping, the z-buffering. For example, TUER uses software (in the slow mode) z-buffering and hardware (in the experimental mode) z-buffering. But what do you mean when you use the term "arbitrary"?

With "arbitrary" i meant polygons of any size or orientation. jPCT uses bascially the same culling algorithms in software mode as it does in hardware mode. The software renderer does exactly the same things as the hardware renderer does. Just at a slower speed and with lower filtering quality (plus the hardware one supports more features, but that's only a problem when switching from hard- back to software, not vice versa). What i tried to say was, that for such an engine pimping the software mode with some hardware features is pointless, but for a raycaster or something similar, it may not. Because otherwise, you would have to rewrite the engine from scratch to make proper use of hardware rendering, which seems to be what you are doing with TUER.

With "arbitrary" i meant polygons of any size or orientation. jPCT uses bascially the same culling algorithms in software mode as it does in hardware mode. The software renderer does exactly the same things as the hardware renderer does. Just at a slower speed and with lower filtering quality (plus the hardware one supports more features, but that's only a problem when switching from hard- back to software, not vice versa). What i tried to say was, that for such an engine pimping the software mode with some hardware features is pointless, but for a raycaster or something similar, it may not. Because otherwise, you would have to rewrite the engine from scratch to make proper use of hardware rendering, which seems to be what you are doing with TUER.

Yes, excellent analysis and the game turns at between 142 and 200 FPS on my machine . But Bloodridge turns very fast only on very recent machines which may have quite good graphics cards. Then, software rendering is independent of the hardware, what are the other advantages of using software rendering according to you? Quicker start? Better reliability? Something else?

Then, software rendering is independent of the hardware, what are the other advantages of using software rendering according to you? Quicker start? Better reliability? Something else?

Software rendering doesn't depend on good OpenGL support, so it will also run reliably on machines without OpenGL drivers.As far as I'm concerned, software rendering for 3D action games as a fall back when hardware rendering fails is a 'nice to have' at best, unless the 3D world is so simple that software rendering might still provide playable speed.

Also, the whole window is tall and narrow - approx 900 pixels wide by approx 1100 pixels high, and the character is standing at the right edge of the screen, as if it THINKS the screen is twice as wide.

But, sadly, you have committed one of the cardinal sins of bad web design - you've made a popup window of fixed size, so I physically cannot drag the window to be the correct size .

So ... I hope that's a momentary problem, because I'd like to have a proper go at this, it looks good.

Also, the whole window is tall and narrow - approx 900 pixels wide by approx 1100 pixels high, and the character is standing at the right edge of the screen, as if it THINKS the screen is twice as wide.But, sadly, you have committed one of the cardinal sins of bad web design - you've made a popup window of fixed size, so I physically cannot drag the window to be the correct size .

The window should be fullscreen! I've tested up to 1600x1200 with no problems - did you change the screen size after starting the game? Doesn't the window fill the screen?

I'm getting 20fps with both normal and high quality graphics with my Athlon XP 3200. Maybe the method does not work so well with blah's JVM and setup (maybe) - I had that once where Linux was terribly slow with certain AWT methods.

I'm getting 20fps with both normal and high quality graphics with my Athlon XP 3200. Maybe the method does not work so well with blah's JVM and setup (maybe) - I had that once where Linux was terribly slow with certain AWT methods.

No AWT is not terribly slow under Linux, that's wrong. I use Sun's JVM and I have no problem. It might come from your JVM.

EgonOlsen, have you tried the 3DzzD engine? They managed to blur the textures when the polygons are very close to the view point.I noticed that in bloodridge, although the renderer attempts to smooth the texutre, they still look quite pixelated. Does jpct provide any functionality that truely smooth the texutre like what opengl does?

Does jpct provide any functionality that truely smooth the texutre like what opengl does?

No, the software renderer does Unreal-engine-style-dithering, no real filtering. You can combine that with anti-aliasing and it looks similar to real bilinear filtering, but that will of course cost performance due to the AA-overhead.

That is a good question; once I noticed I removed any trace of it. It might have been a particular active rendering method, but I really can't remember - plus I didn't use my normal user name on irc so I can't search the logs for it. But awt can eat away time with graphics, just look at using BufferedImage.setPixels, or whatever method it is.

That is a good question; once I noticed I removed any trace of it. It might have been a particular active rendering method, but I really can't remember - plus I didn't use my normal user name on irc so I can't search the logs for it. But awt can eat away time with graphics, just look at using BufferedImage.setPixels, or whatever method it is.

I know that the class called "PixelGrabber" has a method called "grabPixels" which is very slow. The drawing methods is the class called "Graphics" are slow too. AWT is faster than Swing but more limited. Don't forget that AWT operates now with Java2D and JOGL, then it is not so slow and it is not slower under Linux than under Windows.

Astonishing! My machine is nowhere near as good and I get 20fps! (12fps with 'high quality' graphics)The window should be fullscreen! I've tested up to 1600x1200 with no problems - did you change the screen size after starting the game? Doesn't the window fill the screen?

No changes to screen size, and as I said it nowhere near fills the screen.

All bog standard, but this doesn't give you a fullscreen window? What OS/browser are you using? And you say 3-6fps? I'm really puzzled - I wrote the game with the idea that it would work anywhere - why not on your (really good) system?

I'm sure there's no bottlenecks - What's really puzzling me is why the window isn't fullscreen - I'm not convinced this is a rendering problem, more of a browser related issue is my guess...

Hmm, well if you can be sure that the same code is being executed on all computers then couldn't the only place you can expect to be causing such dramatic slowdown be in some API call? At least with such a high slowdown factor, I mean my machine doesn't even come close to that one and it's pushing 20fps on both low and high quality, in fact there was pretty much no difference in performance between the two!

Well I'm sure it shouldn't take too long to get to the bottom of this, it'll probably be something you laugh about in the future

Hmm, well if you can be sure that the same code is being executed on all computers then couldn't the only place you can expect to be causing such dramatic slowdown be in some API call? At least with such a high slowdown factor, I mean my machine doesn't even come close to that one and it's pushing 20fps on both low and high quality, in fact there was pretty much no difference in performance between the two!Well I'm sure it shouldn't take too long to get to the bottom of this, it'll probably be something you laugh about in the future

The game is pegged to 20fps max. My guess is that because the window isn't fullscreen and the screen is so large, the clipping required in the blit stage is slowing everything down... I'd love to know what browser/OS blahblahblah is using!

The game is pegged to 20fps max. My guess is that because the window isn't fullscreen and the screen is so large, the clipping required in the blit stage is slowing everything down... I'd love to know what browser/OS blahblahblah is using!

I spoke about the fullscreen mode with Kenneth Russell. It doesn't hugely improve performance. Don't expect to have a noticeable increase of the FPS if you succeed. The problem with software rendering is that the amount of computation increases more than proportionally with the number of pixels to handle. I'm surprised that someone gets the same performance both on low and high quality.

Your game is still so pleasant! so fun! But there is a problem. When I used the multiplayer arenas, sometimes the humans "merge", two humans make together as one, they are so close that they go through one another

Thanks to a local development grant Bloodridge has got some funding - not much, only £1000 ($2000) - but it's something! The question is; 'How do I spend the money?'The options are: better artwork, implementing multiplayer or improving AI/gameplay.

Excellent; well the best thing to do is not to just spend it but to store it for the project's use. When you have a time where you definitely need it for the project then use it, for now just keep it in the project's account.

java-gaming.org 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‑gaming.org