Cave flying technique

[User137]

I want to show a technique i used in this video (using my nxPascal):
http://www.youtube.com/watch?v=0BrFwCob8xI

Commonly it is believed that manipulating hardware accelerated graphics in pixel level is slow. Therefore a whole genre of "caveflying" games were forgotten for years.

I'm using OpenGL's framebuffer object extension. To make explosion hole in map texture, i'm drawing a black circle through framebuffer. Using substractive filter it is able to remove alpha channel from that part of the texture. For collisions there is a separate boolean array so i don't have to read from texture at any point.

If i set to full timer mode at Sleep(1), i'm getting 800-1200 fps while using 1680x1050 resolution, and while firing button is held down. Removing sleep(), makes fps go above 4000 but also giving frightening noises from my monitor... I mean this technique is extremely fast for this.



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

[paul_nicholls]

that is pretty cool indeed! :)

Any chance of sharing some source code? ;)

cheers,
Paul

[WILL]

That's impressive! I'd love to have a tutorial on how to do that here on PGD or in the next issue of Pascal Gamer Magazine. :)

[pstudio]

Looks good and +1 for sharing code :)

[Traveler]

That's pretty neat indeed!

[phibermon]

Excellent effect! there are all kinds of ways of using this in a game, worms of course springs to mind :)

Love it! what graphics card was used in the example video? Would you say that the CPU bound checks on the boolean array were the limiting factor?

(and are you sure that the noise you're hearing at high framerates is coming from your monitor and not the voltage regulators on the motherboard/GPU? it's a high pitched 'screech' like you get when you turn on old Tv's right? despite the high frame-rate numbers, the monitors refresh rate will not vary)

[User137]

Thanks for the feedback, and yeah it was sort of like high pitched screech i heard. I'm not sure if the monitor cable is firmly attached though, i have tried my best but it sometimes shows feint "shadows" of different things on screen.

I added zip in the first post, it includes compiled exe and source code. To compile you also need nxPascal which is in this thread:
http://www.pascalgamedevelopment.com/showthread.php?8785-nxPascal
The source is of Lazarus, but nxPascal itself is Delphi compatible too. So with little to no changes this would work with Delphi, there is one framebuffer demo for Delphi.

Graphics card i use is Radeon HD 5700, cpu E8400 3GHz dualcore.

[phibermon]

Thank you, I'll take a good look and see if I can write my name with fire while I'm at it :) Oh and that 'ghosting' you're getting on screen (the faint shadows) is most commonly due to a poor analog signal, often due to electrical noise (is your monitor cable hanging down, crossing power cables at sharp angles? move it around, you'll most likely see the ghosting change)

I'm not sure if it will work for you, but I've fixed such ghosting in the past by looping the monitor cable through a ferrite ring. A lot of cables have ferrite rings already, (normally a cylinder at the end of the cable wrapped in plastic) but they don't loop the cable round the ring, just go through it once, minimizing the effectivness.

Poor signal might just be due to weak contacts in the cable, if your monitor cable is detachable, try replacing it.

But that's beside the point, I've not checked out nxPascal yet so I'll give it a read :)

[User137]

Happy to announce the project now has water physics ready ;D

Water is in 2 parts: as particles and solid in texture. The particles are only namely, because they don't move. Sharing density to down, left and right it makes it appear as they are moving. I didn't expect it to work this good...

1 BUT with it of course; max amount of moving water is 65535. If you go above that you may experience water not dropping down or something weird. If i added 2 more bytes per pixel this could be fixed at cost of little more memory.

Additionally the project no longer uses hole texture, but GL_POINTS per pixel for explosions holes and water. It still proves to be incredibly fast even if there are thousands updates per frame. This fixes the old problem of colliding to invisible pixels as everything with collision map and texture are now perfectly in sync.

Collision map was previously boolean, but now it's used as material map of bytes, where 0=Air, 1=land, 2=MovingWater, 3=StillWater. And leaves much more room to expand later if needed.

