alexleroyross / amble Goto Github PK

So the update that was released several days ago appeared to fix the lagging issue only to a small extent. It would appear that the lagging (which is still very much apparent) is caused by various parts of the engine just generally being written badly. There is, nonetheless, one aspect of the engine which is likely responsible for a large majority of the lagging:

There is a 'for' loop for everything. For example, just in the C++ code, there is one for applying AI, one for moving the level, one for rendering, etc., which all loop through every single entity in the level. On top of that, there are SEVERAL loops in LuaBridge alone, which communicate the status of things to and from luacode.lua. Then, in luacode, there are even more loops to apply other various properties to everything! I would imagine that all of these loops are extremely inefficient. The better way to go about doing this would (probably) be to have ONE loop in C++ to do everything that needs to be done with all things, and MAYBE one loop in luacode.lua if necessary, though I would imagine I could probably even get around doing that.

Again, I know there are more things that are probably causing the problem, though I would imagine this is the most significant issue. Now, I am again not sure if I am going to go ahead and actually address this issue, or whether I will simply call this game as a whole a learning experience and move on. Rewriting the C++ code would perhaps not be too bad, even though it would probably take awhile. The code relating to Lua, on the other hand, is so messy and unnecessarily long that I would legitimately probably be better off just getting rid of all of it and starting over, which would take another eon to do. Like, I could probably have a large part of an engine for a new game already written by the time I would finish with all of this.

I dunno, man. I'm not calling this project dead yet, but I do feel like it may be in my best interests to just move on. This project has been on life support for a while anyways. Plus, I seriously have learned an immeasurable amount of invaluable experience, from teaching myself the best ways to write code through trial-and-error to being taught the best programming practices by seasoned programmers. I have no doubt my next game (which may even be called Amble 2.0 or something since I like the idea I have going with this game) will be infinitely better than this one.

If custom frames and states are to be allowed, then it would probably be easiest to move frame handling and cycling from c++ to lua.

Apparently the game lags horribly when levels are any larger than roughly 80x80 or so units, which is actually extremely small. I am pretty certain that this issue stems from the things[] vector having an index for each level unit, regardless of whether it is empty or actually contains something. All of the loops, in turn, have to check every single index, which I would imagine is causing the lag. Plus, it would not take long before the things[] vector would be a ridiculously huge size in general (a level that is just 100x100 units would have 10,000 indices!).

The way I see it, there are two potential paths that could be taken:

1. Rewrite a large portion of the game engine so that the things[] vector only contains indices for things, and not for empty level units. This would take quite a long time to do since I would need to completely redesign the level reading/writing system, most of LuaBridge, and a lot of the code that handles things in general, both in C++ as well as in Lua.
2. Simply call this project a failure and use the knowledge and experience that I've gained from working on it to design a bigger and much better game. I'm aware that the engine for this game has many other flaws than just this one in particular as well.

I will update this issue with a comment as soon as I have made up my mind as to what I will do.

Need to make Lua aware when collisions occur and transfer tgHandleCollision functions over as well.

Need to make all things be able to dash. Also need to allow this value to be modified from Luacode.

Need to make the game write to/read from a config file so that settings can be saved.

There are a bunch of linker errors that were somehow never noticed until now. Need to change around the order of file includes to address this.

• At least one occurs in labHandleEnvironment() (line 705?)
• Also one in gxRender() (specifically line 263)
• Need to check for others

Each thing has tgDirection. It is sometimes updated, though not every time it should be. It is also currently never used. Need to decide to either:

• Get rid of tgDirection entirely and just determine direction by tgVerticals and tgSpeed
• Optimize its usage by updating it each time it needs to be and adding specific directions for diagonals

Code could be made significantly better if userdata was used instead of the awkward current system.

Enums need to be able to work with Lua tables more optimally.

Possible Solutions (in order of estimated effectiveness):

• Use maps instead of enums
• Somehow make enum and table values correspond & interact
• Remove enums entirely

The projectile engine will sometimes confuse which projectile is which for some reason. Because the particle engine runs in a similar fashion, it may have the same issue, though I have not yet done any testing to see if that is actually the case.

Currently, the button that is mapped to a function in the button mapping menu is not displayed. Not a big issue, but should consider adding this feature at some point.

I've been adding, removing, and changing a LOT of things lately but haven't reviewed any of it afterwards. Would probably be best to look over all code and make sure everything is working properly and that there are not any mistakes that may not have explicitly yielded an error.

Need to look into using smart pointers instead of regular ones, such as with things[]. May simplify some of the code.

It would be handy if there were at least a 1.5x window scale option in addition to the 1.0x and 2.0x.

I've read that lists are more efficient than vectors since they do not use arrays behind-the-scenes, but I have not actually looked into this yet.

Should add another smaller font to be used for places where there is more than just a few words.