The curious drawing bug

I’m in the middle of refactoring all the drawing and positioning code for Stunt Man Rip it up and start again. This is quite a big job and does involve destroying not only huge swathes of code as I build automated routines to process data, but also throwing away data sets to produce more unified data models.

It’s often difficult to test code when you have to write so much before you can get some visual effects running. I’m using my title screen to test the code as I’m developing it before moving onto reworking all the game logic for jumping the buses.

During some of this initial testing I came across a bug, discussed here in this video

What’s interesting about this (well to me), is it shows how sometimes visual bugs can be a help. It has highlighted to me a semantic problem with my code, which may have been ignored for a long time. Not all bugs are bad. I still need to learn more about Dissi in VIDE so that I can do some more useful debugging than just straight breakpoints.

I’ve made some good progress so far and do have some interesting functional mechanics in place. Just got to finish refactoring the data for the bike and then I can work on the bigger job of reworking the game logic and then to start adding animation for the wheels and wheeling based on the inertia of the bike.

After that I will then have to tidy up and get of any outstanding and unnecessary data and work out what space I’ve got left to implement the other game modes I want to implement.

Stunt Man stories

I’ve decided I need to change the name of my game as there are a few games called stunt man and I don’t want to step on toes. So I’ve come up with “Stunt Man Stories”. As the full game will be a collection of different events, the bus jumping is just where I got my initial inspiration.

I’m going to code some form of clapper board (if that is the correct term) to act as introduction/attempt information counter. Here’s a mock up of how that might look.

Next job is to convert the rest of the bus jumping mechanic over to the new 16 bit placement engine code and then going to work on animation.

I’ll post a bigger update when I have something complete.

Scrolling viewport

I need to scroll the objects as the stunt rider jumps the buses in order to allow a reasonable number of buses to be jumped. the original Atari arcade machine had 28 buses. I did some test of what this would look like and now I’ve started building the first iteration of the framework that will enable a scrolling viewport.

The system is relatively simple and requires using a double word (16 bits) to represent the location of all sprites and objects. this gives a playfield of 65536 positions. An associated viewport position is also represented using the same 16 bit format. It’s actually quite trivial to check to see if an object is withing the current viewport region as the width of the viewport spans a byte (0-255 points).

It’s quite an interesting effect and allows a lot of possibilities. There is a cost associated with this work but it allows quite complex scenes to be developed with minimal hackery.

I now need to finished the manager that has been partly built to enable this little demo, this will then enable me to finish work on the logic and jumping mechanics.

Rip it up and start again

When of the interesting aspects of coding on a platform you are not familiar with. Is that you iterate quite a lot, trying ideas and managing to implement features. Some times you can almost get a complete working product only to think of or stumble across a different way of doing things. This can often involve throwing away practically everything from the previous iteration.

This is very common (I find) with low level work, I’m currently onto revision 4 of stuntman and have decided to implement scrolling for the buses. This will allow 28 buses to be jumped while in standard portrait orientation (I am going to implement a tate mode with it’s own horizontal overlay, but will need to adjust the y scale to get 28 buses in).

I hacked up the existing code to see what the bottom row of graphics would look like when scrolling and it looks pretty good.

I don’t like the hacky way I got this to work (it was just for visual checking), so I’ve decided to work out and implement a 16 bit view-port system, this will in the long run allow me “easily” to implement sprites moving in and out of the current view-port. This involves quite a major re-write of handling routines. So hopefully in a couple of weeks I should have a good working base to get the Jumping mode of stunt man finished.

I’m enjoying programming the Vectrex and I think I picked a nice project to learn the machine on. Just need to implement a better scoring mechanic other than number of buses jumped. I’m leaning towards some form of landing accuracy system.

Potential Control System for Stunt Man

The original Stunt Cycle game had a twist grip controller. Here’s a picture of the home version of Stunt Cycle.

Here’s a picture of the Arcade machine

To hook up something like this to a Vectrex you need a potentiometer as it will act in place of the joystick. I hunted around and found this potential candidate. Which has a return spring (it’s quite strong which is good)

Hopefully I’ll be able to make a controller similar to the home game one. I’m working on the analogue and digital acceleration mechanics next so will hopefully have something to test with.