next »

[ஒழுக்கின்மை (Paul Eres)]

I think fillrate is a pretty vague concept in general and it definitely has absolutely nothing to do with what's actually going on on the screen.

it's real enough. try filling the screen many times each frame. it slows the game down. and it's often the bottleneck for high-resolution (anything above 800x600) 2d games. you're right that some things make it hard to measure, like different blending modes, but i think in every game i've made in the last 10 years, the fill rate was the speed bottleneck.

[Ivan]

Paul seemed to define 3d more based on the camera viewpoint than the graphical presentation, so we split on whether or not The Sims is a 3d game.

no, i said 3d games are games which are rendered using polygons, not just any game that uses 3d models. in other words, baldur's gate is a 2d game even though it uses models to create its sprites, simply because it's not polygonal.

That distinction doesn't really make sense. All hardware accelerated games are rendered using polygons.

[Ivan]

I think fillrate is a pretty vague concept in general and it definitely has absolutely nothing to do with what's actually going on on the screen.

it's real enough. try filling the screen many times each frame. it slows the game down. and it's often the bottleneck for high-resolution (anything above 800x600) 2d games. you're right that some things make it hard to measure, like different blending modes, but i think in every game i've made in the last 10 years, the fill rate was the speed bottleneck.

What do you mean by fillrate exactly? If you're talking about non-accelerated 2D games, then it's not the card's ability to fill the screen with pixels (which is what fillrate is by definition), but the ability to copy the pixel data into video memory from RAM. The latter is not fillrate.

[moi]

1) whether 2d games are generally more hardware-intensive than 3d games anymore, or whether this is a myth

Depends a lot on the games, but I doubt any 2D game can be more intensive than, say, FarCry 2.

Just add more effects and transparent layers and particles and simulated elements and increase the resolution and [etc] and you can make a 2D game be arbitrarily intensive ... there is no limit to how intensive a game can be (in either 2D or 3D).

You'd have to really go overboard (like stack several tilemaps on top of each other with a hundred sprites with transparency, lots of particles, etc...) to be able to challenge the most busy scenes in far cry 2 where you have hundreds (thousands?) of foliage elements, special effects textures with transparency, etc... like this one for example
And then I'm sure your game would be lame because particles in a 2D game are generally lame.

[Eclipse]

Paul seemed to define 3d more based on the camera viewpoint than the graphical presentation, so we split on whether or not The Sims is a 3d game.

no, i said 3d games are games which are rendered using polygons, not just any game that uses 3d models. in other words, baldur's gate is a 2d game even though it uses models to create its sprites, simply because it's not polygonal.

errr.... all 2d games nowadays are rendered using polygons, Gish was rendered using polygons, Aquaria is rendered using polygons since it uses OpenGL, maybe only stuff like cave story uses to push pixels on a software rendering pipeline.

So basically:  2d = 3d without a projection matrix.

a 2d game has less performance problems also because it doesn't need to use a zbuffer, since depth tests are quite expensive operations, and doesn't need do to a lot of 3d math that truly kills the cpu...

It's another fact that commonly used 2d libraries such allegro and so are painfully slow, but that's because they rely heavly on the cpu and they use ancient or bad code

[Eclipse]

I think fillrate is a pretty vague concept in general and it definitely has absolutely nothing to do with what's actually going on on the screen.

it's real enough. try filling the screen many times each frame. it slows the game down. and it's often the bottleneck for high-resolution (anything above 800x600) 2d games. you're right that some things make it hard to measure, like different blending modes, but i think in every game i've made in the last 10 years, the fill rate was the speed bottleneck.

i think game maker rendering pipeline was your bottleneck...

[ஒழுக்கின்மை (Paul Eres)]

That distinction doesn't really make sense. All hardware accelerated games are rendered using polygons.

they are technically rendered in that way if you consider a sprite as a flat polygon, yes. that's how the video card treats it. but that isn't the way it's normally conceptualized. usually, you think of them as sprites, not polygons.

What do you mean by fillrate exactly? If you're talking about non-accelerated 2D games, then it's not the card's ability to fill the screen with pixels (which is what fillrate is by definition), but the ability to copy the pixel data into video memory from RAM. The latter is not fillrate.

