Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Project M - needs your help.

Author
Message
haliop
User Banned
Posted: 6th Jun 2012 19:47
hello ,
Project M is a 3rd Person Shooter with multiplayer capabilites.

for now , there is no Character and no shooting, this is becouse i recently moved into DarkGDK 2.0 rc 4 and i expriance some fps fails.

what i need from you is to try it out a bit and post back the fps you get.

also the game may crush on startup so just run it again.

ty for your time and help.
please help , cause if i'll get low fps i might disband GDK and move onto another engine, i'm sorry but i will not play my games on 42 fps..

sometimes i get 40 and sometimes i get 60 and i wonder maybe it is the computer i'm developing with cause it heats up really fast so maybe that is the problem and not GDK , in GDK 1 i got stable 60 fps but since i moved onto the RC betas i expriance difficulties in containing a solid 60 fps.

pls help if you have like 5 minutes to play around.

Movment
W,A,S,D like all FPSs.
Space to jump.

pls help it will mean alot to me , ty.

Attachments

Login to view attachments
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 6th Jun 2012 20:17 Edited at: 6th Jun 2012 20:17
Couldn't run it at all. Tried about 10 times, get the same error over and over again.

Typically it's due to higher resolution than what's supported by the graphics adapter. I recommend you change your code so that display is created using the user's screen resolution (in my case it's 1280x800).




Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0

Attachments

Login to view attachments
haliop
User Banned
Posted: 6th Jun 2012 20:38
ohh forgot about that , ty.

however i do not know how to change according to induvidual users since
the old 1.0 gdk commands on checking aviable screen resolution is not found at 2.0.
Mistrel
Retired Moderator
19
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 6th Jun 2012 20:39 Edited at: 6th Jun 2012 20:40
Quote: "the old 1.0 gdk commands on checking aviable screen resolution is not found at 2.0."


This is covered in the documentation: How to > Basics for C++ > Fundamentals.

See the section on How to change the resolution.

haliop
User Banned
Posted: 6th Jun 2012 20:42
theres probably a C++ code using Windows.h but i just do not know about it ... not that familiar with C++, if anyone have an idea on how to check aviable Resoultion i will add it at program startup.
Mistrel
Retired Moderator
19
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 6th Jun 2012 20:43
Read the section in the documentation I just suggested.

Quote: "Identifying supported resolutions is also very easy using the Win32 API. Consider this example which will output all resolutions supported by the user's monitor matching the current display depth, refresh rate, and aspect ratio of the desktop:"


I then go on to provide example source code in C++.

haliop
User Banned
Posted: 6th Jun 2012 21:55
TNX matt.

ok copied pasted the example from the documented presented by Matt
changed it a bit and now the program will select the higest resolution aviable.

new file attached.

just now checked it out and i got about 43 fps
closed it , ran it again and got 60 fps

i dont really understand why this is happening but it makes me wonder..

Attachments

Login to view attachments
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 6th Jun 2012 23:46 Edited at: 6th Jun 2012 23:48
I tried your game- got an average of 55-60 fps. You're rendering too many high-poly objects far away. LOD or imposter system on those barrels would definitely improve the speed.


Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
haliop
User Banned
Posted: 7th Jun 2012 00:12
already using imposter with those barrels

check closly distand barrels and see for yourself
however i currently use 350 for distance can easily reduce it to 200 i just do want the pop when the imposter / object change to be so obvious.

and cool thing you didnot noticed it i feel good about that cause at any time most of the barrels are impostered.

thinking also when Dark occlusion will be aviable for us it will be even better.
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 7th Jun 2012 01:13
Quote: "already using imposter with those barrels"


Haha, true, didn't notice.

Suppose it's something else then, because I've been playing around with similar sized levels and got decent frame rates.


Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.60 + DarkGDK 2.0
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 7th Jun 2012 15:56 Edited at: 7th Jun 2012 17:52
I would say your main issue is the level geometry. It would help if you describe your technique for generating the levels. I think it's this because from the edges of the map looking towards the centre is when it slows down most. Try displaying poly count on your screen, dbStatistic().

