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.

DarkBASIC Professional Discussion / How to optimize a fps 3d game at it's best for netbook

Author
Message
darkvee
20
Years of Service
User Offline
Joined: 18th Nov 2005
Location:
Posted: 8th May 2012 23:05 Edited at: 8th May 2012 23:08
Does anyone know what steps you would use to insure your game has a lot of detail counting polys and textures and squeezes everything out of your game for a netbook.

I'm very experienced but I really want to know how you optimize your game for a netbook at it's fullest. I'm looking to make a game that doesn't seem it would be able to run on a netbook.

darkvee
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 9th May 2012 13:07
avoid hardware shaders... and keep texture sizes down... and the rest will be added by someone else later

Seppuku Arts
Moderator
21
Years of Service
User Offline
Joined: 18th Aug 2004
Location: Cambridgeshire, England
Posted: 9th May 2012 13:45
For meshes just make sure when you model them you keep the polygon count down, it is actually possible to have a good looking low poly mesh - you just rely on textures for the rest of the details. Try to keep the number of objects in a scene/on display down to a minimum. As Mr Valentine said avoid hardware shaders. If you want your lights to look good use a lightmap. Something like Cartography Shop or MapScape will be useful for building and lightmapping those levels. They'll look good without the fancy shaders. Character shadows don't have to be shaders either or anything sophisticated, you could make a blob shadow.

However, if you do wish to add shaders, make sure they're optional. You might decide you want a stencil shadow on your characters, but find it's too much processing power for a netbook but works fine for a normal PC.

Also, as mentioned, texture resolution should help, you don't need to go mad and make tiny ugly textures but understand the larger your textures there's more data to process.

Matty H
17
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 9th May 2012 14:03
When I looked into appup development the advice given there was to do as much as possible on hardware.

A game I made slowed right down in the menu with lots of 2D going on, while the actual game ran ok.

MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 9th May 2012 14:05
Quote: "as much as possible on hardware."


interesting

Seppuku Arts
Moderator
21
Years of Service
User Offline
Joined: 18th Aug 2004
Location: Cambridgeshire, England
Posted: 9th May 2012 14:57
Quote: "A game I made slowed right down in the menu with lots of 2D going on, while the actual game ran ok."


Were you using native DBP text commands? They can be a wee bit slow at times. I use Cloggy's D3Dfunc plugin, which offers faster text (and faster draw commands), also its RGB command offer alpha, which is useful. Particularly if you want a semi-transparent box for your GUI without using an image or wish to simulate a fade-in/fade-out effect.

Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 9th May 2012 15:06
If you use embossed textures instead of a normal maps you can get details that look 3D. You use Photoshop to make the emboss effect. You can also pre-calculate lighting by using a render of your model as a texture. So you texture your model with a first stage texture, then render the model in a modelling package, then use the new render as a new texture. It can now look metallic, and shiny without any shaders.

WLGfx
18
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 9th May 2012 17:54
I think everyone so far has already covered it. I'd do the same, and I have to at the moment anyway as I don't have a fast laptop to work with, but then I think that's a bonus for me when it comes to optimising for FPS rates on low-end machines.

. Low poly and medium textures max.
. Distance culling of objects. You can cheat by using fogging but also consider using the Hide Object for anything over a certain distance.
. Try avoid calculation of objects that are too far away too to keep the CPU free for handling closer objects and effects. ie. If you have you own particle engine then ignore processing those not in view, by hiding them when out of view and ignoring them on the processing loop.
. Pre-rendered light-mapping makes for faster rendering.
. Normal maps could be used if distance culling is being used as it uses the same amount of processing time approx as blending two maps as in light-mapping.
. Use all the default object functions to the max when cheating with effects. ie diffuse, emmissive, specular, transparency, alpha, etc.
. Not sure, but I guess mixing a lot of smaller objects into limbs of a main object can make a difference too.

There's probably quite a few more that you could do to squeeze frame rates too.

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
darkvee
20
Years of Service
User Offline
Joined: 18th Nov 2005
Location:
Posted: 9th May 2012 19:14 Edited at: 9th May 2012 21:41
Hi guys,

Thanks for the your help guys.

Here is somethings I think that can speed up netbook game to the max. I have a system that only shows if objects are in the players view. Which really speeds up performance. I was thinking of adding to it where it also takes away poly by poly hiding and showing.

So what you have is what I call a players field- of view streaming poly by poly system. However if you have 5,000 to 10,000 polys being updated to show or hide. It might cause a slow down.

I'm thinking of building a system that is 1 big image to store all the different textures into like tiles and it's a dxt to handle the whole game. I'm planning on using a system to convert each room to 1 limb. So it's like rendering 1 big mesh instead of say 2 or 4 meshes. Which should speed up performance.