that may very well be the case, but in such a case there's still an effective fill rate. but it's true that there are some things which affect it -- for instance, textures are stored in multiples of two, so a 300x300 sprite will be stored as 512x512 of video memory rather than 300x300. so a 257x256 sprite would take four times slower to render than a 256x256 sprite. so it's somewhat counter-intuitive. so it's not a set number that you can easily measure. but it's still a limit that you have to work within, and often a speed bottleneck.

i think game maker rendering pipeline was your bottleneck...

game maker actually renders stuff as fast as anything hardware accelerated; it uses directx. game maker often has an interpretation of code bottleneck, and a large number of objects bottleneck, but i don't often come up against those; i've done tests and i'm sure that the bottleneck is the drawing itself, not the interpretation speed of the code.

[Ivan]

Paul, I think the misunderstanding here comes from the fact that a non-accelerated application has to manually copy pixels of the entire screen from RAM to video memory every frame. That is very very slow and will be a bottleneck past 800x600 or whatever, as you were saying.

In a 3D accelerated application, the rendering is done on the card itself, so there is no copying of pixels between the video card and the computer memory, thus eliminating "fillrate" issues.

[Impossible]

Plus, I render like 2 polys at a time for sprites. 3D models have the advantage of being able to use large triangle strips for batch rendering.

This isn't a limitation of 2D games.  You can batch sprites...

[ஒழுக்கின்மை (Paul Eres)]

Paul, I think the misunderstanding here comes from the fact that a non-accelerated application has to manually copy pixels of the entire screen from RAM to video memory every frame. That is very very slow and will be a bottleneck past 800x600 or whatever, as you were saying.

In a 3D accelerated application, the rendering is done on the card itself, so there is no copying of pixels between the video card and the computer memory, thus eliminating "fillrate" issues.

if that were true, wouldn't the issue not come up in games with hardware acceleration? yet it does.

[Eclipse]

Plus, I render like 2 polys at a time for sprites. 3D models have the advantage of being able to use large triangle strips for batch rendering.

you can optimize that with a little effort and make very few drawcalls

[Ivan]

they are technically rendered in that way if you consider a sprite as a flat polygon, yes. that's how the video card treats it. but that isn't the way it's normally conceptualized. usually, you think of them as sprites, not polygons.

There is absolutely no difference programmatically between rendering sprites and rendering a 3D model in OpenGL or Direct3D.

that may very well be the case, but in such a case there's still an effective fill rate. but it's true that there are some things which affect it -- for instance, textures are stored in multiples of two, so a 300x300 sprite will be stored as 512x512 of video memory rather than 300x300. so a 257x256 sprite would take four times slower to render than a 256x256 sprite. so it's somewhat counter-intuitive. so it's not a set number that you can easily measure. but it's still a limit that you have to work within, and often a speed bottleneck.

Textured are stored on the video card itself, so there is no copying of any data between the card and the computer memory whatsoever, unless you are using old render to texture methods or reading texture data into memory.

[Ivan]

Paul, I think the misunderstanding here comes from the fact that a non-accelerated application has to manually copy pixels of the entire screen from RAM to video memory every frame. That is very very slow and will be a bottleneck past 800x600 or whatever, as you were saying.

In a 3D accelerated application, the rendering is done on the card itself, so there is no copying of pixels between the video card and the computer memory, thus eliminating "fillrate" issues.

if that were true, wouldn't the issue not come up in games with hardware acceleration? yet it does.

But it doesn't! Because game maker is hardware accelerated doesn't mean anything. You have no idea what it's doing or how it's doing it. It may very well be copying all the data to the card every frame, you have no way of knowing.

[ஒழுக்கின்மை (Paul Eres)]

There is absolutely no difference programmatically between rendering sprites and rendering a 3D model in OpenGL or Direct3D.

did i say there was? i said the difference is just conceptual.

Textured are stored on the video card itself, so there is no copying of any data between the card and the computer memory whatsoever, unless you are using old render to texture methods or reading texture data into memory.

yes, but, i still don't get what your basic message is. are you saying there is no limitation on  how much you can draw to the screen, and that drawing more per frame will not or does not have to slow a game down?

