[quote=“gouessej,post:80,topic:29395”]
Er… I don’t think so - I let Egon worry about that sort of stuff, he’s the expert! I just build Object3Ds and throw them to jPCT. I’m still really impressed at the durability of jPCT - so far not one rendering or display issue reported from hundreds of plays. I know you can do alot more with openGL (have you seen BangHowdy BTW? http://www.banghowdy.com/launch.html Quite impressive!) but software rendering ‘just works’. No bugs==happy me!
If it is a critic about my game, that does not make me laugh. “Art Attack”, the ancester of “TUER”, uses software rendering and the author had had a some problems of division by zero like me with hardware rendering. This means that the reliability of an engine doesn’t depend on the fact it uses software rendering or not.Then, software rendering can have bugs too, you’re not open minded enough. I wanted to give you a little advice because I know that you use jPCT and you prefer saying that it’s not your problem, it’s good as it is. That’s not my fault if Microsoft has no interest of helping OpenGL developers to use OpenGL under Vista (because Microsoft prefers promoting DirectX) or if OpenGL doesn’t like multi-thread. You’re at least two on this project whereas I’m alone, my alpha testers are in holidays, I don’t have internet at home, I update my files at work and the hardware part of my engine has been written from scratch. I find your game impressive and I thought it would be fine if you could easily increase the performance. I had no bad intentions.
Finally, (almost?) ALL commercial games use hardware rendering. You know why.
Hi Juien,
Absolutely no criticism intended - didn’t mean to offend you - I think TUER is an impressive achievement!
[quote=“gouessej,post:82,topic:29395”]
I wish it were so! It’s only me. I just meant that I rely on jPCT to handle the 3D side of things… Anyway, Egon has helped you a fair bit hasn’t he - even though you don’t use jPCT? I think we both owe him a lot!
[quote=“gouessej,post:82,topic:29395”]
Why on earth not? Surely if you’re working you can afford the €20 or so a month?
As you say (almost) all commercial games use hw but is it a coincidence that the only really successful java game doesn’t?
Nice game SimonH! Congrats!
You’re right. On my website, there are 2 links to successful java games using hardware rendering, it includes the famous Jake2. I hope I will succeed. Egon helped me because I don’t own any Microsoft OS but I never asked him to touch my source code and I rely on my neighbours who use Vista to test my game and solve the problem. I know that the choice of rendering is not the only choice to do for a game but the performances can be hugely better by using hardware rendering. If I succeed in using Pixel Buffer Objects, I will be honoured to help you to modify your engine to use only this kind of optimisation to improve your game if you’re really interested.
Where do you see room for improvement by using PBOs in a software renderer? It renders into an int[]-array and blits that to screen. How can a PBO improve this process? And even if it could: where’s the point in a software renderer that uses OpenGL for something? You can go fully hardware if OpenGL is available and you want to use it. But that’s something that he can already do if he wish. No need for PBOs here either. So what’s your point?
Forgive my ignorance but what is a Pixel Buffer Object?
You can find more info here: http://www.opengl.org/registry/specs/ARB/pixel_buffer_object.txt
The overview section has some examples of how to improve performance of some operations with it.
Right… So no performance plus for software rendering then; bufferAccessTime==userMemoryAccessTime
All a bit deep for me, I prefer the AI side of things!
Maybe you’re wrong on something. When I used only raycasting and no hardware acceleration, I had only 0.5 FPS. When I use raycasting and hardware acceleration (only glDrawPixels()) in the slow mode, on the same computer, I have between 1 and 4 FPS. By using the PBO, I should have the same performance in the worst case. Then, if you used at least the very little piece of hardware acceleration currently used in the slow mode of my game even without PBO, it would improve the performance. If you’re not convinced, download the source code of the ancestor of “TUER” which is called “Art Attack” (raycasting + software rendering), put it in full screen and it will be between 2 and 8 times slower than the slow mode of TUER.
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 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.
Yes, excellent analysis and the game turns at between 142 and 200 FPS on my machine ;D. 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?
[quote]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?
[/quote]
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.
is runescape a software implemenation?
yes
3.8 - 6 fps
Which is shocking, considering I’ve got:
Core2Duo 6400
2 Gb RAM
7900 GS
1900 x 1200 monitor
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.
[quote=“blahblahblahh,post:98,topic:29395”]
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?
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.