Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

IronFist

Processing power of a FPS vs Baldur's Gate: Dark Alliance. (experienced people enter)

This topic is 6086 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have been having a debate with someone for the past few days, and it pretty much lead to a dead end. He claims I'm wrong, yet he can't give me any reasons why he's right. So now I need your help. This all started as a debate about the power of the PS2, but somehow it lead to if a first person shooter taxes the system more than Baldur's Gate: Dark Alliance does. So I need someone who not only understands how much power it takes to make a FPS game, but also someone who is familiar with BG: DA and how the game is set up(completely 3d unlike the previous BG games). I want to know first, who is right? And if I am wrong, please explain to me why I'm wrong (because he won't). So here are the three things we are debating: --------------------------------------------- 1. Does having a controllable camera make a significant impact in the processing power? In other words, does having a controllable camera tax the system a lot more than if it wasn't controllable? This is what he thinks: Having a controllable comera has a huge impact (zooming and scaling etc) on performance, not just a little. Unfortunately, he didn’t back up his statement with anything. So that’s why I’m coming to you to see what the answer is. This is what I think: Keeping track of where the camera is takes practically zero processing power -- whether or not the camera is controllable or not. Everything is rendered from that camera point (again, whether or not the camera is movable). The only thing that having a controllable camera does is adds a couple more checks per cycle. The game has to check and see if the Rotate_Camera_Left or Rotate_Camera_Right button is pressed. Then it moves the camera accordingly. Then it goes back to the normal draw screen function. Adding two more checks per cycle does not add significant processing to the game. ---------------------------------------------------- 2. Does a faster paced game need to draw things on screen a lot quicker than a slow paced game? This is what he thinks, and this is where the question above comes from: A FPS is a quicker game, things move more quickly and therefore have to be drawn more quickly. This is what I think: Nomatter what the speed of the game is, it is drawn at the framerate of the game. For example, 60 FPS games display 60 frames every second. Nomatter how fast the game moves, or how fast the characters move in the game, it will only display the graphics every 1/60 of a second. Then he still argued with me without anything to back up what he was saying, so I posted this: Lets say we have a ball rolling across the screen. It could roll across 1 point per cycle, or it could roll across 100 points per cycle. Either way, if the framerate is 60 fps, it would only draw the ball every 1/60 of a second. ----------------------------------------------- Those two questions come from this main question. They were things he tried to use to prove he was right about the main question, but I don’t think those things make a difference. So here is the main question: 3. Does a FPS game take more processing power than BG: DA does? This is what he originally said about BG: DA, and what started this whole thing: This isn't a FPS or a flight sim or anything that requires heavy processing. The coding doesn't have to account for a massive amout of floating operations. This is what I think: BG: DA has to deal with everything that a FPS game has to deal with. It has to deal with hiding off-screen or blocked-from-view polygons. It has to deal with lighting effects. It has to render the world and the characters all in real time, because they are always changing. The backgrounds aren't prerendered or anything. It has to resize the characters to make them look normal on the screen (objects are smaller farther from the camera). ---------------------------------------- So why would a FPS or flight sim require more processing power than BG: DA? Does a faster pace game need to draw things on screen a lot quicker than a slow paced game? And does having a controllable camera make a significant impact in the processing power? Thanks for any help you can give. I don’t mind if I’m wrong as long as you explain to me why I’m wrong. And if you want to, post what 3D experience you have in programming. That will make sure he can't say stuff like, "These people don't know what they're talking about either." Edited by - IronFist on September 22, 2001 4:02:50 AM

Share this post


Link to post
Share on other sites
Advertisement
First off, I''ve not played BG:DA, but I''ll assume it''s something like Baldur''s Gate 1/2 but with a Asheron''s Call or Everquest style viewpoint. (Looking at the screenshots that''s how it appears)

quote:
1. Does having a controllable camera make a significant impact in the processing power? In other words, does having a controllable camera tax the system a lot more than if it wasn''t controllable?


I don''t know what you''re friend is trying to say here. I mean, the camera is an FPS is controllable as well, since when you look left, the camera has to rotate left as well... How is that different to what it''s like in Dark Alliance?

quote:
2. Does a faster paced game need to draw things on screen a lot quicker than a slow paced game?


Now matter how fast-paced the action is, the game will draw its graphics as fast as it can. So even if the stuff in Baldur''s Gate takes 1/2 the time to draw (which is kind of unlikely looking at the detail in those screenshots!) it''ll just draw them twice as often.

It''s not the speed that objects move at, it''s the detail in those objects that defines how long it takes to render them. Just because an object has moved a larger distance from one frame to the next doesn''t mean it takes longer to draw the next time!

