Release Easy RPG PND for Pandora


Yay a new EasyRPG Version is comming Soon.

I am happy to grabbed out my Pandora for new Software/Games Testing:D
 
hi, I'm planning to release two of my older RPG Maker-based titles for the Pandora through EasyRPG, but with a modified version (I modified the original runtime files back then so I need to port those changes to EasyRPG as well).
Just wanted to ask before I start and hit a roadblock, since compiling on the Pandora will be slow: Anything special you do when compiling these for Pandora, or can I get away with compiling liblcf and EasyRPG straight just like on regular Linux (using Code::Blocks PND command line tho)?

Worst case I'll ask you to do it for me in person at Gamescom. :p
 
Yeah, my build is mostly vanilla. The liblcf is vanilla (hint: don't build it separatly, it's easier to git clone it inside "lib", so you have a "lib/liblcf" folder).

Player itself is slightly changed, but that's just details, not really necessary...
Code:
diff --git a/src/audio_sdl.cpp b/src/audio_sdl.cpp
index 533228c8..cd9bbd23 100644
--- a/src/audio_sdl.cpp
+++ b/src/audio_sdl.cpp
@@ -66,13 +66,13 @@ SdlAudio::SdlAudio() :
        GenericAudio()
 {
        if (SDL_InitSubSystem(SDL_INIT_AUDIO) < 0) {
-               Output::Warning("Couldn't init audio: %s", SDL_GetError());
+               Output::Error("Couldn't initialize audio.\n%s", SDL_GetError());
                return;
        }

        SDL_AudioSpec want = {0};
        SDL_AudioSpec have = {0};
-       want.freq = 44100;
+       want.freq = 22050;      //SEB Pandora 44100;
        want.format = AUDIO_S16;
        want.channels = 2;
        want.samples = 2048;
diff --git a/src/input_buttons_desktop.cpp b/src/input_buttons_desktop.cpp
old mode 100644
new mode 100755
index 6aeaa4e4..81efae7b
--- a/src/input_buttons_desktop.cpp
+++ b/src/input_buttons_desktop.cpp
@@ -45,6 +45,10 @@ void Input::InitButtons() {
        buttons[DECISION].push_back(Keys::SPACE);
        buttons[DECISION].push_back(Keys::RETURN);
        buttons[DECISION].push_back(Keys::SELECT);
+    if(getenv("FLIPBX"))
+        buttons[DECISION].push_back(Keys::PGDN);
+    else
+        buttons[DECISION].push_back(Keys::ENDS);
        buttons[CANCEL].push_back(Keys::AC_BACK);
        buttons[CANCEL].push_back(Keys::X);
        buttons[CANCEL].push_back(Keys::C);
@@ -53,6 +57,11 @@ void Input::InitButtons() {
        buttons[CANCEL].push_back(Keys::N);
        buttons[CANCEL].push_back(Keys::ESCAPE);
        buttons[CANCEL].push_back(Keys::KP0);
+    buttons[CANCEL].push_back(Keys::PGUP);
+    if(getenv("FLIPBX"))
+        buttons[SHIFT].push_back(Keys::ENDS);
+       else
+        buttons[SHIFT].push_back(Keys::PGDN);
        buttons[SHIFT].push_back(Keys::LSHIFT);
        buttons[SHIFT].push_back(Keys::RSHIFT);
        buttons[N0].push_back(Keys::N0);
diff --git a/tests/filefinder.cpp b/tests/filefinder.cpp
index 3c18b3d9..39e83a58 100644
--- a/tests/filefinder.cpp
+++ b/tests/filefinder.cpp
@@ -1,5 +1,6 @@
 #include <cassert>
 #include <cstdlib>
+#include <assert.h>
 #include "filefinder.h"
 #include "player.h"
 #include "reader_util.h"
 
Been a bit busy, so this is late, but: Thanks!

Unfortunately, it appears that my games are a bit heavy for this little device. Lots of overlapping graphics at times as well as rather advanced scripting trickery seems be too much for it. Also frequent stutter playing sound effects, even when they should be cached. A boss battle is literally unplayable (screen refreshes a every few seconds). I feel like I could optimize that one a lot by moving the commands into the compiled code, but not sure about the rest.
The majority of the game runs playable, but the stutters don't scream "quality" to me. I'll need to see what I can do here.
That stuff used to run fine on dated PCs and I've never gotten any complaints either.

Also curious how the Pyra fairs in this... well, we shall find out soon enough!
 
Unfortunately, it appears that my games are a bit heavy for this little device. Lots of overlapping graphics at times as well as rather advanced scripting trickery seems be too much for it.

We are aware of performance regressions in 0.6.0 and 0.6.1 but don't really know how they happened.
Currently we try to optimize our code for another picture heavy game (Frozen Triggers). Likely will also help for yours.

That the game gets stuck at 0 FPS (one refresh per second) and never recovers is another bug we are aware of. I recommend waiting for 0.6.2 or using the nightly when all patches are in (in ca. 1 week).
 
I've been somewhat busy with other projects, so I haven't had a more detailed look at what's really taking up all the time on the Pandora, but sounds interesting. My game isn't exactly picture heavy, I'd say, rather than the boss battle in question having a lot of moving and non-moving events with visible graphics set. But I'll still look out for the future versions!
 
Btw I would be interested in performance comparisons. Especially for games that were running slow or stuck at 0 FPS before: Just test if they are more playable now. There were some improvements, e.g. on the old 3DS (very slow system) we get now 5-10 FPS more depending on the workload.

And the low FPS logic is better. When the game runs very slow (~10 FPS) it still "feels" smooth now because the update code is smarter now.

(oh and this is the first buiild that needs C++14, but seems your compiler supported it :D)
 
Back
Top