The Drunken Lizard Pub

I've been waiting for this game to come out forever, and it's horribly slow. I'm running a G4 1.66 GHz with 2 GB of ram, 128 mb video card. That should be more than enough, but my computer consistently overheats and gameplay gets excruciatingly slow, especially when I get to a village with lots of people and torches and other things to render.

I will buy this game, just not now. When can we expect a speed increase?

Thanks, I'm a big fan of the game, it just needs some improvement.

You are on the very bottom end of system requirements with your 1.66 Ghz CPU. Have you tried running the game in 16-bit color? Inside the game, have you set it for low detail?

Eschalon may look like a simple engine, but we are alpha blending hundreds of sprites, particle effects, layered rendering (clouds and parallax backdrops), real-time lighting, and quite a few rule and AI calculations every round. Your computer just doesn't have the power it needs.

I would recommend upgrading your video card. Get something a bit more robust and you should be okay.

Fair enough. Too bad I have a powerbook... no real way to upgrade the video card on that. I guess I'll have to wait until I have a new computer to start seriously playing

Thanks anyway!

Hi... I come across as confrontational, maybe, but I'm just being incredibly clear about what I am trying to say. So, please don't get offended.

I have simply profiled your engine using OpenGL profiler, and I am a bit horrified. At first glance, it is a pretty obvious why everything is going so slow. You are using immediate mode to render every object in the game... i.e. glBegin...glEnd blocks of code. This is incredibly slow, this is obvious problem.

You need to optimise the rendering path of your code... using vertex array. glBegin...glEnd style code is about 1000 times slower than appropriate vertex array. If you don't believe me benchmark rendering 100,000 triangles with immediate mode and then using retained mode.

The kind of configuration the above user has should be enough to render a few hundred thousand fully textured and blended triangles, so actually your explanation is not really acceptable..

Even just using display list would be advisable as a bandage for the this gushing wound...

Don't think of this as a problem, think of it as a task to increase the size of your customer base.

Immediate mode vs Retained mode:
http://www.cs.utk.edu/~huangj/CS594S06/ ... icsArc.ppt

Vertex Arrays:
http://www.opengl.org/documentation/spe ... ode21.html

Every frame you are making approximately 15,000 OpenGL calls.

Sample of the trace:
0.05 µs glColor4ubv({0, 40, 0, 255});
0.27 µs glBegin(GL_QUADS);
0.05 µs glTexCoord2f(0, 0);
0.05 µs glVertex2f(442, 533);
0.05 µs glTexCoord2f(0.8125, 0);
0.05 µs glVertex2f(494, 533);
0.05 µs glTexCoord2f(0.8125, 0.8125);
0.05 µs glVertex2f(494, 559);
0.05 µs glTexCoord2f(0, 0.8125);
0.05 µs glVertex2f(442, 559);
0.33 µs glEnd();
0.05 µs glColor4ubv({0, 40, 0, 255});
0.22 µs glBegin(GL_QUADS);
0.05 µs glTexCoord2f(0, 0);
0.05 µs glVertex2f(494, 533);
0.05 µs glTexCoord2f(0.8125, 0);
0.05 µs glVertex2f(546, 533);
0.00 µs glTexCoord2f(0.8125, 0.8125);
0.05 µs glVertex2f(546, 559);
0.00 µs glTexCoord2f(0, 0.8125);
0.05 µs glVertex2f(494, 559);
0.22 µs glEnd();
0.05 µs glColor4ubv({0, 40, 0, 255});
2.17 µs glBindTexture(GL_TEXTURE_2D, 83);
54.31 µs glBegin(GL_QUADS);
0.22 µs glTexCoord2f(0, 0);
0.22 µs glVertex2f(546, 533);
0.00 µs glTexCoord2f(0.8125, 0);
0.05 µs glVertex2f(598, 533);
0.00 µs glTexCoord2f(0.8125, 0.8125);
0.05 µs glVertex2f(598, 559);
0.05 µs glTexCoord2f(0, 0.8125);
0.05 µs glVertex2f(546, 559);
0.76 µs glEnd();
0.16 µs glColor4ubv({0, 40, 0, 255});
0.27 µs glBegin(GL_QUADS);
0.05 µs glTexCoord2f(0, 0);
0.05 µs glVertex2f(598, 533);
0.05 µs glTexCoord2f(0.8125, 0);
0.05 µs glVertex2f(650, 533);
0.05 µs glTexCoord2f(0.8125, 0.8125);
0.05 µs glVertex2f(650, 559);
0.05 µs glTexCoord2f(0, 0.8125);
0.05 µs glVertex2f(598, 559);
0.22 µs glEnd();

You could probably replace this with about 20-30 calls using deferred rendering APIs... it would be soooo much faster. Even changing to 16-bit color shouldn't be needed - actually I was surprised to see this.. it won't make much different on modern hardware as it is all geared for 32-bit data anyway.

I am a competent OpenGL programmer if you need further advise.

