Classic Graal for iPhone

[DustyPorViva]

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).

[Sky]

Should make it work for the google phones too!

[12171217]

Originally Posted by DustyPorViva

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).

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.

[DustyPorViva]

Originally Posted by 12171217

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).

[12171217]

Originally Posted by DustyPorViva

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

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.

[DustyPorViva]

Originally Posted by 12171217

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.

[12171217]

Originally Posted by DustyPorViva

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.

[DustyPorViva]

Originally Posted by 12171217

"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.

[SKJF91]

Originally Posted by 12171217

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.

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.

[12171217]

Originally Posted by SKJF91

what about the changing of colors for each unique player on the bodies etc..

A palette swap. Simple.

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

[SKJF91]

Originally Posted by 12171217

A palette swap. Simple.

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

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..

[12171217]

Originally Posted by SKJF91

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..

The amount of textures is irrelevant, it wouldn't cause slowdowns.

You should only receive data on the players in adjacent levels and your own level, probably around 20.

Scripts, there are barely any scripts on the overworld.

Levels, all that has to be done is some simple collision algorithm and rendering them.

It's a mystery where the slowdown is coming from.

[Immolate]

Originally Posted by 12171217

The amount of textures is irrelevant, it wouldn't cause slowdowns.

You should only receive data on the players in adjacent levels and your own level, probably around 20.

Scripts, there are barely any scripts on the overworld.

Levels, all that has to be done is some simple collision algorithm and rendering them.

It's a mystery where the slowdown is coming from.

Would be cool to actually look at the actual sourcecode and find out first-hand, but that'll never happen, haha.

[SKJF91]

Originally Posted by 12171217

The amount of textures is irrelevant, it wouldn't cause slowdowns.

high amount of ram usage, constant loading of textures etc..

You should only receive data on the players in adjacent levels and your own level, probably around 20.

Graal servers receive data about all players x/y/headimg/etc.. and other playerlist data - it also has the knowledge of each player whose actually online, the client sends ping-data to the server, status updates etc..

but on a different note, the lag does occur only because of the people on adjacent levels. if you walk a few levels away from everyone, you'll notice all the lag is gone. so with that said, it's because of the amount of data being sent from people like constant gani-changes from idle->walk->sword etc, among constant movement packets from each player - and with about 20-30 people in all these levels, of course lag is going to exist. if you remember graal in the older times, when the best processor was a pentium 3 with like 650-800 mhz.. there was lag back then too although there was a lot more multi-tasking going on with computers then such as aol always having to be on for dialup connections etc..

but it wasn't that bad because it was levels, not really a map.