Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (488)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5 6
  ignore  |  Print  
  Bloodridge  (Read 30661 times)
0 Members and 1 Guest are viewing this topic.
Offline EgonOlsen
« Reply #90 - Posted 2007-08-03 11:45:12 »

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.

Offline gouessej
« Reply #91 - Posted 2007-08-03 16:09:40 »

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"?

Offline EgonOlsen
« Reply #92 - Posted 2007-08-03 21:34:00 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #93 - Posted 2007-08-06 08:05:18 »

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  Grin. 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?

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #94 - Posted 2007-08-06 09:43:33 »

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?

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.

Offline phu004

JGO Coder


Medals: 4
Projects: 9
Exp: 10 years


NoSuchPersonException


« Reply #95 - Posted 2007-08-07 08:08:38 »

is runescape a software implemenation?
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #96 - Posted 2007-08-07 09:36:26 »

is runescape a software implemenation?

yes

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #97 - Posted 2007-08-07 15:19:26 »

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 Wink - you've made a popup window of fixed size, so I physically cannot drag the window to be the correct size Sad.

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

malloc will be first against the wall when the revolution comes...
Offline SimonH
« Reply #98 - Posted 2007-08-07 15:51:28 »

3.8 - 6 fps
Astonishing! My machine is nowhere near as good and I get 20fps! (12fps with 'high quality' graphics)

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 Wink - you've made a popup window of fixed size, so I physically cannot drag the window to be the correct size Sad.
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?

People make games and games make people
Offline keldon85

Senior Member


Medals: 1



« Reply #99 - Posted 2007-08-07 21:12:03 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #100 - Posted 2007-08-08 07:32:18 »

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.

Offline keldon85

Senior Member


Medals: 1



« Reply #101 - Posted 2007-08-08 07:42:04 »

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.
I was not talking about the entire AWT, just a certain method.

Offline phu004

JGO Coder


Medals: 4
Projects: 9
Exp: 10 years


NoSuchPersonException


« Reply #102 - Posted 2007-08-08 07:53:14 »

Quite playable on my computer.
I have 20+ fps on low resolution mode(518 x 388), and 8 ~14 fps on high resolution mode(1036 x 776).

I am running bloodridge on an old celeron 1.5Ghz laptop, with java 1.6 installed.

(by the way my screen resolution is 1280 x 800)
Offline gouessej
« Reply #103 - Posted 2007-08-08 08:19:49 »

I was not talking about the entire AWT, just a certain method.
Which method??

Offline phu004

JGO Coder


Medals: 4
Projects: 9
Exp: 10 years


NoSuchPersonException


« Reply #104 - Posted 2007-08-08 09:23:03 »

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?
Offline EgonOlsen
« Reply #105 - Posted 2007-08-08 10:22:47 »

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.

Offline keldon85

Senior Member


Medals: 1



« Reply #106 - Posted 2007-08-08 13:28:54 »

Which method??
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.

Offline gouessej
« Reply #107 - Posted 2007-08-09 11:53:37 »

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.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #108 - Posted 2007-08-13 18:09:01 »

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.

malloc will be first against the wall when the revolution comes...
Offline SimonH
« Reply #109 - Posted 2007-08-14 01:13:44 »

No changes to screen size, and as I said it nowhere near fills the screen.
I'm completely nonplussed! Here is the javascript on the intro page;

1  
2  
3  
<SCRIPT LANGUAGE="JavaScript">
function fullScreen(theURL) {window.open(theURL, 'Bloodridge', 'titlebar=yes, status=0, scrollbars=auto');}
</script>

and here's the link;
1  
click <a href="bloodridge.html" onClick="fullScreen('game.html');"><u>here</u></a> 

and here's game.html;
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
<html>
<head>
<title>Bloodridge</title>
<SCRIPT LANGUAGE="JavaScript">
function maximizeWindow() {
 if (parseInt(navigator.appVersion)>3) {
  if (navigator.appName=="Netscape") {
   if (top.screenX>0 || top.screenY>0) top.moveTo(0,0);
   if (top.outerWidth < screen.availWidth)
      top.outerWidth=screen.availWidth;
   if (top.outerHeight < screen.availHeight)
      top.outerHeight=screen.availHeight;
  }
  else {
   top.moveTo(-4,-4);
   top.resizeTo(screen.availWidth+8,screen.availHeight+8);
  }
 }
}
</script>
</head>
<body leftmargin=0 rightmargin=0 topmargin=0 bottommargin=0 scroll=no onLoad="maximizeWindow();">
<applet
    code=LoaderApplet.class
    name=LoaderApplet
    width=100%
    height=100%
>
</applet>
</body>
</html>


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?

People make games and games make people
Offline keldon85

Senior Member


Medals: 1



« Reply #110 - Posted 2007-08-14 06:16:03 »

What's your drawing method, could a few calls in your approach be acting as a bottleneck maybe?

Offline gouessej
« Reply #111 - Posted 2007-08-14 07:57:25 »

I wrote the game with the idea that it would work anywhere - why not on your (really good) system?
You're discovering that using software rendering doesn't solve all your problems; whatever you choose, software or hardware rendering, you're not protected from bugs  Wink

Offline SimonH
« Reply #112 - Posted 2007-08-15 14:42:18 »

What's your drawing method, could a few calls in your approach be acting as a bottleneck maybe?
You're discovering that using software rendering doesn't solve all your problems
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...

People make games and games make people
Offline keldon85

Senior Member


Medals: 1



« Reply #113 - Posted 2007-08-15 14:47:52 »

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 Smiley

Offline SimonH
« Reply #114 - Posted 2007-08-15 15:04:29 »

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 Smiley
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!

People make games and games make people
Offline gouessej
« Reply #115 - Posted 2007-08-16 08:06:57 »

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.

Offline gouessej
« Reply #116 - Posted 2007-08-21 23:27:31 »

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  Huh

Offline SimonH
« Reply #117 - Posted 2007-09-15 15:56:12 »

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.

Any suggestions?


Also Vers. 0.0.14 posted;
  • Attempt made at Flash-style loading screen.
  • Annoying 'click once, fire twice' bug fixed.
  • Grenades (Cauldron) can now be lobbed over walls &c.


People make games and games make people
Offline EgonOlsen
« Reply #118 - Posted 2007-09-16 18:04:59 »

I think that adding MP will add the most value to this kind of game.

Offline keldon85

Senior Member


Medals: 1



« Reply #119 - Posted 2007-09-29 18:45:39 »

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.

Pages: 1 2 3 [4] 5 6
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (17 views)
2014-08-28 18:26:30

CopyableCougar4 (26 views)
2014-08-22 19:31:30

atombrot (39 views)
2014-08-19 09:29:53

Tekkerue (36 views)
2014-08-16 06:45:27

Tekkerue (33 views)
2014-08-16 06:22:17

Tekkerue (22 views)
2014-08-16 06:20:21

Tekkerue (33 views)
2014-08-16 06:12:11

Rayexar (69 views)
2014-08-11 02:49:23

BurntPizza (46 views)
2014-08-09 21:09:32

BurntPizza (37 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!