Is pseudo 3D possible in 7800Basic?

[VGAGuy]

Like in Ballblazer. I'm wondering if a game in a similar vein to Konami's Devastators arcade game could be done, with 7800Basic. As I am considering making one.
Where the engine reads a table for each strip of the area, telling it what obstacles to display and what enemies to place.
The strips also being alternating colors to show movement.

 

 

For my purposes the 2.5D scrolling would only need to take up around half of the screen, the rest being used for background graphics and the HUD, with the strips divided into 4 sections with a byte telling the engine what to put on each section, if anything.

Any help is welcome.

 

[+SmittyB]

The short answer is yes. The long answer is yes, but you you would probably need to use a bit of assembly to make it run at a good enough speed.

 

The gist of how to do it would be to use 7800BASIC's 'topscreenroutine' to have a subroutine that starts at the top of the screen, then waits for a number of lines, changes the value of 'BACKGRND', waits some more, changes it again, etc. The splitmode.bas sample program will give you an idea of what I mean.

 

The downside to this technique is that while your game is just waiting to the get to the right line it's not doing anything else. If your 'topscreenroutine' code doesn't return until the bottom of the screen you've lost that time where it could have been processing something else so it's a good idea to have your screen changes as high up the screen as you can.

This is somewhat mitigated by doublebuffering so even if the rest of your code can't complete in time for the next frame the screen will still be drawn properly and it can carry on where it left off the frame after.

 

The simplest way I can think to do things would be to have an array the length of the number of lines tall your 3D effect is, then have the routine load the colour for the next line, wait until the next line starts, change the colour, then repeat.

 

To set the array of colours if your sections were at most 32 lines tall and you alternated between green and brown for example, you'd set everything for the first 32 entries (minus an offset based on movement) green, then set everything brown for 32 minus a value that looks good number of lines say 32-10, then green again for the number you got minus the same offset, so 22-10, all the way until you reach the end of the array. You'll need to ensure that any number that becomes less than 1 is set to 1 instead so you get an alternating pattern up to your horizon.

 

 

 

 

If you then wanted to get more complicated with things, Ballblazer does the above but then cycles through a number of tiles to create the vertical lines as you can see from the screenshot of running a PAL copy on an NTSC machine which breaks the timings.

 

An even nicer technique is explained in this video but the 7800 is too slow to pull it off nicely for 4 colour modes so you have to hide part of the screen on the left to cover the colour changes.

 

I hope I haven't overwhelmed you with a wall of text.

[RevEng]

SmittyB has given a comprehensive answer, and I agree with the points he's made, so I'll just add a few observations.

 

For most 7800 game designs, the resource you run into trouble with most often is the CPU. The technique SmittyB described is the perfect answer to your question of having lines move down the screen, but as he pointed out, it throws away a lot of CPU time. Alternatively you could have characters defined that have a horizontal line though them in various positions. Then you just update selective characters in the buffer, so the lines are rendered at needed vertical positions.

 

You mentioned Devastator. It's airfield sequence has a nice trick we should note here...

 

https://youtu.be/xaovQeiNWtw?t=2m24s

 

If you look at the land near the horizon, you'll see they use an 8-frame looped-animation sequence to give the illusion the planes are scrolling forward and off-screen. This is a nice way to sell the pseudo-3d effect.

 

Whatever technique, you'll probably need to throw a lot of graphics ROM at it, so you'll likely need bankswitching. Do a few prototypes or whatever without bankswitching, but then try to use bankswitching for any code you don't intend to throw away. Bankswitching comes with it's own set of constraints, and it's less painful to have start the game design with them, rather than adapting some non-banked design later on.

[VGAGuy]

Thanks for all the help!
I think I might go for the Devastators approach, though I don't know how the table for object placement would work(Rock walls, turrets, etc...).
Sprite scaling and enemy handling will be tough as well.