I've got yet another public alpha of Vectorzone out. Now you can shoot the walls down: http://www.pixelships.com/vzone/downloads.html

...though considering no one responded to my initial posting of this I'm at a loss as to whether or not I should keep posting my updates here, since they're going to be roughly every two to three weeks each now, unless I once again run into some major disaster that requires yet another total redesign of the game, but somehow I doubt that's gonna happen. ;)

But yeah, do you guys want me to keep posting each update or save my next post about Vectorzone for when the game's had lots of major additions?

In any case, have a couple clickable screenshots:

This would look sick with one of those boss CRT shader mods running.

Like post #11 in this thread: Patch for OpenGL fullscreen bug

Do keep posting updates, I'm sure more people will start chiming in once the game has more playable ...stuff in it.

For now I can say it looks cool graphics-wise. Still getting used to the dual controls system (by pure coincidence, earlier today I came across Invaders Corruption: it has similar controls and is very twitch-based, which feels like good practice).

SquallStrife wrote:

This would look sick with one of those boss CRT shader mods running.

But then the underlying resolution would have to be quite low, on the order of 320x200/240, as making those nice scanlines involves a good deal of upscaling. Besides, the glow effect is already kicking my ancient GPU's ass hard enough all by itself...

... it's like anti-Qix... 😁

VileRancour wrote:

But then the underlying resolution would have to be quite low, on the order of 320x200/240, as making those nice scanlines involves a good deal of upscaling. Besides, the glow effect is already kicking my ancient GPU's ass hard enough all by itself...

The game supports all resolutions from 640x480 and higher. It's designed to look its best at 1280x960 or higher and the sprites have additional detail so they look sharp all the way up to 2560x1920. ;)

Also you can turn the glow effect on and off with F6 and alter the way the map is drawn with F7. Turning the glow off and using the translucent mode with the map also makes for a good look that won't kill the framerate, since the glow shader burns roughly 3,000,000,000 pixels of GPU power per second. o_o;

Yeah, was aware of F6/F7 (I did check out the readme). 😉 On this machine, fullscreen @ 1280x1024 gives me 30fps without glow, 10fps with it... I do have another box with a more modern video card, and now that I actually tested on that one, it has no problem getting 60fps at the same resolution with glow enabled. Looks much, much more impressive.

To clarify, my comment about resolution was just in regard to the CRT shader that was mentioned (it needs a lot of wiggle room to do its own upscaling, so it looks best with the "target" resolution as high as it can be, but the "source" resolution has to be much lower).

Would it be faster to just precompute glow "textures" with opacity and render them with additive alpha blending, than to do it all dynamically per-pixel with convolution with the GPU?

Walls would be simple, since you'd only have vertical, horizontal, and corner cases to consider. I guess you could do anything with a lot of animation frames dynamically, but you'd probably cut the work down quite a bit by using "texture" glow for more or less fixed parts of the level. Seems like it'd be a reasonable memory/performance tradeoff, anyway.

