Next Gen ZC. (Otherwise known as ZC3.0)

[Christopho]

Well that's an interesting discussion :)
(Including the programming language troll.)

To summarize, any discussion on this in the past two years has just boiled down to the following:

1. Will be open source and primarily written in c/c++.
2. Take advantage of well tested 3rd party libs for portability (ie,; windowing, input, etc.). Don't use allegro.
3. A game engine or framework should be at it's core, and should be independent of Zelda-related IP or other copyrighted materials. The community can easily add a Zelda resource pack just like using a tileset in ZC.
4. Use qt for the GUI.
5. Use a fast and powerful scripting language like Lua, or C#. (Alternates have been brought up before, such as python or javascript, but are usually met with mixed results, however there's nothing stopping anyone from adding bindings to all of these later on!)

This is actually a very accurate description of Solarus.

I don't know ZC much but I am always open to learn and share things. I am sure both teams can learn from each other.
What I know is that I have a lot of respect for what you guys do, because the ZC community is very active, and this is an amazing source of fangames! The number of ZC quests is just crazy.

Solarus is a young project. It started in 2006, that's true, but at that time it was a not a Zelda Maker at all, it was a dedicated engine for a particular game I was developing (Zelda Mytery of Solarus DX). Now, Solarus as a general Zelda-like creation tool is quite new. Before the latest release (1.4) of May 2015, there was no GUI to make dialogs or to set the properties of the quest. Each release brings new features to allow users to achieve great things more easily.

You seem to want to make things open and this is obviously going into the right direction. Since Solarus code is open-source, and only relies on open-source third parties, it can be compiled on a lot of plaforms. We officially support a lot of operating systems, but for example people are also working on a (non fully working yet) Wii port!
Keeping everything open is important. Not only the code, but we also spent a lot of time on the documentation. We try to give a very complete documentation of the scripting API. We also provide a full specification of the format of data files, so that people can develop their own tools. For example, thanks to the openness of data file formats, people developed automatically generated maps with procedural generation with Solarus.

Whatever you decide, we are here to help and your feedback is welcome. Including bug reports and even pointing out ugly parts of the code

Any way, even if you decide to start from scratch, the least we should do together is to work on some conversion tools to import/export resources between ZC and Solarus.

