Low Poly Hardware Specs
polycounter lvl 19
Nintendo DS
suggested polygon count for performance (total visible): 2000
texture memory (per screen): 512kb
max texture size: 1024px x 1024px
screen colour depth: 18-bit (260,000 colours)
alpha blending: 5-bit (32 colours)
suggested texture size: under 128 x 128
Sony PSP
suggested polygon count for performance (total visible): 50,000
texture memory: 2mb
max texture size: 128px x 128px
screen colour depth: 16-bit (65,536 colours)
alpha blending: 8-bit (256 colours)
iPhone 3G
suggested polygon count for performance (total visible): 7000
texture memory: 24MB
max texture size: 1024px x 1024px
screen colour depth: 16-bit (65,536 colours)
alpha blending: free! (use PNG)
suggested texture size: under 512 x 512
suggested polygon count for performance (total visible): 2000
texture memory (per screen): 512kb
max texture size: 1024px x 1024px
screen colour depth: 18-bit (260,000 colours)
alpha blending: 5-bit (32 colours)
suggested texture size: under 128 x 128
Sony PSP
suggested polygon count for performance (total visible): 50,000
texture memory: 2mb
max texture size: 128px x 128px
screen colour depth: 16-bit (65,536 colours)
alpha blending: 8-bit (256 colours)
iPhone 3G
suggested polygon count for performance (total visible): 7000
texture memory: 24MB
max texture size: 1024px x 1024px
screen colour depth: 16-bit (65,536 colours)
alpha blending: free! (use PNG)
suggested texture size: under 512 x 512
Replies
just an idea
lets do a vote and choose one format
and then use challenges/contests to generate content and make a lowpoly polycount.net game hoooraaaayyy
polygons per screen at 60fps: <font color="red"> 2000 </font> Well, this is true if you plan to have 3D going on both screens. Which I wouldn't recommend. A good scenario is 2000 polys per frame at 60fps. You can also pull off 4000 polys per frame if you drop to 30 fps.
It really is a hard fast rule of the hardware according to a thread on http://forum.gbadev.org/
If you give it a framebuffer you could draw half the scene in the first pass and the other half in the second pass.
[/ QUOTE ]
If it could only hold 2048tris in memory then you would have to do t&l twice aswell and i dont know how good you can do it (i guess you cant really).
polygons per screen at 60fps: 80k per frame is what we're sticking with as the limit
texture memory (per screen): ?
max texture size: 128px x 128px (yep)
screen colour depth: ?
3d data format: GMO
texture format: GIM which goes from 4 bit indexed to 32bit RGBA. With the standard GMO model converter the texture gets baked in the binary GMO file along with the model.
alpha blending: 8bit
I was just wondering, so you use 256colour textures for DS now is it viable to have custom pallet for each texture?
[/ QUOTE ]
that would appear to be the case
AC does semi transparency aswell (embarassed animation).
Also - the screen display is 24-bit, but some games run in a 16-bit mode.
Would this tri. count plan work good?
600 main character
400-600 npcs.
100-200 a weapon
200 doodads and environment art.
Any examples,portfolios,textures or wireframes of ngage games would be great.
I know Psp can do spec maps, but im intrested in normals.
Ps2 can do them so it isnt out the question is it?
"Currently, normal mapping has been utilized successfully and extensively on both the PC and gaming consoles. Initially, Microsoft's Xbox was the only home game console to fully support this effect, whereas other consoles use a software-only implementation as they don't support it directly on hardware."
so i guess yeah,ps2 can do them.
so i guess yeah,ps2 can do them.
[/ QUOTE ]
I'm not sure that's true. Anyone can add to Wikipedia.
I don't have any real knowledge about this, but I seem to remember compaines like Ubisoft specifically mentioning what effects they were using instead of normal mapping when making a PS2 version of some of their Xbox games. (Like SCCT and GR2)
At the very least in terms of consoles xbox can because it has doom 3.
anyways, would be cool if psp could do it, regardless of how it would look on the tiny screen.
http://startrek.bethsoft.com/art/ta_pspscreens.html
regarding the PSP - it can play flash swf's through its webbrowser function, and as far is a know it only takes flash player 6 stuff - anyone one know wether that's increased with the firmware upgrades - it'd be nice if we could get some as2/as3 action happening
(and damn sony for making dev on a psp so bloomin hard).
you can't use more then 256 colors on the ds. for alpha texture there is just stencil then. for 5bit alpha 32 colors for 3bit alpha 8 colors.
there is converter to "autoconvert" the textures, but the quality is not that good. especially for alphas you need to handpick to get better results.
Getting alpha sorting to work correctly on the DS can be a pain, if I can go with a 1 bit I absolutely do.
There is a max limit of 2000 Polys per frame, but you can also run into problems if there is over about 400 polys being drawn in a single line. This can cause massive screen tearing issues.
We try to keep our levels under 10k tri's to prevent performance issues, but I have seen some that run perfectly fine coming in at around 17k tris.
Thetexture memory (per screen) number given doesn't sound right. It may depend on your engine and how the memory banks are being distributed between compressed textures, uncompressed textures, as well as sound and model data. In my experience I've had two 128Kb banks delegated for compressed and uncompressed textures, with an additional 128 bank being partially (64Kb) used to uncompress the textures while the additional 64Kb is used for sound. All additional memory goes to model data and the executable files. Designating one bank for compressed textures you do lose half of another, but you fit about three times the textures in when compressed.
from an iphone thread:
suggested polygon count for performance (total visible): 7000?
texture memory (per screen): 24MB?
max texture size: 1024px x 1024px
screen colour depth: 16-bit (65,000 colours)
3d data format: ?
texture format: ?
alpha blending: ?
suggested texture size: under 512?
The only model I've done for Iphone was around 2000 triangles and 512x512 texture for an OpenGLES engine.
btw, I think DS specs are correct.
The low-poly character also has to register nicely in that small frame. So, my vote is for the DS format.
(PSP if we were doing 1000 tris with 256x256 maps)
I know for a fact that 128x128 isn't max texture size on psp - I've seen some of my own models with 256x256 textures on my psp in fact. I was always under the impression that the max was 256, based on what a few devs told me, but since then they've said forget the limit but stick to 256 max for the sake of performance.
I think this is true, but stick with 256 paletted colors (1 bit alpha).
Also to explain 3D on both screens. There is only 1 3D engine that can write to one screen at a time. To write 3D to both screens you have to write the second screens 3D on the first screen, then copy over a picture of that to the second. So you get 2000 tri per screen, but have to alternately draw each screen cutting fps in half. You also have to use 128k of your texture memory to store the screengrab.
This is actually my first post on this forum. I'm a grad. student beginning work on my master's project and this thread has quite a lot to do with my topic. I was wondering where the numbers in the first post came from. If anyone (especially the initial poster) knows, I'd love to have the source. Thanks.
The psp's speed really depends upon the engine and optimization.
Vram size is 2MB, but textures may be stored in the 24mb ram as well.
You can swizzle textures to get a speed boost as well
Not to mention That the psp supports up to 512x512px textures, however they tender to be slow.
Also the screen buffer can be 32 or 16bit in either 8888,5650,5551, or 4444 formats.
If you want any more information let me know, I have been programming for the psp for along time, just making small tech demos for myself and such.
Not sure about phones but most devices now have dedicated 3d / graphics hardware. These are the bottlenecks and limits to the amount of triangles on screen (and typically the memory for this hardware). The processor will not normally be a bottleneck when you are talking 3D games, granted on phones and such you need to be considerate of the processor time for physics and game logic.
The processor difference between the Android and Iphone won't make much of a difference in rendering, only the dedicated hardware differences would.
Another limitation would be Android using Java vs. Iphone using objective C natively, java is a slower language then C, granted on PCs there normally isn't too much of a difference but on devices with slower processors the difference will be much more noticable.
Well, on one good side, Android does allow native code though JNI and I'm running all of my opengl calls natively. The Snapdragon CPU appears to have an AMD Z430 GPU which I'm having trouble getting much information on. I should have my hands on a phone any day now... so maybe I can get some benchmarks myself.
If the screen colour depth for iPhone 3G is 16-bit, and alpha blending is free if I use PNG, does that mean that if I save my diffuse out as a 16-bit, I have to save my alpha separately as a PNG?
iPod touch and iPhone 3gs and older resolution 480x320
iPhone 4 resolution (retina display) 960x480
iOS supports 32-bit textures with 8 bit alpha (I always use .png), however the final screen image is rendered in 16-bit color.
iOS also supports compressed textures using PowerVR texture compression as .pvr files. These are like DXT compression - lossy and mushy results so you only really use them for photographic style textures, nothing crisp and certainly not for sprites.
iOS devices have texture filtering in hardware and some games feature AA, but those are usually slow paced games, not requiring a high framerate.
I can't comment on polycounts as I'm making a 2D game, but I'd imagine it's somewhere between PS1 and PS2 depending on which iOS device you're running on.
and does anyone have any examples they could just describe of past projects for the DS with specs and tir counts etc?
this information will be used in my research and would be greatly appreciated
Any shading algorithm is possible for any platform, technically. I mean, it's not probable or practical to see PS2 w/ normal mapping, but it's not a very obscure algorithm and you can program software lighting to use normal maps.
Also, thanks a ton for this thread. UDK has just released iOS support with the new beta, and some people at the forums there wonder about poly counts for models.
Anyone knows the polycount for Android based devices like Nexus S? Or Htc Desire HD?? And for iPhone 4 and iPad???
With Unity there's so much you have to deal with. Scripting performance is ON YOU. GUI performance as well. So if your GUI is a hog, you will not get much on screen. My latest project in Unity started out with max 20 enemies on screen. This was all scripting performance issues. I knew it. After some changes(I found the issue) I was able to get 240 at 15fps. I cap it at 120 now. That's 120x702 polys. The NPC share a single texture/mesh. The GUI is one texture with boss health and player health bars. Environments range from 8,000~14,000 polys (but not all on screen at once with a single 1024x1024 for everything. Player mesh is 702. New NPC mesh is now 300~ polys. Bullet sprites are 16x16, and each mesh has a shadow blob. 1 sound for shooting (enemy) one sound shooting player/boss. One sound track, no environment sounds.
I would like to add that only certain bosses are skinned, other than that all the other meshes are just animated in code. Personally I don't think there's a hard number for UDK and Unity for iOS, there's too many variables. It's all about "How YOU want to do it".
These numbers are on iPod4G and iPad1.
The nds supports 6 texture formats:
The NDS has a 15 bit color screen as well as 8 VRAM banks which can be repurposed to store texture data or the frame buffer and such. The 3D engine reserves the use of at least 1 128kb VRAM bank (A-B). You may also use more than 1 bank for storage of textures. Keep in mind that you use the texture bank for texture data and pallets.
Geometry supports vertex normals but they override any previously done vertex color commands.
The nds supports directional lights only and when defining the vertex normals, it is equvilant to setting a vertex color, but this time it samples the normal and the directional lights to set the vertex color.
The NDS's 3d engine is very similar to openGL specifications so libraries like devkitpro have adapted to openGL-like functions.
Anyways here is the bank info:
Thanks for the information! Which, if any, changes can we expect from the iPad2 Hardware-wise?