[ஒழுக்கின்மை (Paul Eres)]

But it doesn't! Because game maker is hardware accelerated doesn't mean anything. You have no idea what it's doing or how it's doing it. It may very well be copying all the data to the card every frame, you have no way of knowing.

well, you can run tests, and look at behavior, so there's not no way of knowing. you can also compare drawing speeds in and out of game maker -- e.g. draw the same amount of stuff in another engine using other methods, or directly in c++ etc., and see if there are any speed differences.

[Ivan]

There is absolutely no difference programmatically between rendering sprites and rendering a 3D model in OpenGL or Direct3D.

did i say there was? i said the difference is just conceptual.

Textured are stored on the video card itself, so there is no copying of any data between the card and the computer memory whatsoever, unless you are using old render to texture methods or reading texture data into memory.

yes, but, i still don't get what your basic message is. are you saying there is no limitation on  how much you can draw to the screen, and that drawing more per frame will not or does not have to slow a game down?

I'm saying that the limitation is with the amount of polygons you can draw, not the resolution you can drawn them in. You can have a fullscreen textured polygon running at 1000+ fps at 1600x1200 on any modern 3d card, which should tell you that the speed bottlenecks are not in the resolution of the screen, but in the amount of textured polygons that are drawn on the screen.

[ஒழுக்கின்மை (Paul Eres)]

yes, one fullscreen textured polygon running at 1000 fps is easy, but that's just filling the screen once per frame. in games you have to fill the screen many times per frame in order to have a workable game (overdrawing).

so are you saying that resolution has no effect on speed if the number of polygons is the same? that isn't true in my experience. for instance, if i run half life 2 at 1440x900, it runs at around 20fps; it runs at around 80fps at 800x600 resolution. same number of polygons, but much faster speed. isn't that a fill rate issue? if not, what causes that speed difference?

[Ivan]

Of course the resolution affects the fps, but it's not "fillrate". That is, it's not the amount of data that has to get copied to the screen. The speed decrease comes from the video card having to rasterize 3D data at a higher resolution. SO all the shaders have to run on more pixels, the multisampling has to run over more pixels, and yes the textures themselves have to be transformed to higher resolution targets. But that's not the same as filling a screen with pixels.

[Eclipse]

yes, one fullscreen textured polygon running at 1000 fps is easy, but that's just filling the screen once per frame. in games you have to fill the screen many times per frame in order to have a workable game (overdrawing).

so are you saying that resolution has no effect on speed if the number of polygons is the same? that isn't true in my experience. for instance, if i run half life 2 at 1440x900, it runs at around 20fps; it runs at around 80fps at 800x600 resolution. same number of polygons, but much faster speed. isn't that a fill rate issue? if not, what causes that speed difference?

resolution has effect on speed, of course, but normally a 2d game runs at a lower resolution than a 3d one or maybe at the same one. I play most of my 3d games at 1280x1024, using also full scene antialiasing and they draw a shitload of polygons using huge textures, normalmaps, specularmaps, lightmaps, and so on, so no, a 2d game is normally WAY speedier than even a simple 3d rts.

A MMF2\game maker game that runs at 800x600 fullscreen anyway is quite slow. And it's not a DirectX bottleneck since i can render the same stuff 100x times faster in c++ and directx

[ஒழுக்கின்மை (Paul Eres)]

Of course the resolution affects the fps, but it's not "fillrate". That is, it's not the amount of data that has to get copied to the screen. The speed decrease comes from the video card having to rasterize 3D data at a higher resolution. SO all the shaders have to run on more pixels, the multisampling has to run over more pixels, and yes the textures themselves have to be transformed to higher resolution targets. But that's not the same as filling a screen with pixels.

if this were true, wouldn't 2d games run at the same speed regardless of resolution, then? i mean, assuming no anti-aliasing and such. this isn't true in my experience; for instance, cave story runs far faster for me at 320x200 than at 640x480. and it doesn't use rasterization or shaders or anti-aliasing, it just doubles the size of the image directly. another example is emulation, such as zsnes: running zsnes at higher resolutions will cause the game to run slower even though it's simply scaling up the image.