![]() ![]() In case your wondering – yes, they fixed the Sprite_Clickable issues for the v1.0 release and now the onMouseExit function will get called properly. This means that plugins for repositioning windows, and creating new windows – if following the same structure, will be much cleaner and easier to manage.Ī number of new sprite classes, such as Sprite_Clickable, and Sprite_Gauge now exist, which are excellent examples for newer programmers to build upon or use as a base for creating custom hud elements or clickable buttons. For example, all scenes now create their windows using the Rectangle object to define its position, which is defined in a function separate to the function which creates the window. The default codebase for MZ is structured very similar to the previous MV, but it features a large number of improvements and minor tweaks that overall, make expanding on its functionality fairly trivial. Of course its great that the engine now doesnt need 3rd party solutions to do things it should have done on day 1, but it also means I wasted time in writing the system to begin with! To me, this is both a blessing and a curse. Yes, my plugin can still add a nice loading gauge and graphic, but the default code to load modules is now handled much better and makes a large portion of that system worthless. But in doing so, I have also noticed that there are a number of improvements that completely nullify a lot of the systems and features I had in place…įor example, the logic I used for handling loading of modules is mostly useless now. Moving to the new maker I have found that it’s been very easy to port most of my logic directly, which has made updating older plugins nice and painless. Such as proper mouse position tracking, properly handling loading of plugins and modules, and of course, enhancements to the capabilities of default scenes and windows. Most of them are unreleased, but over that time I have created a number of things that I felt were a requirement for the maker. Instead I am going to talk about what its been like as a programmer writing systems and plugins for this new maker, as well as the possible disadvantage in performance it has compared to the previous maker!!įor a number of years I have been writing plugins for RPG Maker Mv. Unlike other reviews you may see, I am not going to focus on capabilities of the editor, or the quality of the included assets. ![]() At first it seemed the new maker was no different to the previous RPG Maker MV, but now, after spending over 150 hours (at the time of writing) within the new maker, I feel like I have seen enough to make my own decision. wavs can be played in RM2k3 without concern, and those are significantly larger.I mentioned previously that I would have a review of the new RPG Maker MZ game engine after release. mp3s and not a memory issue, since even short mp3s have the same problem with the same delays.ogg files, which are natively supported in RMXP, don't share the issue at all, and even very large. I'm almost positive this is a problem with the way RM2k3 handles. edit: author=Zachary_Braun I know a lot of the RPG Makers have trouble looping any music that isn't a midi file, causing a little stutter between loops as it loads the music into memory again. ![]() Also, I really dig that art style! Very nice. Panoramas are handled very well by RM2k3, for most purposes. ![]() Larger maps may cause a bit of slowdown on load, but I doubt it'll ever be a problem for 95% of computers. pngs (like you should always) and keep your maps under, oh, 75x75, maybe 100x100, and you should never see any lag whatsoever. This isn't an RM2k3 issue, it's just that bmps contain a lot of totally uncompressed data. Massive parallax images can cause lag, especially if you're using. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |