Add smooth scrolling to the game. I think this will require running "show_game_area" more often, than usual, so the scrolling would be smooth (like scroll by 4 pixels, instead of the whole tile), but would not break the playability
I noticed that this is currently being implemented but I think that there are some issues with it.
* When the level first starts, the scrolling is slow at the opposite end of the level for a while before speeding up and slowing down on reaching Robbo. Is this slow-fast-slow a feature?
* When watching the demos, because of the above issue/feature the demo is running but Robbo cannot be seen.
* Originally when the user pressed a control the viewport would immediately centre on Robbo (at least I remember it doing so). This was so that when Robbo started to move/shoot you could see him.
* The new smooth scrolling has replaced the original tile scrolling rather than being an option. It would have been nice (even for a short while) to make it an option in-code via a preprocessor directive because at the moment I personally feel as though the tile based system works better due to the above issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There seem to be quite a few more issues as I've just been studying the code changes since last release.
I've noticed that an attempt has been made to make the game less CPU intensive, but there wasn't a problem before and so I'm assuming it's because of the fact that smooth scrolling has introduced an overhead due to the increased screen updates.
* I see that some code has been introduced to temporarily hide the visible pointer control bar but this causes strange behaviour when it is made visible again as it was designed to centre on Robbo in tile units not pixels.
* There're potentially some bugs (I think) where SCROLL_PREC is being compared with 4 since 4 is different when field_size=16 and field_size=32. I think this should be a fraction of field_size i.e. possibly SCROLL_PREC<field_size/8
* Scrolling in 640x480 is very different to 320x240; maybe this is related to the above. 320x240 is not smooth and the fade seems to have speeded up (are there frames missing from the fade?)
I'm going to attempt to add preprocessor directives to seperate the smooth scrolling stuff so that the original tile based scrolling can be preserved. Especially for handheld devices running at 200MHz with small screens I think it is a good thing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, my idea is to create a menu entry, that would configure the scrolling.
temporarily I added SCROLL_PREC constant, but in the end it will be a variable. Valid values for SCROLL_PREC are 1 - I think this should make GNU Robbo to scroll the old style, 2 - scroll by half of the tile, 4 - scoll by quaters, 8,16,32 - scroll one tile in 8,16,32 (valid only for tile size = 32). I didn't change much, the whole engine, I modified show_game_area, and the meaning of viewport.x, viewport.y fields. now (x,y) point on the board could be calculated as (floor(viewport.x/SCROLL_PREC),floor(viewport.y/SCROLL_PREC)), perhaps I didn't update every place, where viewport.x and viewport.y were used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added a preprocessor directive SMOOTH_SCROLLING and wrapped your new smooth scrolling code within it. Now you can develop this code whilst the original scrolling code continues to function.
neurocyp: I have added a comment within the code (game.c:1580) about how game loops/timing work because you're doing some odd things in there! After the game loop (frame) has completed you are repeating some things that have already been processed within the timing loop! Everything must be done ONCE per frame. You cannot do things one or more times per frame (cycle) as everything becomes out-of-sync and jerky.
Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that I should point out a few things about the GNU Robbo engine which apart from the huge amount of work it's had over the years is pretty much the same as when alus created it back in 2002 :-
The game engine is based around the tile (field_size). Many functions are designed to deal with units of a tile, not pixels, and really the game is simply just a big board game. Because it was me who took alus's original work -- which was just a few files -- and reorganised/re-engineered much of the framework so that it could be scaled up to the point that it is today, I know the project inside out. I have also worked on many other projects including emulators and game engines and so I know that getting GNU Robbo to scroll smoothly is not going to be simple. You see that GNU Robbo runs by default at 25Hz -- 25 cycles per second -- and this isn't exactly the frequency of smooth. 50Hz is smooth for single pixels (my ENG engine ( http://eng.sourceforge.net/ ) runs at 50Hz), and I think that the GNU Robbo engine does have enough spare time to increase the number of screen frames drawn.
There are also some other "issues" which I think you have already experienced. The screen fade function draws another layer of black tiles over the screen because this was the easiest way to add a screen fader to the tile based engine. Ideally a fader would be fading in each icon pixel by pixel, not hiding the icon underneath another fading black layer, but it would be a huge amount of work to make the screen renderer do this and there is/was no point since the engine is so efficient it can easily cope with another layer that briefly fades away over the game. Of course if you attempt to make a smooth scrolling viewport this will require additional screen updates and then you will/may experience lag from the fader. There's also the pointer controls which when visible could either require redrawing the viewport every frame or the entire screen, on top of the fact that the pointer controls are semi-opaque which is CPU intensive to render.
Smooth scrolling is a great idea and it would look really nice, but I think that the engine can only be fractionally smoother, not smooth. If I was going to attempt this I would first try to half the current unit used in the viewport renderer and see what happens. Then you can half it again etc. until you reach the limit. Do this though without rewriting the existing scrolling code else you'll leave a temporarily broken game in SVN and it's not easy for others to work on it.
Goog luck :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed that clicking stopped to work.
Perhaps we should revert the files in the svn, and then we could change SMOOTH_SCROLLING define, so defined would ser SCROLL_PREC to something different than 1,and undefined would turn SCROLL_PREC to 1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Split the functions that you need to make major changes to, like this:
int show_game_area (void)
{
#ifdef SMOOTH_SCROLLING
your code here
#else
original code here
#endif
}
If you only need to make a few simple modifications then it's best not to duplicate the entire function but rather wrap your few modifications inside SMOOTH_SCROLLING directives.
This way the project still functions and can be released even if you fail to get smooth scrolling to work acceptably or make a horrible mess of the engine :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed that this is currently being implemented but I think that there are some issues with it.
* When the level first starts, the scrolling is slow at the opposite end of the level for a while before speeding up and slowing down on reaching Robbo. Is this slow-fast-slow a feature?
* When watching the demos, because of the above issue/feature the demo is running but Robbo cannot be seen.
* Originally when the user pressed a control the viewport would immediately centre on Robbo (at least I remember it doing so). This was so that when Robbo started to move/shoot you could see him.
* The new smooth scrolling has replaced the original tile scrolling rather than being an option. It would have been nice (even for a short while) to make it an option in-code via a preprocessor directive because at the moment I personally feel as though the tile based system works better due to the above issues.
There seem to be quite a few more issues as I've just been studying the code changes since last release.
I've noticed that an attempt has been made to make the game less CPU intensive, but there wasn't a problem before and so I'm assuming it's because of the fact that smooth scrolling has introduced an overhead due to the increased screen updates.
* I see that some code has been introduced to temporarily hide the visible pointer control bar but this causes strange behaviour when it is made visible again as it was designed to centre on Robbo in tile units not pixels.
* There're potentially some bugs (I think) where SCROLL_PREC is being compared with 4 since 4 is different when field_size=16 and field_size=32. I think this should be a fraction of field_size i.e. possibly SCROLL_PREC<field_size/8
* Scrolling in 640x480 is very different to 320x240; maybe this is related to the above. 320x240 is not smooth and the fade seems to have speeded up (are there frames missing from the fade?)
I'm going to attempt to add preprocessor directives to seperate the smooth scrolling stuff so that the original tile based scrolling can be preserved. Especially for handheld devices running at 200MHz with small screens I think it is a good thing.
Well, my idea is to create a menu entry, that would configure the scrolling.
temporarily I added SCROLL_PREC constant, but in the end it will be a variable. Valid values for SCROLL_PREC are 1 - I think this should make GNU Robbo to scroll the old style, 2 - scroll by half of the tile, 4 - scoll by quaters, 8,16,32 - scroll one tile in 8,16,32 (valid only for tile size = 32). I didn't change much, the whole engine, I modified show_game_area, and the meaning of viewport.x, viewport.y fields. now (x,y) point on the board could be calculated as (floor(viewport.x/SCROLL_PREC),floor(viewport.y/SCROLL_PREC)), perhaps I didn't update every place, where viewport.x and viewport.y were used.
Sorry, I meant 8,16,32 - scroll one tile in 8,16,32 steps (and 32 vaule is invalid for tile size<32)
I added a preprocessor directive SMOOTH_SCROLLING and wrapped your new smooth scrolling code within it. Now you can develop this code whilst the original scrolling code continues to function.
neurocyp: I have added a comment within the code (game.c:1580) about how game loops/timing work because you're doing some odd things in there! After the game loop (frame) has completed you are repeating some things that have already been processed within the timing loop! Everything must be done ONCE per frame. You cannot do things one or more times per frame (cycle) as everything becomes out-of-sync and jerky.
Regards.
I think that I should point out a few things about the GNU Robbo engine which apart from the huge amount of work it's had over the years is pretty much the same as when alus created it back in 2002 :-
The game engine is based around the tile (field_size). Many functions are designed to deal with units of a tile, not pixels, and really the game is simply just a big board game. Because it was me who took alus's original work -- which was just a few files -- and reorganised/re-engineered much of the framework so that it could be scaled up to the point that it is today, I know the project inside out. I have also worked on many other projects including emulators and game engines and so I know that getting GNU Robbo to scroll smoothly is not going to be simple. You see that GNU Robbo runs by default at 25Hz -- 25 cycles per second -- and this isn't exactly the frequency of smooth. 50Hz is smooth for single pixels (my ENG engine ( http://eng.sourceforge.net/ ) runs at 50Hz), and I think that the GNU Robbo engine does have enough spare time to increase the number of screen frames drawn.
There are also some other "issues" which I think you have already experienced. The screen fade function draws another layer of black tiles over the screen because this was the easiest way to add a screen fader to the tile based engine. Ideally a fader would be fading in each icon pixel by pixel, not hiding the icon underneath another fading black layer, but it would be a huge amount of work to make the screen renderer do this and there is/was no point since the engine is so efficient it can easily cope with another layer that briefly fades away over the game. Of course if you attempt to make a smooth scrolling viewport this will require additional screen updates and then you will/may experience lag from the fader. There's also the pointer controls which when visible could either require redrawing the viewport every frame or the entire screen, on top of the fact that the pointer controls are semi-opaque which is CPU intensive to render.
Smooth scrolling is a great idea and it would look really nice, but I think that the engine can only be fractionally smoother, not smooth. If I was going to attempt this I would first try to half the current unit used in the viewport renderer and see what happens. Then you can half it again etc. until you reach the limit. Do this though without rewriting the existing scrolling code else you'll leave a temporarily broken game in SVN and it's not easy for others to work on it.
Goog luck :)
Ok, when I get back home, I'll get back to coding:)
I noticed that clicking stopped to work.
Perhaps we should revert the files in the svn, and then we could change SMOOTH_SCROLLING define, so defined would ser SCROLL_PREC to something different than 1,and undefined would turn SCROLL_PREC to 1.
Do this to minimise disruption :-
Split the functions that you need to make major changes to, like this:
int show_game_area (void)
{
#ifdef SMOOTH_SCROLLING
your code here
#else
original code here
#endif
}
If you only need to make a few simple modifications then it's best not to duplicate the entire function but rather wrap your few modifications inside SMOOTH_SCROLLING directives.
This way the project still functions and can be released even if you fail to get smooth scrolling to work acceptably or make a horrible mess of the engine :)