Rebel - 8 Bit Wars Contest

[TomToad]

The year is 2248.  This quadrant of the galaxy has been taken over by the Zargon empire.  All sentient life has been enslaved for their personal gain.  You play a lone rebel who utilizes Earth's most advanced technology to battle each of the Zargon's strongholds, winning back the galaxy's freedom.

This game is going to be a vertical scroll shoot-em-up.  Language will be CBM Basic and 6510 assembly.  Using CBM .prg Studio to cross develop on my PC and VICE emulator to test the program.  Will release the game as .d64 for emulators and real hardware.  Trying out C64 Emulator Create as a wrapper so Windows users can run the program without installing an emulator.

[Xerra]

The year is 2248.  This quadrant of the galaxy has been taken over by the Zargon empire.  All sentient life has been enslaved for their personal gain.  You play a lone rebel who utilizes Earth's most advanced technology to battle each of the Zargon's strongholds, winning back the galaxy's freedom.

This game is going to be a vertical scroll shoot-em-up.  Language will be CBM Basic and 6510 assembly.  Using CBM .prg Studio to cross develop on my PC and VICE emulator to test the program.  Will release the game as .d64 for emulators and real hardware.  Trying out C64 Emulator Create as a wrapper so Windows users can run the program without installing an emulator.

I can not wait to see how well you get on with this. I think it's a brilliant idea to code it for the real hardware. I really hope your game comes off.

Also glad I didn't go for a vertical scrolling shoot-em up now, as I did consider it for a while.

[TomToad]

Still brushing up on my C64 programming.  Many things I've forgotten over the years.  The image is a basic prototype of one of the main fortresses.  It will actually be much longer, extending beyond the top of the screen and scroll into view.  The blueish circles will be where energy bullets will be fired from, and can be destroyed in the game.

My plan going forward is to use custom multi-colored characters for the fortress, allowing fast scrolling onto the screen.  I will also modify the characters "on the fly" for the bullets' path.  The way I am designing the engine, it will allow for 128 bullets on the screen at once.  I am not sure yet if the C64 is fast enough to allow that many without speeding up the emulator, will need to experiment to see where that limit will be.
The ships will be done with sprites.  I don't anticipate the need for more than 8 ships at once, so no need for sprite trickery here.

[TomToad]

Did a few tests and found that I can redraw the entire screen and color memory at about 34 fps, a little too slow.  As the C64 can move the entire screen by 8 pixels by using the vertical scroll register, the screen only needs to be redrawn once every 8th frame.  This means I can get away with drawing 1/8th of the screen every frame and theoretically up the frame rate to somewhere around 200 fps.

Before I test the scroll registers, I need a level to scroll on the screen, so I've been working on a level editor in BMX-NG.

[TomToad]

There's nothing like programming for older hardware that makes you appreciate the people that developed for them originally.  I have run into a snag in my game as it seems that the C64 doesn't like you to split the screen between a vertical scrolling section and a static one.

The way the video controller works is that every 8th line, it will grab character and color information for rendering the next row of characters.  These lines are called "bad lines" as it needs to lock the bus during this period and stops the cpu for a few cycles.  When you use the smooth vertical scroll feature, you move these bad lines down the screen 1 to 8 pixels.  This is not a problem when you are scrolling the entire screen, but when you split the screen with a static portion (needed for score, lives, etc...) then it creates problems. 

There is a known bug in the VIC-II chip in which if the screen is scrolled after a bad line in such a way that the next one is delayed past 8 lines, then the VIC-II chip runs out of things to draw and the internal counters never update.  When it finally reaches the next bad line, the VIC-II starts drawing again from where it thinks it left off.  This effectively pushes the screen down a few pixels from where it should be.

To fix, you need to control the timing perfectly, making sure there is never more than 8 lines from one bad line to the next.  You also need to make sure that the distance isn't too close as that could leave you with too little time for the processor to actually make the changes on the screen that are necessary.  This is rather difficult as you scroll the screen down, the gap gets wider from the text above. and narrower to the text below.

The fun thing about this, as was always quite common for those early developers, is that someone has figured out a way to turn this bug into a feature.  By carefully controlling when the next "bad line" is reached, you can push the entire screen down by any arbitrary number of lines, whether it be text or hi-res graphics.  The only caveat is that you can't draw anything above the scrolled portion, but you can get nice effects such as a "bouncing" logo and such.  This has been called "Flexible Line Distance" or FLD.  Here is a nice description of what it is and how it works.

As for my game, I have thought about just ditching the hardware route all together and program my game in BlitzMax or AGK.  But now I have been challenged and fixing it has become a game in itself to me.  So I might not get my entry in on time.  There are still other challenges I have not yet faced.

[Qube]

As for my game, I have thought about just ditching the hardware route all together and program my game in BlitzMax or AGK.  But now I have been challenged and fixing it has become a game in itself to me.  So I might not get my entry in on time.  There are still other challenges I have not yet faced.

You're a brave man for coding on the real machine ( emulated but still the same pitfalls ). There's nothing stopping you zipping over to Max or AGK and then revisiting this after the comp

[MrmediamanX]

I've just been giving (Turbo Rascal SE, TRSE) a bit of jam ... seems ok I guess.
been watching this as well.

[TomToad]

I still haven't gotten past this bug. Unfortunately, between an extra busy couple of months, and now being sick the past couple of days,I don't seem to have enough time to complete anything, even if I were to only do a Windows version and skip the native version.  I may still finish this some day, it has been fun programming for the c64 again.
I still have one trick left up my sleeve which I might try when I get the time and feel up to it.