Using lod will help too. Also I notice if your camera is to close to a object with a texture or without it boggs down your fps so make sure the camera is not to close to anything that would about cover the whole screen or make the object hide before it gets to close.

So it seems it better to send on the vertex data to the gpu on a netbook. This way the cpu is free but I dunno how much data a netbook intel gmc graphics chip can handle. I know it's 128 video ram though.

I might use a system that streams the textures in like the players field of view system. So the video card doesn't fill up with to much texture memory. If you have collisions then you can use collision maps to speed the collisions checks. That's about all I know that you can do to speed up a netbook to the max.

Anyone has any other ideas?

Here is a test fps demo that uses my player. The player only sees objects if their in fov system. See how many zombies you can have in it if it's above 30 fps. The limit is 999 zombies.

Here is the Darkvee's Fov System demo with zombies.
http://dl.dropbox.com/u/6138533/Darkvee%27s%20Fov%20System%20Demo.zip

Tell me if you think it's optimized good.

darkvee
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 9th May 2012 19:50
In my opinion, if you want to make speedy shooter fo NETbook, you should do this:

1. default vertex lighting + lighmapping
2. sprites. oh yeah, sprites! with them you can have a LOTS of enemies, like 100 or even 1000.

«It's the Shader, shader me this, shader me that»
The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 9th May 2012 20:16
Thanks for all the suggestions, everyone.
We're already applying most of the suggestions here said (lightmapped rooms with mapscape, using the visgroup system, no shaders, low poly models, darkvee's fov system, sparky's collision, low number of objects in teh scene, small texture size, etc...).

Cheers

mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 9th May 2012 20:44
Quote: "darkvee's fov system"

what's that? searched with no results.

«It's the Shader, shader me this, shader me that»
darkvee
20
Years of Service
User Offline
Joined: 18th Nov 2005
Location:
Posted: 9th May 2012 22:27 Edited at: 9th May 2012 22:28
Hi mrHandy,

The Darkvee's Fov System is homemade you can't find it anywhere on the fourms. However it is in the demo I posted.

darkvee
Adrian
22
Years of Service
User Offline
Joined: 11th Nov 2003
Location: My Living Room
Posted: 10th May 2012 01:58
I try to let the player select the level of "eye candy" they need. If they are on a slow machine, They can cut down the number of particles emitted, reduce the number of explosions, reduce the culling depth etc.

Try to only execute code when it's needed.
For example, on my shooter game, I found that I only need to update the HUD map once every 10 times around the main loop. It still gets updated 6 times per second so it's still nice and smooth, and it frees up a few extra cpu cycles.

If you are calculating the distance between you and several enemies, use vector lengths instead of square roots and pythagoras' theorm.
This is also a great way to calculate culling distances. It's quicker to check if it's out of range and not draw it than to just draw it anyway.

Use integers and not floats where you can (do you need floating point accuracy for your compass, use whole numbers instead.)

If you need to calculate Sin and Cos for whole numbers (see tip above), pre-calculate them and store in an array. Accessing this array will be quicker than doing the maths each time.

Don't use screen width()/2 if you need to Center lots of text on the screen. set a variable instead.
I use HalfScreenWidth=screen Width()/2
Do the same with screen height()
Make them Global to work inside functions.

Pre-render text as images and paste them to the screen. It's quicker than using the Text commands if you have lots to display. This is especially true if you need to change the font, colour or size.
You can also do cool alpha blending and rotations. This tends to make the game look more professional too.

Basically, you just need to keep chipping away at it. There are 100's of tiny little things you can do. It all adds up.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 10th May 2012 11:11 Edited at: 10th May 2012 11:46
I already have a working concept of this.
I plan to be releasing a WIP with a demo in about a month.


I can speak from experience there's a few key things about speed:

1. Don't Use The 2D Draw Commands.
Even a single dot on the screen can half your framerate. Use a 2D Plugin instead if you have to.

2. Break Levels Into Invisible Sections.
You can hide whole parts of the level without any calculations by knowing the camera is inside an area not visible to the others.

3. Use Timer Based Movement.
Don't forget to apply this to player controls. They need to be scaled with framerate also.

4. Use A Heart Beat.
A lot of stuff doesn't need to be checked every frame. Especially gameplay related things like taking damage in traps, etc. You can group this work into a function that is called once a second or half second etc.

5. Build An Image/Object Management System.
Instead of directly using Load Image or Load Object, have a system that manages what images/objects are loaded. So when images are loaded, the system can return the image number of the already loaded image, or clone the object and return the new object id. This vastly reduces memory usage and load times.

