Micro Hexagon arrived to C64

[José Pereira]

Hi.

Just came across this

http://www.youtube.com/watch?v=-HZS0_RW3cg

 

 

 

From what I am seeing here its really possible in A8.

3colours more black BACKGROUND register at the Borders GR.15.

Scores at the bottom can be just PMGs PRIOR1 over Playfield and reuse one of them for the player point.

And it could even makes use of the A8 hardware collision registers.

 

Will play it when I get home and also the original P.C. version.

There they says its asimplified version. Is this worth a conversion...

One thing I have to see is if the logo and credits more the end of level letters are C64 sprites or not. On A8 we dont have enough PMGs to put over the PFs area but doesn-t seem a problem to have the rotating tunnel with the letters above as PFs bitmap masking...

 

 

 

Download it here

http://csdb.dk/release/?id=125133

 

[Paul Westphal]

I know the Atari can do this, and probably better in some ways. How about some brighter colors and some RMT music?

[José Pereira]

Like always I'll post here my idea for anyone interested.

I'm not at home now but I think I know how to... Ah! And yes the A8 can have better colours because of its Palette.

Just think in Yoomp and all the trouble C64 guys had and never got it converted.

Even if Yoomp is in a 'more cycle available' because it uses GR.7 I also don't see any problem if this one uses GR.15. Or there is?

Even as a last option this one could also be in GR.7 but is it really needed?

[MrFish]

I don't think the color changes during the levels enhance it, and the fast color cycling is nigh to causing an epileptic seizure.

 

It'd be better to have the color change at slower intervals and have some meaning to progress in the game, or just change them per level as in Yoomp.

[José Pereira]

@MrFish: It hasn't to be the same. Maybe some things new and yes, just started to play the C64 version and that colour cycling is probably why I can't play it much more than a few seconds. Maybe if I can get a C64 emulator with my P.C. mouse as joystick it will be better...

Edited December 11, 2013 by José Pereira

[Heaven/TQA]

tMR should answer if it uses bitmap or charmode... And how much ram is used...

[MrFish]

@MrFish: It hasn't to be the same. Maybe some things new and yes, just started to play the C64 version and that colour cycling is probably why I can't play it much more than a few seconds. Maybe if I can get a C64 emulator with my P.C. mouse as joystick it will be better...

 

Certainly an Atari version wouldn't have to be the same. The gameplay looks interesting enough. I think the rotating board, and moving bars that need to be avoided, are enough for the eyes to deal with.

Edited December 11, 2013 by MrFish

[José Pereira]

tMR should answer if it uses bitmap or charmode... And how much ram is used...

Don't know why but I l loaded a freezed file into C64 Chars/Sprite Ripper program and it seems that all the white is hardware sprites extended across the screen.

It seems that indeed there's only two gfxs colours: like two blues, two greens,... But then why they didn't it in hi-res?

On the white parts to do the same on the white we would need to change the the white PMGs xPos and the increasing size at the same time as the rotation. But I have almost sure that we don't have enough PMGs to do the same.

[Rybags]

Nice music. It appears to be char based, I slowed it down and it looks like the lines do 40 steps across the screen.

 

The sprites are enabled, I suspect they might be used for the barriers, epecially since they have slight gaps when on the outer part of screen.

 

Colour cycling appears to speed up to the point where they change once per frame - along with the circular movement it's just part of the disorientation process but annoying, yes.

 

Atari could be much more versatile with what it does in that regard.

 

87 blocks used for the file - about 22K although probably compressed.

Edited December 11, 2013 by Rybags

[José Pereira]

Run the game in slow motion Emulation speed and you'll see that they come in parts. Each of them are a C64 hardware sprite and re-used at different (x,y)Pos on the screen.

Lets say that for an hexagon with the rotation you can have at same line (following what it seems to be the C64 idea/code):

2or3 outside large white parts

+

2or3 inside lines

+

1 point player pixel.

This is the around 7 of the 8 possible per line C64 hardware sprites.

 

And if the player point and the inside hexagon lines don't get to the bottom then it's to get that the time's numbers are re-use of these ones.

Maybe a C64 coder and an English native speaker can explain better but I am almost sure that I am not far from the reality.

 

@Heaven: It seems a thing to ast Oswald at FWar .

[TMR]

It appears to be char based, I slowed it down and it looks like the lines do 40 steps across the screen.

 

The sprites are enabled, I suspect they might be used for the barriers, epecially since they have slight gaps when on the outer part of screen.

Yup, using character-based screens and hardware sprites for the barriers and player square. Had a quick prod and it seems to only be using half of each character set (with the related screen shoved into the other half) so anyone wanting to do a port might well be in luck on that count, as will not having to store multiple iterations of the sprite data. It does appear to be using memory from the $02xx range right through to end of RAM though, so possibly swings and roundabouts...

 

87 blocks used for the file - about 22K although probably compressed.

That's compressed but with the crack intro as well, the game alone is roughly 15.1K compressed (it was an entry into a 16K cartridge competition and you lose at least half a page to the autostart headers and block shift code).

[Heaven/TQA]

ok... half of character sets gets interesting as it might fit into our 128 char damned limit

 

but sprite overlays... hmmm.... if we expand the players and do some multiplex it get's tough and might look like a 2600 game . Why I thought it would be good in looking at to see if we can import the code into A8 and patch it here and there and see where we are coming... as I had done in the past with VIC20 code... or XXL with Z80 stuff or BBC/Apple 2

[Heaven/TQA]

the SID is cool btw....

[Rybags]

I'm thinking the barriers would probably best be done using characters. Due to the rotation and required resolution I don't think using PMGs would cut it. Plus there can be more than one set coming down on you at a time.

Of course this likely would blow us past 128. Although I suspect each possible angle of the lanes would need it's unique chset.

 

Such a simple game concept but the rotation even at character resolution makes the programming task much more complex.

[José Pereira]

Can't it be done in Bitmap GR.15 avoiding the 128chars A8 charset limit?

Of course it would need to be coded from scratch and some 'maths thinking', but on my tries last night I was thinking in:

something around this:

BAK: borders

PF0 and PF1: the two coloured zones

PF2: the outer side white lines.

Then PRIOR1 I would add another colour on the inside center hexagon lines with [P0|P1] (16pixels is enough) and I'll even have the inside hexagon with the BAK register darker same as borders colour. The players point can be P2.

This way we could set the hardware collision between our P2 point and PF2_outer lines and P2 with the [P0|P1]_hexagon lines.

 

 

At the bottom the [left timer] and [right timer] can be (re-use DLIs/PMGs) using again PRIOR1:

Left: [P0 P1 M0|M1]

Right: [P2 P3 M2|M3]

[Rybags]

Bitmap, probably not in Gr. 15.

 

Pre-rendered could be possible with mirroring trick on DList for bottom half of screen. But rendering the barriers in bitmap might take too much CPU time. Much of the barrier data is unmasked which can speed things up but a wipe operation is also needed.

 

Pre-rendered though we're probably talking lots of memory. Colour swapping could mean that less is needed again but still half a screen of data is effectively 4K.

 

Char mode is looking best I think. The concerning factor being able to include the barriers as well. Colour swap trick could be used too, ie no point duplicating angles where the screen is essentially the same except the background colour.

[TMR]

Although I suspect each possible angle of the lanes would need it's unique chset.

That seems to be how the C64 is doing it yeah, a fairly populated half a character set (it varies depending on the frame, some are more optimal than others) and a block of screen RAM per frame of rotation; trying to cram pre-shifted data for the barriers into that space is going to be a nightmare.

[TMR]

Can't it be done in Bitmap GR.15 avoiding the 128chars A8 charset limit?

The only thing the C64 is really handling in realtime is the barriers with the CPU load for the background rotation probably needing at most a couple of scanlines, anything you do to move from that technique towards something that actually redraws to a bitmapped buffer each iteration will be a massive spike in CPU requirement.

[Rybags]

Barriers would probably need to be a mix of preallocated and dynamically generated.

 

Doing some screencaps or maybe just generating blank screens with all the angles then seeing what G2F spits out could give some idea of what limitations will apply.

[Heaven/TQA]

in meantime I love the "limit" feature of G2F... so actually using 1 font per line and leaving f.e. 32 chars untouchted... these could be used for the barriers... and 1 missle for the "player"

 

how is the level data stored?

[Rybags]

Aren't the levels just random?

 

Here's the soundtrack from original PC version... very 2600esque.

 

[Heaven/TQA]

yeah. btw. Got it on my iPhone....

[José Pereira]

Different ideas:

http://www.youtube.com/watch?v=YWvAocD21H0

[bfollett]

Looking at the video, the oncoming barriers can pass right under the score keeping text, so I can't see how you could use PMG graphics for both the score keeping and barriers. It might be simpler to just put a single standard (Gr.0) line of text at the bottom below the gaming area for score keeping and not have to worry about how it has to interact with the playfield.

 

Bob

[José Pereira]

Because on A8 the barriers have to be PFs. There's no way to have them as PMGs.

That's the reason why you have to code, probably, the A8 version from scratch.