Thursday, March 31, 2011

34 – Performance woes?

There, fixed it for you! That's right: 120 FPS at 800x600 with Irrlicht software rendering at the highest zoom level with Z-levels 0 to 30 included in the rendering pipeline. This is the best result I am willing/I can achieve. I am tired of tweaking the rendering engine and this is the one that will be included in "Stoneage".

But even this performance is not enough. More precisely the performance is more than enough, but I can not consistently reproduce it. I have two main machines I do tests on, with three more weak machines for extra tests.  My first machine is clunky but has very powerful hardware behind it. It is a development machine and it does not have a good graphics card. The above screenshot was taken on this machine (and yes, I did wait a few seconds until the framerate counter showed exactly 120 since it does fluctuate a little; I can't get it up to 128 though). Using software rendering, framerate is very good at all zoom levels. Scrolling is slow at higher zoom levels, but it is good enough and I can't improve it more right now. As said, the GPU is trash on this machine. I will be slow but playable with DirectX, and completely unplayable with OpenGL. That is why it is good to have multiple backends.

The problem is that I can't get the same results on all machines. Performance does not scale linearly with the power of the hardware. On my second machine, a development/gaming machine with a 8800 GT GPU, I get less framerate (but not by much) with software rendering, but I get a lot more with hardware acceleration. Unless I increase zoom level. For some strange reason, my GPU drops in performance a lot once the number of tiles crosses over a yet undetermined threshold. I guess there are to many draw operations. And since the CPU is weaker, scrolling is even slower at highest zoom level.

So the simple solution of software rendering if you do not have a good GPU, hardware otherwise, becomes a lot more complicated. And even worse, there are computers out there that judging by the numbers should run good in software mode but in practice they don't. This is why developing for the PC is so hard. There is a huge number of hardware combinations that yield unexpected results and this without counting legacy systems.

As much as I would like to create something that works perfectly on everything, I am afraid it is impossible. There will always be people that will have a less than smooth experience.

These people will have to do one of the following:
  • play at low resolutions, probably in windowed mode
  • try every single backend combination. I'll add an autodetect option, but it will not be fail proof so some manual try and error will be needed
  • use the new option for selecting the Z level ranges
I think it is obvious what the new feature from this post is: huge increase in framerate at all zoom levels, but it is only important for high zoom levels. But one feature and a wall of text does not a post make.

My second feature is the ability to select the number of Z levels that are rendered. Before I had two options: render from level 0 to current levels and render from zero to maximum level. So on a normal map, you would render 30 or 40 levels. With the new system you have a number that governs how many levels you get above and below your current level. Let's call it N. So you are rendering from current minus N to current or from current - N to current + N. Default will be N = 5. See how I am cheating? This way you will render 6 or 11 levels. Going by defaults, you will render 6 levels instead of 30. There is good chance that this will have zero impact on the number of tiles you need to render since I have a clever rendering algorithm that only renders as much as needed and I cache everything. But 5 times less Z levels will still requires 5 times less CPU power and make scrolling smoother. This is a fair compromise. People with weaker computers or strong computers that my engine does not like will get a better experience. People with strong computers will adjust N with PageUp/PageDown keys. In the future I'll add a GUI component showing you your current level and how much you are rendering.

I created a video showing things in action: a full on stress test. I have 150 dwarves digging out over 11000 wall at the highest zoom level on my computer that does not like hardware rendering at the highest zoom level. Keeping in mind that FRAPS reduces the framerate, things are pretty smooth but there are a few moments where the game struggles:

Wednesday, March 23, 2011

33 – I feel like there is an impenetrable brick wall between us

Why can't you open up to me? After all this time...

That's exactly what I am going to do: open up about this post's new features!

Creation of stone structures

I have added the possibility to create a stone structure out of the stone you have. You have to dig through stone walls before to get the stone. Here is the new menu:

Walls are similar to natural walls and come in two flavors: made out of stone chunks and made out of bricks. Right now the difference is purely aesthetic, but I'll try to differentiate between them. Brick wall could take longer to build because you have to take stone chunks and cut them down to brick size, but on the other hand they could be more robust. You can use these walls to make rooms or to draw something. Since I am far too lazy to clear out a section of the map removing all plants, I dug out a section of the natural wall and drew something with a mix of brick and stone chunks:

Next, we have fortifications. These are similar to walls but they will offer cover when using ranged weapons. I introduced them previously as an option when carving out stone blocks. Let me demonstrate the use of both chunk and brick fortifications:

And finally, we have stairs. These will allow your dwarves to reach higher Z levels, but I do plan to give them the ability to jump. Jumping is slow, makes you tired, you have to drop large objects you are carrying and you can't do it with a heavy backpack, but it should add a new level of strategy. Some creatures can't jump and the only viable defense is having walls higher than one Z level. Or a walls with fortifications on top so you can defend yourself. BOOOOM! HEADSHOT! Jump will be available only after multiple Z level walking is implemented and will have a largely passive skill associated to it. But back to our subject. Right now stairs are again just mostly cosmetic, but using these elements you can start and design something interesting:

OK, that was not that interesting, but I do feel like thing are starting to look promising. It would be great if I take these new options and combine them with stone carving and post a few interesting screenshots of some complex fortresses. Or a video. But not right now.

There are two thing I have not implemented yet. For starters, you can't select your stone. This will be done once I finally finish the new item browser. I said the same thing last time I talked about seeds and planting. Second, right now you can walk through these quite solid stone constructions. This is temporary, until I figure out a new algortihm for some technical problem I am having which is of no interest probably for most of you.

Tree trunks and roots can be removed

Here is a scenario you might be familiar with:

You cut down a bunch of trees and their trunk remains. It is not that easy to see, but there is trunk there between the logs. Even if you move the logs, the trunk remains. Am I the only one who feels a Metallica song coming up? DF has this feature where excessive deforestation will upset elven traders. I am not going to copy this feature but I do like the idea that some decisions in the way you structure your fort will influence your relation with other civilizations. Maybe you paint everything green to upset/entice all the green goblins? So you need to be able to do these small changes to your fortress, starting with the removal of logs:

This is the same map after you removed all the trunks and roots from ground. This is massive and time consuming operation. The root must be dug out and chopped into small pieces, then you need to cover the hole with soil and if you have logs around they need to be moved somewhere and back again. Your reward? Firewood. Smaller pieces of wood that are too small and strange shaped to be used as logs, but that are perfect as fuel and for crafting.

Condensed options for plant stuff

Like all other family of related operations, plant stuff now has its own window:

All separate options are gone. This is what I used to instruct my dwarves to remove the trunks and roots.

Optimizations for the map cache

I made several optimizations in the map cache code that have made scrolling smoother for zoom level 1. Unfortunately, it is still not enough for zoom level 2, but I'll continue optimizing. And I introduced some minor bugs. The map cache is also less memory consuming, but even so general RAM use has gone up by about 20 MiBs as the complexity of the world increases.

Tuesday, March 22, 2011

Screens of the day 05

Just a little filler while I work on other stuff: I decided to add a few skins to the editor. In the final version I would like to have them both use the same GUI skin, rather than the game having a skin and the editor using the skin of your target platform. I added a new menu to allow you to select the theme:

The first option uses the default skin from your operating system. The second and third options are based on Skulpture for KDE4, a theme I really enjoy created by Christoph Feck (skulptor). Here is a link if you want to check it out: Skulpture from Check it out if you use Linux with KDE4! The skin does not look quite as good as the official KDE version, but I still like it:

The standard windows window frame does not fit well with the overall look of the theme. And there is a dark version, for people who do not enjoy a bright screen:

Thursday, March 17, 2011

Screens of the day 04

So I was like editing away in my awesome editor, finalizing the fruit list, and I discovered a problem with usability. I found that I was changing tabs very often, going from trees to seeds to leaves to trees to fruit to leaves to... you get the idea. Unless you really had the full list memorized, there was no way around it. And I also had some problems with some kinds of plants. Cones are the ones who come to mind. Cones are technically not fruit. Yet they have a lot of similar properties. I could have skipped cones, and only go with the seeds. But I wanted to add the cones.

So I ended up redesigning the editor. since I don't want to repeat the mistake from last time (doing something and realizing mid-post that there is a better design), and since plants tend to shift around a lot until I find the perfect model, I am going to use the freedom offered by my "Screens of the day" topic to cover these changes.

So let us take a look at the new layout:

The list of trees is available at the top, but below now you can find a list with all the biological (or not) products that the currently selected tree produces. Let us see how we read this list for the acacia. First, you have the acacia leaf. It is available in all months and there is a new field that says what type it is, in our case a leaf. So acacias have leaves and it is not deciduous. All other field are gone. It has a result field. If an item has a result field, based on its type you can get somehow to that result. In the case of plants, you plant them. If the leaf would have a result that is different from -1, you could plant those leaves. As you can see, with this system I have fully done away with all fixed slots. You just have a master plant a list of things it produces or has. 

Then we see that the acacia has pods. Pods are the fruit, but you do not need to give this information in the editor. I am yet to decide if giving this information would make things more clear or not. The engine does not need it. The result is again -1, so you can't plant pods.

And finally, acacias have seeds. These are plantable and the result is an acacia. I hope it is clear how this system is as flexible as I wanted it to be. To reiterate on my old example of trees that grow diamonds and result in battle axes, all you need to do is add a new item to the list, name it diamond, give it a high value, a diamond tile, change the type to precious stone and change the result field to battleaxe. There are still a few problems, like diamonds having properties that may or may not show up in the tree produce list, but I'll find a solution for that. Another example of the non traditional tree is the money tree.

Here is another example:

Alder trees have leaves, cones and nutlets. These are not edible, like in the case of the acacia. There is no extra information to distinguish the cone from a normal fruit as it is not needed within the confines of the engine.

So what do you think? I think this system is a wast improvement on the previous one. There are still a few a few quirks to iron out. And I don't know if I should remove the old tabs that show you the leaf, seed and fruit list.

Anyway, I am very close to finding the final model and finishing the editor. I promised a video on YouTube about it, so I need to hurry.

Monday, March 14, 2011

32 – A little more love for the editor

I've continued updating the editor for the coming apocalypse. New versions might seems more and more complicated, but there is a good reason for that.

The editor is designed to handle both a simple and realistic set of items and a very complicated set of items. Let's take trees for example, at the risk of repeating myself. Trees have multiple "slots". The first is the seed slot. As far as I know, there are no trees in reality that have seeds. I am talking about just seeds, without any fruit. In the right season, trees bear seeds. You can harvest them without harming the tree. Out of the box, DwarvesH will not ship with any trees that have seeds that are considered seeds (what?), but the option is always there for modders. Then, trees can have leaves. And leaves can have seeds. Again, this is not the traditional way trees are. These seeds are embedded in the leaves and you get them by harvesting the leaves. And finally, trees have fruit with seeds. Now this seems familiar. The good old apple tree. Or beans encased in a pod. But if you blur the lines between fruit and seeds, the other models seem feasible. Take a tree that has nuts. If you want to model this, you may choose to make the nuts edible "seeds". This way you don't have to add a dummy seed to a nut. Nuts do not open to release the real seed. This goes for all fruit that you plant directly in the ground and which has no discernible seed (by the layman).

Did I mange to confuse you? To make things more complicated (and more expressive), you can have a tree with all three kind of seeds. And you can make them all yield a different kind of plant when they reach maturity if you wish. The only rule is that a given seed, or more precisely, a given ID can only be used once. If you want to add three kind of seeds to same tree in all three different slots, then you need to create three seeds with the same information (or not), but with different IDs.

While this may seem overly complicated, let me repeat that the plants that I will ship are more traditional and will bear fruit that contains seeds.

SUPER SPECIAL LAST MINUTE UPDATE: While writing this I decided that I want to experiment with a model where the distinction between seeds, leaves and fruit is totally blurred. In this model, trees still have three slots, but leaves, fruit and seeds are the same kind of item. Everything gets a result field and the type of the slot determines the behavior. If this model turns out to be a success the above explanation will be outdated. Sorry for not coming up with a final design on time, but I never done something like this before. But here's a question: who has?

Advancements in the plant model

Here is the new seed editor tab:

These are all items from DF and I am adding the new ones, but I started with trees and first I must finish the fruit before I can create the seeds. Fairly typical stuff here, but notice the "result" field. You must specify what plant will result from a seed. This is not done automatically for the cases where you want to try something strange and mix up the results. As said before, the result doesn't have to be a plant, but it will take some time before this can be seen in practice, and not before 0.1. So if seeds are their stand alone entity, how does the plant editor look like?

The same, only this time seeds are referenced by the bush. The tree editor is the same, but it references both the seeds and the leaves:

I moved the trees that are part of the final list closer to the top. Some items are missing, like the common fruit trees. And the final piece of the puzzle: the leaf editor:

I let pictures do the talking intentionally, since I already confused everybody with the lengthy introduction. The icons for seeds and leaves are the same, but this is only temporary.

Editor usability improved

Besides the new features, I greatly improved the editor and its usability. The design of the code is better, allowing me to add new tabs with great ease. Serialization is so robust that during these frequent changes in format and data layout, I have not lost any data once. Automatic cursor movement when doing some task in the spreadsheets is improved, and there is a more feature rich right click menu:

Engine updates

All these changes in the model have resulted in countless small changes in the code. The most visible one is the way things are handled in the item browser:

Here you can see the icons for leaves. Notice that a cooked leaf has three icons. They tell a little story. Fire was used on a leaf from a tree. A cooked leaf! I hope I managed to make the list fairly intuitive. I will rename the "Seed" tab to "Plantables".

Saturday, March 12, 2011

31 – A little love for the editor

Don't worry, little editor. I have not forgotten about you. I made some changes to both the editor and the underlying system that might not seem as much work, but it was certainly time consuming.

Unique ID system

All items that can be edited with the editor now have a unique ID. I want my editor to be at least as powerful as the Elder Scrolls Construction Kit, but limited in scope to the needs of my game. You will be able to make big master mods, that contain a self sufficient list of items and rules, and small mods, that build upon existing master files. So you need something to identify an object cross mod. A name is not that good because it can clash easily. I have assigned 100 IDs for each category of item. This is only a convention, you do not need to follow it. IDs need not be continuous. Let's see the new plant editor:

New centralized biome editor

As you may have noticed in the above image, plants have less options now. All biome options are gone. I now have a new centralized biome editor, where you can see all the entities that will be used to populate a given biome:

Biome names are a mix of real climate names and short descriptions of the climate. The names are not that important but I'll fine-tune the list. The content is still populated with a mix of DF items and the items that I'll have in 0.1. It takes time to go over the plants, since I am doing them one by one. I would like to have unique content for each biome when possible once the final list of plats is available.

But the biome list is more open than ever. The little buttons on the bottom are just used by me to insert an item in multiple categories. I'll look into how I can make these options more general.

Leaves are stand alone items

Here is the new tree editor:

Pretty barren. Biome options are moved to the new editor tab. Density is gone for good. I have no use for this property. Deciduous is gone, because now we have leaves that have their own seasonal properties. A deciduous tree is just a tree that has leaves that have their “autumn” and “winter” boxes unchecked:

With the new system, you can also create the opposite of traditional deciduous trees, i.e. trees that loose their leaves in spring and summer or any other possibility. I am investigating if I could get some worth wile features from replacing the four season boxes with a month ranges.

This list of leaves also betrays the new list of trees. Add to it saguaro, and you get the items that are both in DF and exist in reality. I'll add a few more trees ans slowly phase out the ones I no longer want.

Wednesday, March 9, 2011

Version 0.1 feature set

Here is the list of features for version 0.1. I am sure I forgot at least an item. “Stoneage” will be a more polished and rich version 0.1. I have included in the list both existing and future features.

Region map
  • Created based on map size, height, biome and map type. Map type includes slight incline maps, mountain maps (less soil, more rock) and experimental random elevation map.
  • Initial dwarf and equipment customization
  • 3 general map types based mostly on soil, sand or ice based on biome (I have no idea how you will survive on the ice map)
  • Map exploration on a single Z level. To compensate, maps will be larger.
  • New display mode, based on current Z level, decrement and increment. You can swap between rendering Z levels form current minus decrement to current and current minus decrement to current plus increment. This should help a lot when rendering performance is not enough, because you can fine tune the number of Z levels that will be displayed. UI component to track this information.
  • Map can be zoomed with two zoom levels.
  • Wall borders and short wall draw mode that can be toggled
  • Progressive snow fall
  • Action: remove snow. Cosmetic and only temporary
  • Progressive grass grow
  • Action: remove grass. Cosmetic and only temporary.

  • Primary build element for maps.
  • List of stones is near final, and does not include ore.
  • Action: dig wall. This will remove a tile or rock, creating a passage. You will get between 2-5 stones. Stones only have one size, even if it not that realistic. It is not fun to deal with 10 sizes of stone that can only be converted down, not up. Due to the sheer abundance or rock, the resulting stones will not be visible on the map. You will not need a stone stockpile and hauling of stone labor. This is an abstraction, because there is no way you can run out of stone and I would like to keep focus on creating rooms and passageways rather than endlessly hauling stone. Stone related tasks will be a little longer to include time for the invisible hauling operation.
  • Action: dig floor. Sometimes it can result in one usable stone. Low chance. If the floor (or wall) is sand, you will get all the sand.
  • Smooth and engrave for walls and floor. You can choose the pattern, but all patterns will look the same when viewed on the map.

  • Only on the top layer of the world. Fertile. Not present on mountain.

  • Stone can carved into furniture, containers, decorations or crafts.
  • Carved large objects like furniture can be moved
  • Open ended craft list. There are no fixed options except a few necessary items. You enter anything in a text box and the item is created. If you drop a picture in the right location, the item will even look like in the picture. No modding or technical skill required.

  • First batch of trees, either 16 or 32.
  • System designed to handle both realistic and more fantasy oriented plants.
  • Trees can have leaves, fruit or seeds.
  • Action: harvest leaves. You can choose the amount of leaves to harvest. Repeated harvesting of a majority of leaves will kill the tree.
  • Leaves come with little out of the box recipes. Leaves are flexible and ship with normal properties for leaves. Using the modding tools you can design leaves that have seeds.
  • Action: harvest fruit. Fruit is generally edible and has seeds.
  • Using the editor you can design a tree that has seeds without any leaves or fruit.
  • When harvesting an entity that has seeds, you will get units of that respective entity prepared for eating/processing and the seeds. I do not want to over complicate things for the player and have them worry about things that they already extracted seeds from.
  • Action: cut down tree. This will remove the tree and deny you its bearing potential. You will get 5 logs. Branches will be chopped down to firewood, making you not waste wood that is too small to form a log. Firewood can be used for making wood crafts. You will not get fruit, seed or leaves.
  • Action: cut down tree and remove trunk and roots. Very long task that gives extra firewood and fully frees up the tile.

  • Similar to stonecrafting, but you do it at a workshop and have a few extra items.

  • Semi final list of 16 plants
  • Behave like trees, but cutting them down yield plants and not wood. While trees can be harvested year after year and can be considered useful only for their yield if you do not need wood, plant generally are planted and fully removed by harvesting to get a useful yield.
  • With plants and trees the focus is more on surface plants rather than cave plants. I would like you to have to defend and place crops strategically rather than turtle up in a cave.

  • Workshops for the tasks above
  • Building walls from stone blocks or bricks, with or without roof
  • Building roads

Item browser
  • One centralized place where you can see all your stockpiles

Dwarf browser
  • Inspect the skills, gear and tasks for all your dwarves

  • The editor that I use to populate the world and create the rules made public

Monday, March 7, 2011

Release schedule

No, I am not releasing but I do have a schedule and I am going to talk about it. And also about what I mean by release.

Now, there are two important versions that we need to talk about. The first is the “release” version and then version 0.1. The first release, codenamed “Stoneage” will be the first release quality form of this project. I have a very clear idea of the features that it will include and in my next post I will detail all these features. The number of features is in no way meant to be taken as a competitive feature set when comparing DwarvesH with the competition. Not when comparing by quantity. On the other hand the features will be deep enough and I’ll try to raise the quality as high as I can with the resources I have at my disposal. So “Stoneage“ will feature single Z-level fortress building on a small map generated according to some parameters, with the focus been on never before seen (I hope) depth in the way plants are handled and with a number of wood and stone related products and tools that will be near final. It will also have the new item browser, a “dwarf browser” and other small touches. What it will not have is metal working, hence the name. You will still be able to choose a few required metal tools on embark, but you will not be able to set up a metalworking industry.

The above description might seem interesting, boring or something else to you.  But actually I was not that precise when giving it. This is not “Stoneage”. It is version 0.1. Stoneage will be between version 0.1 and version 0.2, a more polished, feature rich and more gameish experience than 0.1, which will serve as a foundation.

And now to answer the when and the how. My plan is to have “Stoneage” done somewhere between July and September. The three month period is a buffer for me if by some ill fortune I only finish 0.1 by the 1st of July, I still have ample time to fire it up. The rest of the details, the how, I do not know yet. All the properties are not set in stone (public, private, free, cost, open-source, organ donation, mandatory pet adoption…) and please do not ask about them before somewhere close to the release date. I do not know right now and do not really care. Coding now, politics later.

But between 0.1 and Stoneage, I must decide on the final name for the project, create a web site and launch the editor service. Here’s the short version: I will make the editor publically available, and launch a site/service with which the editor and the game will interact. Here you will be able to do fun stuff, like registering and account and making your own rule set available to others if you wish. Registering will not be mandatory of course. First version of the service will be very simple, but it should be enough.

And speaking of the editor, I will be seriously opening it up. Wide as canyon.  I realized that my fix set of rules is somewhat of a limitation. Not only will I impose my own vision upon the world, but unavoidably some Dwarf fortress influences will linger on. This won’t be such a problem if I make the editor more free form. Do you want to try something more radical? Do you want your trees to bear fruit with seeds made out of diamonds?  And after planting those diamonds, do you want to get battle axes instead of a new tree? Done! The new editor will be much more open ended. This also increases the responsibility of someone using the tool, but I hope we will get to see some interesting worlds.

You may have noticed that I wasn’t that active the last few days. I’ve been busy. Both with the project and other endeavors. But I did not code that much, I was very busy with designing. The question of content still remains, as does the controversy of using elements from DF.

Let’s take trees as an example. And let’s say that I don’t want to have the trees from DF. There are multiple solutions. First, I can make up my own absolutely fantastical names. So I can have a schubooboolou tree with minghidingidong fruit. And plump dragonsword chikantras for seed. This could easily get out of hand. Learning dozens of new made up terms would not serve the learning curve well. Or I could still make up names, but do it in a more traditional way, by using the same principles as people used in the past to name trees. This way we get brightwood, swampwood, morningleaf and moonleaf. Actually, moonleaf sounds pretty good and I’ll add this tree as soon as I figure out an interesting property for it that will serve its name well. Or I can go with existing species. And when going with existing species, you will find that a lot of the DF items are heavily inspired by existing species. So I have a simple rule: if the item exists in reality and I do want to keep it around, I will, regardless if it is on the list of any other game. I will not give up on acacias or apple trees. But these items will have different properties, sometime more deep, sometimes more superficial. The properties will either be reality inspired or will serve to fill a void in gameplay.

And speaking of acacias, let me illustrate how this tree will differ from the one in Dwarf Fortress.  In Dwarf Fortress trees are fairly similar. Acacias have name, density, biome, deciduous status and a few template properties for their material and material of objects created from them. I do not have density, but I do have the rest of properties except the material templates in one form or another. But my trees have leaves. Pickable leaves. You can even “kill” a tree by repeatedly removing all its leaves. Leaves are similar to plants but unable of reproduction. You can eat them, use them for cooking or process them. Or you could. Acacia leaves are not useful, but other leaves from other trees might be. And with the new open ended editor, some leaves and some water might be the only thing that separates you from the most awesome tea ever. What is interesting about acacias is their fruit, the acacia seed pods. They are edible and cookable. Their seeds, wattleseed, is again edible and cookable, but they can also be milled into flour. And then made into “bush bread”. Acacia gum is a primary base for a lot of paints. But you need to add pigment obtained from other sources. Of course, I might not be able to add all the uses and recipes in time for release. I spent quite a while researching different plants and uses.  Do you know what a genera or a taxonomic family is? I certainly didn’t and I’m not sure I know now. This is where the editor comes in. Once it is done and you know how to use it, adding a new use for the seeds or leaves or whatever, together with an associated cooking or processing recipe should be done in 5 minutes. Researching and balancing the new recipe, and finding a good use for it that will enhance your enjoyment of the game on the other hand is priceless. This is no wishful thinking I am doing. You will see all these features added slowly, one post at a time.

OK, this post is getting to long. Rant quota exceeded. Engaging thrusters. Join me next time for the full bullet list of the feature set from version 0.1.

Tuesday, March 1, 2011

Screens of the day 03

Here are a few screenshots with the new random elevation generator at different zoom levels:

And here you can see the full map without a cross section at the current Z level:

Right now the only thing that is preventing me from making this an official feature (except a few minor tweaks) is the performance. The engine was not quite designed to handle such an absurd number of tiles and I am not sure if it is even possible to do. The interesting thing is that I am having better performance in software mode as the tile number increased when compared to hardware mode. I guess that I am approaching the magical limit where the overhead of communicating with the hardware outweigh its benefits, like I did with the 3D engine putting a huge number of meshes in the scene at once.

But no worries, I'll optimize it as much as humanly possible, and then I'll look into some tricks to only create the impression that everything is genuinely rendered. With tiles so small, some detail is not noticeable and I'll try to actually draw one large tile except for 4 small one when working with terrain.