Regards,
Samuel

Hi ioquatix- thanks for the suggestion. We are looking into optimization right now and hopefully can improve the engine for the next game.

However, we are using a very high-level language to draw sprites, meaning, we are not communicating directly to the OpenGL layer. We are simply loading sprites via pixel maps and drawing them to the framebuffer using the built-in commands. The language itself is responsible for the low-level OpenGL stuff and rendering pipeline.

I am forwarding this information to Blitz Research so that they can investigate your information.

You should consider dividing up the world into layers, such as

* Terrain
* Objects

Some things can be optimised easily such as Terrain (grass/buildings/stones/etc) - this is probably static. Objects (people/items/etc) are always changing, but there are not many of them so performance is not degraded if these are rendered directly.

You should consider caching 32x32 or 64x64 tiles of Terrain.. use vertex buffer to draw this quickly.

You can still use vertex buffer to optimise smaller tiles - it will still be faster than glBegin and glEnd and glVertex calls - even for a small tile. But it would be worth benchmarking it to confirm.

Use lightmaps for dynamic lighting. You can achieve the same effect using carefully designed texture and caching.. you can achieve better effect using higher resolution light map.

Anyway, I am interested, what framework did you build on top of? If it is open source I'd be interested to look at it and optimise it.

Regards,
Samuel

Hey, you should give Sam a chance! Maybe he can help, and you'd certainly have another customer if he does!

Certainly! I would very much like to use whatever suggestion Samuel (or anyone else) sends my way.

The problem is what I already stated: this is not my pipeline. BlitzMax is a very high-level language, and there are certain drawbacks to using it, for example it doesn't do things as fast as talking directly to the API layer. However, there are great benefits, such as a much faster development cycle and code compatibility on Windows, Mac and Linux with minimal fuss.

To implement what Samuel is suggesting is not just a few tweaks to the engine- it would mean serious overhaul of the engine as it is now. Now, if Sam wants to donate some of his time to writing us a new OpenGL sprite engine to be incorporated into BlitzMax, well I'll be happy to work with him.

Regardless, we will do what we can to speed the engine up, but major changes to the engine may not make it into Book I. They are more likely to be a Book II feature.

No offense, but you really should look into optimization. I've kept a close eye on the game since around the beta started, and been downloading the demo three times now since release, and I still don't find myself wanting to pay for the full game sadly.

I've got a MacBook Pro of the previous "generation" (if you really could call those minor upgrades generations...) and I'm just astonished by how poorly the game runs. It's almost as if the entire thing had been written in Java! I'd estimate that my FPS lands on about 15 in average outdoors, call it a hunch.

I'm not as technically experienced as Samuel or the developers here, but I would have been a customer... Don't get me wrong. The little I saw truly appealed to me, it's a great game, but so frustratingly slow I lose my patience that I can't bear to play it.

Book II's engine has been optimized quite a bit. The number of OpenGL calls per frame has been reduced, though the increase in resolution (to 1024x768) offsets most of that speed gain. These optimizations cannot be implemented into Book I because of the fundamental changes to the rendering pipeline...we would literally have to re-write the Book I engine. It's not an impossibility, but it won't happen right now.

As I said above, there is a lot going on in the Book I (and Book II engine) that is more then just rendering a screen full of tiles. The engine handles multiple tile layers, parallax scrolling, a particle engine, environmental effects and real-time lighting on all light sources. If we went with something more like Spiderweb's engine, then yes, it would run better on 5 year old Macs but it would look more like Avernum.

Book II's engine has been optimized quite a bit. The number of OpenGL calls per frame has been reduced, though the increase in resolution (to 1024x768) offsets most of that speed gain. These optimizations cannot be implemented into Book I because of the fundamental changes to the rendering pipeline...we would literally have to re-write the Book I engine. It's not an impossibility, but it won't happen right now.

What you are saying doesn't really make much sense... resolution will be limited by the fill-rate of the graphics card (and obviously how you are texturing your primitives), not by polygon count. A particular hardware combination will generally have a fixed cost per triangle, regardless of resolution... not taking into account more advanced things such as anti-aliasing, multi-texturing, etc.

As I said above, there is a lot going on in the Book I (and Book II engine) that is more then just rendering a screen full of tiles. The engine handles multiple tile layers, parallax scrolling, a particle engine, environmental effects and real-time lighting on all light sources. If we went with something more like Spiderweb's engine, then yes, it would run better on 5 year old Macs but it would look more like Avernum.

Yep, and I can almost guarantee that you will see a 3-5 times performance improvement (if not more) by batch rendering your graphics primitives, without any other optimisations to your game engine.

I can say without a doubt that it is possible to write an engine that displays graphics on par with Book I, with performance benefits as above, if not more.

I found your post on the blitz forum and read through it to much amusement - many people have no idea what they are talking about - however there were a few posts which had good information. I find your lack of acceptance of this problem a bit odd - it is definitely the case that the engine is slow because of its immediate mode rendering - there is no question about it.

