Frogger game development for Vectrex computer
Some time ago I was translating the story of Chris Salomon about his development of the Frogger game for the Vectrex computer . That story, written by him in 1998, is, in my opinion, a very interesting document, allowing you to feel the spirit of this unusual platform, and the specifics of development in assembly language in general.
Chris did not abandon Vectrex and, relatively recently, brought to release his own Vectrex emulator for Windows (the best at the moment) called “Vide”. By the way, I am pleased that my Electric Force sources helped him to implement decent support for displaying vector curves in this emulator.
And now, having received such a powerful tool, Chris could not deny himself the pleasure of returning to his old Frogger to refine and improve it. He told about it in his blog .
')
Thus, here I publish two parts of my translation - the first, about the original development of 1998 (from the file progger.txt , wandered along with the source of the game) and the second - about its continuation (from the author’s blog ).
This file contains notes that may be of interest to other developers under Vectrex.
It also includes a “brief” history of the development of the Vectrex Frogger.
Image update in Vectrex Frogger always occurs at 50Hz. Everything is drawn no more than 30,000 cycles. Below are some notes about optimization techniques that allow this to be achieved.
Actually, I am very much a city achieved speed! It is possible that my functions for working with sprites are the fastest of all existing in games under Vectrex (at least, I like to think so ...)
Sprites look a bit strange on a real Vectrex - slightly "spotty", however, you can get used to it. They are spotted because I used for each of them a fixed scale (scale) 6. Long lines had to be made up of shorter ones. Vectrex, by its nature, does not always turn off the beam when needed (two or three clocks later than necessary). And it always turns on the beam for a few bars before starting drawing ...
This leads to a bright point (it would be possible to write new functions for drawing vectors that do not use a timer and calculate time differently, more precisely, but who wants to do this?).
Vectrex Frogger, among other things, was supposed to serve as a well-documented program for teaching programming on this computer. It seems to me that I could not do it.
Because of the gigantic number of vectors that had to be rendered in tiny intervals, it was necessary to optimize each beat. Because of these optimizations, it seems to me, the program has ceased to be well read. In the main loop, the call remains for a single BIOS function (polling the status of the digital joystick).
All other calls were successively deleted and replaced by optimized (for specific situations) macros or subroutines.
It is extremely difficult to grasp all this, unless you wrote it yourself.
One of the applied optimization techniques:
Explanation of how to draw a vector.
...
Anyway, to move the beam to the desired position, you specify its speed, direction and time during which this speed is applied. Then wait for that time to expire.
Time is the scale you set. If you set the scale to $ 90, this value should be written to timer 1 (VIA_t1_cnt_lo. Approx. Lane) and then, in a “useless” cycle, it is expected when it expires.
What I did was make this cycle useful. A significant part of the computation is done at Vectrex Frogger just at this, usually useless, time.
I used this approach mainly when moving the beam. A big plus here is that no matter how much I did at this time, it does not affect anything! The only thing you have to watch out for is not to occupy time LESS than the timer value. However, this is easily solved by the same timer polling cycle (VIA_int_flags - approx. Lane) at the end of your calculations.
The same approach can be used while drawing a vector. Drawing and moving a vector are the same. The only difference is the “pattern” written to the shift register. 0 is written to move there, $ FF for drawing (unless, of course, you want to draw a solid line).
However, when drawing, you need to make sure that you turn off the beam (by writing 0 to the shift register) on time. Otherwise, get a bright dot at the end of the vector!
Another optimization method was to write a special function (macro) for drawing a list of vectors. Each beat won there was worth its weight in gold.
Suppose I print 30 sprites and each sprite consists of, say, 20 vectors. This is about 600 vectors. If I write an optimized function that will save about 10 cycles per vector, we will win about 6000 cycles with one blow !!!
And yet - the unfolding of cycles! In fact, I used this approach all the time with my programs on Watcom C, but I never thought that I would implement this myself. Today I tried my luck by expanding the function of drawing the list of vectors. Luck! I won more than 10 cycles per EVERY vector. This gave me another acceleration of almost 3000 clock cycles! I spun only one cycle - the main sprite drawing cycle.
The other important cycle of drawing sprites (for sprites of houses) would remain intact, although if I had optimized all the cycles in this way, I would probably have won between 500 and 1000 cycles. But there is also a negative side - it makes the program much longer. Well, we can't get everything, can we?
Another technique has not been used, since it seems no longer necessary:
The implementation of a new type of vector list, which would include information about the scale, can give a gain of several cycles, since many long lines would now be drawn short. This can reduce losses if the list includes a second variable for length.
By the way:
The assembler that I used is VERY good. For optimization, be sure to look at the * .lst file created by it. It contains not only the code, but also the number of cycles for each instruction and their length ... True, very cool)
A little about object definitions (specifically for the subroutines used in Vectrex Frogger):
All items displayed in the game are now called objects. These objects consist of two different entities - a list of vectors and an object structure definition. The list of vectors is common for Vectrex. First comes the number of vectors (minus 1), then the relative coordinates of the vectors (displacements).
To facilitate collision fixation, all of these vector lists should start from the leftmost point. In the earlier version of the subroutine, they should have been necessarily closed, but this is no longer required.
The following is an example of the structure of an object (taken from Vectrex Frogger):
Sprites are drawn with a fixed scale of 6 (this may change in future versions - I am thinking about a new list of vectors that will include information about the scale).
Due to the highly optimized drawing routines, this cannot (and should not) be changed. In fact, the subroutines are so optimized that they no longer draw exactly what they need.
There are two problems:
Emulator Notes:
Vectrex Frogger normally works on an emulator (here we are talking about DVE - approx. Lane), however :
Optimization was done using this Vectrex, the emulator can not yet cope with some of the small things that are needed to verify the code. They work fine as they are now. But if you yourself will optimize something, you need a Vectrex - you will be upset, if on a real hardware everything works completely differently. Especially it concerns exact observance of time intervals.
The emulator does many things immediately, while a real Vectrex takes time. For example, this is true for zeroing the beam and accessing any VIA register ...
There are many interesting exponential functions for viewing on the screen of your Vectrex-a)
(such as charging and discharging integrator capacitors).
My programming history is under Vectrex and, in particular, Vectrex Frogger.
I first became interested in Vectrex in 1983, but I didn't have the money to buy it. In 1996, I thought that I could test my skills as a programmer and write a Vectrex emulator. However, Kate Wilkins thought in the same direction. He laid out his source at the moment when I had only the first sketches of my emulator, so I threw them and began to look at the sources of Keith.
Over the next 2 years, I improved his emulator in some aspects and I think that I now, like, am responsible for it.
A few months ago, I thought it would be fun to turn DVE into Vectrex development environment, as it seemed to me that emulation was now good enough for this (although I now know that it’s not and may never be the case unless the Pentium III 500 MHz is released soon, and at an affordable price).
Once again, I looked at the Internet for everything related to Vectrex programming to figure out what a programmer would need.
Found quite a few. A bit of disassembled game images, however, well documented. Something from Clay and John, although I would not say that it is well documented (especially yours, John). There was no “real” programming information. So I decided that I had to figure it out myself.
Somehow, one day, I sat down and tried to write my first game for Vectrex - VPONG. It was written in about 4-5 hours and worked surprisingly well for a beginner, although it does not mean achievements in terms of playability (there is one player and it is rather difficult to play). However, all that was needed was sound, vectors, text, joystick, buttons, scaling, fading, etc.
The following week, the idea of ​​a Vectrex Frogger came to my mind, from which the first prototype of the sprite engine was born. Then I made a “discovery” that scaling with large values ​​is a bad idea.
I thought about the speed of my program and the goal was one update (hereinafter we are talking about the complete rendering of one conditional “frame” - until the next Wait_Recal call. Appro. Per.) At least 70,000 cycles, otherwise I would quit. I figured that if this happens in 70,000 cycles, the refresh rate will be more than 20 Hz - i.e. with an acceptable shimmer.
At that time I already had Vectrex, but it was not connected to the parallel port of my computer yet (and well, as if I had figured out the connection then, I would have abandoned the whole project rather quickly).
Experimenting with scale values, I learned that large values ​​cause updates to last more than 100,000 cycles. Further checks revealed that small values ​​work fine and I came up with about 50,000 ticks (by the way, the fact that I was responsible for the emulator sometimes helped a lot. I wrote an emulator function to measure the number of ticks - it was enough for me to type 'rc' and issued cycles required for updating)
(now it’s quite clear that the scale actually affects, because this is a timer ... but then, knowing this too, I really didn’t know what that meant).
In any case, I had in my hands a working sprite engine and all sorts of strange vector drawings moving across the screen in the manner of a frog. My routines for working with sprites already supported animation, however, after making two or three sprites, I was completely tired of it. Drew sprites in pencil on paper and translated coordinates into coordinates for Vectrex. To do this for a heap of sprites - full! $ "$" &! "$ & = (!!!
Fortunately, I found a friend who was looking for something to do and convinced him to make a small program for drawing vectors that saved coordinates in a way that I could easily work with in my program. James (my friend) made such a program, and I was in charge of the main program.
Pretty quickly, the joystick and collision detection routines were arranged.
The first version of Frogger (initial levels) could be played after three days of programming, although you could not enter the house and no other special features were implemented.
Again, I was a little tired of doing sprites. I thought about some of the sub-programs even on the bus on the way home from work. Subroutines that I generously dubbed "morphing routines."
I had the idea that one list of vectors could slowly be changed into another, and that the result would be a cool effect. I thought about this a bit and found that in 6809 there was no DIV instruction, and MUL was unsigned.
I wrote two such functions and two (still existing) morphing routines (setup and do_one_step). Oh, they were very slow - for dividing and multiplying many times per frame through handwritten subroutines I had to pay dearly, I tell you. Soon, I replaced the divide function with an optimized version that worked as it should.
So far, I had a morph function that could morph in any (8 bit) number of steps. But it was still too slow for practical use. After numerous optimizations, I came to the morphing function with a fixed number of steps - 16. This is the function that is used during the launch of the game and in some intermediate episodes.
Having finished with this, I switched to sound. I was always interested in what notes were what, until finally I figured it out (meaning BIOS-related Vectrex-a). I can't read music and I am anyone, but not a musician.
Having searched the Internet for notes of “The yankee doodle”, I could not find anything. It all ended midi file. Then I started looking for a midi player / editor. As a result, I found one that displayed the notes of a melody in a readable form. In the end, I “wrote” the yankee doodle music for Frogger.
For me it was a great feat, really !!!
In the beginning, I wanted the drum set theme, but it sounded pretty bad. In the way that the melody is played now, three voices are used, with an octave shift in each. It sounds so normal to me - in any case, I can’t recognize errors :-(
Now it's time to add a couple of details. This was what I was afraid of, because it meant entertainment with already ready code and the introduction of new things into it (of course, filled with bugs). New items were flies, crocodiles, snakes, girls, a timer, a clock, an otter, floating turtles ...
I programmed them all with my eyes closed, but I didn’t like a single minute of this activity. To tell you the truth, I hated it. However, these were things that I had to do in order for Frogger to be Frogger. These damn games with idiotic time variables when flies appear, checking the coordinates again and again, if the frog is close to the snake's head, etc. ... I couldn’t tolerate it.
But as you can see, I did it. However, everything has its price. Frogger became slow - he again became close to those 70,000 bars.
At that time, I just received a cartridge with an EPROM for my Vectrex-a and running several different games, found that slow games flicker a lot :-(. I really did not like it. I still could not transfer my Frogger to Vectrex, because the ordered PROM emulator has not arrived yet, but I had several PROMs and I looked at them ...
At that moment I was very worried about how Frogger would look on a real Vectrex, but I could not find anyone with a programmer.
However, I realized that Frogger, as it is, was too slow, so I started thinking about optimization and trade-offs. The first thing I did was delete the scoring of points, lives and the level indicator from the main screen. Can you believe that one call to this idiotic 'print string' function takes more than 10,000 clock cycles !?
Next, I edited all the sprites, trimmed them so that no more than 20 were used, but only 10-15 vectors, which resulted in a gain of about 10,000 strokes (I could not bear to edit all these sprites again!)
(by the way, the turtle you see in the scrolling text is the ancestor of those turtles that crawl in the game itself).
After that, I was sure that I could achieve my timing goal. This goal has now become the rendering of each frame within 50,000 cycles, since all the measurements made on commercial games available to me meant that this value was reliable, and some games even went beyond its limits.
(Still waiting for the PROM emulator ...)
Since so far there was some free time, I decided that it would be good to implement the scrolling text. Having a nearly finished frogger with ten lanes of moving sprites, I figured that making one strip of moving letters wouldn't be too difficult. And indeed, after drawing all the letters 3 or 4 times (the vector drawing program had a serious bug) and after spending a certain amount of nerves, I got rid of it.
However, now there is a new problem. Vectrex has so much RAM! (One kilobyte. Approx. Lane.). Having information about levels and sprites, the need to store many other variables in RAM, do morphing and still have scrolling text - this was another challenge. I changed the distribution of the RAM cells and began to use some of them twice and three times. This was also done, although I later thought that Vectrex programming was still easy at the time.
(Still waiting for the PROM emulator ...)
So I just waited and the time went without any changes in the code.
For a couple of weeks, I didn’t do anything, because the final check was to be done on a real Vectrex.…
Finally he arrived, connected and ... does not work (
I checked something ... Yes, it works, but the only PROM cartridge that I had had addresses only up to 8K, and Frogger had already exceeded this size by that time, so I couldn’t play my game (
(although, I played almost all the other games for the first time).
Since I myself do not understand electronics and do not know how to remake a cartridge so that it works with a 16KB (or 32KB) PROM, I loudly called for help. John heard my screams and sent me a couple of PROM cartridges that worked perfectly (it took another two weeks).
The ability to have access to 8Kb for starters was also not so bad, so I was able to split the Frogger into a couple of parts and check them one by one. Although it did not allow to evaluate all the features of the game, it is quite enough for partial verification.
Here I discovered a strong wobble effect that the emulator could not reproduce. After studying the issue, I realized that it was related to timings. The reel was, for the most part, noticeable at startup. And only when “motionless” vectors were drawn, animated or moving, somehow acquired something of an immunity type to this (strange?)
Anyway, having caught a few gray hairs, I figured out that if the frame update takes more than 30,000 cycles, the fixed vectors start to wobble (at least on my Vectrex-e). This concerned not only my game, but almost all games that had motionless vectors anywhere and required more than 30,000 frame updates.
This was true even for Minestorm - the game built into Vectrex. When the game was launched, after a few seconds, when the first mines appeared on the screen, the points were reeling (of course on my Vectrex, since I could only check on it).
As soon as you know what this effect looks like, you begin to detect it quite often.
Needless to say, I, as a perfectionist, did not like this at all.
Other games can stagger as they please, but not my game. And certainly not on the start screen that you see when you launch it.
I still do not know what causes this effect - any technical information on this topic is welcome. I thought that the only thing that would happen if the update took too much time was flickering. But even if I set the “recalibration wait time” timer to more than the standard 30,000 clock ticks, the value, fixed vectors GO! (usually the value of this timer is initialized when Vectrex is turned on and checked in Wait_Recal so that all the “frames” take at least 3000 clock cycles. Approx. I think there is a second “fixing” value, somewhere in the region of 50,000, but the flickering is unacceptable.
I changed the code so that the inscription 'VECTREX FROGGER' and everything else did not appear on the screen at the same time (this stupid text also requires about 5000-6000 cycles for drawing). Reel (at start) is gone.
But now I have found another effect ((which can still be seen on the present Vectrex, since I could not fix it in any reasonable way). The coordinates always drift slowly to +, + (up to the right).
If you leave the beam alone for quite a long time, it will go up to the right. Drawing a large frog at the beginning of the game by traversing a large list of vectors using a large scale is quite long. To completely draw a giant frog, it takes about 2000-3000 cycles. During this time, the beam floats about half a centimeter. It is necessary to recalibrate the ray between the renderings, which would solve the problem. But there is not enough time for this :-( (the frog consists of 63 vectors, and the positioning of 63 vectors at a given scale is impossible in no way that would not be time critical!
(63 * $ 90 = 9000 net time of movement of the beam, without overhead
63 * $ 70 = 7000 net time drawing vectors, no overhead
overhead = 1000 cycles. This is about 17,000 cycles only for a frog. And I also wanted a scrolling text, plus the morph of the frog should be short!)).
In addition, a fixed offset cannot be specified because the said drift is not constant. It depends on the mood of my Vectrex (after all, this is an old analog machine). So, the frog looks good on the emulator (if there is no drift in it), but on the real Vectrex, its tip is lost. It bothers me a little, but cannot be fixed easily!
Apart from this, everything seems to work just fine. I spent a couple of weeks without doing Vectrex Frogger (and I didn’t miss him very much - after working for a while, I was happy to leave him, after all, alone).
One day, John's cartridges finally arrived.
I tried Frogger ... And he earned !!! (disgusting :()
Somehow, I avoided this before, but there were also motionless "wobbling" vectors in the game itself. And they WENT :-( At that moment I was ready to quit everything. I was glad that I had achieved the goal of 50,000 cycles, considering that I wanted 70,000 at first. However, this was far from enough. To get rid of the reel, there was no other way than to achieve 30,000 cycles (in fact, this can be understood from the source Wait_Recal in the BIOS. Approx. Lane.)
For some time I experimented to get rid of fixed vectors, inventing “moving” houses, dotted lines, etc. But it almost did not help. I was ALL upset. My friend tried to console me by saying “this is not so bad,” but from my point of view it was bad. I wanted to make a full-fledged full game of Vectrex Frogger WITHOUT compromise with "reel".
I was thinking of changing all the sprites again in order to reduce the use of vectors, but this would lead to sprites as in the Atari 2600 - more guessable than distinguishable. So, I refused this idea.
Here I first tried to use the DP register (which was always always set to D0). Its more or less reasonable use, together with other optimizations, saved me from 1,000 to 2,000 bytes of code. This allowed me to again transfer some BIOS functions to my code and optimize them. I won another 10,000 cycles and reached 40,000, but I wondered what else could be optimized.
Step by step, going through the code and looking at the * .lst file created by the assembler, I looked for bottlenecks in critical areas ... I did this for a day and a half ... moving in small steps and saving 10-20, sometimes even 100 cycles, I reached about 37,000. a long way and every next step was harder. I need a break ... I
played Diddy Kong perfectly on my N64 (yes, I have other consoles besides Vectrex) and I got the idea ...
Why not use the wait cycles in the beam positioning and vector drawing functions for something more useful than just waiting when the timer expires?
Said and done - after two days of hassle, the implementation of too fast functions, the appearance of exhibitors on the Vectrex screen, strange effects and ... and ... and ... I saved 5000 more ticks! (it was easy to say, but pretty much spoiled my nerves - see the source for details).
Anyway, I was at 32,000 (this is at worst - with four houses occupied, a girl, a crocodile, an otter and snakes on the screen ...)
After that, I couldn't think more about all these optimizations. I edited all levels, changed them, deleted sprites, rearranged sprites, turned off all sorts of chips, ..., etc., although the levels still had the character that I asked them at the beginning, despite the fact that most of them changed slightly . In the end, I did it!
EVERY LEVEL UPDATED LESS THAN 30,000 TAKTS !!!
I really am very proud of my achievement. And now I consider Vectrex Frogger an outstanding program for Vectrex.
Perhaps this is just vanity on my part, but I put a lot of effort into Vectrex Frogger and hope that people will enjoy the game, and some may find the source useful and / or instructive.
STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP
Another optimization success! Today I spun a couple of cycles, which gave a speed gain of about 3000 clock cycles! Hip-hip hooray! I rolled back the changes of all levels and they still do not require more than 30,000 cycles ...
Now I even have about 1500 cycles in stock :-)
FINISHING THE FILE (Finally)
... this week I began to program Frogger closely. In my plans:
In recent weeks, I occasionally edited separate lists of vectors in Vide, but only this week I collected them together and transferred them to Frogger (see the gif).
I had to change the original source more than I expected, because the player's sprite had no animation. And entering the old source code, which is already 18 years old, did not simplify the matter either.
One way or another, as you can see, an animated frog from the top-down view is implemented.
As I wrote earlier (almost 20 years ago, I remind you), one of my main tasks was to keep within 30 thousand cycles in order to avoid image oscillations. Since I now wanted to add additional features, I had to peer into the code again.
I changed and tightened up the part that generated the lists of vectors, until it became mega-efficient. True, the first level of the game (the most loaded) began to be drawn in just 22 thousand clock cycles!
One problem - the graphics were of the same type as before - “typical” Vectrex'a vector graphics, when you often see a “point” at one end of the line, because the beam ignites too early.
Voila!
Look at the new frog: isn't he beautiful?
Although I did it myself, but still extremely excited about how vectors without dots look)
For those in the subject:
Needless to say that, despite the fact that the Vide is a very good emulator, this kind of experiments with precise time keeping require this Vectrex.
Another great news is that it looks like this code works flawlessly on all three of my Vectrexes.
And finally, some videos - the first steps as a level in slot machines (however, as you can see, the transitions are not completed yet).
I added a dispatcher to Frogger’s code. The old code for MoveTo-InBetween is called from the dispatcher. The dispatcher uses subroutines so, theoretically, clocks are spent on JSR and RTS, but the code looks so much nicer that I left it as it is (since I didn't really need extra clocks). YM decoding [music, note] is done through the controller - I broke the decoding into 9 parts, each of which is independent of the others and they are called in different parts of MoveTo. Thus, YM decoding uses almost no extra clock cycles. Almost finished editing sprites for the top view (see picture) - the sprites of two different cars, a van, a racing car and a tractor more or less resemble the originals.
In general, lists of vectors are about a third longer than those that were before. Although, I think it is now drawn about 40 vectors more than in the original Frogger for Vectrex. I counted only drawn objects, but in some scenes the number of vectors matters. The tractor alone consists of 26 individual vectors. For Vectrex this is a giant number.
I also improved the playability somewhat by slightly stretching the game area. Frogger is now not so easy to go beyond the borders. It was very difficult to get to the far right house. Now jumping a little slower (because of the animation) and it is even more difficult. However, adding animation was a good idea. Jumping feels more like a frogger than it used to be.
It is necessary to test a lot more gameplay, make sound effects and other things, but things are going well with the new version.
Frogger again. Twice I checked the first 7 levels and changed their structure to reflect the changes made in the sprites. Measurements in the Vide showed that Frogger again became a little slower - the 7th level with 4 occupied houses requires about 32 thousand cycles. Damn - I will have to fight again for tact - I thought it was over. If you look at the available resources, I’ve got a lot more behind me now than when I went to the university (look at the picture on the right - this is a self-made slot machine based on MAME - guess what Frogger is :) [here’s an intrigue, see further - approx. lane.] Having gone beyond the limit of 30 thousand clock cycles, I no longer consider the possibility of adding a display of information about records during the game and this worries me!
Below is another example of the current Frogger gameplay. I think I will add the missing sound effects last - when I double check and correct the levels.
It feels like I'm moving back in time.
Just finished optimizing the code, winning about a thousand more cycles. However, I can not think of what else can be done. I have to save about a thousand more cycles (in the most difficult levels).
By optimizing the code, I can’t get it anymore, so I’ll be editing new sprites - change them slightly. 26 vectors per tractor (for example) - not a ride.
I calculated that each drawn vector uses about 50 cycles.
In the most full levels, I need to save 50 vectors.
Since about 20-25 objects are displayed, I have to shave about two vectors from each of them - this should be doable :-)
After each level will again fit into less than 30 thousand, I will do the rest of the effects, then it will all really look and feel like Frogger. You also need to lick the "intermission" and make a better screensaver ... and, voila, I will finish somewhere in 2017 ...
A small report on the progress in the work on the new version of Frogger.
Almost done!
Probably I'm still fixing something, optimizing and improving, but adding features is complete.
Compared to the original Vectrex Frogger, the following things have changed:
Also deleted:
So far I have been wondering whether it is necessary to change the levels so that they look more like the “original”. In the original Frogger (from slot machines), two adjacent strips of water moved in the same direction - this I have not yet taken into account. So, the stripes above are felt differently.
Anyway, enough talk ... Here is a ten-minute video of the current version:
I stopped working on the source code and decided that there would be no new version of Vectrex Frogger.
Due to certain circumstances, which I will discuss below, Vectrex Frogger is dead and the only available version will be the one I did 18 years ago.
Why am I not going to work on it anymore?
- Everything is complete!
Except for possible bug fixes.
Why not be a new version of frogger?
- Because I decided to rename it.
I know frogger is a popular name. However, to be honest, not one Vectrex game will reach the glory of the original.
And, although the game on which I was working inspired Frogger, this is definitely another game!
So I decided to change the working title to the final one:
This title probably doesn’t tell you anything, but in the early 1990s I wrote a game under DOS, which was called that way.
(see: Karl Quappe - DOS , or, on an older page: Karl Quappe - AOL )
For readers who do not read German, the same title information as on the AOL page:
“KAULQUAPPE” translates as “Tadpole”, “QUAPPE” is short for tadpole, and KARL is just a name similar to “KAUL” (homophone). So, if you want to translate it, for example, into English, you will get something like “CHARLES POLE” (Charles - English version of Karl) or Tedpole ('Ted' - a name that sounds like 'tad') '
Next is another short video. There are no big changes, just something polished. I let the game run itself - did not touch the buttons, so the gameplay that you see is a demo mode.
Enjoy!
Chris did not abandon Vectrex and, relatively recently, brought to release his own Vectrex emulator for Windows (the best at the moment) called “Vide”. By the way, I am pleased that my Electric Force sources helped him to implement decent support for displaying vector curves in this emulator.
And now, having received such a powerful tool, Chris could not deny himself the pleasure of returning to his old Frogger to refine and improve it. He told about it in his blog .
')
Thus, here I publish two parts of my translation - the first, about the original development of 1998 (from the file progger.txt , wandered along with the source of the game) and the second - about its continuation (from the author’s blog ).
Year 1998. Start
This file contains notes that may be of interest to other developers under Vectrex.
It also includes a “brief” history of the development of the Vectrex Frogger.
Image update in Vectrex Frogger always occurs at 50Hz. Everything is drawn no more than 30,000 cycles. Below are some notes about optimization techniques that allow this to be achieved.
Actually, I am very much a city achieved speed! It is possible that my functions for working with sprites are the fastest of all existing in games under Vectrex (at least, I like to think so ...)
Sprites look a bit strange on a real Vectrex - slightly "spotty", however, you can get used to it. They are spotted because I used for each of them a fixed scale (scale) 6. Long lines had to be made up of shorter ones. Vectrex, by its nature, does not always turn off the beam when needed (two or three clocks later than necessary). And it always turns on the beam for a few bars before starting drawing ...
This leads to a bright point (it would be possible to write new functions for drawing vectors that do not use a timer and calculate time differently, more precisely, but who wants to do this?).
Vectrex Frogger, among other things, was supposed to serve as a well-documented program for teaching programming on this computer. It seems to me that I could not do it.
Because of the gigantic number of vectors that had to be rendered in tiny intervals, it was necessary to optimize each beat. Because of these optimizations, it seems to me, the program has ceased to be well read. In the main loop, the call remains for a single BIOS function (polling the status of the digital joystick).
All other calls were successively deleted and replaced by optimized (for specific situations) macros or subroutines.
It is extremely difficult to grasp all this, unless you wrote it yourself.
One of the applied optimization techniques:
Explanation of how to draw a vector.
...
Anyway, to move the beam to the desired position, you specify its speed, direction and time during which this speed is applied. Then wait for that time to expire.
Time is the scale you set. If you set the scale to $ 90, this value should be written to timer 1 (VIA_t1_cnt_lo. Approx. Lane) and then, in a “useless” cycle, it is expected when it expires.
What I did was make this cycle useful. A significant part of the computation is done at Vectrex Frogger just at this, usually useless, time.
I used this approach mainly when moving the beam. A big plus here is that no matter how much I did at this time, it does not affect anything! The only thing you have to watch out for is not to occupy time LESS than the timer value. However, this is easily solved by the same timer polling cycle (VIA_int_flags - approx. Lane) at the end of your calculations.
The same approach can be used while drawing a vector. Drawing and moving a vector are the same. The only difference is the “pattern” written to the shift register. 0 is written to move there, $ FF for drawing (unless, of course, you want to draw a solid line).
However, when drawing, you need to make sure that you turn off the beam (by writing 0 to the shift register) on time. Otherwise, get a bright dot at the end of the vector!
Another optimization method was to write a special function (macro) for drawing a list of vectors. Each beat won there was worth its weight in gold.
Suppose I print 30 sprites and each sprite consists of, say, 20 vectors. This is about 600 vectors. If I write an optimized function that will save about 10 cycles per vector, we will win about 6000 cycles with one blow !!!
And yet - the unfolding of cycles! In fact, I used this approach all the time with my programs on Watcom C, but I never thought that I would implement this myself. Today I tried my luck by expanding the function of drawing the list of vectors. Luck! I won more than 10 cycles per EVERY vector. This gave me another acceleration of almost 3000 clock cycles! I spun only one cycle - the main sprite drawing cycle.
The other important cycle of drawing sprites (for sprites of houses) would remain intact, although if I had optimized all the cycles in this way, I would probably have won between 500 and 1000 cycles. But there is also a negative side - it makes the program much longer. Well, we can't get everything, can we?
Another technique has not been used, since it seems no longer necessary:
The implementation of a new type of vector list, which would include information about the scale, can give a gain of several cycles, since many long lines would now be drawn short. This can reduce losses if the list includes a second variable for length.
By the way:
The assembler that I used is VERY good. For optimization, be sure to look at the * .lst file created by it. It contains not only the code, but also the number of cycles for each instruction and their length ... True, very cool)
A little about object definitions (specifically for the subroutines used in Vectrex Frogger):
All items displayed in the game are now called objects. These objects consist of two different entities - a list of vectors and an object structure definition. The list of vectors is common for Vectrex. First comes the number of vectors (minus 1), then the relative coordinates of the vectors (displacements).
To facilitate collision fixation, all of these vector lists should start from the leftmost point. In the earlier version of the subroutine, they should have been necessarily closed, but this is no longer required.
The following is an example of the structure of an object (taken from Vectrex Frogger):
otter1a_object: DB 0 ; + DW otter1a_sprite ; DB 0 ; SCALE_FACTOR_GAME DB 5 ; DW otter1b_object ; DB -4 ; y 'SCALE_IN_HOME', "" DB 0 ; x 'SCALE_IN_HOME', "" DB $60 ; DB 0 ; Sprites are drawn with a fixed scale of 6 (this may change in future versions - I am thinking about a new list of vectors that will include information about the scale).
Due to the highly optimized drawing routines, this cannot (and should not) be changed. In fact, the subroutines are so optimized that they no longer draw exactly what they need.
There are two problems:
- The last vector in the list is truncated 2-4 bars before the one needed.
- Between objects in the list of objects (not yet mentioned), we always zero the beam (talking about zeroing integrators and setting the beam to the center by calling Reset0Ref - approx. Lane)
This reset is not 100% correct (only 98% or something like that)
In fact, the subroutine is slightly quick. The beam does not have enough time to reach zero (this is in view of the fact that I have already slowed down the subroutine by 4 or 5 cycles, but this is not enough ...), which leads to a slightly noticeable inaccuracy in the positioning of objects.
Emulator Notes:
Vectrex Frogger normally works on an emulator (here we are talking about DVE - approx. Lane), however :
Optimization was done using this Vectrex, the emulator can not yet cope with some of the small things that are needed to verify the code. They work fine as they are now. But if you yourself will optimize something, you need a Vectrex - you will be upset, if on a real hardware everything works completely differently. Especially it concerns exact observance of time intervals.
The emulator does many things immediately, while a real Vectrex takes time. For example, this is true for zeroing the beam and accessing any VIA register ...
There are many interesting exponential functions for viewing on the screen of your Vectrex-a)
(such as charging and discharging integrator capacitors).
Story
My programming history is under Vectrex and, in particular, Vectrex Frogger.
I first became interested in Vectrex in 1983, but I didn't have the money to buy it. In 1996, I thought that I could test my skills as a programmer and write a Vectrex emulator. However, Kate Wilkins thought in the same direction. He laid out his source at the moment when I had only the first sketches of my emulator, so I threw them and began to look at the sources of Keith.
Over the next 2 years, I improved his emulator in some aspects and I think that I now, like, am responsible for it.
A few months ago, I thought it would be fun to turn DVE into Vectrex development environment, as it seemed to me that emulation was now good enough for this (although I now know that it’s not and may never be the case unless the Pentium III 500 MHz is released soon, and at an affordable price).
Once again, I looked at the Internet for everything related to Vectrex programming to figure out what a programmer would need.
Found quite a few. A bit of disassembled game images, however, well documented. Something from Clay and John, although I would not say that it is well documented (especially yours, John). There was no “real” programming information. So I decided that I had to figure it out myself.
Somehow, one day, I sat down and tried to write my first game for Vectrex - VPONG. It was written in about 4-5 hours and worked surprisingly well for a beginner, although it does not mean achievements in terms of playability (there is one player and it is rather difficult to play). However, all that was needed was sound, vectors, text, joystick, buttons, scaling, fading, etc.
The following week, the idea of ​​a Vectrex Frogger came to my mind, from which the first prototype of the sprite engine was born. Then I made a “discovery” that scaling with large values ​​is a bad idea.
I thought about the speed of my program and the goal was one update (hereinafter we are talking about the complete rendering of one conditional “frame” - until the next Wait_Recal call. Appro. Per.) At least 70,000 cycles, otherwise I would quit. I figured that if this happens in 70,000 cycles, the refresh rate will be more than 20 Hz - i.e. with an acceptable shimmer.
At that time I already had Vectrex, but it was not connected to the parallel port of my computer yet (and well, as if I had figured out the connection then, I would have abandoned the whole project rather quickly).
Experimenting with scale values, I learned that large values ​​cause updates to last more than 100,000 cycles. Further checks revealed that small values ​​work fine and I came up with about 50,000 ticks (by the way, the fact that I was responsible for the emulator sometimes helped a lot. I wrote an emulator function to measure the number of ticks - it was enough for me to type 'rc' and issued cycles required for updating)
(now it’s quite clear that the scale actually affects, because this is a timer ... but then, knowing this too, I really didn’t know what that meant).
In any case, I had in my hands a working sprite engine and all sorts of strange vector drawings moving across the screen in the manner of a frog. My routines for working with sprites already supported animation, however, after making two or three sprites, I was completely tired of it. Drew sprites in pencil on paper and translated coordinates into coordinates for Vectrex. To do this for a heap of sprites - full! $ "$" &! "$ & = (!!!
Fortunately, I found a friend who was looking for something to do and convinced him to make a small program for drawing vectors that saved coordinates in a way that I could easily work with in my program. James (my friend) made such a program, and I was in charge of the main program.
Pretty quickly, the joystick and collision detection routines were arranged.
The first version of Frogger (initial levels) could be played after three days of programming, although you could not enter the house and no other special features were implemented.
Again, I was a little tired of doing sprites. I thought about some of the sub-programs even on the bus on the way home from work. Subroutines that I generously dubbed "morphing routines."
I had the idea that one list of vectors could slowly be changed into another, and that the result would be a cool effect. I thought about this a bit and found that in 6809 there was no DIV instruction, and MUL was unsigned.
I wrote two such functions and two (still existing) morphing routines (setup and do_one_step). Oh, they were very slow - for dividing and multiplying many times per frame through handwritten subroutines I had to pay dearly, I tell you. Soon, I replaced the divide function with an optimized version that worked as it should.
So far, I had a morph function that could morph in any (8 bit) number of steps. But it was still too slow for practical use. After numerous optimizations, I came to the morphing function with a fixed number of steps - 16. This is the function that is used during the launch of the game and in some intermediate episodes.
Having finished with this, I switched to sound. I was always interested in what notes were what, until finally I figured it out (meaning BIOS-related Vectrex-a). I can't read music and I am anyone, but not a musician.
Having searched the Internet for notes of “The yankee doodle”, I could not find anything. It all ended midi file. Then I started looking for a midi player / editor. As a result, I found one that displayed the notes of a melody in a readable form. In the end, I “wrote” the yankee doodle music for Frogger.
For me it was a great feat, really !!!
In the beginning, I wanted the drum set theme, but it sounded pretty bad. In the way that the melody is played now, three voices are used, with an octave shift in each. It sounds so normal to me - in any case, I can’t recognize errors :-(
Now it's time to add a couple of details. This was what I was afraid of, because it meant entertainment with already ready code and the introduction of new things into it (of course, filled with bugs). New items were flies, crocodiles, snakes, girls, a timer, a clock, an otter, floating turtles ...
I programmed them all with my eyes closed, but I didn’t like a single minute of this activity. To tell you the truth, I hated it. However, these were things that I had to do in order for Frogger to be Frogger. These damn games with idiotic time variables when flies appear, checking the coordinates again and again, if the frog is close to the snake's head, etc. ... I couldn’t tolerate it.
But as you can see, I did it. However, everything has its price. Frogger became slow - he again became close to those 70,000 bars.
At that time, I just received a cartridge with an EPROM for my Vectrex-a and running several different games, found that slow games flicker a lot :-(. I really did not like it. I still could not transfer my Frogger to Vectrex, because the ordered PROM emulator has not arrived yet, but I had several PROMs and I looked at them ...
At that moment I was very worried about how Frogger would look on a real Vectrex, but I could not find anyone with a programmer.
However, I realized that Frogger, as it is, was too slow, so I started thinking about optimization and trade-offs. The first thing I did was delete the scoring of points, lives and the level indicator from the main screen. Can you believe that one call to this idiotic 'print string' function takes more than 10,000 clock cycles !?
Next, I edited all the sprites, trimmed them so that no more than 20 were used, but only 10-15 vectors, which resulted in a gain of about 10,000 strokes (I could not bear to edit all these sprites again!)
(by the way, the turtle you see in the scrolling text is the ancestor of those turtles that crawl in the game itself).
After that, I was sure that I could achieve my timing goal. This goal has now become the rendering of each frame within 50,000 cycles, since all the measurements made on commercial games available to me meant that this value was reliable, and some games even went beyond its limits.
(Still waiting for the PROM emulator ...)
Since so far there was some free time, I decided that it would be good to implement the scrolling text. Having a nearly finished frogger with ten lanes of moving sprites, I figured that making one strip of moving letters wouldn't be too difficult. And indeed, after drawing all the letters 3 or 4 times (the vector drawing program had a serious bug) and after spending a certain amount of nerves, I got rid of it.
However, now there is a new problem. Vectrex has so much RAM! (One kilobyte. Approx. Lane.). Having information about levels and sprites, the need to store many other variables in RAM, do morphing and still have scrolling text - this was another challenge. I changed the distribution of the RAM cells and began to use some of them twice and three times. This was also done, although I later thought that Vectrex programming was still easy at the time.
(Still waiting for the PROM emulator ...)
So I just waited and the time went without any changes in the code.
For a couple of weeks, I didn’t do anything, because the final check was to be done on a real Vectrex.…
Finally he arrived, connected and ... does not work (
I checked something ... Yes, it works, but the only PROM cartridge that I had had addresses only up to 8K, and Frogger had already exceeded this size by that time, so I couldn’t play my game (
(although, I played almost all the other games for the first time).
Since I myself do not understand electronics and do not know how to remake a cartridge so that it works with a 16KB (or 32KB) PROM, I loudly called for help. John heard my screams and sent me a couple of PROM cartridges that worked perfectly (it took another two weeks).
The ability to have access to 8Kb for starters was also not so bad, so I was able to split the Frogger into a couple of parts and check them one by one. Although it did not allow to evaluate all the features of the game, it is quite enough for partial verification.
Here I discovered a strong wobble effect that the emulator could not reproduce. After studying the issue, I realized that it was related to timings. The reel was, for the most part, noticeable at startup. And only when “motionless” vectors were drawn, animated or moving, somehow acquired something of an immunity type to this (strange?)
Anyway, having caught a few gray hairs, I figured out that if the frame update takes more than 30,000 cycles, the fixed vectors start to wobble (at least on my Vectrex-e). This concerned not only my game, but almost all games that had motionless vectors anywhere and required more than 30,000 frame updates.
This was true even for Minestorm - the game built into Vectrex. When the game was launched, after a few seconds, when the first mines appeared on the screen, the points were reeling (of course on my Vectrex, since I could only check on it).
As soon as you know what this effect looks like, you begin to detect it quite often.
Needless to say, I, as a perfectionist, did not like this at all.
Other games can stagger as they please, but not my game. And certainly not on the start screen that you see when you launch it.
I still do not know what causes this effect - any technical information on this topic is welcome. I thought that the only thing that would happen if the update took too much time was flickering. But even if I set the “recalibration wait time” timer to more than the standard 30,000 clock ticks, the value, fixed vectors GO! (usually the value of this timer is initialized when Vectrex is turned on and checked in Wait_Recal so that all the “frames” take at least 3000 clock cycles. Approx. I think there is a second “fixing” value, somewhere in the region of 50,000, but the flickering is unacceptable.
I changed the code so that the inscription 'VECTREX FROGGER' and everything else did not appear on the screen at the same time (this stupid text also requires about 5000-6000 cycles for drawing). Reel (at start) is gone.
But now I have found another effect ((which can still be seen on the present Vectrex, since I could not fix it in any reasonable way). The coordinates always drift slowly to +, + (up to the right).
If you leave the beam alone for quite a long time, it will go up to the right. Drawing a large frog at the beginning of the game by traversing a large list of vectors using a large scale is quite long. To completely draw a giant frog, it takes about 2000-3000 cycles. During this time, the beam floats about half a centimeter. It is necessary to recalibrate the ray between the renderings, which would solve the problem. But there is not enough time for this :-( (the frog consists of 63 vectors, and the positioning of 63 vectors at a given scale is impossible in no way that would not be time critical!
(63 * $ 90 = 9000 net time of movement of the beam, without overhead
63 * $ 70 = 7000 net time drawing vectors, no overhead
overhead = 1000 cycles. This is about 17,000 cycles only for a frog. And I also wanted a scrolling text, plus the morph of the frog should be short!)).
In addition, a fixed offset cannot be specified because the said drift is not constant. It depends on the mood of my Vectrex (after all, this is an old analog machine). So, the frog looks good on the emulator (if there is no drift in it), but on the real Vectrex, its tip is lost. It bothers me a little, but cannot be fixed easily!
Apart from this, everything seems to work just fine. I spent a couple of weeks without doing Vectrex Frogger (and I didn’t miss him very much - after working for a while, I was happy to leave him, after all, alone).
One day, John's cartridges finally arrived.
I tried Frogger ... And he earned !!! (disgusting :()
Somehow, I avoided this before, but there were also motionless "wobbling" vectors in the game itself. And they WENT :-( At that moment I was ready to quit everything. I was glad that I had achieved the goal of 50,000 cycles, considering that I wanted 70,000 at first. However, this was far from enough. To get rid of the reel, there was no other way than to achieve 30,000 cycles (in fact, this can be understood from the source Wait_Recal in the BIOS. Approx. Lane.)
For some time I experimented to get rid of fixed vectors, inventing “moving” houses, dotted lines, etc. But it almost did not help. I was ALL upset. My friend tried to console me by saying “this is not so bad,” but from my point of view it was bad. I wanted to make a full-fledged full game of Vectrex Frogger WITHOUT compromise with "reel".
I was thinking of changing all the sprites again in order to reduce the use of vectors, but this would lead to sprites as in the Atari 2600 - more guessable than distinguishable. So, I refused this idea.
Here I first tried to use the DP register (which was always always set to D0). Its more or less reasonable use, together with other optimizations, saved me from 1,000 to 2,000 bytes of code. This allowed me to again transfer some BIOS functions to my code and optimize them. I won another 10,000 cycles and reached 40,000, but I wondered what else could be optimized.
Step by step, going through the code and looking at the * .lst file created by the assembler, I looked for bottlenecks in critical areas ... I did this for a day and a half ... moving in small steps and saving 10-20, sometimes even 100 cycles, I reached about 37,000. a long way and every next step was harder. I need a break ... I
played Diddy Kong perfectly on my N64 (yes, I have other consoles besides Vectrex) and I got the idea ...
Why not use the wait cycles in the beam positioning and vector drawing functions for something more useful than just waiting when the timer expires?
Said and done - after two days of hassle, the implementation of too fast functions, the appearance of exhibitors on the Vectrex screen, strange effects and ... and ... and ... I saved 5000 more ticks! (it was easy to say, but pretty much spoiled my nerves - see the source for details).
Anyway, I was at 32,000 (this is at worst - with four houses occupied, a girl, a crocodile, an otter and snakes on the screen ...)
After that, I couldn't think more about all these optimizations. I edited all levels, changed them, deleted sprites, rearranged sprites, turned off all sorts of chips, ..., etc., although the levels still had the character that I asked them at the beginning, despite the fact that most of them changed slightly . In the end, I did it!
EVERY LEVEL UPDATED LESS THAN 30,000 TAKTS !!!
I really am very proud of my achievement. And now I consider Vectrex Frogger an outstanding program for Vectrex.
Perhaps this is just vanity on my part, but I put a lot of effort into Vectrex Frogger and hope that people will enjoy the game, and some may find the source useful and / or instructive.
STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP STOP
Another optimization success! Today I spun a couple of cycles, which gave a speed gain of about 3000 clock cycles! Hip-hip hooray! I rolled back the changes of all levels and they still do not require more than 30,000 cycles ...
Now I even have about 1500 cycles in stock :-)
FINISHING THE FILE (Finally)
Year 2016 A fresh look at frogger
... this week I began to program Frogger closely. In my plans:
- Music and sound effects
- Smoother graphics
- Fit in with 30000 cycles
- Animation
- View from the top down (many do not like the side view)
- Two player mode (take turns)
- Probably keeping records
- Screensaver prettier
In recent weeks, I occasionally edited separate lists of vectors in Vide, but only this week I collected them together and transferred them to Frogger (see the gif).
I had to change the original source more than I expected, because the player's sprite had no animation. And entering the old source code, which is already 18 years old, did not simplify the matter either.
One way or another, as you can see, an animated frog from the top-down view is implemented.
As I wrote earlier (almost 20 years ago, I remind you), one of my main tasks was to keep within 30 thousand cycles in order to avoid image oscillations. Since I now wanted to add additional features, I had to peer into the code again.
I changed and tightened up the part that generated the lists of vectors, until it became mega-efficient. True, the first level of the game (the most loaded) began to be drawn in just 22 thousand clock cycles!
One problem - the graphics were of the same type as before - “typical” Vectrex'a vector graphics, when you often see a “point” at one end of the line, because the beam ignites too early.
Voila!
Look at the new frog: isn't he beautiful?
Although I did it myself, but still extremely excited about how vectors without dots look)
For those in the subject:
- At first I tried to go the usual way, using the timer T1 for scale and ramp, and shift for damping.
- No matter how hard I tried, there was still some “overlap”.
- PB7 (ramp) CB2 (blank) — . , , , , Frogger'a.
- [ , . .] — T1 ramp, blank (CB2) (.. ).
- , , .
- Frogger'a ( ) 25 .
Needless to say that, despite the fact that the Vide is a very good emulator, this kind of experiments with precise time keeping require this Vectrex.
Another great news is that it looks like this code works flawlessly on all three of my Vectrexes.
And finally, some videos - the first steps as a level in slot machines (however, as you can see, the transitions are not completed yet).
Continued ...
I added a dispatcher to Frogger’s code. The old code for MoveTo-InBetween is called from the dispatcher. The dispatcher uses subroutines so, theoretically, clocks are spent on JSR and RTS, but the code looks so much nicer that I left it as it is (since I didn't really need extra clocks). YM decoding [music, note] is done through the controller - I broke the decoding into 9 parts, each of which is independent of the others and they are called in different parts of MoveTo. Thus, YM decoding uses almost no extra clock cycles. Almost finished editing sprites for the top view (see picture) - the sprites of two different cars, a van, a racing car and a tractor more or less resemble the originals.
In general, lists of vectors are about a third longer than those that were before. Although, I think it is now drawn about 40 vectors more than in the original Frogger for Vectrex. I counted only drawn objects, but in some scenes the number of vectors matters. The tractor alone consists of 26 individual vectors. For Vectrex this is a giant number.
I also improved the playability somewhat by slightly stretching the game area. Frogger is now not so easy to go beyond the borders. It was very difficult to get to the far right house. Now jumping a little slower (because of the animation) and it is even more difficult. However, adding animation was a good idea. Jumping feels more like a frogger than it used to be.
It is necessary to test a lot more gameplay, make sound effects and other things, but things are going well with the new version.
The continuation continues ...
Frogger again. Twice I checked the first 7 levels and changed their structure to reflect the changes made in the sprites. Measurements in the Vide showed that Frogger again became a little slower - the 7th level with 4 occupied houses requires about 32 thousand cycles. Damn - I will have to fight again for tact - I thought it was over. If you look at the available resources, I’ve got a lot more behind me now than when I went to the university (look at the picture on the right - this is a self-made slot machine based on MAME - guess what Frogger is :) [here’s an intrigue, see further - approx. lane.] Having gone beyond the limit of 30 thousand clock cycles, I no longer consider the possibility of adding a display of information about records during the game and this worries me!
Below is another example of the current Frogger gameplay. I think I will add the missing sound effects last - when I double check and correct the levels.
It feels like I'm moving back in time.
Just finished optimizing the code, winning about a thousand more cycles. However, I can not think of what else can be done. I have to save about a thousand more cycles (in the most difficult levels).
By optimizing the code, I can’t get it anymore, so I’ll be editing new sprites - change them slightly. 26 vectors per tractor (for example) - not a ride.
I calculated that each drawn vector uses about 50 cycles.
In the most full levels, I need to save 50 vectors.
Since about 20-25 objects are displayed, I have to shave about two vectors from each of them - this should be doable :-)
After each level will again fit into less than 30 thousand, I will do the rest of the effects, then it will all really look and feel like Frogger. You also need to lick the "intermission" and make a better screensaver ... and, voila, I will finish somewhere in 2017 ...
Ten minutes of continuation ....
A small report on the progress in the work on the new version of Frogger.
Almost done!
Probably I'm still fixing something, optimizing and improving, but adding features is complete.
Compared to the original Vectrex Frogger, the following things have changed:
- top view of cars and frog
- smoother vectors
- during gameplay points are displayed, levels and lives
- the game area is slightly extended
- more sounds and music
- one and two player options
- In the single player mode, the option "training" is added
- option to turn on / off music
- 5 best records saved in PR24 DS2431
- new main screen
- demo mode
Also deleted:
- "Intermissions"
- pause mode
So far I have been wondering whether it is necessary to change the levels so that they look more like the “original”. In the original Frogger (from slot machines), two adjacent strips of water moved in the same direction - this I have not yet taken into account. So, the stripes above are felt differently.
Anyway, enough talk ... Here is a ten-minute video of the current version:
No more frogger!
I stopped working on the source code and decided that there would be no new version of Vectrex Frogger.
Due to certain circumstances, which I will discuss below, Vectrex Frogger is dead and the only available version will be the one I did 18 years ago.
Why am I not going to work on it anymore?
- Everything is complete!
Except for possible bug fixes.
Why not be a new version of frogger?
- Because I decided to rename it.
I know frogger is a popular name. However, to be honest, not one Vectrex game will reach the glory of the original.
And, although the game on which I was working inspired Frogger, this is definitely another game!
So I decided to change the working title to the final one:
This title probably doesn’t tell you anything, but in the early 1990s I wrote a game under DOS, which was called that way.
(see: Karl Quappe - DOS , or, on an older page: Karl Quappe - AOL )
For readers who do not read German, the same title information as on the AOL page:
“KAULQUAPPE” translates as “Tadpole”, “QUAPPE” is short for tadpole, and KARL is just a name similar to “KAUL” (homophone). So, if you want to translate it, for example, into English, you will get something like “CHARLES POLE” (Charles - English version of Karl) or Tedpole ('Ted' - a name that sounds like 'tad') '
Next is another short video. There are no big changes, just something polished. I let the game run itself - did not touch the buttons, so the gameplay that you see is a demo mode.
Enjoy!
Source: https://habr.com/ru/post/317656/
All Articles