Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10561 - Fullscreen brickmania

Attached to Project: Rockbox
Opened by Clément Pit--Claudel (CFP) - Monday, 24 August 2009, 10:37 GMT+2
Last edited by Karl Kurbjun (kkurbjun) - Friday, 18 December 2009, 05:12 GMT+2
Task Type Patches
Category Plugins
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Version 3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

This patch makes brickmania fullscreen on all targets.

To ensure that it the game isn't easier on DAPs with bigger screens, it recalculates the game and pad speed.

Please, do test it :) I've tried it on all color targets (in sim), but there may still be a few modifications to do.

CFP.

   brickmania-fullscreen.diff (4 KiB) 
 apps/plugins/brickmania.c |   44 +++++++++++++++++++++++---------------------
 1 file changed, 23 insertions(+), 21 deletions(-)

This task depends upon

Closed by  Karl Kurbjun (kkurbjun)
Friday, 18 December 2009, 05:12 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  Thanks.
Comment by Johannes Schwarz (Ubuntuxer) - Monday, 24 August 2009, 15:31 GMT+2
Hi, I like the idea to play brickmania fullscreen on all target, although the difficulty is harder, because the ball change its direction more often.
But it's highly discouraged to use float, because the targets don't have hardware units to do floating point calculation, so it's horribly slow. explanation: (http://www.rockbox.org/tracker/task/10193#comment31618)
Apart from that the patch works fine on my Sansa E200.
Comment by Clément Pit--Claudel (CFP) - Monday, 24 August 2009, 20:00 GMT+2
Here is an integer version. I modified it so that multiplications are done before divisions, by reorganizing the defines.
CFP.
   brickmania-fullscreen-v2.diff (4 KiB) 
 apps/plugins/brickmania.c |   44 +++++++++++++++++++++++---------------------
 1 file changed, 23 insertions(+), 21 deletions(-)

Comment by Karl Kurbjun (kkurbjun) - Thursday, 27 August 2009, 15:07 GMT+2
I really like the idea of this and the implementation looks clean too. I think it would be good if it applied across all screen sizes. I believe brickmania was written for the H300 which has a 220x176 screen. On screens smaller than that the ball movement it too fast, and on screens larger than that it can be much too slow (i.e. the m:robe 500). If this applied to all screens it could really help balance the game so that it plays at a comparable speed across all devices.
Comment by Clément Pit--Claudel (CFP) - Thursday, 27 August 2009, 23:05 GMT+2
Hello Karl,
I'm not sure I got your last comment: I think the patch work an all color targets. I haven't however, tested on other targets. Did you mean there was targets where the calculation wasn't right?
Thanks,
CFP.
Comment by Karl Kurbjun (kkurbjun) - Friday, 28 August 2009, 00:07 GMT+2
Sorry, I was not clear. The patch is setup so that the HEIGHT_DELTA only effects targets that have a larger height than width.

As an enhancement across all targets I think it would make sense to have PAD_MOTION dependent on the the overall screen height regardless of whether the screen is portrait or landscape.

With a screen height of 176 PAD_MOTION should calculate out to 8. As the screen height increases or decreases the PAD_MOTION should scale with the screen height.

So, for example the PAD_MOTION calculation could be 8*SCREEN_HEIGHT/176. This would make is so that the ball speed would scale across all screen sizes. HEIGHT_DELTA could then be eliminated, CYCLE_TIME should probably stay at 50, but if needed it could scale similar to PAD_MOTION.

This would eliminate the need for the screen height checks below:
/* Calculates the delta between a 4/3 ratio and the actual ratio */
#if LCD_WIDTH<=LCD_HEIGHT
#define HEIGHT_DELTA (LCD_WIDTH * 3) / (LCD_HEIGHT * 4)
#else
#define HEIGHT_DELTA 1
#endif

Then the defines might look something like this instead:
#define CYCLETIME 50
#define PAD_MOTION (8*SCREEN_HEIGHT/176)