I have to agree with the previous poster - if I had realised the performance of Book I was as bad as it is, I probably wouldn't have bought it. It's been a fun game, but also has a lot of room for improvement..

You should probably consider re-releasing Book I with a decent graphics engine - it would show you are committed to making a great game, and I'm sure if the performance requirements were lower, you'd get more people interested in it.

On the other hand, your game has some fantastic music.

Keep up the good work - and why don't you spend some time benchmarking OpenGL code.

Samuel

it would run better on 5 year old Macs but it would look more like Avernum

By the way, my Mac is less than three years old, and it is a PowerBook G4, and the game is slow as hell.

Regards,
Samuel

BasiliskWrangler wrote:Book II's engine has been optimized quite a bit. The number of OpenGL calls per frame has been reduced, though the increase in resolution (to 1024x768) offsets most of that speed gain. These optimizations cannot be implemented into Book I because of the fundamental changes to the rendering pipeline...we would literally have to re-write the Book I engine. It's not an impossibility, but it won't happen right now.

It's nice to know that you care and are looking into improving this in the sequel. Like I said, it seems like a great game with alot of appeal to people like me. However 1024x768 seems a bit scarce to me? Don't get me wrong here, I dig the old school looks, but even Baldur's Gate II allowed a wider area of view, viewport, whatever it might be called... by offering higher resolutions. Playing in 800x600 on a monitor suited for 1680x1050, leaves something to desire.

BasiliskWrangler wrote:As I said above, there is a lot going on in the Book I (and Book II engine) that is more then just rendering a screen full of tiles. The engine handles multiple tile layers, parallax scrolling, a particle engine, environmental effects and real-time lighting on all light sources. If we went with something more like Spiderweb's engine, then yes, it would run better on 5 year old Macs but it would look more like Avernum.

I can barely understand SDL, having only minor experience in C++ and Python, but is all of that really necessary to accomplish great game visuals? Really, no offense at all, just curious since people have made great games in the past too which ran smoothly on lesser hardware, e.g. the game Outcast utilizing "voxels" or something, or the textures in Warcraft III (well I found them bloody well done).

I'd like to mention that I bought my MacBook Pro in August 2007, it's not even six months old yet. If I turn off 32-bit colour and disable high detail graphics (resulting in a 640x480 or something viewport...) the FPS goes up a bit, but in that state I can't see a thing at nighttime, and it looks, well, awful...

I'll say it again: I dig the game, I really do - and it's great that you release it for Mac and Linux as well, but you really ought to iron out the graphics part of it.

ioquatix wrote:...I find your lack of acceptance of this problem a bit odd - it is definitely the case that the engine is slow because of its immediate mode rendering - there is no question about it.

...and I can almost guarantee that you will see a 3-5 times performance improvement (if not more) by batch rendering your graphics primitives, without any other optimisations to your game engine.

I can say without a doubt that it is possible to write an engine that displays graphics on par with Book I, with performance benefits as above, if not more.

Sam- I do "accept" what you and others have said. Blitz doesn't handle rendering as efficiently as we could if we had written a custom rendering pipeline to do the job. This was the trade-off to using a high level language: cross-platform compatibility with minimal development time, but a bit less performance than if we had wrote a custom rendering pipeline of our own. I think every developer is forced to into this decision- do you take 2 years to write a custom high-speed engine specifically for your game, or do you license an existing engine and adapt your game to it, knowing you will need to accept some limitations.

We have done a lot to Book II to optimize the order of sprites being drawn and the number of passes per frame. We have also changed some timing code so that the game scales better on slower machines, but yes, we are still using the default method of drawing sprites. Many other talented Blitz developers have made attempts to create faster rendering pipelines with various degrees of success depending on the application, but I have not yet found one that has made a noted difference in the speed of Eschalon.

Sam, you could probably make yourself some good money if you bought Blitz and created a cross-platform module that dramatically increased the speed of OpenGL/DirectX sprite rendering. There are thousands of registered Blitz developers and many would gladly purchase an improved rendering module if it were available. However, if it were as easy as you claim, I think it would have already been done. But I would be happy to assist you in any way if you would like to attempt this.

Thoht wrote:'d like to mention that I bought my MacBook Pro in August 2007, it's not even six months old yet. If I turn off 32-bit colour and disable high detail graphics (resulting in a 640x480 or something viewport...) the FPS goes up a bit, but in that state I can't see a thing at nighttime, and it looks, well, awful...

Thoht- it sounds like you may have some other issue there. It should run perfectly fine on your system. We've run it on a 3-year old iMac at full speed.

Some people may confuse "walking speed" with "game speed". Open your Options dialog and check the performance rating. That number you see is the time (in milliseconds) needed to draw the previous frame. It should be below 10 for best performance. Once that gets around 16-17, the game is running slower than the 60-frames-per-second that we intended and will really appear sluggish.