On the gmap it actually renders one level in every adjacent level. So that's typically 9 levels when you're on the gmap. However, I don't think it's actually rendering it. However, I'm pretty sure it's still rendering NPC's and players(as I've used NPCs to get past the clipping of showimgs).

Should make it work for the google phones too! :D

I fail to see how rendering 3 quad polygons (Head, body, shield) with 32x32 textures for each player creates so much slowdown, as there's some pretty intense 3D games on the iPhone with 128x128 and 256x256 textures and 1000 poly character models, and they don't drop beyond 30 FPS.

It's CPU stress, is what it is, unless it's the amount of textures that have to be bound, since nearly every player has a different head/shield/body combo and it has to swap textures all the time.. I remember how some of my stuff ran on the PSP when it would render the world from in a nearly random order, and the performance increase I got when I sorted the world by texture.. Unfortunately, Graal can't do anything like that because of the sheer amount of different heads and bodies.

Nonetheless, I doubt it's that, and it's still probably CPU stress. GS2 isn't horribly efficient, you know.

Exactly. It has to process the data of 9 levels(including all the NPC scripts and player data).

That's my point. I'm not sure why angle movement was requested if there are diagonals. Chris made it seem like it was only 4 directions.

But see, there's very little GScript in all of that. Even when you're in an area with no baddies (They're the only scripted NPCs on the GMap, at least scripted in the sense that they're a bit more complicated than drawUnderPlayer(); dontBlock(); or something), having simply players in your view creates slowdown.

I fail to see why; it's 3 polygons to render, a name to render, and a gani to parse. Both should be incredibly easy for the engine to do.

It's the same on PC. If you enter a level with a lot of players you tend to get a lot of slowdown(I actually get slowdown before players are visible on the gmap). Why exactly? I dunno, it's definitely not the rendering(though disabling nicks can help sometimes). Probably the way it processes player data(it's sending constant streams of just about all of the player's info like the x,y, all 30 attr's and such). If you could get a healthy amount of players on an UC server or the cooperation of one of the main servers, could test it by hiding all the players and seeing if it helps(if it helps a lot, it may be the rendering).

Also, I don't think the new one(which the iPhone uses) uses 3d rendering for flat images anymore.

"Flat images" are still rendered using polygons in OpenGL.

I just remember Stefan posting that v6 no longer is rendering polygons for flat images anymore, to speed things up. No idea what he means then.

Software rendering directly to the draw buffer?

Eh? That would be silly.

Oh, my mistake. He just said it's doing it faster in v6.

each gani of the player, drawing parts of images - what about the changing of colors for each unique player on the bodies etc.. but it's not the drawing of players. i was in a inside level with 10 other players without a problem - very little lag.

A palette swap. Simple.

I do dozens in each frame in some of the stuff I do; no slowdowns.

I'd like to ask whats the chances of having some PC player user submitted bodies and heads n stuff? Or is this already something taken care of?

yes, and each body needs it's own unique texture to be loaded in memory as well -- and we're on 433 mhz processors or so running a large amount of levels, scripts, receiving data on all 100 or so players etc..