Could CV do vector graphics?

[tz101]

You know, like arcade-close translations of Asteroids, Tempest, Black Widow, or Battlezone?

[VectorGamer]

You know, like arcade-close translations of Asteroids, Tempest, Black Widow, or Battlezone?

 

See Space Fury and Omega Race...

 

The short of it is no...it's a better than nothing effort

 

That's why you need a Vectrex...problem is we could use more titles for it

[retroillucid]

Yes it can

 

I made some graphics works on Tempest for Colecovision, Pixelboy also made some graphics works on Asteroids

[Rex Dart]

It could probably do a vector or two

[ed1475]

You know, like arcade-close translations of Asteroids, Tempest, Black Widow, or Battlezone?

 

Those would be cool for the cv along with Red Baron.

 

Isn't CV Star Wars: The Arcade Game considered vector graphics?

Edited July 20, 2011 by ed1475

[raskar42]

star wars is a great conversion .

[Pixelboy]

You know, like arcade-close translations of Asteroids, Tempest, Black Widow, or Battlezone?

Well, Asteroids is definately doable, by "imitating" the vector graphics with tiles and sprites, but the others would be much more difficult to pull off. The problem with the CV is that the video RAM is completely distinct from RAM, and the only link between the video RAM and the CPU is a very slow transfer bottleneck that can only pass one byte at a time. So you can't update the TV screen fast enough to do proper vector-style graphics.

[VectorGamer]

Yes it can

 

I made some graphics works on Tempest for Colecovision, Pixelboy also made some graphics works on Asteroids

 

Screenshots or vids?

[Pixelboy]

Yes it can

 

I made some graphics works on Tempest for Colecovision, Pixelboy also made some graphics works on Asteroids

 

Screenshots or vids?

You can see some man-made mockups of Asteroids on my web site. The actual game should look very much like those mockups. I don't recall ever seing J-F's rendition of Tempest...

[VectorGamer]

Yes it can

 

I made some graphics works on Tempest for Colecovision, Pixelboy also made some graphics works on Asteroids

 

Screenshots or vids?

You can see some man-made mockups of Asteroids on my web site. The actual game should look very much like those mockups. I don't recall ever seing J-F's rendition of Tempest...

 

What are man-made mockups?

[Pixelboy]

What are man-made mockups?

Mockups made with Microsoft Paint, in this case. The game doesn't actually exist yet, you know.

[VectorGamer]

What are man-made mockups?

Mockups made with Microsoft Paint, in this case. The game doesn't actually exist yet, you know.

 

So, in the case of Asteroids, it's possible that the end product could look somewhat like Space Fury?

[retroillucid]

I don't recall ever seing J-F's rendition of Tempest...

 

Here's the CV Tempest test rom

 

*NOTE this Test rom will not work in BlueMSX*

 

 

 

EDIT: Will work on your SD/USB Multicart

Tempest CV.bin

Edited July 20, 2011 by retroillucid

[Pixelboy]

What are man-made mockups?

Mockups made with Microsoft Paint, in this case. The game doesn't actually exist yet, you know.

 

So, in the case of Asteroids, it's possible that the end product could look somewhat like Space Fury?

Well, they changed the graphics in Space Fury on CV a little bit, to take advantage of the use of sprites instead of vectors, but yeah, it would be something like that. But I would go with graphics that closely resemble the arcade game, to get as close to the arcade experience as possible.

[youki]

Vector graphics on CV purely monochrome are perfectly possible. Of course the number of vector on screen is not illimited if you want acceptable framerate... a correct rendition of Battle zone or Asteroid should be doable.

 

But nothing comparable to what a vectrex can do. Vector graphics on raster screen didn't translate well in my opinion. I love Vector Game on a vectrex but i have never liked rendition of the same kind of game on other machine.

 

The problem is the screen resolution. To render in an acceptable way a vector game you need at least a 1024x768 pixel of resolution, imho.

[GroovyBee]

The problem is the screen resolution. To render in an acceptable way a vector game you need at least a 1024x768 pixel of resolution, imho.

 

I'd say at least 320 pixels in X is good enough. That is the resolution Elite on the BBC micro ran at. Having said that, Starion on the Spectrum was pretty good too and it only has 256 pixels available horizontally.

[opcode]

To get acceptable speed in a 3D vector game we would need a frame buffer (lots of RAM), something the stock CV doesn't offer.

And as Youki said, only monochrome games. The tile structure of the CV VDP makes it kind of hard to have those games done. On the hand they made Elite for the MSX1, so it is definitely possible. But again, lack of RAM is a big issue.

[VectorGamer]

Vector graphics on CV purely monochrome are perfectly possible.

 

That's what I'd like to see with Asteroids. I really don't care for the Atari versions where they used colored graphics.

 

What's cool with Omega Race on the C64 is you can choose your colors.

[opcode]

Well, they changed the graphics in Space Fury on CV a little bit, to take advantage of the use of sprites instead of vectors, but yeah, it would be something like that. But I would go with graphics that closely resemble the arcade game, to get as close to the arcade experience as possible.

 

