I've seen a few discussions regarding 'Point Sprites vs Textured Quad Sprites' and the like.
However, one thing confuses me, if I understand correctly, aren't the size of point sprites limited (By a point sprite range)?
I'm fairly new to OpenGL ES 2.0 so am very likely missing something, but under what circumstances could point sprites be used effectively in a game (apart from the obvious being a particle system)? If they can't go over a certain size, then aren't they pretty much useless for characters etc? (I understand also that the min and max sizes may vary from device to device making things even more unpredictable)?
EDIT: Further to the comments below and further research it appears that the only size that is guaranteed for a 'Point' is '1' (being 1 pixel).
So on a system like Android with so many screen DPI's and resolutions, are points even realistically usable for particle systems?
Let me elaborate, on a low Res / DPI screen a single pixel point will appear quite large , but on say, a Nexus 10 tablet with it's really high Res / DPI screen a single pixel point is going to virtually unnoticeable. Normally when I work with sprites I scale them according to the screen resolution (ie, if I want a sprite to take up 1/4 of the available screen I will simply scale it by screen/2 in both X and Y directions. This gives me screen independence and works great. But if I need a particle size of say 4 on my N10 Tablet so it takes up the same amount of relative space than of say a lower-end (and lower res) phone device which only uses a point size of 1 and I can't be guarantee anything bigger than 1 pixel - how is this going to work?
I'm just trying to understand when Points/Point Sprites would be useful in a system like Android!?
Related
Does it matter, how high the resultion of my graphics are (the picture of my player is 1500 x 2000 px) or are there any problems, that the game couldn't work very well or smooth or something like that? (Unity, 2D Game)
This really depends on the target device, as well as the scale of your game. I wouldn't think that it would cause issues, but it really depends on how many large images you have rendered at the same time. You can also always change the max size in the sprite settings if it becomes a problem.
Also keep in mind that if your player is small it really doesn't need to be that large, so I would just go ahead and decrease the max size in the sprite settings if that is the case.
I'm assuming that you are asking about texture size.
modern hardware can handle resolution such as 1500 x 2000 very easily and I would not worry about rendering speed.
However, texture loading (affects both CPU & GPU) may become issue if you have large textures (or large number of textures). if you have 1000 textures of 1500 x 2000, it will become hard to load the texture without affecting user experience.
I use SurfaceView for my 2D Android game which I have almost completed. It's based on JBox2D. It is perfectly running on Samsung Galaxy S2, its FPS is 60. It is also running smoothly on HTC Explorer, its FPS is about 54. I thought that if my game was working well in these relatively old devices, it would be working better in the newer ones. But I was wrong! I saw yesterday the FPS value of my game on Galaxy Note 4 is varied between 22 and 45 depending on the number of game objects.
After investigating on this issue in Google and StackOverflow, I deduced that the new devices like Galaxy Note 4 which has higher resolutions (1440 x 2560) could not handle with their large images whereas the little ones can handle with their own smaller images (Galaxy s2:480 x 800, HTC Explorer:320 x 480). Yes, the new devices are surely faster than the older ones, but I think their huge resolutions of the newer devices are the reason of the slowness on the SurfaceView. Of course, this is valid under SurfaceView conditions. If I used OpenGL for my game, it would not be a problem for the new devices having high resolutions.
My bitmaps are designed for 800 x 1280 devices. According to the different device resolutions, my game rescales the images when they are loaded at the beginning of the each level by using createScaledBitmap.
I couldn't transform my game from SurfaceView to OpenGL platform because my game is about to finish and I didn't have enough knowledge about OpenGL.
What should I do?
I believe you have correctly identified the problem: newer devices have pixel counts like you'd find on a 27" monitor (2560x1440), because the manufacturers are chasing screen resolution like they do camera megapixels. The result is that rendering a full screen takes longer, especially when you're doing it in software. Faster CPUs and increased bus bandwidth can help, but full-screen software rendering is problematic.
The solution for Android is to make the Surface smaller, and let the hardware scale it up as it's being scanned out. This is significantly easier (and more efficient) than scaling up each individual item. You do this with the SurfaceHolder#setFixedSize() method. For example, for a 2560x1440 display, you could set the Surface size to 1280x720, and only render a quarter of the pixels. The display performs the pixel doubling (with bilinear filtering).
You can find a blog post here, and can see this in action in Grafika's "hardware scaler exerciser" activity (youtube demo video).
The various examples use GLES -- which also benefits from having fewer pixels to fill -- but applies to Canvas rendering as well.
If you're laying out an interactive touch UI element, such as a button, you want something with a sensible physical size, so the user can hit it comfortably. In this way, laying out a touch UI is just like laying out physical buttons and knobs on an electronic device. And for this kind of physical engineering, millimeters (or inches) are the unit of choice.
For some reason this doesn't seem to be the case in touch UI design. I don't consider myself extremely well-read in the subject, but I've honestly never seen anybody use mm as a unit in, say, an Android layout file. But I've seen endless debates about "px" vs "dp" vs "sp" vs who knows what.
The "device-independent pixel" (which on Android is defined in terms of physical length - 1dp ≈ 0.16mm) seems like a really convoluted way to specify a length.
Why not just use millimeters?
Is it a problem with devices not supporting these units properly? Is it a cultural thing (programmers might be more used to thinking in "some sorta pixels" rather than physical units)? What's going on?
Generally, you'll find mobile usability folks talking about millimeters. But programmers and visual designers talk about density-independent pixels or points (1 Android "DIP" = 1 iOS "point") because even if you could specify a measurement in millimeters exactly, you'd end up with rounding issues or half-pixel anti-aliasing ugliness:
1mm equals 6.3 DIP (degree of precision there depends on the exact DPI value of the screen, since dip are quantized to the nearest of 120/160/240/320/480/640 dpi). That means on a standard G1-style 160DIP screen, if you specify a button as (let's say) 8mm, it'd be 50.4 pixels on that screen - good luck rendering that with any degree of precision, or telling Photoshop to end a line exactly 50.4px. And just rounding isn't much of a solution; the screen is still a fixed total width in pixels, and those rounding errors would compound in ways that mess up symmetry if you're (let's say) laying out a grid of buttons with specific sizes and padding amounts.
Specifying that as (let's say) 48DIP is much better, since that smoothly scales: 48px at 160DPI, 72px at HDPI (240) and 96px at 320DPI (AKA 2x in iOS terminology), no fractional pixel rendering or rounding needed.
As to why exactly the 160DPI pixel won out as the 1x mobile unit of measurement for the density-independent pixel, blame the first few iPhones and the HTC G1, which shared that configuration.
I think the W3C provides a decent explanation of various units of measurement for screens, and where each has advantages and disadvantages. I would also very highly recommend Roman Nurik's Density Independent Pixels video. While it doesn't directly answer your question, it provides a lot of great information.
Here are my arguments for DPs instead of mm:
Resources
This is probably the biggest one. When designers and developers create image or video assets, we don't use physical sizes. If you take a picture with your camera, you can't say that the picture is 5 inches tall. How tall the picture is depends on how you decide to print it out.
Thus if I want to display an image to my users or I want to create a button graphic, I can't simply create the resource at 10mm wide by 10mm tall. That one image will render at different sizes on different screens. Even if the device/code does scale the image to exactly 10mm tall, it will look incredibly pixelated on most TVs, and/or will have more detail than a low density device (such as a watch) will be able to display (thus wasting the device's resources).
The answer then is to export a single image at different sizes so that it looks good across multiple devices.
Of course there are other ways around this. Vector graphics could solve this problem, but that's a completely different topic.
DP
As for an Android-specific answer- we kind of do. As you pointed out, we use DP which can be roughly converted to conventional physical units of length such as mm.
However, using DPs works in tandem with Android's density buckets to allow designers to create assets for a finite set of display sizes. In my opinion, labeling these buckets with a physical measurement would be a bit more confusing, as a 4.2" phone might be in a 4" bucket.
SP
SPs are used primarily for text to allow the user to customize their font size. Defining a font size in pixels or mm would be misleading once the user changes their scaling.
it is because Android supports many device sizes and resolutions. Would you want to develop an app that accepts touches in certain places measured by mm and have that location be different on a phone vs a tablet? Or a hi-density tablet of the same size as a low density tablet? Or even just the height/width ratio differences between phones and tablets.
Millimeters is a hard measurement that reflects real life distance, but not the number of pixels. Units such as "dp" and "sp" take into account the pixels as well as the size
Using sp/dp
will make your
Android applications
compatible with
multiple screen
densities and
resolutions
Which is not possible with mm
where your app layout is independent of resolution .
Right now my game is using direct x and y values. I realized that my the S3 was scaling my images double size along with some other size inconsistencies between devices. I read around and learned a bit about android dpi and scaling and stuff.
I'm wondering whats the correct way to do locations and stuff so that it takes into account different screen sizes.
I'm thinking it can be done by setting a target dimension and then scaling all positional values according to the ratio of the target dimension to the actual screen size.
I also read somewhere that you can draw onto a buffer and display that buffer stretched to the screensize, however for this method would android's auto resizing affect the drawn bitmaps?
Thanks
The idea is to use aspect ratio, android auto resizing to your benefit. Every android screen has its own aspect ratio, your game should use the aspect ratio and fill blackborder where ever there is a need to fill space on the screen. So use appropriate root layout fitting attributes.
Android resizes drawables automatically that dont fit. So if you keep only 1 set of drawables, the resizing work for Android increases and it uses Bitmap's internally to do the resize. More the bitmaps more the memory utilization, more the cleanup, more the GC and slower your game. So the best practice here is to create different dpi different image sets to use.
To start with I suggest that you purchase 3 phones, samsung y (small screen), samsung s2 (good screen) and a tab 7 or 10 inch. Copy your original drawables to all the folders, just to get a feel of the game and to eliminate all memory issues. Once your game works nicely, smoothly without any memory issues on all the phone sizes, just walk into a graphic designers office and show him how bad your game looks on some phones. He will create graphics that will work for that dpi.
Its a game of intelligent drawable resolution, sizing and A WHOLE LOAD OF TESTING :).
Hope this has helped.
Edit : Read my answer in memory issues
I've determined an estimate of the size of my Android emulator's screen in pixels, although I think its resolution can be changed to other numbers. Quite frankly though that doesn't eliminate the general problem of not knowing how many pixels on each axis I have to work with on my Android applications in general.
The main problem I'm trying to solve is this: How do I make sure I don't use a faulty resolution on Android applications if I want to keep things' sizes constant (so that if the application screen shrinks, for instances, objects will still show up just as big - there just won't be as many of them being shown) if I wish to do this with a single universal resolution for each program? Failing that, how do I make sure everything's alright if I try to do everything the same way with maybe a few different pre-set resolutions?
Mainly it seems like a relevant question that must be answered before I can come across a complete answer for the general problem is how big can I always make my application in pixels, NOT regarding if and when a user resizes the application's screen to something smaller than the maximum size permitted by the phone and its operating system.
I really want to try to keep this simple. If I were doing this for a modern desktop, for instance, I know that if I design the application with a 800x600 canvas, the user can still shrink the application to the point they're not doing themselves any favors, but at least I can basically count on it working right and not being too big for the monitor or something. Is there such a magic resolution for Android, assuming that I'm designing for API levels 3+ (Android 1.5+)?
Thanks
Hmm, I suggest you read this: Supporting Multiple Screens. That gives a wealth of information on how to handle different screen sizes. In particular, read about its concept of density independent pixels versus absolute pixels. Density independent pixels are essentially pixel sizes that the system automatically scales for you depending on the screen size you're working on. It considers the 'standard' screen as that of the G1, Hero or similar devices, i.e. 480x320 pixels with a density of 160dpi. If the screen you're working with is bigger than that, i.e. the Droid or Nexus One, it adjusts all density independent pixel sizes by 50%.
Alternatively, if you're really talking about canvases, as in, Canvas for animations etc, you can just call canvas.getWidth() and canvas.getHeight().