6. Cull Everything You Can.
Cull everything outside of the screen, and too far away. For things nearby behind walls, see advice #2.

7. Use Box Detection, Avoid SQRT() Usage.
A lot of times when comparing distances, using a box area instead of a circle is good enough. A lot of times you can compare squared distances and skip taking the square root also.

8. No Video Media.
Don't use AVI files to animate textures. Build a texture cycling system instead.

9. No Shaders.
You might want to ignore this one a little. Problem is a lot of netbooks won't be able to use your shaders. Either don't use them or include a fallback inside of a settings menu.

10. Video Settings Menu.
This is important because you need to support several resolutions, and you need a way to turn off any shaders you might be using. Things like draw distance also go here.

11. Make Mute Sound/Music Turn Them Off.
Why process sound if you can't hear it?

12. Don't Use Extra Cameras.
Anything that uses additional cameras is going to be slow.

13. Don't Process AI Every Frame.
Build the AI to keep doing what ever it's last action was. Then process some of the AI each frame. That way nothing stutters.

14. Decouple Game Loop From Display Loop.
This is more important if you have any plans of including multiplayer. You need to be able to handle things like networking more rapidly.

15. Don't Draw A Sky Indoors.
You can't see the sky anyway.

16. Reduce/Omit Distant Effects
Anything far away should be reduced or ignored completely.

17. Ignore Animating Hidden Objects And Effects.
Don't process animation for anything that is culled.

18. Load Media You Know Will Be Used.
Common objects, images, sounds should be preloaded and not streamed in when needed.

19. Build A Sound Management System.
Keep track of what sounds are used. More frequently used sounds are kept loaded and given loaded status priority. This reduces the need to load sounds during active gameplay.

20. Don't Unload What You Need When Level Changes.
Try to avoid reloading things that are already loaded. Don't keep what you don't need, or you might run out of memory. Just try your best.

21. Turn Off AI When They're Dead.
Dead people don't LOS hitscan for targets.

22. Turn Off Collisions For People You Can't See.
Do this ONLY if you can get away with it. And don't do it for anyone nearby.

23. Turn Off Collisions For People Far From Collision.
If you can figure out a quick check method eliminate the workload.

24. Turn Off Collisions For People Not Moving.
If they don't move, they can't collide with walls. This includes overriding gravity if standing on the wall.

25. Use FOG To Hide Distance Clipping.
What they can't see can't hurt them.

26. Use Dark Levels To Hide Crappy Object Detail.
It's what the professionals do.

27. Distance Clip Sounds.
If they are too far away to hear then don't process them.



These are some of the most important Speed tricks I've learned making a FPS. I could hit 100 with non-speed related advice.

Edit: Threw in some screens to spice things up.

cyril
18
Years of Service
User Offline
Joined: 6th Aug 2007
Location: 7 miles away from big ben
Posted: 11th May 2012 02:23
Wow, mage basically covered most of the points, but a good one also would be to bake faraway details into the skybox,if the area the player will play in is greatly smaller than the area that can be seen, this is very useful for speed.

Gile[s] has a built in cubemap renderer for this, Gile[s] itself is a lightmapping program. If you want to link areas that can be seen from two different location but in each location the other would normally be baked into a skybox, just link them with a indoor section and swap the skybox.
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 11th May 2012 15:19 Edited at: 11th May 2012 15:20
Quote: "26. Use Dark Levels To Hide Crappy Object Detail.
It's what the professionals do."



«It's the Shader, shader me this, shader me that»
darkvee
20
Years of Service
User Offline
Joined: 18th Nov 2005
Location:
Posted: 11th May 2012 22:16 Edited at: 11th May 2012 22:17
Wow! Mage!

Thanks for all the tricks to look for in a 3d fps shooter to gain performance.

I used a vertex animation shader to speed up the fps with rigged mdoels. However I can still see a poly count with the shader on.

How do you pass vertex data and polys to the gpu so their is no work being done on the cpu at all? Meaning if I typed in for example "tempPolys = statistic(1)" It would return a zero on polys being drawn. So the gpu is handling the render and everything.

That's so funny mrHandy. lol

darkvee
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 12th May 2012 02:33
Quote: "So the gpu is handling the render and everything"

the gpu is handlling the render and everything graphics related. What you can move froom cpu to gpu in character animation. If you have animated characters with bones you can use bone shader so animation frames don't get calculated on cpu (slow), instead they are calculated in vertex shader (fast)

Login to post a reply

Server time is: 2026-07-08 05:38:44
Your offset time is: 2026-07-08 05:38:44