New Platform Game Programming Tool

[PhilRanger]

Hello,

There are not many platform games in the SuperMario style on the VIC and I think that the lack of an easy and fast tool for scrolling might be the main reason for it. Please let me know if something similar exists, but I'm thinking about developing something like this:

1- Move the whole screen horizontally to scroll everything at once. The smallest move is then 4 pixels, or 2 multicolor pixels. I'd use 2 separate memory areas for the re-definitions of the characters, the second being an offset version of the first one, generated automatically. Scrolling would be fast for 1/2 of them : just change the character pointer. The other one would be longer as it would also offset every character on the screen and introduce a new column.

2- Change the screen size so there is no vertical border.

3- Have hi-res characters of 2 categories:
a) Decor : move automatically left-right or right-left
b) Heroes: Fixed Characters that stay at the same position on the screen while the decor moves (they can have multiples leg positions for example though). This would be done by overwriting the 2nd character set after its initialization and re-drawing manually at every scroll call if needed.
4- Jumps would be taken care of by defining additional "heroes" characters and putting them on the screen as needed

Wishful thinking:
4- Hopefully have some kind of or/xor??? to see heroes and decor nicely overlap. Otherwise, just let the path clear!
5- Possibility to call the scrolls from basic
6- Have the same thing for vertical scrolling someday so you could do both in the same game

I see the following subroutines:
i) Init (copies the 1st set of char in the second one and initializes the screen size)
ii) Scroll. Parameter=direction
The rest would be left to the user (poking characters, colors, defining the character set, timing, etc.)

Questions:
a) Does it already exist?
b) Any problems to expect (apart from finding the time to do it!!!)
c) I'm thinking about using maybe double height characters in multi-color mode only, since the move will be crude anyway the objects should be big. Otherwise I'd sacrifice some rows to get enough columns?
d) I don't know how to handle the collisions between the heroes and decor
e) Should I expect flicker problems?
f) Useful/inspiring or not?

Any other comment is MORE than welcome!

Best regards

[Mike]

a) Does it already exist?

Depends. Horizontal scrolling is not too unusual in VIC-20 games. Examples: Splatform, Level edit (also vertical), Dragonwing, ...

b) Any problems to expect (apart from finding the time to do it!!!)

The difficulty only ramps up if you proceed to pixel-wise scrolling (as opposed to char or half-char based scrolling).

c) I'm thinking about using maybe double height characters in multi-color mode only, since the move will be crude anyway the objects should be big. Otherwise I'd sacrifice some rows to get enough columns?

The VIC can access more than 512 characters on screen. Only prerequisite is, that (internal) RAM is available at that place.

d) I don't know how to handle the collisions between the heroes and decor

You could do with either with a simple distance calcution, or an off-screen bitmap to check if the player collides with background features or enemies.

e) Should I expect flicker problems?

Yes, unless you synchronise a VIA timer so updates happen during flyback and/or you use double buffering.

f) Useful/inspiring or not?

Go ahead!

[PhilRanger]

a) Does it already exist?

Depends. Horizontal scrolling is not too unusual in VIC-20 games. Examples: Splatform, Level edit (also vertical), Dragonwing, ...

I'm thinking about an "open source" tool more than a single game. A tool to make platform programming easy, even in basic.

b) Any problems to expect (apart from finding the time to do it!!!)

The difficulty only ramps up if you proceed to pixel-wise scrolling (as opposed to char or half-char based scrolling).

The idea of moving the full screen via 36864 is to avoid the nightmare of re-creating characters for every position (I guess I wasn't clear when I explained the mechanics of my project). This mean 2 multi-color pixel at a time. That being said, going to single color pixel move is only one additional character set, but with every combination of adjacent tiles it increases the complexity a lot!

c) I'm thinking about using maybe double height characters in multi-color mode only, since the move will be crude anyway the objects should be big. Otherwise I'd sacrifice some rows to get enough columns?

The VIC can access more than 512 characters on screen. Only prerequisite is, that (internal) RAM is available at that place.

The speed would drop though as I would have to move twice as many characters for a complete screen. I'll see how bad it is, maybe I'll implement both modes!

d) I don't know how to handle the collisions between the heroes and decor

You could do with either with a simple distance calcution, or an off-screen bitmap to check if the player collides with background features or enemies.

Sorry, my bad, I wasn't clear. I mean how to draw the decor and the heroes at the same time in a single character on the screen. Especially if they are different colors!

e) Should I expect flicker problems?

Yes, unless you synchronise a VIA timer so updates happen during flyback and/or you use double buffering.

I'll need to find how to do that. I may be back asking for help WHEN I reach that point.

f) Useful/inspiring or not?

Go ahead!

Thanks. Somewhere deep inside I knew the famous "Mike" would answer me!

[RJBowman]

With the amount of stuff that you are going to be moving around the screen, I advise against trying to create a full hi-res screen. Super Mario Brothers uses background objects built from tiles, just like the characters on the VIC screen, and the memory savings is great. If you write a game that requires a VIC20 with maxed out memory expansion, you are writing the game for emulation only, with maybe a few hardcore people that will be able to play it on a real machine.

