![]() Of course I know this is a beginner tutorial but it sort of does pay off in the end to show people how things "kind of should be done" so they don't end-up going down a dark path (sad attempt at a pun there) You don't need to have loads of numbers to fetch regions, just "GetTextureRegion("somefilename.png") EnterFrame events (as well as others) really begin to kill performance when you begin to have many of them :OĪs with a few other things it would be better to use a TexturePack for all graphics right from the get-go because it really is the easiest thing to use. In my experience it is more efficient to have each class have it's own update(dt) function and then have just one EnterFrame event in your game class which calls the update function of each class every frame. Where you start adding EnterFrame events to classes. Related to the above, maybe it would have been better to introduce Maybe it would have been better to start using classes for everything immediately instead of introducing them in part 4 and having to re-code a ton of stuff |) It might be better to grab some off (there are heaps of those "LPC" style graphics there) just incase somebody followed your articles and published their result on the play store The tilemap images you use aren't free for a commercial product. It would be better to define all of your constants in a, or better yet a (which is loaded even before a) so all constants will be available on demand and you won't need to ever look at the dependencies screen #:-S In part two you use Dependencies to make sure a is available to other files as required. You have really been busy! Some things that stood out for me were. This version is a big step forward, multithreading in particular should allow for more efficient 3D games, by allowing to run 3D collision engine in parallel with rendering, and on demand rendering being a big improvement for professionnal apps.Great stuff man. Now we use the same OpenAL-Soft version for every platform, providing a consistent API accross platforms and opening the way for future audio additions such as filters and effects. Audio used to depend on various engines: XAudio2 on UWP and several versions of OpenAL. This saves a lot of GPU/CPU power as well as battery life. ![]() Gideros now supports on demand rendering: rather than updating the screen continously (the fps), when on demand rendering is enabled Gideros will refresh the screen only if it can figure out something has changed. Such table accesses are slower, but thread safe. A new table.share call has been added to make a lua table protected with mutexes. in theory! In practise care should be taken to avoid concurrent modifications, and most Gideros API isn't thread safe. They share the same environment as the rest of your code, and can access anything. ![]() ![]() Parallel threads are launched by Core.asyncThread instead of Core.asyncCall, and have a lot in common with those asynchronous threads. True parallel multithreading is now possible in Gideros, with limitations similar to those that come with multithreading in C++. It comes with performance improvements and a new form of litteral strings. LuaU engine have been upgraded to latest (or rather latest a few weeks ago!). I am confident it should be at least backward compatible. I am happy to announce the (pre) release of Gideros 2022.9, maybe too soon but lets face it, I can't spend time doing in depth testing of each release so lets do it together.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |