AArknoid: Vertical lines or no?

[+Gemintronic]

I'm wondering how many people care about the vertical lines in Arkanoid bricks. Without the lines I can put in an enemy that bounces around. With the lines no enemy.

 

NoLines.bin

Lines.bin

Flicker.bin

[+RevEng]

My vote is for no lines. The moving enemies/dropping powers are key elements for Arkanoid, and the brick appearance is a little less key.

[AtariFriend]

Vertical lines make a big difference. Looks like just another breakout without them.

[+save2600]

I vote for lines, but only if the enemies bounce around as they're supposed to I guess. Absolutely no other way around it? Maybe just haven't stumbled on a fix yet...

[+Gemintronic]

I vote for lines, but only if the enemies bounce around as they're supposed to I guess. Absolutely no other way around it? Maybe just haven't stumbled on a fix yet...

 

Well. The forbidden, secret third option is flickered vertical lines. Random Terrain almost had a seizure so I ONLY used flicker for the lines in this build. I'm wondering if people would find this to be a good compromise.

 

ADDED FLICKERING VERTICAL LINES OPTIONS AT TOP

[Mr SQL]

 

Well. The forbidden, secret third option is flickered vertical lines. Random Terrain almost had a seizure so I ONLY used flicker for the lines in this build. I'm wondering if people would find this to be a good compromise.

 

ADDED FLICKERING VERTICAL LINES OPTIONS AT TOP

Wow! The lines look incredible - excellent effect, I can't even see the flicker - definitely go with that version!

 

I can see why RT had seisures over the other version

[Fr0st]

Definitely needs lines, looks so much better and helps focus on what specific blocks you're aiming for

 

Edit - after just looking at all three, that flickering is horrible! Shame one thing has to be sacrificed for the other to work.

Edited March 24, 2014 by Fr0st

[enthusi]

As you know I hate flicker

But could you maybe have each row of bricks wobble in the other direction per alternating frame?

(I hope you know what I mean).

Im aware that this requires tighter code in that one line space but maybe that would be nicer?

This kind of flicker being a 'global' side-to-side flicker is kinda disturbing IMHO.

[Rybags]

IIRC there's actually 2 enemies at a time possible in Arkanoid, I'd prefer flickering enemies/powerups to the brick deliniation.

 

Once a few bricks have been cleared the lines become less important, and there's plenty of levels that have steps or shapes that make it clear as to the brick size as well.

 

On a static shot, it does look like another Breakout, but in a moving game once there's enemies and bonuses floating around it becomes pretty clear what game you're playing.

[+Nathan Strum]

I completely agree with this:

 

Once a few bricks have been cleared the lines become less important, and there's plenty of levels that have steps or shapes that make it clear as to the brick size as well.

 

So my vote would be for no lines.

 

The trick will be the doing color changes necessary for the metal bricks.

[+save2600]

Could the option for lines or not be incorporated via a difficulty switch or game option?

[+Omegamatrix]

That flicker hurt my eyes.

 

Here is your mission now. I would like to see you try another version where you alternate between two frames. First frame you draw the bricks. Second frame you draw the paddles, ball, and enemy.

 

This is a flicker utility I wrote for CAA. You can move a cursor around to change the background color. It gives you a quick idea of what combinations work colors to choose to minimize the flicker. In general on a dark background colors with low luminosity flicker less. On a bright background it is vice-versa.

 

 

FlickerTest.zip

 

 

Edit:

I forgot to say draw the bricks on the first frame with lines, of course!!

Edited March 25, 2014 by Omegamatrix

[enthusi]

It will be even worse for PAL, just in case anyone cares

[+Gemintronic]

That flicker hurt my eyes.

 

Here is your mission now. I would like to see you try another version where you alternate between two frames. First frame you draw the bricks. Second frame you draw the paddles, ball, and enemy.

 

This is a flicker utility I wrote for CAA. You can move a cursor around to change the background color. It gives you a quick idea of what combinations work colors to choose to minimize the flicker. In general on a dark background colors with low luminosity flicker less. On a bright background it is vice-versa.

 

 

