Thanks
[Edited by - WhatEver on April 14, 2005 11:31:59 AM]
Can you test my game?
Author
Edit: You can now download and unzip "Fruit Lobbers" directly to your hardrive without an installer.
The game is nothing special; I just want to see how it runs on someone elses computer.
Press escape for option settings. Press 'v' to toggle between first person and HoverCAM views. Press F9 for a list of obtrusive statistics.
If you want to just mess around, you can spawn 10 evil mikeys at a time by pressing ENTER, then if you want to wipe them all out pretty quickly, press 't' :). Careful though, to many watermellons really bog the game down :O and I don't know how a slower computer might handle that.
In solid render mode running in 640x480x32 with 54 root items(press enter 5 times, that's 50 evil mikeys), I get 42 FPS. With phong mode(per pixel shading) turned on I get 27 FPS.
Fruit Lobbers
Thanks
[Edited by - WhatEver on April 14, 2005 11:31:59 AM]
Thanks
[Edited by - WhatEver on April 14, 2005 11:31:59 AM]
Nice...
What language was it made in?
Btw, you might want to limit your framerate to 30, since some computers may run faster than others, and that affects the game dramatically...
What language was it made in?
Btw, you might want to limit your framerate to 30, since some computers may run faster than others, and that affects the game dramatically...
Author
Thanks! The game was written in C++ and uses OpenGL.
Are you getting fluxuations in object speeds due to increases and decreases in frame rate? You shouldn't be, but if you are, I'll need to look into the problem.
Thanks
Are you getting fluxuations in object speeds due to increases and decreases in frame rate? You shouldn't be, but if you are, I'll need to look into the problem.
Thanks
Looks very nice, especially when the per pixel lighting is used (phong) i'm getting a steady 60fps in 1280x1024x32 in this mode too with about 30 dudes and lotsa watermelons it drops to about 35fps but i don't notice the speed of the objects in the game changing at all. good work. How long did it take you to write?
PC specs
Athlon64 3200+ @ 2500MHz
Nvidia Geforce 6800 GT Drivers: v71.84
PC specs
Athlon64 3200+ @ 2500MHz
Nvidia Geforce 6800 GT Drivers: v71.84
Author
~technomancer
I started writing the tools in 2002, but it wasn't until about 6 months ago that I started the Fruit Lobbers project. That's not to long I guess.
I'm relieved to hear you say that the object speeds are fine. Testing this game on other computers seems to bring up issues you'd never think could exist. I hope this bad boy continues to work properly on everyone elses computers! :D
I started writing the tools in 2002, but it wasn't until about 6 months ago that I started the Fruit Lobbers project. That's not to long I guess.
I'm relieved to hear you say that the object speeds are fine. Testing this game on other computers seems to bring up issues you'd never think could exist. I hope this bad boy continues to work properly on everyone elses computers! :D
Nice job.
Running in fullscreen phong mode @ 1024 x 768 x 32.
No enemies - 140 fps.
10 enemies - 60 fps.
20 enemies - 40 fps.
30+ enemies and tons of fruit ~15 fps, but it still does not seem to take any noticable preformance hit or slow down at all.
This is on an older system.
AMD XP 2000+ @ 1250 MHz
ASUS A7V333 MB
1024 MB RAM
ATI Radeon 7500 (AGP 4x, 64 MB RAM)
Windows XP Professional (SP2)
Running in fullscreen phong mode @ 1024 x 768 x 32.
No enemies - 140 fps.
10 enemies - 60 fps.
20 enemies - 40 fps.
30+ enemies and tons of fruit ~15 fps, but it still does not seem to take any noticable preformance hit or slow down at all.
This is on an older system.
AMD XP 2000+ @ 1250 MHz
ASUS A7V333 MB
1024 MB RAM
ATI Radeon 7500 (AGP 4x, 64 MB RAM)
Windows XP Professional (SP2)
Author
Thank you!
Awesome McCoy! I'm glad the pixel shaders work with your ATI card! That means Cg is working just as it should.
I also like the performance. 40 fps with 20 evil mikey's in phong mode at that res is impresive. Between 30 and 60 fps with 20 enemies is my target range, and your system makes it.
FYI, 15 fps should be the lowest the framerate ever goes because I clamped the timer to that. So theoreticly, if you are actualy getting 7 frames a second, the game would look like it was in slow motion...half speed if you will.
Awesome McCoy! I'm glad the pixel shaders work with your ATI card! That means Cg is working just as it should.
I also like the performance. 40 fps with 20 evil mikey's in phong mode at that res is impresive. Between 30 and 60 fps with 20 enemies is my target range, and your system makes it.
FYI, 15 fps should be the lowest the framerate ever goes because I clamped the timer to that. So theoreticly, if you are actualy getting 7 frames a second, the game would look like it was in slow motion...half speed if you will.
Cool, whatever!
Nice watermelon physics too!
Default scene, @1280x1024 32 bit (desktop res)
Phong: 11 fps
Everything else: 61 fps
McCoy, you call that an older system! I'd dream of that (-64MB gfx card!)
Mine:
Pentium 800MHz
256MB RAM
NVidia GeForce FX 5200 (128MB) (new, but I saw a thread on its poor shader performance)
Windows 2000 Professional
Tips:
Shadow map resolution needs to be upped on cool systems because I'm afraid it looks a bit jaggy on my crappy PC
The cartoon shader seems to make no difference. The shader worked for my game, Rock Paper Scissors 3D. I diffuse texture mapped, lit with 3 specular white lights, then did 3 dependent reads into a cartoon mapping texture, then modulated that with a texture lookup with a dot product to get inked edges.
Oh, I'll give you some of the shader:
I also tried to ink the difference between colors on the texture map but it didn't really work because of the antialiasing in the texture map:
Have a look at this as well.
Real-Time Cartoon Rendering in DirectX 8
I actually based my method on the one described in 'Special Effects Game Programming with DirectX 8'
Hope this post helps :-)
Nice watermelon physics too!
Default scene, @1280x1024 32 bit (desktop res)
Phong: 11 fps
Everything else: 61 fps
McCoy, you call that an older system! I'd dream of that (-64MB gfx card!)
Mine:
Pentium 800MHz
256MB RAM
NVidia GeForce FX 5200 (128MB) (new, but I saw a thread on its poor shader performance)
Windows 2000 Professional
Tips:
Shadow map resolution needs to be upped on cool systems because I'm afraid it looks a bit jaggy on my crappy PC
The cartoon shader seems to make no difference. The shader worked for my game, Rock Paper Scissors 3D. I diffuse texture mapped, lit with 3 specular white lights, then did 3 dependent reads into a cartoon mapping texture, then modulated that with a texture lookup with a dot product to get inked edges.
Oh, I'll give you some of the shader:
float4 TnLSCartoonPixelPS(const in float2 tex0 : TEXCOORD0, const in float3 vertexToEye : TEXCOORD1, const in float3 normal : TEXCOORD2, uniform const bool lightsColored) : COLOR{ //Normalize interpolated vectors float3 N = normalize(normal); float3 VtoE = normalize(vertexToEye); //Calculate the lighting float4 specular; ComputeColorS(N, VtoE, lightsColored, specular); //Apply the diffuse map float4 diffuse = float4(tex2D(DiffuseSampler, tex0).rgb, 1) * MaterialDiffuse; //diffuse full on float4 color = diffuse + specular; color.a = Visibility; //CARTOON SECTION //Remap r, g and b separately color.r = tex1D(CartoonScale, color.r).r; color.g = tex1D(CartoonScale, color.g).g; color.b = tex1D(CartoonScale, color.b).b; //Multiply color by edge value to get outlines color.rgb *= tex1D(CartoonScale, dot(N, VtoE)).aaa; return color;}I also tried to ink the difference between colors on the texture map but it didn't really work because of the antialiasing in the texture map:
float4 TnLSCartoonPixelPS2(const in float2 tex0 : TEXCOORD0, const in float3 vertexToEye : TEXCOORD1, const in float3 normal : TEXCOORD2, uniform const bool lightsColored) : COLOR{ //Normalize interpolated vectors float3 N = normalize(normal); float3 VtoE = normalize(vertexToEye); //Calculate the lighting float4 specular; ComputeColorS(N, VtoE, lightsColored, specular); //Apply the diffuse map float4 diffuse = float4(tex2D(DiffuseSampler, tex0).rgb, 1) * MaterialDiffuse; //diffuse full on float4 color = diffuse + specular; color.a = Visibility; //CARTOON SECTION //Remap r, g and b separately float4 newColor; newColor.r = tex1D(CartoonScale, color.r + 0.015625).r; newColor.g = tex1D(CartoonScale, color.g + 0.015625).g; newColor.b = tex1D(CartoonScale, color.b + 0.015625).b; color.r = tex1D(CartoonScale, color.r).r; color.g = tex1D(CartoonScale, color.g).g; color.b = tex1D(CartoonScale, color.b).b; //Get difference between colors float3 diff = newColor.rgb - color.rgb; if ((diff.r + diff.g + diff.b) > 0) color.rgb = float3(0,0,0); //Multiply color by edge value to get outlines color.rgb *= tex1D(CartoonScale, dot(N, VtoE)).aaa; return color;}Have a look at this as well.
Real-Time Cartoon Rendering in DirectX 8
I actually based my method on the one described in 'Special Effects Game Programming with DirectX 8'
Hope this post helps :-)
It's fun in 1st person mode with loads of Mikies, and in the default window size with gouraud shading, it is fast. However, with about 50 Mikies and loads of watermelons the fps dropped to 10fps, even when looking straight at a wall. You could consider frustum culling but since the fps was the same looking the wall, it's probably the physics with all the objects bobbing around and colliding.
How did you do the collision detection? A sphere for head and a sphere for the body?
Cool
EDIT: Also cool music ;-)
How did you do the collision detection? A sphere for head and a sphere for the body?
Cool
EDIT: Also cool music ;-)
Author
DrGUI, yeah, the shadow map looks bad. That was the first time I ever tried implimenting it.
The cartoon shader is based on some old method where you draw wireframe backfaces first, then draw again with colored front face. The reason it looks bad right now is because I'm drawing the wireframe light grey, which doesn't show up to well.
I'm not at all good with shaders. For instance, I don't understand how bloom lighting can be done in a single pass(or can it) with a pixel shader. I also don't understand skinning much. So I've been focusing my attention on game engine layout while implimenting at least a foundation for vertex and pixel shaders. I appreciate the link and resources, I'll look into them when I get the chance.
Yep, you're partly right about the extremly slow framerate with many mikeys. Collision detection takes the biggest hit on frame rate, and culling hasn't been implimented yet. If you want to see what kind of frame rate you get without collision detection, press pause.
If you press 'b', all the objects' bounding boxes will be drawn. In this implimintation of the game, collision is actually happening when a bounding box is breached by another objects shape(only spheres for now). If you press 'c', a red box will be drawn when one object's shape breaches anothers root items bounding box.
If I wanted to impliment body/head collision, I would export a collidable mesh with the head and body, then if those collidable meshes bounding boxes were breached, they would be tested for collision. However, when I did export the collidable meshes, each mikey was testing if the other mikeys collidable meshes were colliding...which equaled very slow frame rates. This wouldn't be a problem if the mikey's would just stay out of all the other mikey's bounding boxes.
Press 'c' and watch how the frame rate drops when a bunch of watermelons are colliding with each other. You can get them to do this by pressing 't' in the corner of the room.
Press F9 to see how many bounding boxes have been breached/entered, and also how many triangles are being tested when you do the collision test.
The "triangle" label is how many triangles are being drawn.
The cartoon shader is based on some old method where you draw wireframe backfaces first, then draw again with colored front face. The reason it looks bad right now is because I'm drawing the wireframe light grey, which doesn't show up to well.
I'm not at all good with shaders. For instance, I don't understand how bloom lighting can be done in a single pass(or can it) with a pixel shader. I also don't understand skinning much. So I've been focusing my attention on game engine layout while implimenting at least a foundation for vertex and pixel shaders. I appreciate the link and resources, I'll look into them when I get the chance.
Yep, you're partly right about the extremly slow framerate with many mikeys. Collision detection takes the biggest hit on frame rate, and culling hasn't been implimented yet. If you want to see what kind of frame rate you get without collision detection, press pause.
If you press 'b', all the objects' bounding boxes will be drawn. In this implimintation of the game, collision is actually happening when a bounding box is breached by another objects shape(only spheres for now). If you press 'c', a red box will be drawn when one object's shape breaches anothers root items bounding box.
If I wanted to impliment body/head collision, I would export a collidable mesh with the head and body, then if those collidable meshes bounding boxes were breached, they would be tested for collision. However, when I did export the collidable meshes, each mikey was testing if the other mikeys collidable meshes were colliding...which equaled very slow frame rates. This wouldn't be a problem if the mikey's would just stay out of all the other mikey's bounding boxes.
Press 'c' and watch how the frame rate drops when a bunch of watermelons are colliding with each other. You can get them to do this by pressing 't' in the corner of the room.
Press F9 to see how many bounding boxes have been breached/entered, and also how many triangles are being tested when you do the collision test.
The "triangle" label is how many triangles are being drawn.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
