- This topic has 15 replies, 3 voices, and was last updated 4 years, 3 months ago by
.
-
Posts
-
A very great (but very hard) action/platform game, inspired by an awesome comic book. Wikipedia
This .mgc is just an edit of my generic gamepad .mgc.Walk with dPad, run with A, jump with B.
You can also run by Double tapping right or left arrow key
Buttons opacity is set to 50% but you can change this by opening the Options menu (swipe from up to down)
Download .mgc file
Don’t forget to read the user guide first:
English Manual
Manuel en français
I forgot: this layout use the Pixel Trap function for showing level password at the right moment.
But should work even with non-beta versions of the app. I hope 🙂No, it should crash. Wait next version of the app to use this layout.
And I own all the Tintin’s comics 🙂Those were my favourite comics back then, along with Asterix. ?
Pixel Trap will hopefully be included in the next update. It’s running pretty stable, and it’s such a great feature, incredibly useful. ?@Al ex. Yes this feature is just awesome. I secretly wait for it since the first time I use magicdosbox 🙂 The only dark side is the performance sacrifice. It’s difficult to say but I’m pretty sure that before using the beta, Tintin in Tibet ran flawlessly. With the beta I have some slow down one or two time. Nothing unplayable and almost unoticeable, hopefully. My S7 edge is a bit old now 🙂
@admin. Ok. thanks. I was too lazy to test it with the official release XDInteresting. I’ll need to do some side-by-side comparison, but on my S9+, I can’t notice any real slowdowns. Something like 1-3%, but that’s almost completely negligible.
@Al_ex : I just test Grand Prix 2 (yes, I choose the extreme) : on my S7 edge, the game was playable in vga with almost all graphics options ON, or in SVGA with almost none graphics options ON.
Now the game is only playable in vga with all graphics options OFF (svga slow down to death when more than two or three cars on screen). So yes performance impact is noticeable, and I guess the more the game is big and your phone is weak, more the impact is noticeable. But Pixel trap is just awesome and I didn’t plan to play GP2, so… don’t care 😀It must decrease performance from two reasons.
1. we must run synchronization mode (game thread and video thread are synchronized)
2. we look for pixels in big array. Let’s say game has resolution 320×200, this is 64000 pixels, each pixel has two bytes. So we search in 128k big array – every frame. This search is executed for every “trap pixel”.Both operations are time hungry. Is possible skip point 1 and run traps without synchronization mode, but my rough guess is around 5-8% failure if we set one pixel in pixel trap and maybe 50% failure if we set two or more pixels.
That makes sense. SVGA with higher pixel count is more demanding. I’ll run some Quake SVGA benchmarks, and see if there’s a difference (= start Quake, set res to 640×480, them run “timedemo demo3” from console with and without Pixel Trap enabled).
So, I ran the benchmark three times for both configs (Pixel Trap ON & OFF):
Pixel Trap enabled = 13.5 fps / 11.7 fps / 11.1 fps
Pixel Trap disabled = 13.6 fps / 12.7 fps / 9.9 fpsInterestingly, while the best result for both was basically identical, I got the worst result by far running the timedemo without pixel traps. But that was the last benchmark run I did, so all the lower values are obviously just a result of cpu heating. I kept running those benchmarks in rapid succession, and that really squeezed the crap out of my phone. ?
If you want to do some more in-depth benchmarking, you can also try the DOS benchmark suite from Phil’s Computer Lab: https://www.philscomputerlab.com/dos-benchmark-pack.html
Maybe I can speed up point 2, I must do some caching, but I think I can speed it up, but first we should fix all bugs around.
I can do some more testing, still got my S7 edge here. @zebumper is yours an Exynos or a Snapdragon phone?
- You must be logged in to reply to this topic.