Thread: RE: [GD-General] More screen res love (tile graphics)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Troy G. <Tr...@cs...> - 2003-03-31 15:36:21
|
> That is the gist of it. Running at a resolution other than the > native LCD resolution looks really bad -- not in a "this is kinda > crappy" way, but in a "this is pretty damned illegible" kind of way. > So just going fullscreen is actually worse than running windowed. I > tried playing Homeworld the other day, and it has a cap of 1024x768. > When I tried to run it, I pretty much couldn't read the menus on my > Viewsonic VA800. I find this odd... I am constantly on the road and on airplanes, so I'm forced to do most of my PC gaming on my laptop (and it's faster to boot, so it's not all bad!). The laptop runs at a native resolution of 1600x1200, but have absolutely no legibility problems playing any games at lower resolutions (and I play all of them except Medal of Honor at lower resolutions -- I like the extra resolution for aiming over distances). These include alot of 2D games (my particular favorites) including the recent SimCity4. I sometimes find the scaled up graphics with the filtering a nice change from the "supersharp" non-filtered graphics of a CRT. Of course, this isn't always the case... really well done pixelart looks great running at it's native resolution (whether it be CRT or LCD), and interlaced signals look *awful* on LCDs! It drives me insane at GDC, E3, ECTS, Xfest, DevCon, etc., all of these video game related tradeshows they attach the systems to LCDs... I think they make most games look worse (because of the large amount of filtering being done on the interlacing, which ironically most games are already doing assuming the signal will remained interlaced!). I assume the best solution is to have multi-resolution artwork targeting the major resolutions (640x480, 800x600, 1024x768, 1280x1024, etc.). Of course, it would be a pain to hand design this artwork. But, I believe there are two routes to reducing the workload. First, develop the artwork in a resolution-independent format, such as a 3D (ala Starcraft) or vector artwork. These can then be rendered to whatever needed resolution. The second option would be to produce the highest resolution originals and use a better-than-bicubic down-sampling filter (which most often muddies pixelart). I'd recommend separating out luminosity from the chroma channel, then applying different filters to each before recombining. For chroma, a simple bicubic should work fine, and for luminosity you'd want a detail preserving filter. I can't recall one off the top of my head, but Game Developer had a few articles (a few years ago, so they should be on Gamasutra) about better-than-bicubic down-sampling for things like mipmaps with text. Troy Developer Relations Criterion Software www.csl.com |
|
From: Troy G. <Tr...@cs...> - 2003-04-01 00:11:26
|
> Well, consider the pixel density. You're probably using a 15.1" > laptop screen with a 1600x1200 resolution, so your pixels are going > to be very small. A standard 17 or 18" LCD is running at 1280x1024, > so you're going to see much Agreed. Probably the reason that all those LCDs at E3 look so crappy. > >I assume the best solution is to have multi-resolution artwork > Yes, this is the ideal solution, but it requires a lot more content > generation and it also requires a lot more storage and download size, > so it's not practical in every situation. Well, of course. You can't have your cake and eat it too. You've got to either play the odds on what the consumer will have, or put more work in to cover your bases, or be prepared to handle special cases with special instructions or support (or "sorry!"). There is no perfect solution for one-stop, unconstrained content production paired with perfect, multi-resolution display. Well, there is vector artwork (designed to solve this exact problem) like Flash or SVG. And of course 3D (vector artwork in the next dimension!). > >targeting the major resolutions (640x480, 800x600, 1024x768, > >1280x1024, etc.). Of course, it would be a pain to hand design this > >artwork. > > Unfortunately there are a lot more major resolutions than that. > 1152x864 is common on Macs; 1400x1000 (?) on some laptops; 1600x1024; > 1600x1200; 1920x1200; etc. And while neither of these individual > resolutions is very common, combined they make up a sizable fraction > of the market (I would guess). Before you spend too many hours fighting this issue, I would do more than guess about your target market. A quick perusal of TheCounter.com (who gather statistics off the web -- skewed, yes, but you did mention downloadable content so it is applicable) reveals that ~46% of potential customers are using 800x600, ~42% using 1024x768, ~5% using 1280x1024, ~3% 1152x864, and ~3% other. Now, this does sound a bit skewed from what common knowledge would suggest, but then again I hang out with a bunch of game developers and artists, not exactly the crown who'd be using out-of-the-box screen resolutions. But if I was selling a game (particularly one where the mainstream crowd meant something to me) I'd be targetting 640x480, 800x600, 1024x768. Anything else, I'd just ask the user: "Do you want the image stretched (which might be blurrier) or centered (which might be smaller)?" Not all things can be solved algorithmically (particularly when you start second-guessing people's preferences). > >would be to produce the highest resolution originals and use a > >better-than-bicubic down-sampling filter (which most often muddies > >pixelart). > > That's probably the best route, except it does keep content sizes > fairly high. Again, you can't have your cake and eat it too! Troy Developer Relations Criterion Software www.csl.com |
|
From: Brian H. <ho...@py...> - 2003-04-01 00:34:50
|
>There is no perfect solution for one-stop, unconstrained= content >production paired with perfect, multi-resolution display. Well, >there is vector artwork (designed to solve this exact problem)= like >Flash or SVG. And of course 3D (vector artwork in the next >dimension!). Well sure, but since vector graphics and 3D are both common= solutions to their respective problems, I was hoping (foolishly, granted),= that there was an equivalent in the tile/sprite space. I doubted= there was, but because I haven't worked in that medium before I didn't= want to blithely assume that was the case, hence my query. >Before you spend too many hours fighting this issue, I would do= more >than guess about your target market. Excuse me while I laugh. HAHAHAHAHAHAH!!!! Sorry, just had to giggle at the notion that there's a source for meaningful= statistics on consumer penetration of hardware =3D) >TheCounter.com (who gather statistics off the web -- skewed,= yes, >but you did mention downloadable content so it is applicable) For this game it will appeal to a more hardcore gamer market, but= it will still be relatively low system spec. If you take a look at= games like MOO3, Galactic Civilizations, etc. you'll note that they're not aimed at the highest end of hardware but they are definitely aimed at a non-casual gaming market. The same could= be said of many of the isometric RPGs out there. For that market, I'm assuming 1024 and up is a much larger= fraction. >"Do you want the image stretched (which might be blurrier) or >centered (which might be smaller)?" Right, this will likely be the case for any modes outside of 1024x768. Brian |
|
From: <phi...@pl...> - 2003-04-01 20:10:25
|
> >"Do you want the image stretched (which might be blurrier) or > >centered (which might be smaller)?" Given that you're not actually going to be able to 'solve' this issue technically, giving the user the choice is the right thing to do. You should allow them to pick from a range of suitable zoom ratio's, 1x, 2x, as well as fit to screen, or in a window with a fixed ratio, or manual resizing. As for multiple monitors, I know MacOS allows you to enumerate physical devices, and I'm pretty sure DirectX does too. Either only display on the primary monitor (where your menu bar is on the Mac, dunno about Windows), or again, offer the user the choice, and remember it. Getting little things like this right, are a key element in not pissing off the player (which is pretty important in working that "word of mouth" thing). Cheers, Phil PS Mac games used to have this problem, as the only way you could change screen resolution, was by plugging in a different monitor, plus they had multiple monitors way back in the early 90s. This was due to Mac's having a fixed dpi, which in turne was not for any strong technical reason, but for some strange reason that I'm sure was not unrelated to Steve Job's reality distortion field. I believe this changed around System 8, but since the last one I worked on was System 7.5, I can't be sure. |
|
From: ~BG~ <arc...@ma...> - 2003-04-01 20:58:48
|
On Tuesday, April 1, 2003, at 12:12 PM, phi...@pl... wrote: > PS Mac games used to have this problem, as the only way you could > change > screen resolution, was by plugging in a different monitor, plus they > had > multiple monitors way back in the early 90s. This was due to Mac's > having a > fixed dpi, which in turne was not for any strong technical reason, but > for > some strange reason that I'm sure was not unrelated to Steve Job's > reality > distortion field. I believe this changed around System 8, but since the > last one I worked on was System 7.5, I can't be sure. Actually IIRC it was done to maintain 1:1 pixel/point ratio with print. Print also played a big role in the standard gamma differences between Macs and Windows PCs at the time as well... ------------------------------------------------------------------------ -------------------------- Copyright 2002 archie4oz email -- End User Licensing Agreement -- By reading the above post you grant archie4oz (email author of said listed party name) the right to take your money, eat your cat, and urinate on your house. In addition you give archie4oz (above mentioned) the right to use your sister in anyway he sees fit. If you do not agree to these terms then DO NOT READ the above email. |
|
From: <phi...@pl...> - 2003-04-02 01:39:59
|
> Actually IIRC it was done to maintain 1:1 pixel/point ratio with print. That's right, it's all coming back to me now. 72dpi IIRC. Meant that an A4 screen really was A4, also meant that Mac games had to shift at least four times as many pixels to achieve the same effect as PC games that could just change to 320x240 regardless of monitor size. Quite possibly the single biggest thing that killed the Mac as a serious games machine. (ok, other than the price of the machine) Cheers, Phil |
|
From: Brian H. <ho...@py...> - 2003-04-05 00:25:59
|
So I've been thinking about this whole scalable GUI thing some= more, and the "obvious" solution is to do something like make the GUI= in some kind of vector language so that it can scale. This has a large number of advantages, and the biggest= disadvantage is that you can't do real nice pixel/raster effects such as the various filters available for Photoshop. Instead they'd have to= be described procedurally, which might be considered fairly= limiting. A combination of FreeType fonts coupled with vector GUI= descriptions would seem to allow a great degree of scalability while keeping things relatively sane for the artist. To develop the GUI you could use a standard vector drawing= package that exports to a parseable file format such as AI, EPS or SVG. = Then you either load the file directly or run it through a filter to= some local file format such as a Lua script. Since SVG is XML-based,= you can easily allow the artist to tag functions for the GUI= components by embedding a key, or you could simply cheese out and tag it as= part of the object ID. The most difficult part of the process that I can think of is actually rendering the GUI on modern hardware. Obviously pixel plotting is straight out, so you'd probably construct the GUI elements into textures and use those. My biggest concern is that= this can eat up a ton of texture space, especially if you have= alpha (precluding the use of 16-bit texture information). Take a situation where you have a 1280x1024 fullscreen= application, and your total GUI elements come up to an overdraw of 4x (a lot= of the GUI elemenst would presumably be in the form of dialog boxes,= etc. that are temporal). Assuming you wanted the entire GUI= cached, this could easily add up to a lot of texture memory consumed for= a high-res display. Obviously you could rasterize into temporary bitmaps and use liberal amounts of texture destruction, but that= still seems like a lot of overhead just for a GUI. The problem,= of course, being that since this is scalable, the higher your screen= resolution the more texture memory is consumed by your GUI= elements. Thoughts, comments and "you're smoking crack" comments= appreciated. Brian |
|
From: Greg S. <gr...@st...> - 2003-04-05 00:56:47
|
Performance wise, I think you hit the nail on the head with the problems you described. You could forbid the use of alpha or varying levels of opacity on your UI elements, which could obviously help fill rate if you z-test. I'd design the UI for one resolution - say, 1024x768 - and if you're rendering a background, split the texture up into 12 256x256 textures. Then let the gfx hardware handle the scaling for different resolutions. Results are pretty good. And this may not be too practical, but the more ui elements that shared the same texture the better. You could batch em all up and avoid doing much texture swapping on the hardware. That method would obviously work better for ui elements which have a small piece of a texture tiled over them rather than a full background for example, but it looks way better than an untextured quad =) As an aside: I'm not sure if it was here or on the algorithms list, but I think I recall someone mentioning something about a SWF renderer. SWF is the flash file format, which basically means you'll have a layout tool pretty much written for you already. -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Brian Hook Sent: Friday, April 04, 2003 7:26 PM To: gam...@li... Subject: [GD-General] Vector GUIs So I've been thinking about this whole scalable GUI thing some more, and the "obvious" solution is to do something like make the GUI in some kind of vector language so that it can scale. This has a large number of advantages, and the biggest disadvantage is that you can't do real nice pixel/raster effects such as the various filters available for Photoshop. Instead they'd have to be described procedurally, which might be considered fairly limiting. A combination of FreeType fonts coupled with vector GUI descriptions would seem to allow a great degree of scalability while keeping things relatively sane for the artist. To develop the GUI you could use a standard vector drawing package that exports to a parseable file format such as AI, EPS or SVG. Then you either load the file directly or run it through a filter to some local file format such as a Lua script. Since SVG is XML-based, you can easily allow the artist to tag functions for the GUI components by embedding a key, or you could simply cheese out and tag it as part of the object ID. The most difficult part of the process that I can think of is actually rendering the GUI on modern hardware. Obviously pixel plotting is straight out, so you'd probably construct the GUI elements into textures and use those. My biggest concern is that this can eat up a ton of texture space, especially if you have alpha (precluding the use of 16-bit texture information). Take a situation where you have a 1280x1024 fullscreen application, and your total GUI elements come up to an overdraw of 4x (a lot of the GUI elemenst would presumably be in the form of dialog boxes, etc. that are temporal). Assuming you wanted the entire GUI cached, this could easily add up to a lot of texture memory consumed for a high-res display. Obviously you could rasterize into temporary bitmaps and use liberal amounts of texture destruction, but that still seems like a lot of overhead just for a GUI. The problem, of course, being that since this is scalable, the higher your screen resolution the more texture memory is consumed by your GUI elements. Thoughts, comments and "you're smoking crack" comments appreciated. Brian ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
|
From: Brian H. <ho...@py...> - 2003-04-05 01:08:14
|
>As an aside: I'm not sure if it was here or on the algorithms= list, >but I think I recall someone mentioning something about a SWF >renderer. I remember seeing references to this as well, I'd swear it was something Thatcher was associated with, then again it seems like= Thatcher is associated with almost everything cool these days ;) >SWF is the flash file format, which basically means >you'll have a layout tool pretty much written for you already. There are also SVG tools out there. Brian |
|
From: Thatcher U. <tu...@tu...> - 2003-04-05 14:43:41
|
On Apr 04, 2003 at 05:08 -0800, Brian Hook wrote: > >As an aside: I'm not sure if it was here or on the algorithms list, > >but I think I recall someone mentioning something about a SWF > >renderer. > > I remember seeing references to this as well, I'd swear it was > something Thatcher was associated with, then again it seems like > Thatcher is associated with almost everything cool these days ;) Yes, guilty: http://tulrich.com/geekstuff/gameswf.html I've gotten a lot of help lately from Ignacio Castanyo which I think raises the coolness factor 2x. The current status is slightly more advanced than the web page suggests, although render improvements are still in progress. The antialiased text rendering works pretty well, you can do shapes and animations and gradients etc pretty well, etc. We've more or less given up on antialiasing non-text shapes, since it seems to be pretty difficult to do efficiently. That's probably the biggest downside, if you're looking for a really killer solution to resolution independence. I haven't tried it in a game yet, so there are probably a few little necessary things missing, and also some bugs I'm sure. But I would say it's not too far from being usable in a game. -- Thatcher Ulrich http://tulrich.com |
|
From: <phi...@pl...> - 2003-04-05 03:06:03
|
We use flash for our HUD's and menus. IIRC The Star Wars Starfighter guys
did as well. I think you can get a flash renderer as middleware now, but we
rolled our own from the specs (which are publicly available somewhere).
Cheers,
Phil
"Greg Seegert"
<greg@stainlessst
eelstudios.com> To
Sent by: <gam...@li...urcef
gamedevlists-gene orge.net>
ral-admin@lists.s cc
ourceforge.net
Subject
RE: [GD-General] Vector GUIs
04/04/2003 04:56
PM
Please respond to
gamedevlists-gene
ra...@li...urcef
orge.net
Performance wise, I think you hit the nail on the head with the problems
you
described. You could forbid the use of alpha or varying levels of opacity
on your UI elements, which could obviously help fill rate if you z-test.
I'd design the UI for one resolution - say, 1024x768 - and if you're
rendering a background, split the texture up into 12 256x256 textures.
Then
let the gfx hardware handle the scaling for different resolutions. Results
are pretty good. And this may not be too practical, but the more ui
elements that shared the same texture the better. You could batch em all
up
and avoid doing much texture swapping on the hardware. That method would
obviously work better for ui elements which have a small piece of a texture
tiled over them rather than a full background for example, but it looks way
better than an untextured quad =)
As an aside: I'm not sure if it was here or on the algorithms list, but I
think I recall someone mentioning something about a SWF renderer. SWF is
the flash file format, which basically means you'll have a layout tool
pretty much written for you already.
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Friday, April 04, 2003 7:26 PM
To: gam...@li...
Subject: [GD-General] Vector GUIs
So I've been thinking about this whole scalable GUI thing some more,
and the "obvious" solution is to do something like make the GUI in
some kind of vector language so that it can scale.
This has a large number of advantages, and the biggest disadvantage
is that you can't do real nice pixel/raster effects such as the
various filters available for Photoshop. Instead they'd have to be
described procedurally, which might be considered fairly limiting. A
combination of FreeType fonts coupled with vector GUI descriptions
would seem to allow a great degree of scalability while keeping
things relatively sane for the artist.
To develop the GUI you could use a standard vector drawing package
that exports to a parseable file format such as AI, EPS or SVG. Then
you either load the file directly or run it through a filter to some
local file format such as a Lua script. Since SVG is XML-based, you
can easily allow the artist to tag functions for the GUI components
by embedding a key, or you could simply cheese out and tag it as part
of the object ID.
The most difficult part of the process that I can think of is
actually rendering the GUI on modern hardware. Obviously pixel
plotting is straight out, so you'd probably construct the GUI
elements into textures and use those. My biggest concern is that
this can eat up a ton of texture space, especially if you have alpha
(precluding the use of 16-bit texture information).
Take a situation where you have a 1280x1024 fullscreen application,
and your total GUI elements come up to an overdraw of 4x (a lot of
the GUI elemenst would presumably be in the form of dialog boxes,
etc. that are temporal). Assuming you wanted the entire GUI cached,
this could easily add up to a lot of texture memory consumed for a
high-res display. Obviously you could rasterize into temporary
bitmaps and use liberal amounts of texture destruction, but that
still seems like a lot of overhead just for a GUI. The problem, of
course, being that since this is scalable, the higher your screen
resolution the more texture memory is consumed by your GUI elements.
Thoughts, comments and "you're smoking crack" comments appreciated.
Brian
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557
|
|
From: Brian H. <ho...@py...> - 2003-04-05 01:23:56
|
Tom Hubina mentioned to me that a compromise would be to= rasterize the vector elements into a 2D mesh and then use texture mapping= to fill the interiors with some kind of repeating texture. This works fine if you can use a textured background and you're= happy with it either A.) repeating differently at different= resolutions, or B.) having it bilerp up. The advantage is that drawing the GUI requires almost no texture consumption because you don't have predefined GUI elements sitting in texture memory, just= decorative textures (fills, strokes, etc.) You could also leverage the use= of vertices by relying on vertex color for added effects, e.g. doing= bevels or gradients. There are worst case situations where the number of vertices can= skyrocket, e.g. making a round radar image that has to be= perfectly smooth at 400x300 screen size on a 1600x1200 display (well, the= worst case would be a full screen circular HUD element at 1600x1200). = Obviously you don't have to hit 1-pixel accuracy, and I'm not= even sure if vertex counts are really a concern compared to the= texture savings. I do think there's a lot to be said for pixel perfect interface elements, it adds a level of polish that makes a big difference= in perceived refinement. I know every time I play a game that has= base 640x480 interface bitmaps scaled up to the desired resolution= that it just looks really unpolished to me, but maybe that's my own bias= showing through. In fact, I've seen this when dealing with 2D games that have nice= looking sprite artwork, then I see a similar game using 3D= graphics and textures, and the latter looks much worse because of bilerp= and mip artifacts. Brian |
|
From: Brian H. <ho...@py...> - 2003-03-31 23:03:35
|
>I find this odd... I am constantly on the road and on airplanes,= so >I'm forced to do most of my PC gaming on my laptop (and it's= faster >to boot, so it's not all bad!). The laptop runs at a native >resolution of 1600x1200, but have absolutely no legibility= problems >playing any games at lower resolutions (and I play all of them Well, consider the pixel density. You're probably using a 15.1"= laptop screen with a 1600x1200 resolution, so your pixels are= going to be very small. A standard 17 or 18" LCD is running at= 1280x1024, so you're going to see much Also, scaling up to 1600x1200 gives the interpolation hardware a= lot more breathing room to work, instead of dealing with just pixel fractions. Scaling an 800x600 -> 1600x1200 won't introduce near= the artifacts that going from 1024x768 -> 1280x1024 would. >I assume the best solution is to have multi-resolution artwork Yes, this is the ideal solution, but it requires a lot more= content generation and it also requires a lot more storage and download= size, so it's not practical in every situation. >targeting the major resolutions (640x480, 800x600, 1024x768, >1280x1024, etc.). Of course, it would be a pain to hand design= this >artwork. Unfortunately there are a lot more major resolutions than that. = 1152x864 is common on Macs; 1400x1000 (?) on some laptops;= 1600x1024; 1600x1200; 1920x1200; etc. And while neither of these individual= resolutions is very common, combined they make up a sizable= fraction of the market (I would guess). >would be to produce the highest resolution originals and use a >better-than-bicubic down-sampling filter (which most often= muddies >pixelart). That's probably the best route, except it does keep content sizes= fairly high. Brian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X