When I go close to a wall I can see you are drawing polygons outside where you are not supposed to be able to see. This is a massive waste as you only need two polygons for each wall surface, not a whole cube.
This would probably be hard to correct, but I think it would be worth it.

You could try this simpler solution, add all your cubes which share the same texture to the same object via limbs, then make a mesh from the object, then make a new object which will be all your cubes in one mesh meaning only one draw call = faster.

Finally, you could try to add your own simple occlusion culling system while you wait for official version. You could hide major parts of the levels and all objects inside depending on where the player is. Just design your levels in such a way that makes this easy, such as a corridor linking two large areas.

Hope something there can help


EDIT: If you try out the easier option of creating one large mesh remember that you lose culling, you should probably find a balance of perhaps 50-500 blocks in each mesh so they still get culled.

haliop
User Banned
Posted: 8th Jun 2012 11:28
sorry i didnot understand the method with the mesh and limbs

this is how i generate the level :

first off its randomly generated.
i use for each floor a source box with induvidual texture
then i Instance all the walls in the same floor after the source.

so i have about 4 source cubes with textures
instancing them trought the level.

the barrels are using a simple imposter technic
and again instancing them after 2 source barrels one normal and one explosive.

this is basiclly it , the problem im having is diffrent from what one think it is , its not level geometry why?

cuase sometimes i get the full 60 fps stable but sometimes i get 45 fps
this dosenot accour ingame but from startup

so i can run it 5 times and get 60 fps
run it again and get 43 fps

so i think the problem is with GDK not the level geometry however i want to hear more about the turning it into one mesh , havent thought of it ... and obviously i dont know how to do it but this could defently turn things in the good way.

and about occlusion i simple have no idea how to make this happend , so i'll wait for the original DarkOcclusion to come out.
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 8th Jun 2012 13:04
Quote: "cuase sometimes i get the full 60 fps stable but sometimes i get 45 fps"


I tried your project multiple times and got same frame rates. On my laptop it only started to crawl when I looked at centre of the map (from edge). This is when the most polys are rendered so I also believe it's just an optimization issue.


Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.61 + DarkGDK 2.0
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 8th Jun 2012 16:56 Edited at: 8th Jun 2012 16:56
Quote: "the problem im having is diffrent from what one think it is , its not level geometry why?"


I agree with Olby's post. It slows down when there are more polygons on screen. This is a very common issue that many games have to deal with in different ways. Try putting the poly count on screen and you will probably see the connection.

If I get time later I will produce some code to see if the single mesh idea helps with cubes and if it does I will post the technique.

Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 8th Jun 2012 17:57
You can probably forget the single mesh thing, it's a little more complicated than I thought, uses more memory and is really slow to set up using the available commands.

There is still lots of optimisations you could try but none I know of are easy to implement.

haliop
User Banned
Posted: 8th Jun 2012 18:59
yeah that is why i wait for DarkOcclusion i am also thinking about using only needed polies instead of a whole cube, but havent conclude it yet so its all theory.

when DarkOcclusion is out the game will run awesomely.
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 8th Jun 2012 22:55
Quote: "when DarkOcclusion is out the game will run awesomely. "


Are there any plans on releasing DarkOcclusion for GDK? The last I've heard is that it wasn't a proper plugin dll thus requires substantial amount of work to be in-line with GDK.


Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.61 + DarkGDK 2.0
Red Eye
16
Years of Service
User Offline
Joined: 15th Oct 2008
Location:
Posted: 8th Jun 2012 23:07
Getting 58-60 FPS on a Intel Travelmate 2GB Integrated Graphic Card . So basically a 'oldfashion'-laptop runs it pretty damn good!

Good job!

Blue particles emitter is a bit wierd.

Cheers,

