• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Kaptein

The mystery of the spike

7 posts in this topic

I'm coding a game client, which now and then have huuuuuuge spikes

I can run around for minutes, and suddenly there's a 180ms spike for no reason at all

 

I've found where it happens, but consider this:

The area where it happens is something that runs ALOT, compiling hundreds of meshes per second

I just call it the precompiler, which prepares meshes, which is then transferred to rendering thread and "compiled" (uploaded) there

I generate the meshes in smaller chunks, which is then compiled on the rendering side to bigger based on certain criterias

This is done for obvious reasons: Time and the ability to re-use parts of the bigger structure later on enabling very fast modification of terrain

 

Anyways,

I'm sure everyone here has had their fair share of "interesting" problems with threadpools and mesh generation

Anyone have any tips for what i should look for?

 

The timing numbers are 99.8% what I'd expect them to be, within the time limit which i set out to keep myself within

Most (99%) run within the 0.0125 second mark, while 0.8% are slightly above (which is FINE, i know i can do better!)

However, there's that odd giga-spike which is ... insanely long, in the 100-200ms area

 

The threadpool I'm using is (or seems very,) professional:

http://www.hlnum.org/english/projects/tools/threadpool/doc.html

 

I schedule N jobs (mostly 1-4 depending on the preferences of the player/user), then i finish them immediately

I imagine its that latter "finish immediately" part that people will raise eyebrows at

Unfortunately for me, It's downright impossible to wait for the jobs to finish by themselves.. It simply won't work

The rest of the engine needs to be able to modify that data at ANY time in ANY way, including removing it completely

(Or even moving the data around)

 

Any ideas?

If you haven't had any problems like this before, I understand... :S
Edited by Kaptein
0

Share this post


Link to post
Share on other sites

It means I wait for all the N threads to finish, and don't continue executing code on the "physics" thread until they're completely done

I schedule 4 threads, wait for 4 threads, continue. That's the gist of it

 

I realize I probably shouldn't be doing that to begin with, but I haven't found a solution that allows me to not do that

The threads' jobs are completely self-contained, but the data they carry has meaning only if the world is the same when they're done AND during the job

 

Come to think of it, maybe i should "finish" the job after the threads are done by themselves... hmm

That way i could validate that the work they've been doing is still relevant

*sigh*

 

It still doesn't explain 200ms spike :P

0

Share this post


Link to post
Share on other sites

so you're generating meshes on the fly. i do this too. a terrain chunk is 4 ground meshes composed of 225 quads each, plus up to about 5000 instances of mesh primitives for rocks, plants, trees, etc.

 

and you split it into 4 threads to speed it up.    understandable -  i too experience a  slight delay when generating a chunk.   i was considering implementing multi-frame chunk generation  - but perhaps not,  the delay is not really that bad. too short for me to even display a quick "loading..." message! <g>.

 

and you get an intermittent  weird spike in execution time when the 4 threads are running?        all 4? always all 4?  or just some?  are you SURE the 4 are unrelated? no stalls possible?  what about outside interference from the OS or another task?

0

Share this post


Link to post
Share on other sites

Well, the spikes are happening even from the chunk loader which uses a decompressor

The decompressor itself always uses absolutely no time at all, but the "worldbuilder" as a whole sometimes has a super spike too

And all it does is file/io in a very simple manner: Read a linear segment of data from disk, decompress it, check if time to bail out is close etc.

I'm at that point where the entire engine has exits for when time runs out :)

 

I'm starting to think that it's a problem with my computer!

 

My testers are not having these gigaspikes, but they do have spikes.. regular spikes in the 20-40ms area

Precomp delta: 0.040641

the biggest one from my testers is 40ms.. thats noticeable during gameplay, and it's probably because threads are what they are :P scheduled and all that

but its not something that has my jaw dropping and sitting day & night looking at the code... :P

 

So, if the problem is my computer, then I wouldn't know where to start :P

I know enough about OSes to know that the next step would be to reinstall drivers and pray

Captain, 200ms iceberg ahead!

0

Share this post


Link to post
Share on other sites
Have you tried reading all of the data in one go or maybe bigger chunks? I'm wondering if you are getting disk seeks from other processes while you are decompressing. Causing your process to constantly have to seek back to the point in the file it left off when it goes back for more. I've found that file I/O is a get in, do the job, and get out process with no lollygagging inbetween. I could be way off base though and I wouldn't consider myself an expert on file systems.

Also, is your hard drive severely fragmented? This will cause poor performance with file I/O as well.
0

Share this post


Link to post
Share on other sites

The profiling tip was helpful, and I learned a great deal using it

Especially about inlining empty constructors :) One would think the compiler could optimize it away, but not if it could not see the implementation!

 

Anyways, the spikes were actually caused by my own OpenGL interface:

I was deleting and generating alot of objects, which does tend to cost alot of time

And after I "fixed" that part, I decided to not delete objects, but just set the size to 0.

Well, It turns out it didn't "null out" the data all the time, which caused GPU memory to grow and eventually it would get laggy again

After i consistently sat size to 0, most of my problems went away.

 

I finally fixed the empty constructor things, crossing out one thing after another on the profiler list

And I finally decided not to deallocate data I didn't use. It turns out the memory of the application didn't grow too much for me to absolutely have to do something about it

That was the final nail in the coffin for my spikes!

 

Nightmare is over :)

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0