• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.3
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by CFP - 2009-08-24
Last edited by kkurbjun - 2009-12-18

FS#10561 - Fullscreen brickmania

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.


Closed by  kkurbjun
2009-12-18 04:12
Reason for closing:  Accepted
Additional comments about closing:  


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: (
Apart from that the patch works fine on my Sansa E200.

CFP commented on 2009-08-24 18:00

Here is an integer version. I modified it so that multiplications are done before divisions, by reorganizing the defines.

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 220×176 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.

CFP commented on 2009-08-27 21:05

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?

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 */
#define HEIGHT_DELTA 1

Then the defines might look something like this instead:
#define CYCLETIME 50


If the cycle time needs to be scaled that could be changed too, but I think just changing the ball speed should be adequate.

CFP commented on 2009-08-28 08:05

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 :).


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.

CFP commented on 2009-09-01 06:37

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.

CFP commented on 2009-09-01 07:11

Another attempt at scaling the speed in a better way.

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.


Available keyboard shortcuts


Task Details

Task Editing