Actually they changed everything to tiles in Spaec Fury. The problem (now, as honestly I didn't mind back then) is that everything moves in 8 pixels increments.

As I understand, for a game as Asteroid you can have all the objects already rendered and shifted in all possible positions stored in ROM, so it would be just a matter of ORing everything together and sending to the video. And of course you are going to need some smart routines to update the screen...

 

[EDIT]: For 2D vector games, I think it is a matter of someone designing a [good] driver and it should take care of all those games.

Edited July 20, 2011 by opcode

[Pixelboy]

As I understand, for a game as Asteroid you can have all the objects already rendered and shifted in all possible positions stored in ROM, so it would be just a matter of ORing everything together and sending to the video. And of course you are going to need some smart routines to update the screen...

That's exactly what I was thinking of doing for Asteroids. And the renderer would need to be smart indeed, because asteroids can overlap each other as they travel across the screen. The best method for updating the screen with overlapping moving patterns is something I often think about...

Edited July 20, 2011 by Pixelboy

[opcode]

As I understand, for a game as Asteroid you can have all the objects already rendered and shifted in all possible positions stored in ROM, so it would be just a matter of ORing everything together and sending to the video. And of course you are going to need some smart routines to update the screen...

That's exactly what I was thinking of doing for Asteroids. And the renderer would need to be smart indeed, because asteroids can overlap each other as they travel across the screen. The best method for updating the screen with overlapping moving patterns is something I often think about...

 

Overlaping stuff on screen is easy to do, as I said it is simply OR'ing them together. The problem is removing the stuff from the previous animation frame. That requires quite some optimizations. Again, it would be a lot easier and faster if we had more RAM, because we would do everything on RAM first, upload only the updated tiles to VRAM when done and use a dirty bitmap to remove any remaining tile from the previous frame that wasn't update.

[youki]

As I understand, for a game as Asteroid you can have all the objects already rendered and shifted in all possible positions stored in ROM, so it would be just a matter of ORing everything together and sending to the video. And of course you are going to need some smart routines to update the screen...

That's exactly what I was thinking of doing for Asteroids. And the renderer would need to be smart indeed, because asteroids can overlap each other as they travel across the screen. The best method for updating the screen with overlapping moving patterns is something I often think about...

 

Overlaping stuff on screen is easy to do, as I said it is simply OR'ing them together. The problem is removing the stuff from the previous animation frame. That requires quite some optimizations. Again, it would be a lot easier and faster if we had more RAM, because we would do everything on RAM first, upload only the updated tiles to VRAM when done and use a dirty bitmap to remove any remaining tile from the previous frame that wasn't update.

 

you can do simply XOR'ing instead of OR'ing , the first XOR draw , the second at the same location clear. For a pure vector game it works pretty well. (even if in that context of monochrome, i'm not sure the xor'ing would be really necessary , it could be faster to redraw the shape simply in black )

And by organizing your name table and color table smartly you can ignore them completly , and only work on the Pattern table to draw your vectors. You don't have to bother about "tile". "Just" have to do a faster as possible line drawing routine.

[Pixelboy]

As I understand, for a game as Asteroid you can have all the objects already rendered and shifted in all possible positions stored in ROM, so it would be just a matter of ORing everything together and sending to the video. And of course you are going to need some smart routines to update the screen...

That's exactly what I was thinking of doing for Asteroids. And the renderer would need to be smart indeed, because asteroids can overlap each other as they travel across the screen. The best method for updating the screen with overlapping moving patterns is something I often think about...

 

Overlaping stuff on screen is easy to do, as I said it is simply OR'ing them together. The problem is removing the stuff from the previous animation frame. That requires quite some optimizations. Again, it would be a lot easier and faster if we had more RAM, because we would do everything on RAM first, upload only the updated tiles to VRAM when done and use a dirty bitmap to remove any remaining tile from the previous frame that wasn't update.

Sounds like Asteroids would be a good homebrew project to do with your SGM. Not only for the screen renderer, but also for the sound output, as I doubt the CV PSG could replicate the arcade sounds as well as the SGM could.

[Pixelboy]

you can do simply XOR'ing instead of OR'ing , the first XOR draw , the second at the same location clear.

Does the Z80 have a XOR opcode? If yes, then the argorithm could be quite speedy...

[opcode]

you can do simply XOR'ing instead of OR'ing , the first XOR draw , the second at the same location clear.

Does the Z80 have a XOR opcode? If yes, then the argorithm could be quite speedy...

 

Yep, it has. The problem is, the more you need to access VRAM, the slower the result will be. That is why a framebuffer in RAM would help so much.

It also doesn't help that the CV VDP only offers tile modes, as you need to set the VDP address pointers several times to transfer a complete shape of let's say 24x24, and you need to spend time calculating those addresses.

Though you can improve transfers from/to VRAM a lot if you know how to properly set the pointers and how/when do the transfer.