When you''re talking about a role-playing game, with dozens or even hundreds of NPCs, then the graphics will not be taking up a lot of the processor''s time anyway. It''ll be the AI that is needed to make those hundreds of NPCs seem life-like. A game like quake doesn''t have any AI at all (or if you''re talking about single-player quake, then it''s very simple - see player, shoot player)

If anything, I''d say a game like Dark Alliance is more "taxing" on the system, since not only does it have nice-looking graphics, but it''s got to do the AI for all those other characters as well.


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
So would a FPS or flight simulator take more processing time graphically than BG: DA would? I still think they take equal amounts of processing power graphically. Here's why:

Graphically, both games need to do just about the same things. Both games need to completely fill the screen with polygons. They both need to calculate the off-screen and hidden-from-view polygons and make sure not to draw those. They both need to calculate all lighting effects. Most lighting effects in Quake are not calculated in real time (they are calculated while the map is being made). I'm not sure if the lighting effects in BG: DA are done in realtime, or done while the level is being programmed (I'll go ask the people at the Baldur's Gate forums for the answer to that). Both games have to draw multiple characters on the screen at once. (BG: DA has to draw a lot of little objects like barrels and stuff too, but I don't know if that would make it take too much more processing power.) They both have to scale the objects, characters, and levels to make them look in perspective.

That is why I think they take the same processing power graphically. I think the physics engine in BG:DA is a lot more powerful than any FPS game too. i.e. when you kill a skeleton or something or hit a barrel, they break apart differently every time depending how how you hit them. But that is besides the point.

Does anyone else want to input their opinion? The more people that respond, the more I'll understand it.

Edited by - IronFist on September 23, 2001 4:55:13 AM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Take a look on the minimum requirements on the side of the game boxes. Whichever has higher requirements is the greater hog.

There are so many factors that need to be put into consideration it''s not even funny. And it can even be as simple as one game having better collision detection methods then the other. Just because both need to draw polygons doesn''t mean they have equal ammounts of poly''s on the screen. The quality of the textures can matter, the clipping plane, how many npc''s/items the game is keeping track of at a given time, there''s just so many things. And I know RPG''s tend to be much larger in terms of HD space due to sheer number of items, but that does not automatically mean it needs more processing power.

Share this post


Link to post
Share on other sites
The point of the movable camera thing is from a programming point of view different then a non movable camera. The reason this is is because it is possible to take short cuts and ''libertys'' with the way you do things and it doesn''t matter as long as the end resault is the same. What is the big deal, if it all comes out in the end, right?

For example what if you where asked to write a function that returns the distance between to points in two dimensional space? We all know the formula sqr((x1-x2)^2 + (y1-y2)^2). This is slow. Wait what if we new in advance that the points would ALWAYS be on a vertical or horizontal line? then we simply take the differance of the ordered pair that are not the same. ec. (x1-x2). MUCH faster.
This is the only thing I can see that a fixed versuse a movable camera would change, These kind of reduced problems that are easier to solve (or faster) than there more general cousins. When you make these kind of games those few extra clock cycles almost make it worth working around the new problems this kind of programming brings up. (DON''T ASK!)

I hope this helped in some way, and if it didn''t, well I''m sorry to have made you read my entire ramble.

If it''s wierd then it''s the norm for me!

Share this post


Link to post
Share on other sites
I think that you could argue a fixed camera gives some advantages, depending on the game. I was making a space-shooter with levels made of 3d objects. I could use a greatly simplified organization of the levels. No Octrees, BSP''s etc, because everything was pretty much drawn if it was in the x,y coords of the screen. Now, in BG for the PS2, I''m sure certain operations could be simplified. But any small savings in this area could be used in other areas. For example, some of the models in BG are upwards of 20,000 poly''s. You''d be hard-pressed to find a FPS that uses that many in a single model. IMO, unless the programmers for BG were chumps, they would have used all the processing power available to them. CPU cycles left over? Throw in some more lights. Running at 120 FPS? Make explosions twice as big, with 3d flying debree. You could probably find at least 1 FPS game that makes better use of the PS2, and at least 1 that doesn''t. IMO your friend is wrong, if I understand him correctly.

Share this post


Link to post
Share on other sites
Btw, BG runs at 60fps, so there goes argument number 2. Almost any game will benefit from running at 60fps over 30fps. Fast moving objects don''t skip, user input is more reactive, and there''s a noticable smoothness improvement. It can be argued that it''s more important in a fast paced game, but that doesn''t make it undesirable in others.

Share this post


Link to post
Share on other sites
ClickByClick, not sure if I understand you, but I don''t think the fixed camera was chosen to make it easier/faster. BG are meant to be overhead games. I think a movable camera would detract from the game. Yes, there are things you wouldn''t have to worry about given the fixed camera, but even if there wasn''t I don''t think that would have affected the design of the game. I really have no idea though. Just my opinion.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!