Crude but pretty Vectrex style graphics.

Community Forums/Showcase/Crude but pretty Vectrex style graphics.

Ryan Burnside(Posted 2009) [#1]
I know there have been a few but here is my stab at this effect.

For blitzmax.



Source and executable included.
http://www.mediafire.com/?q0znzytylwz


Ked(Posted 2009) [#2]
Very nice! Is that a ghosting-effect I see?


Ryan Burnside(Posted 2009) [#3]
Well yes, I REALLY REALLY wish that we had a solid way to mess with different graphics buffers, but since we don't I cheated and just drew a black transparent square before each draw. There is no CLS function used to make the blurr. My Vectrex at home blurrs a bit when things move so I wanted to capture that.

Please Mark, give us some screen buffers to play with so blurring and raster manipulation of drawn images can be done! Rendering to a texture is a great thing for special effects.


Ked(Posted 2009) [#4]
I know what you mean! Hopefully, Mark is planning on doing that sometime soon. ;)


jsp(Posted 2009) [#5]
Looks nice. Well done!


GW(Posted 2009) [#6]
Interesting, I've been looking forward to a working glowing-line.
its not too bad for oGL, but it chokes my GTX280 using Dx7/Dx9.


Ryan Burnside(Posted 2009) [#7]
This would probably be much much faster in raw OpenGL. I think the line sprite which consists of 3 segments could be stored as an OpenGL display list. The list would be called for each line.

Currently the main problems with my method are

1 Trig functions, the sprites must be rotated and this requires a atan2 check between the 2 sets of points.
2 Sprite stretching, this takes a bit of time too since the texture length must be calculated via a costly square root operation.

I suppose if you wanted, you could procedurally draw all your game objects to the backbuffer then copy them pixel by pixel and store them as one sprite before the game starts. This way you would still retain the vector glow. You then just draw the composite sprite that you have made before run time instead of calling a bunch of draw commands. This might be a good solution as long as you don't need a bunch of dynamic lines.

Keep the comments coming if this is interesting to you.


Ryan Burnside(Posted 2009) [#8]
I now feel compelled to ask for a bit of help. Does anyone see a way to improve my code? I'm not always the good at seeing optimizations...

I don't think lookup tables are good for the line trig functions since they can put a gap in the endpoints and the body of the line due to rounding errors.

Also is anyone interested in using this technique? All the texture and code is provided for your use if you are interested.


Grey Alien(Posted 2009) [#9]
Nice work. Looks good.


Ryan Burnside(Posted 2009) [#10]
I just noticed that the lines are not being drawn in the correct place. For some reason the Y coordinate is getting shifted down a bit. I'll look into this.


Jesse(Posted 2009) [#11]
There seem to be something wrong with the DrawImageRect. it does not rotate correctly. You can really see the problem when the images get wider.
I was trying to do something similar a while back with a laser beam but gave it up sense it would not align properly when turning.