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.

[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...?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

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.