Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
EASYRPG PLAYER 0.2 “ALEX” RELEASED
Posts
Pages:
1
fdelapena
180
fdelapena
View playlists
Close(This is a forum mirror of this engine journal, just for getting more feedback from users as forums are more visited).
EasyRPG Player 0.2 “Alex”
Originally posted by Ghabry at EasyRPG Blog
Only 5 months behind schedule we are glad to announce the next stable release: Version 0.2
This version is named after everyones favourite hero “Alex”.
What is new for users?
As already stated in the Android post in December, SDL2 is used now. The major differences you will notice is that you can play now in fullscreen mode without having resolution changes, so all graphics are perfectly sharp and pixelated now :).
The Android port is now also distributed via the Google Play Store. The account is managed by our developer lobomon. Because the updates are uploaded by hand and are verified everytime by Google before publishing the releases are usually some days behind. You can find more up-to-date ones on our website in the download section.
Battle System (and random encounters) for RPG Maker 2000 and 2003 (#218) with some limitations:
RPG Maker 2000 Battle System
RPG Maker 2003 Battle System
Support for saving and loading (#186). The files are written in the LSD format. In theory they are compatible with the original RPG_RT. Because the LSD-format is not fully understood yet, not all data is saved/loaded yet (we support ~75% of the data), but should be good enough for most cases. As a side effect the arbitrary 50 pictures limit was removed.
All missing move commands implemented (diagonal movement and jumping). Further more some issues with incorrect passability checks (Whether you can (not) walk on a tile) were fixed and the movement frequency is now more accurate when compared with RPG_RT (#224).
Support for half-width cyrillic fonts in our built in font “shinonome” (#216).
Russian language support (old: left, new: right)
Support for command line arguments (See wiki page for further details, #225).
The game title is now read from the RPG_RT.ini and displayed in the title bar (#52).
When returning to the title scene (via End Game or F12) some data was not reset (#192).
In TestPlay mode pressing F11 opens the save scene.
The annoying, game blocking warnings messages are replaced with a quake-like drop down console and therefore don’t halt the game anymore. As a side effect you get full unicode support in the messages (e.g. for asian languages). (#193).
New output
What is new for developers?
Readers was renamed to liblcf and relicensed to MIT license.
Improvements in the build system. The Player and liblcf should compile on more linux distributions now.
The makefiles for the PSP (Playstation Portable) build were removed. Nobody contacted us in the last years to maintain the (broken) PSP build.
Anything else?
Yepp. MarianoGNU is working on a new editor called “Editor-Qt“. It is making good progress but is Not really in a usable state yet, but you can grab the Windows binary from our jenkins system. The Linux version will be released later.
Editor Qt
Editor Qt Database
Gameplay Video: Battle system on Android
EasyRPG Player 0.2 “Alex”
Originally posted by Ghabry at EasyRPG Blog
Only 5 months behind schedule we are glad to announce the next stable release: Version 0.2
This version is named after everyones favourite hero “Alex”.
What is new for users?
As already stated in the Android post in December, SDL2 is used now. The major differences you will notice is that you can play now in fullscreen mode without having resolution changes, so all graphics are perfectly sharp and pixelated now :).
The Android port is now also distributed via the Google Play Store. The account is managed by our developer lobomon. Because the updates are uploaded by hand and are verified everytime by Google before publishing the releases are usually some days behind. You can find more up-to-date ones on our website in the download section.
Battle System (and random encounters) for RPG Maker 2000 and 2003 (#218) with some limitations:
- Only traditional battle style supported for RPG2k3
- Battle event interpreter not well tested
- Conditions (Poison, Sleep, …) unsupported
- Some battle commands unsupported (you get a warning in that case)
RPG Maker 2000 Battle System
RPG Maker 2003 Battle System
Support for saving and loading (#186). The files are written in the LSD format. In theory they are compatible with the original RPG_RT. Because the LSD-format is not fully understood yet, not all data is saved/loaded yet (we support ~75% of the data), but should be good enough for most cases. As a side effect the arbitrary 50 pictures limit was removed.
All missing move commands implemented (diagonal movement and jumping). Further more some issues with incorrect passability checks (Whether you can (not) walk on a tile) were fixed and the movement frequency is now more accurate when compared with RPG_RT (#224).
Support for half-width cyrillic fonts in our built in font “shinonome” (#216).
Russian language support (old: left, new: right)
Support for command line arguments (See wiki page for further details, #225).
The game title is now read from the RPG_RT.ini and displayed in the title bar (#52).
When returning to the title scene (via End Game or F12) some data was not reset (#192).
In TestPlay mode pressing F11 opens the save scene.
The annoying, game blocking warnings messages are replaced with a quake-like drop down console and therefore don’t halt the game anymore. As a side effect you get full unicode support in the messages (e.g. for asian languages). (#193).
New output
What is new for developers?
Readers was renamed to liblcf and relicensed to MIT license.
Improvements in the build system. The Player and liblcf should compile on more linux distributions now.
The makefiles for the PSP (Playstation Portable) build were removed. Nobody contacted us in the last years to maintain the (broken) PSP build.
Anything else?
Yepp. MarianoGNU is working on a new editor called “Editor-Qt“. It is making good progress but is Not really in a usable state yet, but you can grab the Windows binary from our jenkins system. The Linux version will be released later.
Editor Qt
Editor Qt Database
Gameplay Video: Battle system on Android
Kaempfer
1932
This looks pretty amazing! What you're timeline for the rest of the battle stuff being finished?
edit: I know you're still working on full Rm2k3 functionality, but what are your thoughts on Dyn support? Lots of RM2k3 games now use Dyn patches and plugins to enhance their games, and it'd be a shame to see them excluded.
edit: I know you're still working on full Rm2k3 functionality, but what are your thoughts on Dyn support? Lots of RM2k3 games now use Dyn patches and plugins to enhance their games, and it'd be a shame to see them excluded.
Since you are replacing both editor and engine, will you support 32bpp graphics (full rgb+Alpha)? Please?...
fdelapena
180
author=KaempferThis is hard to predict, as this release got delayed half a year from initial estimations. Maybe this year becomes more complete on this part, however there is no public roadmap about this yet.
This looks pretty amazing! What you're timeline for the rest of the battle stuff being finished?
author=KaempferDynRPG is really a problem and shall not be used (as for legal reasons). DynRPG are memory patches over a very specific RPG_RT.exe version, so they are not portable and every plugin should be rewritten for EasyRPG Player again. The very only solution is encourage DynRPG developers to create equivalent code on EasyRPG Player (uses C++ too) and recommend users not to use DynRPG until EasyRPG Editor is being more mature. As there are lots and raising plug-ins being added to DynRPG, we won't have ever enough time to sync compatibility with them, as the priority is to complete the original interpreter.
edit: I know you're still working on full Rm2k3 functionality, but what are your thoughts on Dyn support? Lots of RM2k3 games now use Dyn patches and plugins to enhance their games, and it'd be a shame to see them excluded.
Once EasyRPG Editor is ready, as it is free, open source, any developer can (even legally) add custom features for both Editor and Player, even easier than patching memory registers and easier to debug. RPG_RT.exe 1.08 will be more incompatible between patches as it grows. EasyRPG Player won't have these limits.
author=RaveThis is already implemented in the engine. Video renderer is truecolor already and can be visually perceived. 24 bit PNG images with 8 bit alpha should load without problem too (with its own transparency).
Since you are replacing both editor and engine, will you support 32bpp graphics (full rgb+Alpha)? Please?...
Kaempfer
1932
Yeah, I figured Dyn wouldn't be handled because of its very specific nature. I don't know much about coding unfortunately, what would you opinion be on how hard transferring those patches over would be?
Ghabry
30
Basicly it's possible to simulate DynRpg functionality by reimplementing the functions provided by the plugins.
But depending on the plugin that is a lot of work because we don't share any code with the original RPG maker. Plugins like (elsemini) math and datetime are e.g. simple.
For this part I'm open for discussion (and code patches are welcome ;)).
The hugher pain are the DynPatches that are patching arbitrary in memory locations to move e.g. GUI elements around. It is possible to emulate this, too. But that is so extreme ugly... that I don't want it.
But depending on the plugin that is a lot of work because we don't share any code with the original RPG maker. Plugins like (elsemini) math and datetime are e.g. simple.
For this part I'm open for discussion (and code patches are welcome ;)).
The hugher pain are the DynPatches that are patching arbitrary in memory locations to move e.g. GUI elements around. It is possible to emulate this, too. But that is so extreme ugly... that I don't want it.
fdelapena
180
author=Kaempfer
Yeah, I figured Dyn wouldn't be handled because of its very specific nature. I don't know much about coding unfortunately, what would you opinion be on how hard transferring those patches over would be?
As commented by Ghabry need be implemented specifically for Player, as the C++ API is different too. Fortunately, some C++ method names used in EasyRPG are closer to the RGSS API, but in C++.
For example, how the EasyRPG scene works. It is stack-based, so scenes are pushed and popped (returns to previous scene where called). Here is where the first scene (scene_logo) is added (shows the EasyRPG logo before the title scene:
https://github.com/EasyRPG/Player/blob/master/src/player.cpp#L134
From the scene logo, the scene title is being called after 1 second (60 fps):
https://github.com/EasyRPG/Player/blob/master/src/scene_logo.cpp#L934
The EASYRPG_MAKE_SHARED<scene_name>() is a convenient way to use smart pointers (C++11 or boost). If you don't understand this, don't worry for now. This allows us to create things in memory and not having to destroy them explicitly, it does automatically when all references are clean.
This creates the window with 3 commands: new game, load game and quit game:
https://github.com/EasyRPG/Player/blob/master/src/scene_title.cpp#L149
Note the Data::terms, getting texts from the database "terms" tab.
As you can see in scene_title, there you can set position of the window with ::SetX and ::SetY, defined in Window class (Window_Selectable inherits from Window_Base and Window_Base inherits from Window, similar to RGSS).
This is an example about how Player works. You can hack Player to adapt him to your needs. Player license is expected to be switched to MIT soon, so you can do commercial games without having to share engine modifications and friendly with some stores which cyphers the binary (e.g. the Apple's one), where GPL is not allowed. The editor will remain with the GPL license.
Hm, how about making dummy headers that would translate Dyn code to EasyRPG code? E.g. if you have two functions. let's say A and b, each with two parameters, but in B those are swapped.
Of course if plugin is using direct memory location in its code, this would pose a problem, but such set of dummy headers would help to port over simpler plugins.
Missing parameters note:
If on DynRPG side one parameter is missing in comparison to EasyRPG's version, safe "default" value should be used.
EX: Now function B (EasyRPG) has extra int parameter, but A (DynRPG doesn't) so 0 (safe default in this case) is assumed:
If on EasyRPG side one parameter is missing in comparison to Dyn, parameter is dismissed.
EX: Now function A (Dyn) has extra parameter, which is dropped:
In both cases some sort of warning should be printed to console.
//DynTranslator.h
#include "EasyAPI.h"
void A(int Arg1, bool Arg2){
B(Arg2,Arg1);
return;
}
Of course if plugin is using direct memory location in its code, this would pose a problem, but such set of dummy headers would help to port over simpler plugins.
Missing parameters note:
If on DynRPG side one parameter is missing in comparison to EasyRPG's version, safe "default" value should be used.
EX: Now function B (EasyRPG) has extra int parameter, but A (DynRPG doesn't) so 0 (safe default in this case) is assumed:
#include "EasyAPI.h"
void A(int Arg1, bool Arg2){
B(Arg2,Arg1,0);
return;
}
If on EasyRPG side one parameter is missing in comparison to Dyn, parameter is dismissed.
EX: Now function A (Dyn) has extra parameter, which is dropped:
#include "EasyAPI.h"
void A(int Arg1, bool Arg2, int Arg3){
B(Arg2,Arg1);
return;
}
That's because it is. Though in the end, after whole of RM2k3 is supported, custom file formats specially for ERPG should be made (preferably xml-based) which would make possible to implement capabilities that are outside of regular RM2k/3 capabilities such as more layers, using multiple tilesets on one map, etc.
Of course that should be stretch goal, after full feature set of RM is supported and of course with leaving ability to play legacy RM games with it, which was original goal of the project.
Of course that should be stretch goal, after full feature set of RM is supported and of course with leaving ability to play legacy RM games with it, which was original goal of the project.
fdelapena
180
As a convenience function to translate functions to the EasyRPG API is OK, however the very best solution is to hack the code directy later, though your proposal may be OK when transitioning for people who does not know much C++ and uses built-in plugins.
There is a XML version of the RPG Maker file format already and EasyRPG Player supports it. Editor-Qt writes XML by default already.
liblcf is the library which reads and writes native (lcf) file format, but also can read and write the XML version of it. To demonstrate this, there is a tool called LCF2XML in this thread with usage instructions.
There is a XML version of the RPG Maker file format already and EasyRPG Player supports it. Editor-Qt writes XML by default already.
liblcf is the library which reads and writes native (lcf) file format, but also can read and write the XML version of it. To demonstrate this, there is a tool called LCF2XML in this thread with usage instructions.
Pages:
1
