Classic Graal for iPhone - Page 13

DustyPorViva · #**181** 12-20-2009, 09:31 PM

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 · #**182** 12-20-2009, 10:29 PM

Should make it work for the google phones too!

12171217 · #**183** 12-20-2009, 10:44 PM

Quote:

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 · #**184** 12-20-2009, 10:50 PM

Quote:

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

DustyPorViva · #**185** 12-20-2009, 10:50 PM

Quote:

Originally Posted by Skyld

The iPhone virtual keyboard is exactly that: a virtual keyboard. When you put your finger on the up button, it is sending virtual keyboard events that emulate a physical keyboard button. When you sit your finger between two direction buttons and both of them are highlighted, it is sending virtual keyboard events for both buttons.

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.

12171217 · #**186** 12-20-2009, 10:55 PM

Quote:

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 · #**187** 12-20-2009, 10:58 PM

Quote:

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 · #**188** 12-20-2009, 11:02 PM

Quote:

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 · #**189** 12-20-2009, 11:06 PM

Quote:

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.

12171217 · #**190** 12-20-2009, 11:34 PM

Quote:

Originally Posted by DustyPorViva

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.

DustyPorViva · #**191** 12-20-2009, 11:37 PM

Quote:

Originally Posted by 12171217

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.

SKJF91 · #**192** 12-21-2009, 02:02 AM

Quote:

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 · #**193** 12-21-2009, 02:15 AM

Quote:

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.

Fulg0reSama · #**194** 12-21-2009, 02:15 AM

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?

SKJF91 · #**195** 12-21-2009, 02:38 AM

Quote:

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