Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


PAndersson

Member Since 14 Dec 2009
Offline Last Active Dec 22 2013 08:55 AM

Posts I've Made

In Topic: Tools for proving things for multithreaded systems

10 February 2013 - 03:30 AM

I went with this solution as it minimizes locking and ironically, the risk of deadlocks. The source of my issue is that openGL requires every task for a given openGL context to be performed in the same thread, this leads to tasks depending on other tasks for completion. Sometimes these tasks may end up in the same task queue and in the wrong order. The solution I have now simply finds out if a task waits for another in the same queue, and lets the one that is being waited for skip ahead.

 

Had the requirement to do certain tasks in a given thread not been there, task inter-dependencies would have disappeared and this problem would not be there.


In Topic: Designing an asset loading system

02 January 2013 - 05:02 PM

What's wrong with loading screens?

 

Wont really work well at all for the game I'm designing. As it is a space-strategy game with a fair bit of ground action, and as the gameplay is planned showing loading screens at any time except game startup would very much interupt the flow of the game. The planets themselves need a fair bit of detail due to the zoom allowed, enough that I cannot fit all of them inte video memory except on high-end vide cards. Fitting them all into system RAM is both trivial and required, as they affect gameplay as well as their apperance.

 

Having low-resolution versions of them, for display purposes, makes it possible to view them all at a high level of zoom. Selectily loading them into VRAM as the player zooms in on a region is fairly straighforward and any latency from that can be hidden. It is rather the sudden unanticipated need for new data (ie, some event suddenly creates a new planet somewhere and it's height and terrainmap needs to be generated with an algorithm) that would prompt the "Loading" text, and given that there will be very few instances where the game cannot predict what data it will need ahead of time the player will only very rarely see the "Loading" text at all.

 

The regular textures that represent plain images will be few in number and most fairly low in resolution.


In Topic: Designing an asset loading system

02 January 2013 - 02:38 PM

I should add that a lot of the data is algorithimcally generated at runtime, in some cases the parameters used by the fairly time-consuming algorithm is not known until the last moment.


In Topic: program performance

16 December 2012 - 05:09 AM

Always go for clear and readable code first, and only do micro-optimizations when you know for certain you need it, preferibly when your profiler tells you that it is indeed a performance bottleneck.

In Topic: How long should i study a programming language before moving on to libraries?

15 December 2012 - 06:39 PM

Also, how do i motivate myself to program every day?


Work on something that intrests you would be my suggestion, it has worked well for me at least.

PARTNERS