Session end : 11h59m55s | Hide picture Sexe : OFF | ![]() | ![]() | ![]() | ![]() | Donations 2024 : 679.48 € |
This game of mine was a clear cut copy of Ocean’s 1987 CPC smash hit "Gryzor". I used to play Gryzor a lot. In the end I was even so good at the game that I was able to win it without loosing a single life!
Gryzor was really an amazing game, incredible graphics, great gameplay, just the right amount of difficulty so that it was hard, but still playable, some cool extra weapons, three different types of levels (horizontal fighting, vertical fighting and 3d tunnel levels) and a cool soundtrack.
It was just lacking one thing: scrolling! Unfortunately the game was divided into individual screens. Sometimes going from one screen to another meant instant death, because you ran right into the arms of an enemy soldier or cannon on the new screen!
With this Gryzor clone of mine I wanted to remedy this single drawback about the original game. The primal idea was to create a junge fighting game where the player had to shoot enemy soldiers. But I realized that the graphics I had created looked so much like the original Ocean game that I couldn’t fool anybody about the origin of this idea. I was obviously searching my inspiration a little too hard in the original game...
Anyway, the scrolling I’ve created was just a simple software scrolling with double buffering, so that it didn’t flicker too much. I also made a conceptual error with inserting the new graphics at the right end of the screen, so that every time the screen was moved by one byte to the left the last column on the right came out to be an exact copy of the last but one column. This was due to the fact that I had the computer insert the new column on the right hand side of the screen and move the screen afterwards. I should have done it the other way round...
But this wasn’t the real problem I had with this game. I ran into similar problems like in "The enchanted forest" when it came to finding out where the character was allowed to walk on the screen and where he couldn’t walk or stand. Since I wasn’t able to think of an easy way to test that in the memory I tried to devise a method so that I could find out on the screen whether the character can walk on the next byte or if the road is blocked or ends there.
Since the graphics was very colorful there wasn’t a distinct two-pixel combination (a Mode 0 byte) that I could use to define as ground. I tried to mark the walkable parts on the screen with a brown colored byte. That meant that I would have to change the palm trees in the graphics so that they didn’t contain bytes with two brown pixles anymore, but I was willing to accept that change.
The first tests with this brown walkways on the screen were promising. The program was able to determine where the character was able to walk and where he couldn’t walk. But marking all the walkable parts on the screen with brown bytes looked really stupid. Also finding out where the next brown byte was on the screen took a lot of time. So when I used that walkway identification routine with the software scrolling it was so slow that the guy on the screen was continuously wobbling left and right.
Since the game was already very slow and at that time I didn't have the means or knowledge to create a faster scrolling I soon started to divert my attention to other programs and demos. Thus this Gryzor clone grew to become another unfinished project in my CPC career...
Of course I had already created a map editor with which I was able to draw the landscape that was being scrolled on the screen in the test version of the game. With this editor I was able to select one of several background elements and insert it in one of the three height levels that were used in the game. Since this background elements were very large the combination possibilities of these elements were rather limited.
At that time I obviously had a lot of leisure time. The editor was a regular BASIC-Assembler mix, i. e. the background elements were painted on the screen with an Assembler program, the keyboard input and the loading and saving of data was done in BASIC.
Every time I started the editor a very slow BASIC algorithm added some colored points to the "Landschaft Editor" text on the top of the screen. It took a minute or two to change the points in the whole text, but obviously I had enough time to wait for that algorithm to get finished when I wanted to change the map for the demo. I'm a lot less patient nowadays and was very happy that Caprice had an option to run the CPC Emulation with more than 100% speed.