Although I guess I should say that I've not done games programming in... well, a very long time, and definitely haven't touched GPU programming (although conceptually, I know they're very good at simple, massively parallel operations ideally with little to no conditional branching or looping)

The Gecko wrote:

Would it be faster to just precompute glow "textures" with opacity and render them with additive alpha blending, than to do it all dynamically per-pixel with convolution with the GPU?

Yes, and if I was only using sprites, that's what I would do. ;)

The trouble is the tiles. Back when the tile sizes were larger and I still had the spinning camera, I was really not liking the idea of learning to write fragment shaders because none of the tutorials I tried seemed to work and everyone had a different approach and different ideas about what was valid and what wasn't. I forget the exact reason why I determined that pre-computing wasn't going to work but I believe it revolved around requiring way too much texture memory. (A single tile type would take up over 4 MB, and I had almost 60 tile types to load in all at once; do the math... most GPUs don't have that kind of memory.)

Now that the tile sizes are nine times smaller by area, it may be possible, but I feel going back to that at this point is like trying to fix something that isn't broken. 3,000,000,000 pixels a second may seem like a lot, but my old, mid-range GeForce 9800 GT can handle over 7,000,000,000 a second, and modern mid-range cards are similar, so it's more than enough power. Even when things get hectic and lots of sprites are on-screen, that number's barely going to go up any. ;)

The Gecko wrote:

Although I guess I should say that I've not done games programming in... well, a very long time, and definitely haven't touched GPU programming (although conceptually, I know they're very good at simple, massively parallel operations ideally with little to no conditional branching or looping)

My graphics card can process 112 pixels at the same time. CPUs can only dream about that kind of multi-processing! ;D

The fun thing with the fragment shaders I've developed is that they work on the scene as a whole, rather than on each sprite and font glyph that's pasted in. (Which is the way most coders would do it.) The bottleneck on my system for GPU access is about 10,000 sprites per second while maintaining 60 FPS, which isn't anywhere close to what the GPU can handle and is a limitation of the amount of overhead it takes to drive that many sprites to the GPU in the first place. As a result, the power used by the glow effect doesn't interfere with the power used to render the scene in the first place, so performance at present is barely going to be affected once more stuff gets drawn per second.

Also, 3,000,000,000 is probably an over-estimate. I have three quality settings for the glow shader: Low, High and Ultra, the default setting being High. On Low, it uses 8 times less GPU power but can be hard to look at unless you're also running at 640x480. On Ultra, it uses 8 times MORE GPU power, yet on Ultra, I'm still able to reach about 55 FPS.

Gemini000 wrote:

(A single tile type would take up over 4 MB, and I had almost 60 tile types to load in all at once; do the math... most GPUs don't have that kind of memory.)

WHAT?
There's no way your individual tiles are 1k x 1k (assuming 32bpp RGBA)

1k x 1k?

I dunno where you got that number from. Before removing the spinning camera, each tile was 48x48 pixels large and had 46 variants. One tile type would thus take up 48 x 48 x 46 x 4 = 414 KB of memory. Now that the tiles are only 16x16 pixels big, this translates to 16 x 16 x 46 x 4 = 46 KB.

But remember, this is without pre-computed glows, which would take up a MASSIVE amount of memory if I went that route, and they would look horribly inaccurate without using fragment shaders to blend them together anyways, so one way or another, I'm stuck using fragment shaders. Might as well let them do the entire glow effect and save that video RAM for things like depth-effect buffers and whatnot. :P

3 gigapixels/sec may seem like a lot, but most modern mid-range video cards can handle at least 5 to 10, and the high end cards can reach 30+. Add some SLI and you're really cookin'! ;D

Well, you said a tile would take 4MB, so that's 1M pixels at 32bpp, or 1k x 1k square.

I mean, I don't doubt that you know the size of your own textures, that just seemed like a bizarrely large number for such small tiles.

When I said that I was trying to figure out how much memory the old 48x48 tiles would use if I pre-computed the glows and hadn't yet remembered why I decided against going that route, nor was I remembering all the steps necessary. :P

But yes, pre-computing the glows would be the best way to do it if I didn't have tiles and maps to worry about and just sprites.

Are you doing the glow calculation for the entire map or only the part (with some extras) of the part of the screen that is actually visible ?

It's a screen filter. Here's the way it all goes down:

1: Render newly visible tiles to the TilePage Texture.
2: Render the TilePage Texture to the Draw Buffer.
3: Render all sprites and other elements to the Draw Buffer.
4: Render the Draw Buffer to the Glow Buffer at the current glow shader's quality level.
5: Process the Glow Buffer through the Horizontal Blur Shader.
6: Process the Glow Buffer through the Vertical Blur Shader.
7: Draw both the Draw Buffer and Glow Buffer to the Back Buffer simultaneously using the Glow Effect Shader.
8: Vsync, flip the visible screen page to the Back Buffer, and do it all over again for the next frame! :D

Basically, the way I calculate the GPU power of the glow quality settings is simply determining how many pixels I'm accessing over the course of them when running 1920x1080 screen resolution:

Glow Setting = Low
Glow Buffer is 512x512 pixels big. 12 pixels need to be sampled/written per blur pass. Maximum pixel ops: (512 x 512 x 12 x 2 + 1920 x 1080 + 512 x 512) x 60 FPS = 517,632,000 Pixels/sec

Glow Setting = High (Default)
Glow Buffer is 1024x1024 pixels big. 22 pixels need to be sampled/written per blur pass. Maximum pixel ops: (1024 x 1024 x 22 x 2 + 1920 x 1080 + 1024 x 1024) x 60 FPS = 2,955,571,200 Pixels/sec

Glow Setting = Ultra
Glow Buffer is 2048x2048 pixels big. 42 pixels need to be sampled/written per blur pass. Maximum pixel ops: (2048 x 2048 x 42 x 2 + 1920 x 1080 + 2048 x 2048) x 60 FPS = 21,515,366,400 Pixels/sec

The Ultra setting is basically for people with stupidly powerful graphics cards who don't know what to do with them, but the glow effect looks extremely good in that mode. :3

The Low quality mode is extremely hard to look at if you're running higher than 640x480 resolution. :P

EDIT: I just did another test with the Ultra mode and yeah, despite my GPU toping out around 7 Billion-something pixels a sec I'm still able to hit 56 FPS average with it, so I'm guessing my routines could very well be using up to and over three times less power than I think they are... *shrugs*

And now, there's candy-coated particle effects and enemies to shoot down! :3

Yup, got another public alpha out: http://www.pixelships.com/vzone/downloads.html

Another development journal too:
http://www.pixelships.com/vzone/dj06.html

And of course, clickable screenshots! :D