Mr Bigglesworth
16
Years of Service
User Offline
Joined: 4th Mar 2008
Location:
Posted: 9th Jun 2012 08:05
I got a solid 60 FPS through the whole thing on a Core 2 Quad 2.8GHz with 4GB of RAM and an Nvidia GTX460. It seems to run fine, but I got some camera clipping issues at the edges of the screen (my res is 1920x1080).
haliop
User Banned
Posted: 9th Jun 2012 12:21
ty , and yeah the camera still needs to be rebuild.
haliop
User Banned
Posted: 12th Jun 2012 21:14
Optimization! DONE!

so , what i did is
i took the original cube with 6 faces and optimized it so it will draw only the visible plains how? well
i created the cube, added SC Collision to it , deleted it then started checking around it , up,down,left,right,farward and backwards
if there is another cube for example to the left so i dont need the left face of the current cube cause the other cube will overlap it

did it to all faces and walla
now i have about 1/4 faces then the original where all cubes were rendred and there is simply no need for it , i attach the optimized file so you can see for yourself, just go to the corners of the map and rotate the camera a bit until you see it.

still i get fps lost sometimes but instead of falling to 43 it falls to 51 and thats an improvment!

so instead of an entire Cube for a wall segment the system draws only visible planes , THNAKS MATTY for the suggestion.

i still need an occlusion system but have no idea how to do it.
cheers.

Attachments

Login to view attachments
Olby
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 12th Jun 2012 22:15
Well done. I get solid 60 frames. You can further optimize my getting rid of back side polys. Additionally I think that particle emitter might be slowing things down a bit. Is it the built in emitter?


Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.61 + DarkGDK 2.0
haliop
User Banned
Posted: 12th Jun 2012 22:25
yes, and i plan to keep it cause it will be a huge part of the game, each player will have an emitter attached to its foot limb.

why do you know of another particle system?
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 12th Jun 2012 22:28 Edited at: 12th Jun 2012 22:29
Brilliant, I was having bad dreams about all those unseen polygons

I think an occlusion system which checks every object will not help you too much if most objects are only two triangles. I would have the editor create whole level sections which can be hidden, probably joined by corridors:

--------- ---------
| -------- |
| -------- |
| | | |
---- ---- ---- ----
| | | |
| | | |
---- ---- ---- ----
| -------- |
| -------- |
| | | |
--------- ---------

You could add as many as you like, you only need to show each section and its neighbours, if you make the corridors longer and add turns or slopes you may only need to show one section at any one time and your levels could be huge

EDIT: Drawing never worked, hope you get what I mean without it

haliop
User Banned
Posted: 12th Jun 2012 22:45
not really.. hmm
have no idea..
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 12th Jun 2012 23:48 Edited at: 12th Jun 2012 23:48
This is a basic example, the corridors are where the magic happens and only one section A,B.C or D is rendered at any one time.




Attachments

Login to view attachments
haliop
User Banned
Posted: 13th Jun 2012 00:45
that means i need to recreate my editor to randomly create corridors , which is not my aim.. however ty i will try to see how i can design a system to do something similar.
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 13th Jun 2012 01:09
It's just one idea, probably the easiest way to add occlusion culling, there are other ways, most are more complex.

JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 13th Jun 2012 17:00
Axis aligned bounding boxes come to mind. If the bounding box is not visible, and then nothing that it contains can be. What matty is talking about is called (I believe) portal rendering.

Regards,
JTK
haliop
User Banned
Posted: 13th Jun 2012 19:45
yeah well these portals needs to be configured automatic by the system and not like in other game engine where you would have an editor where you are creating the map , project M uses a random map generator , so its kinda tricky just to understand how to do this but this is possible.

i know portal redering pretty well from when i used to edit my own maps on Unreal/ Halflife and Call of duty maps , all uses them, call of duty the most.

look if this was an editor based map so yeah i would have done portal rendering already but , in my case its a tiled based random generator
so its just a matter of time on how to do it ... sometimes i think about an idea for a week or so before starting coding... portal rendering that sounds right.

still i think occlousion will work the best , does anyone knows if DarkOcclusion is coming out for GDK? mistrel maybe think of adding this plugin for us.

Login to post a reply

Server time is: 2024-11-19 00:26:28
Your offset time is: 2024-11-19 00:26:28