You might think that you need a full screen of hi-res to animate smoothly-moving object, but you don't. You just need to set aside a block of characters for each moving object on the screen, and animate the object within that little block, which you can move around the screen. This is how VIC-20 Jelly Monsters (http://www.youtube.com/watch?v=S0gD_8mdq-w) was programmed.

[Mike]

d) I don't know how to handle the collisions between the heroes and decor

You could do with either with a simple distance calcution, or an off-screen bitmap to check if the player collides with background features or enemies.

Sorry, my bad, I wasn't clear. I mean how to draw the decor and the heroes at the same time in a single character on the screen. Especially if they are different colors!

You would take the definitions of both characters, combine them with logical operations (OR, XOR, or mask-out and mask-in), write the result into a free character and remember the character 'beneath' your player so it can be restored when the player moves on.

I had a similar discussion with RJBowman one year ago in the thread 'Need a graphics algorythm; probably obvious to someone', where the problem of colour clashes was also considered. In short, you're limited by the hardware, there's only one foreground register per character, so you have to decide who 'wins'. The VIC-I has no sprites.

Thus far the efforts of RJBowman didn't lead to any tangible result, though.

[tokra]

In short, you're limited by the hardware, there's only one foreground register per character, so you have to decide who 'wins'. The VIC-I has no sprites.

With raster tricks you can overcome some of those limitations. Take a look at Dragonfire. On the first screen it uses inverse mode and cycle-exact raster modification of $900f to create the multi-color player-"sprite".

On the second screen it uses cycle-exact code to update the color-RAM itself (much like FLI-mode).

Essentially this is like programming for the Atari 2600 where you spend most of the code creating the picture while it is being displayed ("Racing the beam"). Depending on the screen area you use this technique will eat up about 50% of CPU-time. Most games will still run fast enough when done in assembler, though.

[PhilRanger]

Sorry, it seems I am not able to explain properly what I mean. I want to skip redefining characters for mid positions for everything that is part of the decor, while having scrolling smoother than full character. Here's a crude example, using only native characters.

https://www.box.com/s/w7mgceimlg7qiovlpckw(unexpanded vic, works better on PAL)

It is divided in 4 passes:
pass 1: characters move one full character at a time
pass 2: each character moves by 1/2 half character without redefining them. The trick is to move the horizontal position instead
pass 3 and 4 are like pass 1 and 2 but with the frame visible. This is of course ugly, but shows how it works.

[RJBowman]

I had a similar discussion with RJBowman one year ago in the thread 'Need a graphics algorythm; probably obvious to someone', where the problem of colour clashes was also considered. In short, you're limited by the hardware, there's only one foreground register per character, so you have to decide who 'wins'. The VIC-I has no sprites.

Thus far the efforts of RJBowman didn't lead to any tangible result, though.

I have too short of an attention span and too little free time.

Anyway, my proposal to resolve the color clashes was to use a multi-color character wherever two objects overlap. This would require that the object be converted to lower resolution in that square, and you would probably want to use the border or multicolor auxiliary color for the color of the moving object. And when a bunch of objects overlap, there would have to be rules for color conflict resolution.

My ultimate goal would be to have the sprite rendered by the interupt, so all you'd have to do is poke x and y values into a register, and it would be just like working with hardware sprites. The code could be reused to make any kind of game you want.

But if you just want to program one specific game, that would probably be more than you'd need.

Did you plan to use multi-color for your scrolling game?

[PhilRanger]

Did you plan to use multi-color for your scrolling game?

In my case yes, but I want to provide an "open source toolkit" that would allow both if possible

[Mike]

I want to skip redefining characters for mid positions for everything that is part of the decor, while having scrolling smoother than full character.

Your routine just needs to take those characters of the background which are located 'beneath' the intended position of the player, and replace them with copies in the free pool.

Before the replacement, the character definitions of the background characters are copied into the free pool, and the free pool is then updated with the character definition of the player.

When the player is aligned to the background characters (i.e. a 'full' character scroll position), you just need as many characters in the free pool as would be needed for the player alone. Otherwise, you need one character more per row (for horizontal displacement) and/or per column (for vertical displacement).

The technique remains the same, regardless whether the background is scrolled or not. MINIPAINT, for example, implements the blinking cursor in the editor display exactly this way (using 6 characters in the free pool).

[PhilRanger]

Thanks. I understand what you mean. I was hoping some overlay using scan might have been possible to avoid forcing the user to go to hi-res altogether but maybe I'm just dreaming!

[Mike]

Thanks. I understand what you mean. I was hoping some overlay using scan might have been possible to avoid forcing the user to go to hi-res altogether but maybe I'm just dreaming!

I was not talking about a full-screen bitmap. Just the characters around the player position must be taken care of.

[PhilRanger]

I was not talking about a full-screen bitmap. Just the characters around the player position must be taken care of.

Yes I got that. I think a fully bit-mapped screen would be too slow anyway.