Finally, to answer particular previous remarks:
- Don't forget about rule #1 of optimization. Which is "Don't optimize.". Premature optimization is the root of evil. About the code that finds an enum value from a name, you really want yet another map to have a faster reverse mapping? No, I will not optimize a linear traversal of constant container of 10 elements :) Unless there is a use case where profiling shows that this is a bottleneck.
- On the contrary, useful optimizations were done. Like hardware 2D acceleration (with SDL2), pre-rendering of maps (no, we don't redraw all fixed tiles at each frame!), lazy loading of tiles, clever management of obstacles… And we also use LuaJIT for great performance of scripts. The latests realeases are fastest than ever. Solarus can run on limited hardware like the GCW-Zero handheld console. Maps with thousands of tiles can load and run without problem. Actually, individual tiles don't even exist at runtime (except animated ones).
- Animated tile patterns can only have 3 frames in the current version of Solarus. Like with RPG Maker (hmm, 2000 at least). And the code that manages that is clearly terrible, let's admit it :) A funny relic of when I was a beginner in C++. Anyway, more customized tile animations is a planned feature.

[Gleeok]

Finally, to answer particular previous remarks:

Hi Christopho. I hope you didn't take offense to anything I said. I was simply trying to make the point that you can't take a decision to start a major project so willy-nilly; in this case deciding to use an existing code base that no one bothered to look at first, or even knew in depth how it worked or what it did. Nothing against the good things that you have accomplished.

I haven't played it yet, but Solarus looks like a very cool project. I watched the video of it a few years ago. I really hope you can complete it. :)

Finally, to answer particular previous remarks:
- Don't forget about rule #1 of optimization. Which is "Don't optimize.". Premature optimization is the root of evil. About the code that finds an enum value from a name, you really want yet another map to have a faster reverse mapping? No, I will not optimize a linear traversal of constant container of 10 elements :) Unless there is a use case where profiling shows that this is a bottleneck.
- On the contrary, useful optimizations were done. Like hardware 2D acceleration (with SDL2), pre-rendering of maps (no, we don't redraw all fixed tiles at each frame!), lazy loading of tiles, clever management of obstacles… And we also use LuaJIT for great performance of scripts. .

I guess I am on the other end of the spectrum here with "Premature optimization is the root of evil". To me that is one of the dumbest things I have ever heard, right up there with "The war on drugs" and "Stop underage drinking before it starts." ..I wish people would stop saying that. At the very least, I guarantee you that quote originated from someone who absolutely was not a game programmer trying to run an entire simulation in 16.7 milliseconds.

The pre-rendering of maps is an interesting idea that I have never tried. This almost sounds like something in the old pre-GPU card days where bitmaps were marked with dirty flags. I believe this concept was called "dirty rectangles." Interesting. Would this also work with palette effects or color changes to individual tile layers, like a day-night system?

[Christopho]

No offense taken :)

What I mean with "don't optimize too soon" is that there is no point in making the code more complex (in that example, adding a redundant reverse-mapping structure) to save 0.0001% of CPU time. It has no effect. I would probably accept a pull request if someone does it, but this is a waste of time for no improvement. The right approach is to keep time-insignificant code straightforward and work on optimizations where time is spent. Usually, in games, we will focus on rendering and collisions (and, if you use a scripting language other than Lua, in scripts Sorry, I only managed to resist in my previous post).

I made a fundamental mistake in 2006 when I started the project: I decided that all maps should be identified by an integer id for better performance. Because integers are faster than strings, right? So map files were named 1.dat, 2.dat, etc. More friendly names could be set in the project resource list file, and were displayed in the GUI of the editor, so it worked well. Except that it was completely stupid. It made life more complex for users. In scripts, when you want to teleport the player to another map, you have to write the map id, so you first need to find the integer number of the map you want. Unless you know all of them by heart. Obscure file names are also painful to manage in your version control system. What if two people of the team work on new maps at the same time? (I did like this because it felt natural, everything was organized with integer ids in RPG Maker. Map file names, saved variables, etc.).
Now, maps are identified by a string and can be organized in a hierarchy, for example you can name your map "water_temple/1f" and it is fast as before. As fast as before because at runtime, we don't work with map ids a lot, but only when loading a map. Parsing a map id is completely insignificant compared to loading the map content.

For the pre-rendering of maps, I only pre-render fixed tiles. Anything dynamic, like enemies or other moving entities, as well as animated tiles, and other graphics added by scripts like a day-night overlay, is redrawn normally at each cycle. Since the number of non-animated tiles is often huge in big maps, the performance gain was huge. Basically, I lazily pre-render non-animated tiles in areas that are in the camera or close to it. The algorithm is not as simple as one would think, because tiles can not only be animated, but can also have various sizes, can overlap each other and can have transparent parts. Determining what can be pre-rendered and how to recombine everything to get the correct final drawing is a bit tricky.

[Gleeok]

Donald Knuth. He starting coding in the 1950s, so I'm sure he was plenty familiar with speed concerns.
The point, mind, was that optimization efforts should be narrowly focused where they're useful; trying to optimize every line of code is a waste of time.

Donald Knuth. That's right!
It's still a dumb blanket statement, since most people that haven't actually practiced optimizing will have no idea when 'premature' really is or even know what to optimize or how to optimize.

http://www.joshbarczak.com/blog/?p=580

Obviously. If you were to actually optimize every single line of code you'd end up with a lot of assembly, very little objects--only POD components and data--and little OOP, and adding even an extra byte to some struct somewhere might throw off your alignment requirement or cache usage strategy and require a rewrite so it stays 'optimized'. Not only that, but it would take so long that by the time you were done compute hardware would be better anyway and require your program to be redesigned, so it is really not useful at all. However if you ignore optimization altogether and just wait until a game is done to optimize it then it is too late--you can't actually optimize it in a meaningful way without rewriting all the parts that need it, you can only tune it or fix hotspots. That's my story and I'm sticking to it.

Anyway, the topic is rather silly anyway without a proper context. Truth be told, I very rarely optimize anything because it involves looking through the compilers generated code, and that is not very fun or productive; I'd rather not even do it at all, and 99.99% of the time I don't. However, "prematurely" optimizing through design is often easy and will likely remove the need to optimize later, unless profiling shows otherwise.

PS: Yes, this is from experience only, not some random blog post I read from 2008. My first shooter game I made in c++ would not run at 60 FPS [on my machine] no matter what I did, and it was only a single level. I spent months trying to improve it to no avail and finally just gave up on it. Not a fun experience. Years later I prototyped a similar type game--same computer, same OpenGL, same compiler--except that I was smarter and faster than before, and designed everything from scratch by reading lots of information on pretty much whatever was available online for free. Let me just skip to the end of this story now: Not only have I never hit less than 60 FPS since then, but it's not even close. Most of the time the game is just telling the OS to sleep, or waiting to vsync. Of course modern hardware is so fast nowadays that most people won't even have to go through this. They can use bloated libraries, slower languages, write bad code, and have no problems.

No offense taken :)

What I mean with "don't optimize too soon" is that there is no point in making the code more complex (in that example, adding a redundant reverse-mapping structure) to save 0.0001% of CPU time. It has no effect. I would probably accept a pull request if someone does it, but this is a waste of time for no improvement. The right approach is to keep time-insignificant code straightforward and work on optimizations where time is spent. Usually, in games, we will focus on rendering and collisions (and, if you use a scripting language other than Lua, in scripts Sorry, I only managed to resist in my previous post).

True. I am aware that the maps' dynamic lookup table is only ever run for getting resource data when some entity is initialized. It's probably not worth it to optimize, you are right. The point I was trying to get across was complexity and usage, not speed, ie., how complex would it be to use or modify existing code. How complex wold it be to add to...et al.

Yep. Rendering, collisions, particles, and data layout are the most important. I totally agree.

[Saffith]

At the very least, I guarantee you that quote originated from someone who absolutely was not a game programmer trying to run an entire simulation in 16.7 milliseconds.

Donald Knuth. He starting coding in the 1950s, so I'm sure he was plenty familiar with speed concerns.
The point, mind, was that optimization efforts should be narrowly focused where they're useful; trying to optimize every line of code is a waste of time.