#define GAMESCREEN_HEIGHT LCD_HEIGHT

If the cycle time needs to be scaled that could be changed too, but I think just changing the ball speed should be adequate.
Comment by Clément Pit--Claudel (CFP) - Friday, 28 August 2009, 10:05 GMT+2
Ok I got it :)

In fact, CYCLETIME affects both the ball speed and the pad speed: it affects the overall speed of the game. This is why I change it. Then, I apply a corresponding change to how much the pad moves per cycle (that's PAD_MOTION, in pixels), so that so that in the end the pad speed remains the same.

I've tried a few solution to implement what you suggested: I've attached a spreadsheet to demonstrate a few formulas. In fact, the best solution (IMO) is to just use the same calculation as I already did, however without taking into consideration the fact that LCD_WIDTH would be less than LCD_HEIGHT. It gives pretty good results I think.

Scaling the game speed in regards to the H300's size is another good solution, which in fact addresses the problem that currently (in SVN) brickmania isn't faster on larger screens.

To conclude, there are two good solutions:
1. Do not address the "speed should be proportional to the screen size problem". See patch v3-0.
2. Do address the aforementioned problem. See patch v3-1

I'd rather go for not addressing the speed issue, but there is no real reason for this :).

CFP


   brickmania-fullscreen-v3-0.diff (3.8 KiB) 
 apps/plugins/brickmania.c |   41 +++++++++++++++++++----------------------
 1 file changed, 19 insertions(+), 22 deletions(-)

   brickmania-fullscreen-v3-1.diff (3.7 KiB) 
 apps/plugins/brickmania.c |   38 ++++++++++++++++----------------------
 1 file changed, 16 insertions(+), 22 deletions(-)

   brickmania-scaling.xls (7.5 KiB)
Comment by Karl Kurbjun (kkurbjun) - Saturday, 29 August 2009, 03:11 GMT+2
Ah! I missed how you were increasing the difficulty, I mistook it for speeding up the ball and the pad. Here is what I have for a patch in terms of what I was originally thinking. It definitely makes the gigabeat harder when it uses the full screen. The portrait view seems disproportionately difficult though.
   fulldiff.diff (7.1 KiB) 
 apps/plugins/brickmania.c |   71 +++++++++++++++++++++++++++-------------------
 1 file changed, 43 insertions(+), 28 deletions(-)

Comment by Clément Pit--Claudel (CFP) - Tuesday, 01 September 2009, 08:37 GMT+2
Hmmm, I was wondering why your patch wouldn't work. I saw you commited the patch this morning. What I don't get though, is that your implementation scales the speed only according to the screen height. It means that the speed will be the same on a 320*240 screen and on a 180*240 screen ? The the game will obviously be easier on the latter, since the screen in narrower and yet the speed is the same.
Comment by Clément Pit--Claudel (CFP) - Tuesday, 01 September 2009, 09:11 GMT+2
Another attempt at scaling the speed in a better way.
   brickmania-fullscreen-v4.diff (2.1 KiB) 
 apps/plugins/brickmania.c |   32 +++++++++++++-------------------
 1 file changed, 13 insertions(+), 19 deletions(-)

Comment by Karl Kurbjun (kkurbjun) - Thursday, 08 October 2009, 02:24 GMT+2
Sorry for the lack of response on my end, I was writing a significant change to the way that the positions are calculated and collision detection is done. In the process the speed scaling was changed so that it scales by the screen height and width. This should make it so the game takes the same amount of time to go from the top of the screen to the bottom and from the left to the right (and vice versa) on any screen size.

All that I think is left is to change the GAMESCREEN_HEIGHT to be equal to FIXED3(LCD_HEIGHT), but see what you think of the speed and play of the game with that change - if you think it is reasonable I will commit the change. If you think there is anything else that needs to be modified let me know.

Loading...