It lags pretty bad on my 1st generation iPhone. :[

Agree.

It would break the classic feel of the movement, but it would be cool to see something like this as opposed to the 4-direction movement which is kinda annoying to use on an iPhone (keep in mind that it would have proper graphics and wouldn't have the debug graphics (lines and crosshairs)).

There are times it's slow on my 3G, but most of the time it's pretty fast.

Why not just implement diagonals buttons? Just make them invisible.

I seriously think that player, arrow, bomb, etc logic should be independent from framerate, I've said it a bunch of times already.

There already are diagonal buttons, Dusty.

And the 360 degree movement is very meh. It lacks feeling, at least for me, seems very floaty. It's also hard to hit the edge of the joystick on the iPhone, so controlling with a good amount of speed and precision would be a chore.

Then again you could solve that by just multiplying the distance by 2, but it still causes a bit of a problem.

It's pretty simple: players should only be able to lay 2-3 bombs at a time.
He said 4 directions. If it's actually diagonal like the PC is, I don't see the problem.

The problem is that it runs like **** even without bombs or arrows cluttering the (adjacent levels) on the GMap. With only like 5 other players you get extreme slowdowns, even if none of them are doing anything. It's very annoying.

I ponder if the slowdown is caused by lack of polygon-pumping or CPU power.

On G1 or G3?

In between, lol.

The iPod 2G.

That might be the problem. The difference in graphic rendering between G3 and the older generations is pretty large, and in fact a lot of apps are being developed exclusively for the G3 because of that... or so I remember reading. Graal just might be one of those apps.

The 2G runs very well on it, until you introduce a mass amount of players on maps. Even insides run pretty well with 10 people or so in it.

I see no reason why the screen should have to render beyond it's limits at all, so the inside vs outside thing is null.

It has to do calculations, though, for adjacent levels, but players sitting alone, unmoving, shouldn't require any.

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.

Thanks to the multi touch technology, which allows touches at more then 1 point.

Don't like updating your apps, huh? :p

I have a problem, I'm trying to purchase the Player Customization, but it says I cannot purchase it and that I have to create a new account in the Sandbox environnement...

I have no idea what to do :(

I am a layman, but I guess they do the update serverside, so they don't need to upload new versions when they update something.

delete this if you want
I think he means the notifications that are in the bottom right corner :p

Aww sure. I'm sooo stupid



....sometimes... Thx. :D

Graal holds 2 levels in each direction from the player, and I don't know if they render all that or not - if you notice, drag the screen and you see more. I don't know if they render all of that at once - but either way, lag exists when you're on the map with a lot of players near you.

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

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.

As far as I can tell, the Graal code is very abstracted (i.e., the other iPhone games running off of the same codebase), so inefficiencies were likely introduced in the multiple levels of abstraction. Stefan seems to have been trying to weed out those inefficiencies though.

There will be a breaking point where it is simply less efficient for being abstracted in the first place, but I'm confident that point isn't anywhere near; I'm sure there are more cases that can be optimized.


If the iPhone client was written directly from scratch, and wasn't made to support anything but exactly what it is currently doing, I'm sure it'd be plenty faster -- but it would also make the development a big hassle.

This is the answer I was looking for ;)

Now my soul can rest in peace.

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

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.