FlickerTest.zip

 

 

Edit:

I forgot to say draw the bricks on the first frame with lines, of course!!

 

HOLY SWISS CHEESE AND HAM BATMAN!! That utility you whipped up is jawsome! I wish I had it back when I was making MMSBC II.

 

I'm a little slow so I am not altogether understanding the mission. Are you saying we should find out if drawing all the vertical lines half the time is better than half the lines all the time?

[Rybags]

A weird idea just came to me... and it might just work:

 

Instead of doing lines and sacrificing the clarity and number of other objects like enemies/bonuses - how about just having the bricks themselves flicker?

 

Think chessboard pattern. Show the bricks which would correspond to "white" one frame, the "black" ones the next.

Since it's in that pattern, it should be less annoying and also produce a nice deliniation between the bricks.

 

Disadvantage of course will be that instead of just several objects flickering, it'll be potentially a couple of dozen.

[Thomas Jentzsch]

 

HOLY SWISS CHEESE AND HAM BATMAN!!

A full screen flicker of the selected cell by pressing fire would be good too.

[+Gemintronic]

How do these wider bricks look? The advantages are a get to use both sprites for monsters. The missile could be used for lasers or an extra ball in play. No flicker!

 

WideBricks.bin

[roland p]

I would drop the lines and focus on the gameplay, enemies, bonusses, multiball etc. By the way, the lines do not look evenly spaced, which make it harder to check for ball-block collisions?

[+Gemintronic]

I would drop the lines and focus on the gameplay, enemies, bonusses, multiball etc. By the way, the lines do not look evenly spaced, which make it harder to check for ball-block collisions?

 

Not so much. The vertical lines are just eye candy. The collisions are strictly missile/playfield. What about my latest example above? The wide bricks seem evenly spaced and allow all the things you're talkin' about.

[Rybags]

It's probably a good idea to do brick/ball collision detection by calculation rather than collision register. You generally want the ball not to overlap the brick before bouncing off it.

 

I imagine the bricks would be simply kept in Ram as a bitmap + count of # remaining which should lend well to such a method.

Edited March 25, 2014 by Rybags

[roland p]

Like Rybags said, calculation will be better then register (assuming you check the register). Good physics/collision will create a better game.

 

 

Not so much. The vertical lines are just eye candy. The collisions are strictly missile/playfield. What about my latest example above? The wide bricks seem evenly spaced and allow all the things you're talkin' about.

 

I'm still processing it

It looks a bit oversized. The first one (nolines.bin) has the impression of a higher resolution due to more blocks and a smaller ball.

[+Gemintronic]

Using Omegamatrix's flicker tool I came up with this: Wide Blocks with Flicker

 

An improvement? Or, can people still feel the flicker?

WideFlicker.bin

 

P.S. Please try this full screen to avoid syncing problems.

[enthusi]

It doesnt flicker much, but also I dont see very much.

Flicker is directly proportional to contrast (no surprise

[+Gemintronic]

Slightly tweaked the contrast. Added custom score font. Changed ball back to a missile instead of the hardware ball. Yeah.

 

UPDATE: Now with Triangle enemy!

 

WideBrick3.bin

[+Omegamatrix]

There was a bug in the flicker utility for the bottom row. Here is the fixed version:

 

FlickerTest_rev2.zip

.

 

 

HOLY SWISS CHEESE AND HAM BATMAN!! That utility you whipped up is jawsome! I wish I had it back when I was making MMSBC II.

 

I'm a little slow so I am not altogether understanding the mission. Are you saying we should find out if drawing all the vertical lines half the time is better than half the lines all the time?

.

 

I meant something like this:

 

 

 

Choose your colors carefully, so they don't flicker so much. I just threw these mock ups together in Paint, and it doesn't represent what the actual colors should be.

 

The important elements are that by alternating frames you can draw the bricks with lines, and draw an extra enemy or two. The borders don't have the color bleed from the blocks on them. I'm not sure if the ball can have an independent color, but I drew it black anyhow...