Camera View
by Lennart Steinke · in Torque Game Builder · 03/10/2005 (5:30 am) · 21 replies
How do I change the camara, so that instead of (-50,-35) to (50,35) it uses (-400,-300) to (400,300)?
So that my camera would match the resolution of (800,600) I'm developing my gfx for?
I understand why a logical camera view is a good thing in 3d, but unless t2d get's support for vector gfx in one way or another, the logical "screen size" is pretty useless. If I change the resolution say in a 2d rts, I don't want scaled gfx, I want a larger view of the map.
Also, since the increased resolution doesn't increase the gfx quality I'm not sure what it's used for.
I know the camera can be used for split screen and similar effects, but for the normal 2d stuff it would be better to have a default logical size matching the physical size.
This would also stop the "where is point x,y in my sprite?" questions - while you still maintain full flexibility ;)
So that my camera would match the resolution of (800,600) I'm developing my gfx for?
I understand why a logical camera view is a good thing in 3d, but unless t2d get's support for vector gfx in one way or another, the logical "screen size" is pretty useless. If I change the resolution say in a 2d rts, I don't want scaled gfx, I want a larger view of the map.
Also, since the increased resolution doesn't increase the gfx quality I'm not sure what it's used for.
I know the camera can be used for split screen and similar effects, but for the normal 2d stuff it would be better to have a default logical size matching the physical size.
This would also stop the "where is point x,y in my sprite?" questions - while you still maintain full flexibility ;)
About the author
#2
Sorry to disagree with you but using pixels is a very bad way to proceed for modern game development. You may have got used to using pixels but that doesn't really make it a good idea unless you only want to work in a single resolution. Not wanting to sound harsh but saying the "logical" screen size is pretty useless shows how you don't really understand the advantages they bring.
I think you're making big generalisations here. We're not blitting so if you use higher resolution graphics, when you scale-up the sprites because either your resolution is higher or perhaps you zoom the camera-in, you see more detail from your textures. This is the case with our "Fish" demo where the fish and backgrounds are higher resolution but the demo is setup using a single logical coordindate system so that the user can use any resolution without a single change in the demo code. Vector graphics are nothing to do with it at all. Do you really think that working in pixels and having to detect the resolution change so that you can adjust all the boundaries of your objects is a good thing? We don't.
I'm not sure I've seen any "where is point x,y in my sprite?" questions to be honest. Also, you won't have to answer the questions that ask "when I switch to a higher resolution, why does my game only render in the top-left of the screen".
I'm not trying to slam you here but rather I'm trying to highlight how a logical coordindate system is extremely important. Essentially, OpenGL and DirectX both use these logical coordinate systems and are fundamental to computer graphics. Only old-school 2D'ers worry about pixels, we don't.
With all that said, you may want to restrict your application to a single resolution and work with a 1:1 ratio where a world-unit is equal to a pixel and so we provide the ability to quickly configure your camera to use any coordinate system you choose.
Okay, imagine another 2D engine if you will....
The coordinates you use are (0,0) at the top-left and the resolution in the bottom-right, say (800,600). You design your game to work in pixels and everything is good.
The user changes the resolution to 1600x1200 and your game still renders to (800,600). So you say, well I have some variables that look at the resolution and I change the limits of all my objects, where my center is, where my enemy appear. Boy, what alot of fuss over something not under your control.
Then comes T2D that says, choose your own logical coordinate system. Have any coordinates you want. Now you can use a standard coordinate system that automatically scales your graphics for the resolution with absolutely no changes to your code whatsoever.
Then someone says, but I don't want that, I want my old method where I have coordinates mean pixels. T2D says fine then, do this:-
Wow!
Okay, can I have it really old-school and have the (0,0) view at the top-left? Yes, just use...
.. instead.
T2D allows you to work how you want. We've tried to make as few assumptions as possible that'll impact the way you make your games.
As a suppliment to the above, you can also set the camera to a specific area like this:-
We wanted to provide the flexibility to quickly work how you want but I would urge you to consider using a logical coorindate system. In the end, the choice is quite rightly yours.
Hope this helps,
- Melv.
03/10/2005 (7:03 am)
@Lennart: I'm going to post something from the link I gave you before...Sorry to disagree with you but using pixels is a very bad way to proceed for modern game development. You may have got used to using pixels but that doesn't really make it a good idea unless you only want to work in a single resolution. Not wanting to sound harsh but saying the "logical" screen size is pretty useless shows how you don't really understand the advantages they bring.
I think you're making big generalisations here. We're not blitting so if you use higher resolution graphics, when you scale-up the sprites because either your resolution is higher or perhaps you zoom the camera-in, you see more detail from your textures. This is the case with our "Fish" demo where the fish and backgrounds are higher resolution but the demo is setup using a single logical coordindate system so that the user can use any resolution without a single change in the demo code. Vector graphics are nothing to do with it at all. Do you really think that working in pixels and having to detect the resolution change so that you can adjust all the boundaries of your objects is a good thing? We don't.
I'm not sure I've seen any "where is point x,y in my sprite?" questions to be honest. Also, you won't have to answer the questions that ask "when I switch to a higher resolution, why does my game only render in the top-left of the screen".
I'm not trying to slam you here but rather I'm trying to highlight how a logical coordindate system is extremely important. Essentially, OpenGL and DirectX both use these logical coordinate systems and are fundamental to computer graphics. Only old-school 2D'ers worry about pixels, we don't.
With all that said, you may want to restrict your application to a single resolution and work with a 1:1 ratio where a world-unit is equal to a pixel and so we provide the ability to quickly configure your camera to use any coordinate system you choose.
Okay, imagine another 2D engine if you will....
The coordinates you use are (0,0) at the top-left and the resolution in the bottom-right, say (800,600). You design your game to work in pixels and everything is good.
The user changes the resolution to 1600x1200 and your game still renders to (800,600). So you say, well I have some variables that look at the resolution and I change the limits of all my objects, where my center is, where my enemy appear. Boy, what alot of fuss over something not under your control.
Then comes T2D that says, choose your own logical coordinate system. Have any coordinates you want. Now you can use a standard coordinate system that automatically scales your graphics for the resolution with absolutely no changes to your code whatsoever.
Then someone says, but I don't want that, I want my old method where I have coordinates mean pixels. T2D says fine then, do this:-
// When the T2D window has changed...
function sceneWindow2D::onExtentChange( %this, %newExtent )
{
// Set my view to be the Screen-Resolution
sceneWindow2D.setCurrentCameraPosition( "0 0" SPC getWords(%newExtent, 2, 3) );
}Wow!
Okay, can I have it really old-school and have the (0,0) view at the top-left? Yes, just use...
// When the T2D window has changed...
function sceneWindow2D::onExtentChange( %this, %newExtent )
{
// Set my view to be the Screen-Resolution
sceneWindow2D.setCurrentCameraArea( "0 0" SPC getWords(%newExtent, 2, 3) );
}.. instead.
T2D allows you to work how you want. We've tried to make as few assumptions as possible that'll impact the way you make your games.
As a suppliment to the above, you can also set the camera to a specific area like this:-
sceneWindow2D.setCurrentCameraArea( "-400 -300 400 300" );
We wanted to provide the flexibility to quickly work how you want but I would urge you to consider using a logical coorindate system. In the end, the choice is quite rightly yours.
Hope this helps,
- Melv.
#3
While this sounds nice, esp. if youo actually use textures, it's a different thing if you prefer pixeled art. A sprite pixeled at 32x32 won't get more detail if it's blitted at 64x64.
Also, for games distributed via the net, size does matter. Take a look at the t2d demo game - I think it was around 11 MB. And this is way to much for such a game.
I'm new to t2d, so I guess part of that size comes from the engine, but on the other hand, I'd say that using graphics of any size I want might be the other half of the story.
Also, if I mix sprites of different sizes, quality of the sprites in higher resolutions will differ as well.
And sprites / textures are generated at a specif size. Scaling them doesn't give "more detail", because there isn't more detail. So, in order to get the best quality, I should create my sprites for the max resolution people might want to use. Say 1600x1200. And again, in that case it would make sense to run my game at that logical resolution because I don't have to do any math to determine where stuff should be (say for mounts and collision polys).
On the other hand, designing my game for that resolution would result in really large images. And if players decide to play at 800x600 I've wasted that space and information will be lost.
I'm really not sure how running the game at a resolution higher than what it was designed for will result in a better look if you use pixel graphics.
Does t2d support mipmapping? In that case I could provide different sprites for different resolutions (again at the costs of size).
I understand why a logical coord system saves you time and all. Esp. if you think that the game might be run at different resolutions. But could somebody please tell me a single 2d game in which changing resolution results in scaled gfx? (Besides emulators and retro games that want you to allow playing a 320x200 game at double size using 2xSai or something).
Also, don't forget that by setting your logical resolution (not the physical resolution) to the resolution you design your graphics for doesn't remove any of the above mentioned "good things". Unless you don't hardcode your logical resolution to your physical resolution you get all the benefits of the virtual coords system. And yet you can use all those nice pixel coords you already know.
So, you loose nothing but you avoid confusion. I don't see why this is a bad thing?
The current logical resolution is just a set value. Why -50,-30 to 50,30 instead of -5,-3 to 5,3? Or -500,-300 to 500, 300? It's just the logical resolution. If you set it to the value you create your sprites in you can use your pixel program of choice to get delta values directy - no need to do any conversions. And yet if you think that your game designed with 640x480 gfx should be run in 1600x1200 you can. I'm not sure why you'd want that, though :)
I can try to track them down if you want? There are also some related threads where people want to know at what world coordinates there mouse is, so they can determine positions for spawn points, etc.
03/10/2005 (9:19 am)
Quote:e're not blitting so if you use higher resolution graphics, when you scale-up the sprites because either your resolution is higher or perhaps you zoom the camera-in, you see more detail from your textures.
While this sounds nice, esp. if youo actually use textures, it's a different thing if you prefer pixeled art. A sprite pixeled at 32x32 won't get more detail if it's blitted at 64x64.
Also, for games distributed via the net, size does matter. Take a look at the t2d demo game - I think it was around 11 MB. And this is way to much for such a game.
I'm new to t2d, so I guess part of that size comes from the engine, but on the other hand, I'd say that using graphics of any size I want might be the other half of the story.
Also, if I mix sprites of different sizes, quality of the sprites in higher resolutions will differ as well.
And sprites / textures are generated at a specif size. Scaling them doesn't give "more detail", because there isn't more detail. So, in order to get the best quality, I should create my sprites for the max resolution people might want to use. Say 1600x1200. And again, in that case it would make sense to run my game at that logical resolution because I don't have to do any math to determine where stuff should be (say for mounts and collision polys).
On the other hand, designing my game for that resolution would result in really large images. And if players decide to play at 800x600 I've wasted that space and information will be lost.
I'm really not sure how running the game at a resolution higher than what it was designed for will result in a better look if you use pixel graphics.
Does t2d support mipmapping? In that case I could provide different sprites for different resolutions (again at the costs of size).
I understand why a logical coord system saves you time and all. Esp. if you think that the game might be run at different resolutions. But could somebody please tell me a single 2d game in which changing resolution results in scaled gfx? (Besides emulators and retro games that want you to allow playing a 320x200 game at double size using 2xSai or something).
Also, don't forget that by setting your logical resolution (not the physical resolution) to the resolution you design your graphics for doesn't remove any of the above mentioned "good things". Unless you don't hardcode your logical resolution to your physical resolution you get all the benefits of the virtual coords system. And yet you can use all those nice pixel coords you already know.
So, you loose nothing but you avoid confusion. I don't see why this is a bad thing?
The current logical resolution is just a set value. Why -50,-30 to 50,30 instead of -5,-3 to 5,3? Or -500,-300 to 500, 300? It's just the logical resolution. If you set it to the value you create your sprites in you can use your pixel program of choice to get delta values directy - no need to do any conversions. And yet if you think that your game designed with 640x480 gfx should be run in 1600x1200 you can. I'm not sure why you'd want that, though :)
Quote:I'm not sure I've seen any "where is point x,y in my sprite?" questions to be honest. Also, you won't have to answer the questions that ask "when I switch to a higher resolution, why does my game only render in the top-left of the screen".Um.. I could try to find them if you want. They must have been on the 1st two pages last saturday or sunday (I got my t2d then, and browsed the forums).
I can try to track them down if you want? There are also some related threads where people want to know at what world coordinates there mouse is, so they can determine positions for spawn points, etc.
#4
03/10/2005 (9:24 am)
Wanted to edit that piece in, but my post was too long - so here it comes as a Post Scriptum:Quote:Then comes T2D that says, choose your own logical coordinate system. Have any coordinates you want. Now you can use a standard coordinate system that automatically scales your graphics for the resolution with absolutely no changes to your code whatsoever.Why can't I have both? It scales well and means pixels on the one resolution it was designed for? Sounds like the best of both worlds to me.
Then someone says, but I don't want that, I want my old method where I have coordinates mean pixels. T2D says fine then, do this:-
#5
You've turned what I said on its head. I'm the lead software engineer for a 3D image-processing company so you'll have to trust me when I say that I know what I'm talking about. I'm not an ass that thinks you can up-scale a texture and see more detail! You want to start discussing nyquist sampling theory or hardware sampling then I'm quite happy to.
I never said that if you scale-up stuff you get emergent detail, it was the other way around; using higher resolution textures downsampled in hardware at your lower resolution and seeing the full resolution when you switch to the higher resolution or if you zoom in on the camera. This is what happens in realtime by the graphics hardware, typically using bilinear interpolation and in coordination with mip-maps, trilinear interpolation. This is one of the major advantages of using 3D hardware. Of course, there are also downsides such as having to use POT textures although that is beginning to change.
Before I discuss the demo, please stop and remember that you purchased the Early Adopter of the product. Why did I mention that? Well, first up is that analysis of file-sizes is pretty irrelevant at this point. My next point is that the real reason for the demos was to just put something out there that showed a demo written in a day or so, not so see how small we can get for internet distribution. We barely got the demo out in time and it ended up with lots of stuff in there that didn't need to be as well as a few bugs. The "T2D.exe" is 1.85mb unpacked (600kb packed), with a couple of DLLs on-top of that, you're still below the 1Mb level.
Yes, we'll be looking at mip-mapping as an option for the imagemaps.
You use another logical coordindate system for polygons and mounts that have nothing to do with either resolution or logical coordinate systems. They use a normalised local-space.
If you want to keep say a 800x600 coordinate system for all your resolutions then that's no different than what we've done here, using a logical coordinate system. Who's to say that people want to design their graphics to 800x600? You? They can choose with a logical system.
... continued ...
03/10/2005 (11:05 am)
Hi,You've turned what I said on its head. I'm the lead software engineer for a 3D image-processing company so you'll have to trust me when I say that I know what I'm talking about. I'm not an ass that thinks you can up-scale a texture and see more detail! You want to start discussing nyquist sampling theory or hardware sampling then I'm quite happy to.
I never said that if you scale-up stuff you get emergent detail, it was the other way around; using higher resolution textures downsampled in hardware at your lower resolution and seeing the full resolution when you switch to the higher resolution or if you zoom in on the camera. This is what happens in realtime by the graphics hardware, typically using bilinear interpolation and in coordination with mip-maps, trilinear interpolation. This is one of the major advantages of using 3D hardware. Of course, there are also downsides such as having to use POT textures although that is beginning to change.
Before I discuss the demo, please stop and remember that you purchased the Early Adopter of the product. Why did I mention that? Well, first up is that analysis of file-sizes is pretty irrelevant at this point. My next point is that the real reason for the demos was to just put something out there that showed a demo written in a day or so, not so see how small we can get for internet distribution. We barely got the demo out in time and it ended up with lots of stuff in there that didn't need to be as well as a few bugs. The "T2D.exe" is 1.85mb unpacked (600kb packed), with a couple of DLLs on-top of that, you're still below the 1Mb level.
Yes, we'll be looking at mip-mapping as an option for the imagemaps.
You use another logical coordindate system for polygons and mounts that have nothing to do with either resolution or logical coordinate systems. They use a normalised local-space.
Quote:But could somebody please tell me a single 2d game in which changing resolution results in scaled gfx?If your game system uses a set of coords for 800x600 and you therefore limit your sprites to go no further than 800 in your X axis and the user changes the resolution to 1024x768, your game code will need to know this and adjust to the new coordinates so that you know how to limit your sprites. With a logicial coordinate system, you don't need to worry about this. You only need to deal with issues of either using alternate, higher-resolution textures, dynamically using mip-maps or doing the more expensive, using higher-resolution textures all the time.
If you want to keep say a 800x600 coordinate system for all your resolutions then that's no different than what we've done here, using a logical coordinate system. Who's to say that people want to design their graphics to 800x600? You? They can choose with a logical system.
... continued ...
#6
I'm showing you how to have both. I'm showing you that you can tell the camera to set logical coordinate system to match the physical resolution or even keep it fixed, whatever. By asking the question you've just justified having a logical coordinate system. You want both, then you can easily ( in a few lines of code ), set the coordinate system to match the physical resolution easily. But not everyone is you. There are a good majority that don't want to deal with these issues, at least initially.
Because people ask questions and get confused doesn't mean it's a bad thing to do. We don't follow like sheep, we innovate, we make things simpler. You don't like it, fine. I'm not going to argue. Hell, doing without a logical system (your way) would force people to do it your way and you can write code like that if you wish but I prefer to give people the choice.
I don't recall that question. "Where is point x,y IN my sprite" is nothing to do with the issue here. The coordindate system IN the sprites uses a normalised local-space so that no matter what size the sprites are, mount/link-points as well as collision polygon definitions do not change. This is just another logical coordinate space and very valuable it is too unless you prefer changing your mind on your sprites size and having to recalculate the collision-polygon again. This is no different a logical coordinate system than the window.
BTW: Did you read and understand the code examples posted? It really doesn't sound like it to me.
My code showed you that the system can easily accomodate your needs. If you want your coords to be your physical resolution then that single camera command will do that for you. If you don't then you can use another. What exactly is the limitation here?
Also, you need to realise that the 100x75 size is there for a reason. The physics system is designed currently so that the mass/interia is calculated from the collision-polygon area which, if you don't want huge forces required to move objects, requires that areas are logically small. Larger values using FP are bad for precision. This feature is very useful for letting T2D automatically calculate relative values such as this and makes some of the physics work automatic. I think the discussion starts to get way off base here so I won't discuss this in much more detail.
The end result is, configure T2D how you want, it lets you do it. There's no limitation here.
- Melv.
03/10/2005 (11:05 am)
... continued ...I'm showing you how to have both. I'm showing you that you can tell the camera to set logical coordinate system to match the physical resolution or even keep it fixed, whatever. By asking the question you've just justified having a logical coordinate system. You want both, then you can easily ( in a few lines of code ), set the coordinate system to match the physical resolution easily. But not everyone is you. There are a good majority that don't want to deal with these issues, at least initially.
Because people ask questions and get confused doesn't mean it's a bad thing to do. We don't follow like sheep, we innovate, we make things simpler. You don't like it, fine. I'm not going to argue. Hell, doing without a logical system (your way) would force people to do it your way and you can write code like that if you wish but I prefer to give people the choice.
I don't recall that question. "Where is point x,y IN my sprite" is nothing to do with the issue here. The coordindate system IN the sprites uses a normalised local-space so that no matter what size the sprites are, mount/link-points as well as collision polygon definitions do not change. This is just another logical coordinate space and very valuable it is too unless you prefer changing your mind on your sprites size and having to recalculate the collision-polygon again. This is no different a logical coordinate system than the window.
BTW: Did you read and understand the code examples posted? It really doesn't sound like it to me.
My code showed you that the system can easily accomodate your needs. If you want your coords to be your physical resolution then that single camera command will do that for you. If you don't then you can use another. What exactly is the limitation here?
Also, you need to realise that the 100x75 size is there for a reason. The physics system is designed currently so that the mass/interia is calculated from the collision-polygon area which, if you don't want huge forces required to move objects, requires that areas are logically small. Larger values using FP are bad for precision. This feature is very useful for letting T2D automatically calculate relative values such as this and makes some of the physics work automatic. I think the discussion starts to get way off base here so I won't discuss this in much more detail.
The end result is, configure T2D how you want, it lets you do it. There's no limitation here.
- Melv.
#7
I asked you why I somebody would want to increase the resolution, you told me because of "more detail". But since my logical camera view would equal this optimal size already and increasing would result in no benefit.
Decreasing the size might help if the graphics card is fill rate limited.
So, wouldn't it be a good idea to set the viewport size to the resolution the game is designed for?
Another slightly related question: why is the aspect ratio 5:3 in the default system while the actual display has 4:3 aspect ratio?
It's seems to me that this example sets the viewport size and location. If that is right, then: "yes", if that's wrong then: "no".
My original question was answered already by Manuel. Then I wanted to know what the reason behind the current default viewport size is...
I asked it before and the question has been ignored:
IMHO, the best use is to allow lower resolution gaming on a fillrate limited system.
But I'd be really happy to learn about other uses as well.
03/10/2005 (11:50 am)
Right now Torque2d uses a camera that displays 100x60 units. Why would it hurt to change it to a camera that displays m * n units (independ of resolution), wher m equals the width of the resolution the game was designed for and n equals the height of the resolution the game was designed for?I asked you why I somebody would want to increase the resolution, you told me because of "more detail". But since my logical camera view would equal this optimal size already and increasing would result in no benefit.
Decreasing the size might help if the graphics card is fill rate limited.
So, wouldn't it be a good idea to set the viewport size to the resolution the game is designed for?
Another slightly related question: why is the aspect ratio 5:3 in the default system while the actual display has 4:3 aspect ratio?
Quote:
BTW: Did you read and understand the code examples posted? It really doesn't sound like it to me.
My code showed you that the system can easily accomodate your needs
It's seems to me that this example sets the viewport size and location. If that is right, then: "yes", if that's wrong then: "no".
My original question was answered already by Manuel. Then I wanted to know what the reason behind the current default viewport size is...
Quote:We don't follow like sheep, we innovate, we make things simpler.Sounds great. Could you tell me exactly how this makes things simpler?
I asked it before and the question has been ignored:
Quote:But could somebody please tell me a single 2d game in which changing resolution results in scaled gfx?I'm even willing to expand that question to "What kind of game would benefit from that feature?"
IMHO, the best use is to allow lower resolution gaming on a fillrate limited system.
But I'd be really happy to learn about other uses as well.
#8
The defaults for the camera are set at 100 x 75 (4:3), not 100 x 60.
03/10/2005 (11:59 am)
Quote:Another slightly related question: why is the aspect ratio 5:3 in the default system while the actual display has 4:3 aspect ratio?
The defaults for the camera are set at 100 x 75 (4:3), not 100 x 60.
#9
Huh? And you can't do that now with the system I've provided you?
Tell me this. Why do systems such as OpenGL and DirectX provide the ability to work in a logical coordinate spaces taking into account that those system are also used for 2D environments as well? You think its just so that you can design your graphics at a native game resolution? What about applications that have nothing to do with texturing.
It's not my place to teach you computer graphics 101. Go read "Computer Graphics: Principles and Practice" by Foley/van-Dam or any other text.
You seem to be a rebel without a cause here.
- Melv.
03/10/2005 (12:08 pm)
Quote:Right now Torque2d uses a camera that displays 100x60 units. Why would it hurt to change it to a camera that displays m * n units (independ of resolution), wher m equals the width of the resolution the game was designed for and n equals the height of the resolution the game was designed for?
Huh? And you can't do that now with the system I've provided you?
Quote:I asked you why I somebody would want to increase the resolution, you told me because of "more detail". But since my logical camera view would equal this optimal size already and increasing would result in no benefit.You're arguing a mute point. For god sake, T2D allows you to configure the system however you like. We're not forcing you to do anything. Have it our way, have it your way. What's the problem? You don't see the benefit of a logical coordinate system then fine. You understand quantum physics? Doesn't mean it's a silly idea.
Decreasing the size might help if the graphics card is fill rate limited.
Quote:I asked it before and the question has been ignored:Ignored. :) You think I've got nothing better to do than to argue with you on exactly why we provide a system that can give you what you want with a single script call?
Quote:Also, you need to realise that the 100x75 size is there for a reason. The physics system is designed currently so that the mass/interia is calculated from the collision-polygon area which, if you don't want huge forces required to move objects, requires that areas are logically small. Larger values using FP are bad for precision. This feature is very useful for letting T2D automatically calculate relative values such as this and makes some of the physics work automatic. I think the discussion starts to get way off base here so I won't discuss this in much more detail.Hmm, this was a statement but you ignored it. The default is 100x75 which last time I used a calculator was 4:3.
Tell me this. Why do systems such as OpenGL and DirectX provide the ability to work in a logical coordinate spaces taking into account that those system are also used for 2D environments as well? You think its just so that you can design your graphics at a native game resolution? What about applications that have nothing to do with texturing.
It's not my place to teach you computer graphics 101. Go read "Computer Graphics: Principles and Practice" by Foley/van-Dam or any other text.
You seem to be a rebel without a cause here.
- Melv.
#10
Hopefully Lennart, you have enough info to configure T2D to suit your needs, it is rather simple to do.
Good Luck,
- Melv.
03/10/2005 (1:08 pm)
Oooh bad vibes on the forums. Not good at all.Hopefully Lennart, you have enough info to configure T2D to suit your needs, it is rather simple to do.
Good Luck,
- Melv.
#11
I don't see why and how and would like to learn.
I'm just not sure why you seem to tell everybody that it's a bad idea to use a logical resolution that is not set to the desired physical resolution.
I'm also trying to figure out why I would want to rescale my application in such a manner. It seems like you know some reasons, and I'd just like to know them.
So the reason is not flexibility but a requirement of the physics engine.
The normal 2d applications in games are either sprites or interface elements. Sprites in a 3d environment won't be displayed at their original size most of the time anyway and interface elements shouldn't scale if the resolution changes.
Again, I'm not sure what your point is?
Good one. I don't need or want to defend myself or my knowledge. It was you who said that your virtual coordinate system would allow people to get better gfx in higher resolutions.
When I asked you where the actual benefits are, you had no answers and tell me that I should read books that I got the day they came out (yep, I'm in the business that long ;)). I even read about Wu anti-aliasing before it appeared in the Gems.
Please don't jump to conclusions.
But you still tell me (and others reading the threats here) that the reason has something to do with gfx quality and the ability of the user to select a higher resolution.
I just want to know what these benefits are... if there are no such benefits, fine. That's ok as well. Then one can easily use whatever logical resolution one wants - as long as he doesn't need the physics system that is :)
BTW, Manuel answered my question. It was your reply that created more questions ;)
03/10/2005 (1:21 pm)
Quote:Of course I can. That was shown by Manuel already. But your answer spawned a couple of other questions. You also told me that using a logical resolution that is set to the desired resolution is a bad idea, and I want to know why?
Huh? And you can't do that now with the system I've provided you?
Quote:For god sake, T2D allows you to configure the system however you like. We're not forcing you to do anything.Again I'm just trying to figure out what the benefits are of the 100x60 system. You told me above that it's better than using a logical system equal to the desired resolution.
I don't see why and how and would like to learn.
Quote:You think I've got nothing better to do than to argue with you on exactly why we provide a system that can give you what you want with a single script call?Um no.. that system is great.
I'm just not sure why you seem to tell everybody that it's a bad idea to use a logical resolution that is not set to the desired physical resolution.
I'm also trying to figure out why I would want to rescale my application in such a manner. It seems like you know some reasons, and I'd just like to know them.
Quote:Hmm, this was a statement but you ignored it. The default is 100x75 which last time I used a calculator was 4:3.You're right. That's a good reason. You should add this to the FAQ.
So the reason is not flexibility but a requirement of the physics engine.
Quote:Tell me this. Why do systems such as OpenGL and DirectX provide the ability to work in a logical coordinate spaces taking into account that those system are also used for 2D environments as well?Well, because they are mainly vector based environements that allow you to texture the polygons. Why do you ask?
The normal 2d applications in games are either sprites or interface elements. Sprites in a 3d environment won't be displayed at their original size most of the time anyway and interface elements shouldn't scale if the resolution changes.
Again, I'm not sure what your point is?
Quote:What about applications that have nothing to do with texturing.Exactly. Those applications benefit from the virtual screen size. Bitmap based applications don't benefit that much from virtual size - even due to the fact that are pixel based. Again if you know some examples of bitmap based applications that benefit from this feature, let me know.
Quote:It's not my place to teach you computer graphics 101. Go read "Computer Graphics: Principles and Practice" by Foley/van-Dam or any other text.
Good one. I don't need or want to defend myself or my knowledge. It was you who said that your virtual coordinate system would allow people to get better gfx in higher resolutions.
When I asked you where the actual benefits are, you had no answers and tell me that I should read books that I got the day they came out (yep, I'm in the business that long ;)). I even read about Wu anti-aliasing before it appeared in the Gems.
Please don't jump to conclusions.
Quote:You seem to be a rebel without a cause here.I just wanted to know where the benifits are. The best answer so far is: It doesn't break the physics system. That's a good answer.
But you still tell me (and others reading the threats here) that the reason has something to do with gfx quality and the ability of the user to select a higher resolution.
I just want to know what these benefits are... if there are no such benefits, fine. That's ok as well. Then one can easily use whatever logical resolution one wants - as long as he doesn't need the physics system that is :)
BTW, Manuel answered my question. It was your reply that created more questions ;)
#12
You wanted a stock coord set of something like 800x600. Fine do it. Not everyone wants to develop art at that resolution. We made the choice of a coord system that was so different from any value that people are used to e.g. 100x75 simply because it highlighted the fact that we were using a logical coordinate system. This is EA. The final product may choose completely different values, who knows?
My comments previously were to highlight that using a fixed coordinate system based upon pixels that changed if the resolution change is a bad idea, (generally); not having a logical coordinate system that started at a different default setting but stayed the same so you could target your art to a specific set of coordinates. I stand by this and so do many industry professionals in this forum and at GG.
If you want your coordinate set to be dynamic so you see more of your "map" then cool. Not everyone is showing a map or a scene where they wish to see more of the world and most of the time, this isn't the case either. A simple choice of defaults.
I never said it was setup like this because it would break the physics system. It's setup like this to make things easier to digest in the EA release and after all, you can configure it however you like. We haven't yet supplied enough documentation on things like the collision or physics systems to warrant not setting up the defaults to anything other than a more optimal setup that would cause minimum questions. Having large logical viewports fine; the physics can handle it but there are a couple of settings you need to change that we've not documented. I casually mention precision but that is another case of trying not to go into too much detail. Target audience. Your alternate setup of 800x600 would cause confusion because we've no documentation on the physics and people would struggle with some of the setup details. It would also seem to indicate that those were pixel coordinates which they are not. Bad idea?
Well like me, your a veteran of these things so that's good, sorry for my presumption but if that's the case, why ask the questions to something you already knew. You don't think asking such simplistic questions leads to a belief that you don't know the answers? Your posts seemed to indicate that. Don't presume? I can only go from the "tone" of your text and the questions you ask. I speak everyday to people who range from 12 year old to 40 year old vets. As you know, in the forums, you've no indication of the caliber of person you're talking to and so you try to adapt your answers to suit the audience. Sometimes you get it wrong.
Besides the fact that I am living on these forums at the moment, I try to answer with as much accuracy as I can without going into too much detail as to bore people. These answers may not always contain the complete detail but I try to find a middle ground between accuracy and generalisation and this will satisfy most casual coders whereas for the more technically minded, it will leave only questions. In the future, I would recommend filling out your profile so that people can give you the detailed answers you deserve. I try to look at peoples profiles to give me a better idea of the general/detail factor I need to provide.
... continued ...
03/10/2005 (3:12 pm)
Okay, final answer because this is getting silly.You wanted a stock coord set of something like 800x600. Fine do it. Not everyone wants to develop art at that resolution. We made the choice of a coord system that was so different from any value that people are used to e.g. 100x75 simply because it highlighted the fact that we were using a logical coordinate system. This is EA. The final product may choose completely different values, who knows?
My comments previously were to highlight that using a fixed coordinate system based upon pixels that changed if the resolution change is a bad idea, (generally); not having a logical coordinate system that started at a different default setting but stayed the same so you could target your art to a specific set of coordinates. I stand by this and so do many industry professionals in this forum and at GG.
If you want your coordinate set to be dynamic so you see more of your "map" then cool. Not everyone is showing a map or a scene where they wish to see more of the world and most of the time, this isn't the case either. A simple choice of defaults.
I never said it was setup like this because it would break the physics system. It's setup like this to make things easier to digest in the EA release and after all, you can configure it however you like. We haven't yet supplied enough documentation on things like the collision or physics systems to warrant not setting up the defaults to anything other than a more optimal setup that would cause minimum questions. Having large logical viewports fine; the physics can handle it but there are a couple of settings you need to change that we've not documented. I casually mention precision but that is another case of trying not to go into too much detail. Target audience. Your alternate setup of 800x600 would cause confusion because we've no documentation on the physics and people would struggle with some of the setup details. It would also seem to indicate that those were pixel coordinates which they are not. Bad idea?
Well like me, your a veteran of these things so that's good, sorry for my presumption but if that's the case, why ask the questions to something you already knew. You don't think asking such simplistic questions leads to a belief that you don't know the answers? Your posts seemed to indicate that. Don't presume? I can only go from the "tone" of your text and the questions you ask. I speak everyday to people who range from 12 year old to 40 year old vets. As you know, in the forums, you've no indication of the caliber of person you're talking to and so you try to adapt your answers to suit the audience. Sometimes you get it wrong.
Besides the fact that I am living on these forums at the moment, I try to answer with as much accuracy as I can without going into too much detail as to bore people. These answers may not always contain the complete detail but I try to find a middle ground between accuracy and generalisation and this will satisfy most casual coders whereas for the more technically minded, it will leave only questions. In the future, I would recommend filling out your profile so that people can give you the detailed answers you deserve. I try to look at peoples profiles to give me a better idea of the general/detail factor I need to provide.
... continued ...
#13
If you are as experienced as you say you are you will understand the difficulties in setting up defaults for a system that is easy for newbies as well as veterans alike.
- Having a system that has the origin in the center is easier to digest for a newbie who forgets to set the position of a sprite which defaults there.
- Setting logical coordinates set to something completely different from a recognised resolution to highlight it's not a pixel coordinate.
- Setting values that work easier with the physics so that people don't need to know too much about them as we're still working on the doco for that. Afterwards, not a problem.
Threats? What threats? You mean tone? Maybe I'm tired and for that I apologise.
For someone who started his post by saying ...
- Melv.
03/10/2005 (3:12 pm)
... continued ...If you are as experienced as you say you are you will understand the difficulties in setting up defaults for a system that is easy for newbies as well as veterans alike.
- Having a system that has the origin in the center is easier to digest for a newbie who forgets to set the position of a sprite which defaults there.
- Setting logical coordinates set to something completely different from a recognised resolution to highlight it's not a pixel coordinate.
- Setting values that work easier with the physics so that people don't need to know too much about them as we're still working on the doco for that. Afterwards, not a problem.
Threats? What threats? You mean tone? Maybe I'm tired and for that I apologise.
For someone who started his post by saying ...
Quote:unless t2d get's support for vector gfx in one way or another, the logical "screen size" is pretty useless.... you have alot of balls to consider my posts "threats". If T2D's logicial "screen size" is "pretty useless" then I suggest that all the industry veterans who were involved in its design are also the same as we must have made a big mistake. Your post started with a superior attitude and that's why your posts were taken as a front.
- Melv.
#14
Then you replied
Since I really don't see the advantages, I asked what they are, since:
Up to now no advantages (besides working physics) were mentioned.
03/10/2005 (4:03 pm)
Quote:ou wanted a stock coord set of something like 800x600. Fine do it. Not everyone wants to develop art at that resolution.No. I wanted to set the logical resolution to the resolution the game art is designed to.
Quote:So that my camera would match the resolution of (800,600) I'm developing my gfx for?
Then you replied
Quote:You may have got used to using pixels but that doesn't really make it a good idea unless you only want to work in a single resolution. Not wanting to sound harsh but saying the "logical" screen size is pretty useless shows how you don't really understand the advantages they bring.
Since I really don't see the advantages, I asked what they are, since:
Quote:I'm really not sure how running the game at a resolution higher than what it was designed for will result in a better look if you use pixel graphics.
Up to now no advantages (besides working physics) were mentioned.
#15
The good thing is the camera system, since it allows you neat things like split screen effects. The actual scale shouldn't matter, don't you agree? And using a system based on the pixeled art isn't that bad.
If you need a backdrop, do you tell your artists that he can do it on any size he likes? And do you tell the spriter that he should simply use a size he's comfortable with, since the engine will be able to scale them as needed?
Scaling down makes sense only if your graphic card is fill rate limited, or maybe as a gimmick. If you know another reason why I should run the game at a lower resolution than it was designed for, let me know.
My question still remains: why would I want to scale my gfx beyond the size it was designed for?
Also, you quoted that sentence out of context. My next sentences asked for applications of that virtual screen size for 2d games. Still waiting for suggestions here.
It's a good feature, since it allows split screen effects (I'm pretty sure I wrote that before) but running the game split screen is normally just a special case since most PC multiplayer titles are networked these days. And even if you use it for split screen, it would be still a good idea to use the pixel size as a logical coordinate system, since you'll normally design the levels / gfx from the singleplayer respectivly non-splitscreen point of view.
And if you can come up with a good reason why I shouldn't use a logical coordinate system that matches the resolution of my artwork, I'll apologize and will try to find a way undo all my elitist ramblings.
03/10/2005 (4:03 pm)
... continued ...Quote:My comments previously were to highlight that using a fixed coordinate system based upon pixels that changed if the resolution change is a bad ideaWhy is a system based on pixels worse than one using any other value? In both cases scaling the gfx down will be possible and scaling them up pointless.
The good thing is the camera system, since it allows you neat things like split screen effects. The actual scale shouldn't matter, don't you agree? And using a system based on the pixeled art isn't that bad.
If you need a backdrop, do you tell your artists that he can do it on any size he likes? And do you tell the spriter that he should simply use a size he's comfortable with, since the engine will be able to scale them as needed?
Quote:Not everyone is showing a map or a scene where they wish to see more of the world.Please... just one example where scaling the game to a resolution higher than the one your art was designed for makes sense.
Scaling down makes sense only if your graphic card is fill rate limited, or maybe as a gimmick. If you know another reason why I should run the game at a lower resolution than it was designed for, let me know.
Quote:It would also seem to indicate that those were pixel coordinates which they are not. Bad idea?Document it? Also, in the target resolution it is equivalent to pixels. That is the whole idea. Develop for one resolution, don't care about the others since the engine will deal with the details. Doesn't sound like a bad idea to me.
Quote:You don't think asking such simplistic questions leads to a belief that you don't know the answers?Again, my original question was answered in the 1st reply in this topic. It was your reply that spawned new questions that are still open :)
Quote:Threats? What threats? You mean tone? Maybe I'm tired and for that I apologiseThreads. Sorry, English isn't my native language which results in mistakes, esp. since it's pretty late here already.
Quote:If T2D's logicial "screen size" is "pretty useless" then I suggest that all the industry veterans who were involved in its design are also the same as we must have made a big mistake. Your post started with a superior attitude and that's why your posts were taken as a front.
My question still remains: why would I want to scale my gfx beyond the size it was designed for?
Also, you quoted that sentence out of context. My next sentences asked for applications of that virtual screen size for 2d games. Still waiting for suggestions here.
It's a good feature, since it allows split screen effects (I'm pretty sure I wrote that before) but running the game split screen is normally just a special case since most PC multiplayer titles are networked these days. And even if you use it for split screen, it would be still a good idea to use the pixel size as a logical coordinate system, since you'll normally design the levels / gfx from the singleplayer respectivly non-splitscreen point of view.
Quote: Your post started with a superior attitude and that's why your posts were taken as a front.Sorry about that.
And if you can come up with a good reason why I shouldn't use a logical coordinate system that matches the resolution of my artwork, I'll apologize and will try to find a way undo all my elitist ramblings.
#17
The actual coordinates do not have to match pixels. The size of the sprites can also determine whether there's some kind of 1:1, better or worse scaling going on. The graphics card will interpolate appropriately. The size of the sprites can be anything. If you want the convienience that the two are the same, do it, that's why there's the option. Throughout your posts you've mentioned rendering "bitmaps" when discussing a 2D engine. We're not rendering bitmaps, we're rendering textures, there's an important distinction because we're talking about texels here.
My graphics characters may be designed to run @ 1600x1200. Perhaps I want my coordinates to be (400 x 100) and I'm going to zoom the camera in (because it's a sniper game) that will result in bigger on-screen size and therefore more detail because the graphics were designed at a higher resolution and I might want to run in much lower resolutions as standard. In this case, our logical does not equal the art resolution purposely so we can see zoomed detail. Downscaling by default leading to a 1:1 when fully zoomed-in. The reason for the 400x100 might be because my primary concern is that I want my world-units to be equal to metres not pixels as the majority of the game control replies on physical distances or a sense of scale. This is identical to a 3D engine. I can use the sizes of the sprites to ensure my on-screen resolution if I wish.
I keep trying. You're not listening. You're dismissing because it's not for you.
I agree with Paul.
- Melv.
03/10/2005 (11:13 pm)
Quote:My question still remains: why would I want to scale my gfx beyond the size it was designed for?Nobody told you to scale your graphics beyond the scale it was intended for. You said that. This is how this thread has gone on. You are not listening.
The actual coordinates do not have to match pixels. The size of the sprites can also determine whether there's some kind of 1:1, better or worse scaling going on. The graphics card will interpolate appropriately. The size of the sprites can be anything. If you want the convienience that the two are the same, do it, that's why there's the option. Throughout your posts you've mentioned rendering "bitmaps" when discussing a 2D engine. We're not rendering bitmaps, we're rendering textures, there's an important distinction because we're talking about texels here.
My graphics characters may be designed to run @ 1600x1200. Perhaps I want my coordinates to be (400 x 100) and I'm going to zoom the camera in (because it's a sniper game) that will result in bigger on-screen size and therefore more detail because the graphics were designed at a higher resolution and I might want to run in much lower resolutions as standard. In this case, our logical does not equal the art resolution purposely so we can see zoomed detail. Downscaling by default leading to a 1:1 when fully zoomed-in. The reason for the 400x100 might be because my primary concern is that I want my world-units to be equal to metres not pixels as the majority of the game control replies on physical distances or a sense of scale. This is identical to a 3D engine. I can use the sizes of the sprites to ensure my on-screen resolution if I wish.
Quote:And if you can come up with a good reason why I shouldn't use a logical coordinate system that matches the resolution of my artwork, I'll apologize and will try to find a way undo all my elitist ramblings.I thought I had. I am not going to repeat myself again and again.
I keep trying. You're not listening. You're dismissing because it's not for you.
I agree with Paul.
- Melv.
#18
One of the advantages 2D games have over 3D games is that the graphics can be extremely clear, simply because it need not be stretched, resampled or otherwise modified before it hits the screen, giving an artist full control of the appearance. Rarely do we ever want to see the sprite or background resized.
Common strategies to preserve this would be to do things like:
1. Fix the resolution at which the game can be played
2. Show more of the game area when screen resolution is increased, allowing sprites to shrink (relatively)
3. Use different spritesheets for different resolutions.
All of these can be done in T2D. Having LODs in a subsequent iteration would make 3 easier to do. Having a flag to turn off sprite scaling might make variations of 2 easier to do.
The logical coordinate system, being much for flexible than a pixel coordinate system is certainly not at odds with this and arguably makes implementation of 2 somewhat simpler.
Can we just treat this thread as a feature-request for per-resolution-LODs?
03/11/2005 (2:00 am)
Hate to butt in on such a pleasant thread, but speaking from a 2D developer standpoint, maybe I can clarify something to provide more brainfuel for the next iteration of T2D.One of the advantages 2D games have over 3D games is that the graphics can be extremely clear, simply because it need not be stretched, resampled or otherwise modified before it hits the screen, giving an artist full control of the appearance. Rarely do we ever want to see the sprite or background resized.
Common strategies to preserve this would be to do things like:
1. Fix the resolution at which the game can be played
2. Show more of the game area when screen resolution is increased, allowing sprites to shrink (relatively)
3. Use different spritesheets for different resolutions.
All of these can be done in T2D. Having LODs in a subsequent iteration would make 3 easier to do. Having a flag to turn off sprite scaling might make variations of 2 easier to do.
The logical coordinate system, being much for flexible than a pixel coordinate system is certainly not at odds with this and arguably makes implementation of 2 somewhat simpler.
Can we just treat this thread as a feature-request for per-resolution-LODs?
#19
I've certainly got more productive things to do than let this thread monopolise my time.
End of posts.
- Melv.
03/11/2005 (2:16 am)
Agreed.I've certainly got more productive things to do than let this thread monopolise my time.
End of posts.
- Melv.
#20
03/11/2005 (5:37 am)
Quote: I'm going to zoom the camera in (because it's a sniper game)Finally an application. Thanks a lot :)
Torque Owner Manuel F. Lara
Using "400 300 800 600" would set the classic 2D coordinate system (0,0 at top left screen) if you prefer.