Edit: I'll update first post project file instead.

[Ingemar]

Great example of creative texture processing. Inspiring, I think I can come up with some variants. 2D water is pretty much a kind of filtering, although nonlinear. The cave flying is even better, although the changes are in small areas.

I just had a look at the source. No shaders, right? I guess it isn't needed, the FBO's are the key. But for water, I would expect you to use a shader.

[User137]

No shaders needed, i expect all my games to work on wide variety of computers and graphics cards. So pixel shaders would be going out from that, limited to only new cards.

But as far as efficiency goes i can think of ways to improve it even further. For example i'm using glBegin(GL_POINTS),glVertex,glEnd sequence which could be replaced with vertex array. Each individual pixel call would add to array stack and once operations are done or pixel tool changes, or stack goes full, it would draw all at once. But as the drawing part is still very fast i don't think there's need to, yet.

[Ingemar]

No shaders needed, i expect all my games to work on wide variety of computers and graphics cards. So pixel shaders would be going out from that, limited to only new cards.
I would call them fragment shaders since we are talking about OpenGL. Anyway, if you support computers without shaders, you are going way back. Is it important to support computers from 2003? (It is good from an environmental perspective but I am not sure it will affect your sales.) Of course, if we also include hand-held equipment the picture changes quite a bit.


But as far as efficiency goes i can think of ways to improve it even further. For example i'm using glBegin(GL_POINTS),glVertex,glEnd sequence which could be replaced with vertex array. Each individual pixel call would add to array stack and once operations are done or pixel tool changes, or stack goes full, it would draw all at once. But as the drawing part is still very fast i don't think there's need to, yet.

Immediate mode is indeed slow. Just moving to glDrawElements speed things up a lot (by an order of magnitude for a complex scene), and VBOs will improve things further. It depends on how much geometry there is. If the polygon count is low it doesn't matter.

[User137]

I did a major change to the water system in preparation to make Pixelcolony (project name) to more like a game. Earlier the water particles didn't move and had a density. It was fun for "scientific" study but not really as efficient as it can be.

But now the system fits better for games. Water particles don't have density anymore and they fully move themselves to either down, left or right. This means that i was able to remove watermap index array and reduce code and memory use by alot. The water itself of course acts slightly sharper because every particle is either on or off, not between. Animation became faster, water stabilizes faster, no gaps are left anywhere and that causes solidifying to be more efficient. Where old code had particles remaining in thousands when "stable", it is now reduced to ~10-50 which is the absolute water surface only. Also because indexarray was removed, it would now be easier to increase the max amount of moving water.

It's not very different visually so don't really need a screenshot, although animation sure is different and better. One difference is almost lifelike "bubbles" that come to surface when explode there. But i'll drop this topic because i really might flesh that into a game, and release more info then. The current issues to come lie in basic ship tools, computer controlled bots, cave generation and overall map that looks attractive. I'm a fan of old, now buried, game Fuse. It was similar pixelmap game which added elements from Command and conquer. Harvestable resources, structures, infantry units, turrets and all kinds of things. But will see what comes of this :) I will definitely add sand too.

[paul_nicholls]

Nice work! did you update the download file in the first post with the latest version?

cheers,
Paul

[KidPaddle]

I had a look into your code and maybe there is a little failure on

// Move and collide players
for p:=0 to 0 do
with pl[i] do begin
iy:=iy+5*lag/1000; // gravity

"with pl[i] do begin" must be "with pl[p] do begin"?

Thomas

[User137]

Thanks KidPaddle, failure is fixed :) Luckily variable "i" just earlier went through for 0 to 0 so it worked.

And paul, i just now added zip to first post. There is also new keys to use, Numpad + and - to change zoom level (1x-6x).

What i last added yesterday was that when water detaches it takes parameter on which direction it will start heading into. Like, if a water particle collides it from right, it will start moving left rightaway, if it can't go down or once it falls down. I think this chain reaction was part of making it faster fluid.