Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


aerojockey

Member Since 31 Aug 2006
Offline Last Active Jul 04 2015 05:24 PM

Posts I've Made

In Topic: Memory management for 3D wide-open sandbox

01 July 2015 - 03:27 AM

There's not too much GPU memory management you can do on PC, besides just trusting the driver smile.png

 

Actually there is.  Strategy on timing of creation and deletion of data can help out the driver.

 

Fragmentation is a tricky problem; there's a trade-off with performance.  If data are allocated and deallocated all the time in arbitrary order, gaps in allocated memory can appear.  If you are able to stick a small piece of data in a gap, it makes it less likely to lead to memory fragmentation down the road.  However, tracking all those gaps makes allocation an N^2 operation with the number of allocated data chunks, which can kill performance.  Strategies like compaction can affect performance as well.  Therefore, there's typically a complex strategy to memory management that balances performance with minimizing fragmentation.  On a desktop PC which has lots of speed and memory, the algorithms do pretty well, but they might not do so well on a smaller device with less available RAM and throughput.

 

But there are things you can do to help keep it simple for the driver.  The most obvious is LIFO (last in first out), always deallocating data in the opposite order they were allocated in, which would completely eliminate gaps.  Since I can't do that any more, I am thinking of how I can still keep it kind of simple, so that when the game transitions to phones and such, there are no unexpected crashes or missing textures.


In Topic: Memory management for 3D wide-open sandbox

01 July 2015 - 03:03 AM

 


LIFO strategy is not possible

 

FIFO for the rescue ? Or more dynamic LRU cache ?

 

FIFO is no more possible as LIFO.  As a character wanders around different resources must be loaded and unloaded in arbitrary order.  FIFO might be possible on a racetrack.  I'm not sure how LRU cache would help alleviate fragmentation; my gut feeling is that it'd make it worse.  (For that matter I'm not sure how you'd implement this with OpenGL other than to start deleting old data when you get allocation errors.  But that seems like bad design.  Are there any extensions that can unload old data?  I haven't read up on them recently.)

 

I'm not sure if you caught that I was talking about GPU memory.  These strategies (like pooling) assume you have ability to freely lay out data in GPU memory, but unless you're thinking of some extensions I don't know about, GPU memory is handled by the driver.


In Topic: Joystick sign conventions

15 February 2013 - 03:30 PM

And the D-pad is usually mapped to the hat on controllers that have sticks. Take this into account too.

 

I actually just noticed this.  The game is multiplatform, and the D-Pad is considered a joystick on Linux but a D-pad on Windows.  Furthermore, the D-pad sign convention is positve up.  Nice of them to keep things simple.  Since the distinction is irrelevant to my game I'm going to make hats into honorary joysticks.


In Topic: Joystick sign conventions

15 February 2013 - 10:24 AM

It is always possible that somebody is using an obscure joystick from the 1970s with bad drivers and the axis values are reversed, but that is not normal.

 

For those people I have my "Advanced Controls Setup" option; namely editing the control settings file with a text editor.  :)  Thanks for the advice.


In Topic: OpenGL document layout recommendations?

01 January 2010 - 05:09 AM

Upon further searching I think I have a good candidate: pango. It's not a complete solution since it only lays out paragraphs (I'll have to manage higher level structures like columns and tables myself) but it manages fonts and glyphs and so on, which is the hard part. It'll render to a pixmap and I think there might be direct OpenGL rendering backends that exist. It also has a markup language, the XML subset of which is nearly (maybe wholly) powerful as the whole thing, so it will be no problem to integrate into my existing XML markup. It handles international characters as well (which I forgot to mention I'll need). And it's much, much lighter weight than webkit or gecko.

I'd still be willing to hear other suggestions though.

PARTNERS